pen-testing, java and dotNet

Typical pentest assessments of a client-server application involve an inventory of all tcp/ip ports that are reachable over the network, usually through nmap. From the nmap output, a pentester can often identify well-known insecure services, such as tftp, ftp, telnet and more fairly quickly. Using a network sniffer, pentesters can often identify the use of less well known insecure ports in an application may be using. Once insecure ports are found, a pentester can then use network proxies to view and intercept communications from client to server, often exposing application weaknesses.

Many client applications are now written in Java or dotNet. The reason for writing in Java is to gain operating system independence. Java applications can run on Windows, Mac, Linux, FreeBSD and more. Meanwhile, the advantage of writing in dotNet is ease of application development and the ability to run the applications on standard or mobile platforms.

Applications written in Java or dotNet share something in common. They both can be returned to their original source code fairly easily. This is because application from either platform are normally compiled into an intermediate language, and can be reverse compiled back into their original source code.

WARNING: reverse compilation of an application can run against license agreements and possibly some laws, such as the DMCA. Please do not attempt to reverse compiler source code without the proper permissions. If you have any doubts, please seek the advice of a qualified attorney before decompiliing an application. (Just because you can does not mean you should!)

Thus, with client applications written in dotNet or java, pentesters have another avenue of exploration available to them, reverse compilation. Returning an application into source code can often reveal weaknesses, such as:

  • Privileges are set on the client side, not the server side.
  • Passwords hardcoded into the client application
  • The keys used to “encrypt” communications
  • and more…
  • There are two tools of note when looking to reverse compile software. For dotNet platforms, look at Lutz Roeders Reflector tool. This tool does a very good job at returning a dotNet application back into source code.

    For the java platform, the best tool that I have worked with to date is simply called Java Decompiler, or JD. For me, this has been the easiest tool for decompiling Java and returning it to source code.

    Curious to learn more? An excellent site for exercising your reverse compilation skills is the Crackmes site. This site is made for people to test out their ability to decompiler applications and find the weaknesses. Lessons learned from this site will often be immediately applicable to your next pentest assignment.

    So, how can this attack be mitigated? Please note that reverse compilation will not expose an application to security risks if privileges are assigned to authenticated sessions and the server is responsible for checking privileges on each application request.

    Imagine an application that allows administrators to change user access rights from a menu option. Since not all users of the application can change user access rights, the options are greyed out for non-admin users.

    Through decompilation, a pentester may discover a way to enable the greyed out menu options for a low privilege user. As long as the server is tracking privileges correctly, this attack won’t result in a security compromise. This attack is only a problem IF a low privilege user can change user access rights once the menu option is enabled.