Skip to content

Methdology

Jump to bottom
0xghostwriter edited this page Jul 20, 2020 · 12 revisions

https://resources.infosecinstitute.com/practical-thick-client-application-penetration-testing-using-damn-vulnerable-thick-client-app-part-1/#article

Initial Recon:

  • IMPORTANT: before starting anything, use regshot to take a snapshot of the registry
  • Determine what architecture the app is built under. Is it .NET or Java? - This helps determine what decompiler you could use to reverse the application.
  • Determine what hosts that the thick client application communicates with. This can be done with Wireshark or TCPView from Sysinternals.
  • Determine what files and registry keys that the application is reading and writing to. This can be done with process monitor from sysinternals suite.
  • Search through the application's installation folder for configuration files and settings. This can reveal credentials, application configuration files, xml files, etc.

=================================

Intecepting Traffic: http://securitywarrior9.blogspot.com/2017/08/traffic-analysis-for-thick-client.html

  1. Execute wireshark or EchoMirage and analyze the traffic going back and forth to the application. Identify any hosts that the application communicates with.
  2. Once you've identified all hosts that the application communicates with, you can use Burp Suite's NoPE Proxy or EchoMirage to intercept and modify requests going to that host.
  3. Once you've identified the URL (thickclient.target.com) that the application communicates with, set that host in your C:\Windows\System32\drivers\etc\hosts file like so: 127.0.0.1 thickclient.target.com. Now any requests going to thickclient.target.com will be redirect to your localhost machine.

Using socat to forward requests from a local port to destination: socat TCP-LISTEN:55505,fork TCP:10.19.55.156:55505

You can also use Burp Suite to create a listener on the port which the application intends to send data to (ex: 4514). Create a burp suite listener for burp on port 4514, and you can also configure your listener on burp to forward traffic to redirect to actual application client (See Burp's "Request Handling" tab when creating a new proxy listener).

Don't forget to enable burp's "Invisible Proxying" option. Which will have burp emulate a webserver as opposed to a traditional proxy. https://portswigger.net/support/using-burp-suites-invisible-proxy-settings-to-test-a-non-proxy-aware-thick-client-application

Traffic Interception Findings:

  • If traffic is communicated over cleartext, that is a finding. You may be able to perform MitM
  • Perform basic injection attacks, similar to OWASP top 10.

===================================

System Testing:

  • After browsing the application, compare your initial registry snapshot with your current registry snapshot. See if any registry keys changed.
  • Check memory level protections, this can be done with process explorer (Right click program > Properties > Image > DEP, ASLR, Control Flow fields. http://securitywarrior9.blogspot.com/2017/08/memory-forensics-static-testing-and.html
  • Check strings within the program. You can find usernames and sensitive data. This can be done with strings.exe from process explorer. strings.exe targetprogram.exe > output.txt This will check if there are sensitive strings that are visible during compilation.
  • Check the installation folder and look through the configuration files of the program
  • Use process monitor to check for any DLLs loaded by the target application. Then check the file permissions of the folder where the application is installed. If write access is allowed, then may be vulnerable to DLL hijacking. (Find-ProcessDLLHijack would work too)
  • Perform a memory inspection to find any sensitive strings in memory. This can be done with Memoryze (or WinHex). Use Memoryze to take an image of memory. Then use SysInternals strings.exe to find sensitive strings in memory. This technique can also be done with process hacker (process hacker > right click process > properties > memory > strings)
  • Decompile the application and inspect the application's source code. You can use ILSpy for .NET based applications. If it is a .NET application, you can also use Visual Code Review to automate code reviewing (https://github.com/nccgroup/VCG)
  • Check if the application code is signed. You can use sysinternal's sigcheck.exe to verify if it is signed or not. https://resources.infosecinstitute.com/damn-vulnerable-thick-client-app-part-8/#article

System Testing Findings:

  • Sensitive data in the registry
  • Weak memory protections
  • Sensitive data in memory (usernames, passwords, encrypted data, customer data)
  • Sensitive data discovered in configuration files.
  • If installation folder of application is writeable, possible DLL hijacking
  • Always test the installation process of the application. How is it installed? If through SMB share, check the SMB share's permissions. Can you overwrite the installation file? Can you gather sensitive files by traversing the SMB share?
  • Sensitive data/credentials discovered in application's source code.

Clone this wiki locally