Memory Forensics & Reverse Engineering : Thick Client Penetration Testing – Part 4

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:

• Memory Level Protection Checks ( DEP / ASLR)
• String based analysis to find information
• Configuration File checks
• Memory inspection to find hardcoded passwords
• 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 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.

More on ASLR: https://en.wikipedia.org/wiki/Address_space_layout_randomization

More on DEP: https://en.wikipedia.org/wiki/Executable_space_protection#Windows

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.

More information here: https://msdn.microsoft.com/en-us/library/windows/desktop/mt637065(v=vs.85).aspx

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:

Memory Protection Analysis

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

Do note, even with ASLR and DEP enabled,  it still can be bypassed. ASLR does not prevent control of EIP, there are bypass exploits available to bypass the same. On the other hand DEP works using a special flag : NX / XD bit this marks parts of memory as “Non Executable” . Resultant code attempts from  processor gives rise to access violation exception and the program crashes.  However attempted  buffer overflows, can lead to potential DOS. The means of bypass for DEP revolve around using the stack to  execute the code in turn which can lead to exploit by tweaking return addresses.

We shall discuss about the advanced concepts of DEP/ ASLR Bypass and ROP chains in a advanced series under Exploit Development and Fuzzing.

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.

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

Strings exe tool

Strings analysis

1. For command line version use the following:

Strings tool Command Line

Output file will look like this:

Strings output

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:

Config Settings Hardcoded Password

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.

Config settings- File Permissions

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.

WinHex Memory Forensics

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.

Reversing Java Clients Code

Upcoming topics: DLL hijacking.