During a recent web app test, I encountered a situation when I would be randomly logged out of the application when running sqlmap. I wasn’t manipulating any of the session cookies and the logouts happened at random times. I needed a way to detect when I got logged out and log back in automatically.
This particular application was an ASP.NET application and used View States extensively, including the login form. The View State information in the login page changed with each page load, so it effectively acted like several CSRF tokens. As you can see below, there are three values that changed every time the login page was loaded – _VIEWSTATE, _EVENTVALIDATION, and PageInstance.
Login View State Values
Burp’s macro recorder can handle the process of logging in automatically even when CSRF tokens are present, so I decided to proxy sqlmap’s requests through Burp. Since the View State information changed with each page load, the login macro would have to capture each of the different values. Burp’s macro recorder makes this easy and straight forward.
The macro recorder uses traffic that’s already been captured, so to create a login macro, you’ll need to load the login page and log in first. Once you’ve logged into the application, the macro recorder can be found in the Project options tab and then to the Sessions tab. At the bottom of the page is the Macros section. Select the pages that are part of the login process. In this case, I selected the login page, and the POST request where the credentials are submitted. Once you’ve selected your requests, click Ok. If other resources like scripts or images have been requested, you can delete them after pressing Ok by selecting the item and clicking Remove item.
For this particular macro I needed these two requests. The first request is the request for the login page, which contains the view state parameters submitted to the server in the second request to log in to the app. At this point, though, Burp doesn’t know anything about which specific parameters we need to capture for our macro to work. If I saved the macro now, the macro would submit the original view state parameter values over and over and I wouldn’t be able to authenticate. To configure the parameters to capture, select the first request in the macro items pane and click on Configure item.
For this macro, I want to add the cookies to the Burp’s cookie jar so I can use them in future requests from other Burp tools, so both the cookie handling options are checked. Now it’s time to configure the three view state parameters. Click the Add button to configure a new parameter. You can name the parameter whatever you want, but for easy reference I use the name of the parameter from the page. The first parameter I need to add is the _VIEWSTATE parameter, so I’ll use that for the name.
Burp has a nifty feature for defining custom parameters. As you can see below, we can manually define a start and end point for the parameter, either based on an expression, a static offset of bytes, or using a regex. Burp will automatically build the expression or regex for you. All you need to do is select the part of the response that contains your parameter value and burp will do the rest. As you can see below, I’ve selected the value of the _VIEWSTATE parameter, being sure not to include the quotes, and Burp has automatically defined a start and end point for the _VIEWSTATE parameter.
To ensure that Burp has accurately defined where this parameter lives in your request, click the refetch response button several times and inspect the response. If Burp has done it’s job correctly, only the value of the parameter will be highlighted each time. If for some reason Burp isn’t finding your parameter ever time, you can refine the expression to ensure you get it right every time. Click Ok to save this custom parameter and repeat the process to add any other parameters you need for the login macro.
After you’ve selected your requests and defined your parameters, you can test the macro by clicking the Test macro in the lower right corner of the Macro Editor. If you’ve configured everything correctly, your macro should result with you being logged into the application.
Click Ok in the bottom right side of the window to save your macro and exit the macro recorder. Next, in the Sessions tab, select the default rule from the Sessions Handling Rules menu and click Edit.
Click the Add button and select Check session is valid.
New Session Validity Check
First, check the Issue current request radio button. Second, select the location for the rule to inspect. In my case, I selected Response body to look for a specific string on the page. Third, enter the text on the page to search for. In my case, I was looking for a literal string, but a regex can be used as well. Fourth, you need to indicate whether a match indicates if the session is valid or invalid. In my case, a match indicated the session was invalid.
Session Handling Rules
Next, you’ll need to define what happens when Burp determines the session is invalid. Check the “If session is invalid, perform the action below” box, and select the macro from the list of macros.
The rest of the options can be used to further refine the behavior of the rule if necessary. In my case, I left them at their default values.
At this point, I now have a working login macro. The default session handling rule for Burp’s cookie jar only applies to the Spider, Scanner, and Repeater. Since I needed to be able to ensure I stayed logged in while running sqlmap through Burp, I needed the login macro to also apply to the Proxy. To enable this, use the Scope tab of the Session handling rule editor.
Using this login macro and session handling rule setup, I was able to successfully use sqlmap to enumerate information from the host and extract data from the database. I could just have easily used any other tool that can be configured to use a proxy with this same setup.
While I talked about using Burp’s macro recorder to create a login macro for an ASP.NET application, the macro recorder can be used for other purposes, such as automatically capturing and submitting CSRF tokens while performing an active scan. Here are a few links on using Burp’s macro recorder for login macros and dealing with CSRF tokens.
Related StoriesView More
Introduction to Sliver
By Red Siege | November 7, 2022
By: Justin Palk, Security Consultant Around the time Tim decided he was going to give a Siegecast on selecting a C2, I finished building out a test Windows AD domain […]Learn More
Moving beyond T4 – Deconstructing Nmap Tuning
By Red Siege | July 6, 2022
by Alex Norman, Senior Security Consultant Nmap -T4 -iL targets.txt This is a very common scan string that many people use to get initial recon done on assessments and, to […]Learn More
Creating a Simple Windows Domain for Offensive Testing: Part 4
By Red Siege | June 23, 2022
By: Justin Palk, Security Consultant This is part four of my series of blog posts on creating a windows domain for offensive security testing. In part 1, I stood up […]Learn More