SecurityResearch-101

For carrying out penetration testing assessments, our main aim has been to resolve the actual domain to the loopback IP address, by adding an entry to the hosts file. Let us know consider a situation where the thick Client application does not send the request to a domain or a host name, then what happens? We are stuck since it becomes impossible to make a host file entry. Consider a thick client url like http://172.32.23.23:891/login. It cannot be mapped in hosts file without a valid pointing domain. So lets do a workaround via configuring burp with the concept of Microsoft Loopback Adapter. Prerequisites: Two machines residing in the same network ,both having Burp Suite tool running One machine (the testing machine) should have Microsoft Loopback Adapter configured. The second machine acts as a gateway that forwards the requests to the internet. The loopback adapter helps deceiving the local machine. In absence of a real domain, all the application req

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 ( https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite ) Once you download the above suite, there are multiple tools available out in to play with. Let’s launch a sample applic

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

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 applic