December 16, 2012

Sqlmap plugin for BurpSuite - make it work on Windows

I was looking for a good solution to use Sqlmap in BurpSuit and found the post in bugBlog. After this great discover, I decided to check how it works on Windows.. guess what... It doesn't.

Anyway, I figured out how to make it work. The steps are:
1. Install pre-requirements: Python 2.7.x (not newer), Download latest  Burp and Sqlmap.
2. Extract sql map to folder, e.g. c:\Toolz\sqlmap
3. Download Gason (the plugin for burp) and save it in the path with the Burp.
4. Gason won't run if the Sqlmap is not binary in Windows, Therefore, download Py2Exe according to your version (Python + operating system) and install it.
5. Use Py2Exe tutorial to create binary files (store the file "" in Sqlmap folder,  and replace the name in the script from "" to "").
6. Navigate to the Sqlmap folder and run the commands from the tutorial.
7. Now the Sqlmap should be ready in the folder "dist" under Sqlmap's folder. Copy all files from "dist" to the root folder of  Sqlmap, e.g from c:\Toolz\sqlmap\dist to c:\Toolz\sqlmap.
8. Run the following command from Burp's folder: java -classpath burpsuite_pro_v1.5.jar;gason-0.9.5.jar burp.StartBurp (replace your Burp\Gason versions)

Now it should work!!

Disclaimer: if you want to use the Sqlmap to test SOAP requests by using the "-r" parameter, then it is impossible in Gason\Burp. In this case (as mine), I still should use the CLI.

December 12, 2012

Connection strings encryption (in)security

One of the most common best practices to handle connection strings security is encryption. The reason is well known - to protect from connection string disclosure in case that malicious user has access to the web.config or app.config files.
In this post, I would like to explain why it is good to encrypt connection strings, but only in specific case.

DPAPI to be protected

To make a long story short, connection strings are usually encrypted during the installation using DPAPI (Data Protection API). The command line that encrypts the data is defined below:
 The result of running the command above is illustrated in the screenshot below:

DPAPI to be unprotected

DPAPI mainly protects from user that has LOCAL access to the operating system (remote access to config files is prohibited by default in IIS). In this case, since DPAPI encrypts the data using user's\machine's store, the decryption can be executed as follows:
1. If the data encrypted in the user store, then it can be decrypted using the same user credentials.
2. If the data encrypted in the machine store, then it can be decrypted in the local operating system only. 

Henceforth, the malicious user is able to execute the following command in order to decrypt the data:
See the result below:

DPAPI is good, but only in specific case

In order to protect connection strings, it is important to understand that the protection should be based on both application settings and operating system's hardening. 
If the operating system is not hardened, the following (but not limited) bypass methods can be executed:
1. Direct access to DB server.
2. Ability to run "aspnet_regiis" to decrypt the connection string.
3. 3rd party heap inspection tools can be executed in order to see the cleartext connection string in the memory (unless it overloaded somehow to SecureString value).

Thus, I recommend to harden the operating system, specially in the authorization section. In addition, I think that using white listing application control (e.g. Bit9 Pairity) can protect against the 3rd attack from above. 

In addition, I recommend to read the nuclear solution in the code.