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.
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:
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.
Comments
Post a Comment