Skip to main content

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. 


Popular posts from this blog

Web Services/ API Penetration Testing Part - 1

Hi Readers, today we will learn about another interesting part of Penetration Testing, this revolves around Security assessments of web services.
To start with let’s take a look at what web services are made of:
A web service is software composed of standardized XML messaging system.
The benefit of web services are since all of its communication is in XML, they are not restricted to any  operating system or programming languages
They are built on Web services are built on top of open standards such as TCP/IP, HTTP, Java, HTML, and XML.
Anatomy of Web Services
In simple language, any basic web services platform is a combination of XML and HTTP. They can be of: ·SOAP (Simple Object Access Protocol)·UDDI (Universal Description, Discovery and Integration)·WSDL (Web Services Description Language)

How does a Web Service Work
Web services depends on •             XML to tag the data ( as markup and syntax) •             SOAP to transfer a message •             WSDL to describe the availabilit…

Web Services/ API Penetration Testing Part - 2

Web Services and API Penetration Testing Part #2
Welcome readers to Part 2 of Web Services Penetration Testing. In this part, we will take a quick look into the various test cases, tools and method for security testing of Web Services. Black box Web Services Penetration Testing pre-requisite: èWeb Service Description Language (WSDL) file Grey box Web Services Penetration Testing pre-requisite: èSample requests/responses for methods along with WSDL file. Stages of Penetration Testing of Web Service: 1.Information Gathering 2.Black Box 3.Google hacking (using dorks to discover web services for websites hosted over network) 4.UDDI 5.Web Service Discovery (If no WSDL provided) 6.Authentication Type Discovery Testing Methodology: èAutomated Testing Tools ·SoapUI Pro ·OWASP ZAP ·IBM AppScan ·HP Webinspect ·WSBang ·WSMap
èManual Testing Tools ·Soap UI Free ·Burp Suite Pro ·Postman ( with burp) èExtensions: ·SAML Editor ·SAML Encoder / Decoder

Arbitrary file upload and RCE in Wonder CMS - CVE-2017-14521

By- Samrat Das

Hi Readers

Recently in one of my pentest research, I found a CMS " WonderCMS" hosted in github.
Curious to explore its functionalities, I downloaded and set it up in my local system.

After fiddling with the source code, I found that it did not have any kind of file upload security mechanism and allowed the user to upload any file type! After reporting it to them, I did not receive any security relevant response, hence decided to publish a blog on this.

Title of the Vulnerability:  Arbitrary File Upload Vulnerability Class: Security Misconfiguration Technical Details & Description: The application source code is coded in a way which allows arbitrary file extensions to be uploaded. This leads to uploading of remote shells/ malicious Trojans which can lead to complete system compromise and server takeover. CVE ID allocated:  CVE-2017-14521 Product & Service Introduction: Wonder CMS 2.3.1 WonderCMS is an open source CMS (Content Management System) built with P…