11/21/17

Thick Client Penetration Testing – Exploiting JAVA Deserialization Vulnerability for Remote Code Execution

Thick Client? What do you mean by that?

Thick client is the kind of application which is installed on the client side and major of its processing is done at the client side only which is independent of the server. Like we installed some players or .EXE files in our windows system.

Main difference between Thin Client and Thick Client

Thin client is the browser based application which is having database (server) only in the back end & there is no need to install thin client applications at the client side. Also they are lightweight and do not occupy more space at the client system, whereas Thick client needs more storage space in order to install it on client side.

What is Java Serialization?

Java serialization offers an object to convert itself into a stream of bytes that includes object data to store it into the file systems or to transfer it to another remote system.

After serialize input (stream of bytes) is written to a file, it can be read from the file after deserialization process like stream of bytes then converted to the object again into the memory.

Classes ObjectInputStream and ObjectOutputStream are high level streams that contain the methods of serialization and deserialization.

Why it is vulnerable?

The Apache Commons Collection (ACC) Library is the main reason behind the successful RCE attack. This library has the dangerous class InvokerTransformer which an attacker abused to gain access to remote system.

The InvokerTransformer’s goal is to transform objects in a collection by invoking a method. Attackers take advantage of this functionality and manage to call any method they want.

To create malicious method attacker uses readily available tool called ysoserial

Here is the link to the tool: https://github.com/frohoff/ysoserial

The attack can be summarized as:

  1. A vulnerable application(Thick Client) accepts user supplied serialized objects
  2. An attacker creates malicious payload into stream of bytes (serialization process) to invoke any class/method they want and sends it to application.
  3. Then the application reads the stream of bytes and tries to construct the object from it(Deserialization process)
  4. During deserialization the malicious payload gets executed on target system resulting into compromised system.

 

How to Perform this Attack?

Step 1: First we should know what is the IP and Port the Thick client is communicating to, in order to intercept the request/response using burp suite.

In cmd ping the thick client URL to know the IP.

In our case lets the assume the URL for thick client is http://thickclient:8081 and after pinging this URL we got the IP 192.168.0.1 and port is 8081

Make the changes in the burp proxy

 

Step 2: Edit the host file in your system so that the server host (http://thickclient:8081 in our case) points to local host and our burp proxy can intercept the request.

 

Step 3: Run the thick client and intercept the request in burp

 

Step 4: Now, we will replace this serialized data with our malicious serialized data, which will be de serialized server side and our command will be executed. For this purpose we will use a tool called ysoserial (download: https://github.com/frohoff/ysoserial)

Run this tool with following syntax and create our malicious serialized payload (the IP should be your system IP and port I am using here is 4444)

The output will be somewhat like below

 

Step 5: Now on another side listen to incoming connection from server where our malicious data will get execute. We are using netcat tool for this. You can get this tool here: https://nmap.org/download.html

 

Step 6: Now our payload is created in a file (test.out in my case), we will use Burps ‘paste from file’ option to paste our malicious payload in the intercepted login request as follows and will then execute our malicious data.

 

Step 7: Now to check whether our command got executed or not on the server, netcat to the connection and you can see in below screenshot that we got incoming connection form the server, meaning our malicious code get executed on the server.

 

Further Reading:

  1. https://www.owasp.org/index.php/Deserialization_of_untrusted_data
  2. https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr
  3. https://www.synopsys.com/content/dam/synopsys/sig-assets/whitepapers/exploiting-the-java-deserialization-vulnerability.pdf

 

Author
Pranav Jagtap.

Attack & PenTest Team,

Varutra Consulting

11/6/17

What Makes Penetration Testing Impactful – Post Exploitation

As a penetration tester, we often come across this riddle – What Makes Penetration Testing Really Impactful. As per penetration testing methodology – we identify vulnerability, prioritize the vulnerability considering the criticality of impacted assets, we obtain/modify/create an exploit, compromise the target system and we are all excited and happy. BUT, ‘whoami’ command output in a black screen may not mean anything to C-Suite executives, who have never opened the command prompt, or rather not need to.

So how do you explain C-suite executives the consequences/impact of the exploit which you just performed?

Here comes a skillset to our rescue – Relevant Post Exploitation.

  • First understand your client, their nature of the business, their clients and criticality of data etc.
  • Prioritize identified vulnerabilities and exploits to target important assets
  • Obtain/ex-filtrate the information which matters to them most
  • And they will be like WOW

To explain my point, I will walk you through some of my personal experiences in my journey as a penetration tester.

Example 1. 

TL;DR: Test Server -> Apache Exploit -> In-House App  -> Hardcoded DB Credentials -> Central Database Compromise

In one of my earlier engagement, automated scanner identified an instance of open apache manager console and I tried Metasploit for exploitation but observed that anti-virus installed in target machine was deleting Metasploit payload. So I switched to manual method and successfully compromised the server. Hence concluded that engagement is successful, until, client destroyed my enthusiasm saying that it’s a test machine with not much of IMPORTANCE.

Open Apache Tomcat Manager Console

Upload Of Backdoor JSP File

Code for Backdoor JSP

Proof-of-Concept of Exploitation

I had no intention of letting that issue go, so I attacked that machine again with a very definitive purpose – Obtain something critical and/or sensitive.

I created a dummy user with LOCAL ADMINISTRATIVE privileges, started the RDP and logged in using RDP just to make my life easy, relatively

Creation of Dummy User – TestUser

RDP Connection To Target System

I realised there is an in-house application in documents directory (.jar file). Out of curiosity, I just ran it, and it seemed to be data entry application. While I was doing a blind exploration in the application, a message box popped up stating that ‘Read all the entries from database successfully’. Interestingly, the application didn’t ask for any DB credentials at all.

Then, naturally, I opened the application in jd-gui and DB credentials were hard-coded in the application and to my utmost surprise, it was the credentials for central DB of the organization.

Hard-Coded DB Credentials

I used that credentials to login into DB and I was able to access almost all (read all) information about the organization, details of which I can’t mention here for obvious reasons.

Bottom line – Engagement become successful then, from client point-of-view and it made the life of developer of mentioned application [very] difficult.

 

Example 2.

TL;DR: Kiosk Device ->Windows XP -> MS08-067 -> Pass-the-Hash -> Entire Network -> (Very) Important Person Desktop Screenshot

In another one of my engagement, automated scanner identified that Windows XP machine is running in client environment and our favourite MS08-067 popped me a reverse Meterpreter shell with relative ease, but again, it turns out to be Kiosk Device and client were not very interested in the compromise

Proof-of-Concept of Exploitation

This time I explored the entire system but didn’t identify anything significant. Then I took a different route – Pass-the-Hash attack. I dumped the password hashes using Meterpreter and used smbexec (awesome tool) to escalate/replicate my attack to the entire network.

Identification of Domain Admin User

Replicate of Attack to Entire Network

Example 3.

TL;DR: McAfee ePO Server -> JBoss JMX Console Deployer Upload and Execute -> Combined with McAfee Weak Encryption Vulnerability -> McAfee ePO Server Password Compromised

This compromise was relatively simple. First automated scanner identified an open JBoss JMX console and then, I was able to obtain a Meterpreter reverse shell using the Metasploit exploit module – JBoss JMX Deployer Upload and Execute.

Proof-of-Concept of Exploitation

 

After a bit of reconnaissance, I realized it was an ePO server installed with vulnerable version – ePO 4.6. A ready to use post exploitation module of Metasploit – epo_sql, fetched the ePO server credentials for me.

epo_sql Metasploit Module in Action

So, in above scenarios, by aligning post-exploitation techniques to client requirement and with a ‘dig deeper’ approach, I represented technical vulnerabilities into the form of business risk. Effective post exploitation makes the client understand the implications from the business perspective and helps them to prioritize the mitigation strategy.

In conclusion, I would like to say that relevant post exploitation is very crucial for a penetration testing engagement, especially when the client is more emphasizing on measuring the risk not counting the vulnerabilities. There are numerous other ways and tools for making post exploitation a real fun.

Further reading

 

Author
Pramod Rana

Attack & PenTest Team,

Varutra Consulting