Burp Suite Visual Aids

Friday, April 24, 2015

The reason I began blogging years ago was to keep notes on things I wanted for future reference while sharing it with others and making it mildly entertaining to read. I've not done much of that here recently, as I've been trying to do it with 140 characters and screen shots. While this has worked well in the short term, the problem with Twitter is that tweets don't last forever. After a few months a tweet can be hard to access, and I've found it becoming increasingly difficult to redirect people to some of my aging tweets. Therefore, I decided to move a few of my more useful tweets here for historical record. Specifically, several tweets related to Burp Suite Pro.

SSL Stripping Configuration


Do this before visiting the website. After making the configuration change, type the target URL without the protocol into the address bar and hit enter. If the target is vulnerable, Burp will strip the SSL and render the page over an unencrypted session. At this point, I typically click on the address bar where the lock, etc. would normally be and take a screen shot of the message stating that the page is not protected.

Scan Defined Insertion Points


For scanning, I use this almost exclusively. This provides a lot of control over what gets scanned and allows for scanning all parts of the protocol.

Disable Intercept by Default


Don't lie... you've sat there staring at your browser, wondering why the application wasn't responding. Then, after 10 minutes of troubleshooting, you realized that the Intercept tab was glowing orange in the background. Yeah, we've all been there. Burp finally solved that problem.

Filter Out the Noise


Did you know that Burp has a filter for what is displayed in the Targets, HTTP history, and Websockets history tabs? If not, it's probably because the button that opens the filter is poorly styled for its position in the interface. No worries, here's how you access the filter. This is extremely useful for filtering out unimportant content-types and out-of-scope requests/responses.

Session Fixation Demystified

Wednesday, October 29, 2014

I've recently been approached by quite a few junior consultants having issues with understanding, discovering, and exploiting Session Fixation. Rather than continue to provide impromptu training, I decided to brain dump everything I know about Session Fixation into an article for reference.

While not as sexy as many of the other vulnerabilities we deal with in Application Security, Session Fixation is quite common and exposes applications and users to substantial risk. I see Session Fixation behavior in approximately 60% of the applications I test, with it being exploitable in approximately a quarter of those instances.

Session Fixation Defined

Session Fixation is a vulnerability that allows an attacker to predetermine the session token value of a victim. Like Session Hijacking, Session Fixation allows the attacker to assume the identity of the victim user in the context of the application. The root cause of Session Fixation is when an application does not provide a new session identifier, or token, upon successful authentication. In many cases, application's unnecessarily issue session tokens prior to authentication. In other cases, application's contain core business functionality in the pre-authentication pages that require an active session (e-commerce). These 2 conditions, if not handled properly, can result in Session Fixation.

Let's use Amazon as an example. When a user goes to Amazon.com, they can shop the catalogue of items and add items to their shopping cart prior to authenticating. In order for Amazon to maintain state with the user, Amazon must create a session to manage the user's data and issue a token to the user's browser. When the user decides to purchase the items they have added to their unauthenticated shopping cart, they must authenticate to Amazon. This is the important part. When the user successfully authenticates, Amazon must take all of the information associated with the user's unauthenticated session and associate it with a new session. Amazon must then expire the old session token, and replace it with the token associated with the new session. If Amazon does not create a new session upon successful authentication, then theoretically, an attacker could go to Amazon first, be issued a session token for a valid unauthenticated session with the application, fixate that session into a victim's browser, and wait for the victim to log in. After the victim logs in with the attackers fixated session, all the attacker has to do is refresh their browser and they will be authenticated as the victim.

Discovering Session Fixation

Determining if an application is susceptible to Session Fixation is easily accomplished with the following steps.

  1. Map the unauthenticated portion of the application.
  2. Determine if a session cookie has been set in the browser. This can be done by looking at the Set-Cookie headers generated through mapping, using the browser's Developer Tools to view cookies associated with the current domain, or by looking at the Cookie header sent with the most recent request.
  3. If a session token exists, note the value.
  4. Authenticate to the application.
  5. Compare the post-authenticated session token to the pre-authenticated session token. If they are the same, Session Fixation exists.

Regardless of exploitability, which we'll discuss shortly, I consider the existence of Session Fixation behavior to be a low risk finding because it shows failure to design a Session Management system according to security best practices.

Exploiting Session Fixation

If you are the inquisitive type, then you immediately picked up on the statement, "...fixate that session into a victim's browser..." in the Amazon scenario above and said to yourself, "How do you do that?". Good question. This is the second, and more difficult, part of Session Fixation. The previously discussed behavior means that the potential for Session Fixation exists, but exploitability is still in question. In order to exploit Session Fixation, one of several conditions must exist.

  • Cookieless sessions used for session management.
  • Cross-Site Scripting (XSS) in the unauthenticated portion of the application.
  • XSS in another application on the same domain.

Cookieless Sessions

Cookieless sessions are sessions that are managed by a token that is passed in some form other than a cookie. This means that the session token is passed between the client and server as a parameter in the URL, a parameter in the POST payload, or embedded in the URL. Below is an example of a .NET cookieless session. .NET rewrites each URL on the page to include the session token.


There are several reasons for using cookieless sessions. Cookieless sessions allow for multiple sessions with the same browser instance. Have you ever tried to log into a cookie based application on 2 different tabs with 2 different accounts in the same browser instance? It doesn't work in most cases. It is difficult for an application to allow for multiple simultaneous sessions when using Cookies. Cookieless sessions allow for it seamlessly. Cookieless sessions also allow for session management in browsers that don't support cookies. Nowadays cookie support shouldn't be an issue, but you never know what kind of technical restrictions your client may be operating under.

The problem with cookieless sessions is that they provide the potential for several vulnerabilities. They can result in Information Disclosure as they may allow the session token to be disclosed in logs, Referer headers, proxies, and caches. They also allow Session Fixation to be exploited by providing a mechanism for an attacker to fixate a session into a victim's browser. Let's revisit the Amazon example and pretend that Amazon uses cookieless sessions where the session token is embedded in the URL, and does not issue new session tokens upon successful authentication. An attacker can go to Amazon and be issued a valid unauthenticated session token. The attacker can then craft a link to Amazon with the valid session token embedded in the URL and send it to the victim as part of a Social Engineering attack. The victim opens the link, sees that they are not authenticated to Amazon, and authenticates. The attacker refreshes his browser and assumes the identity of the victim in the context of the application. The ability to dictate the session token value through a request parameter or URL makes exploiting Session Fixation trivial.

I consider Session Fixation that is exploitable via cookieless sessions a high risk finding as it is extremely easy to exploit, requiring only the click of a link, and provides a likely vector of attack for privilege escalation.

Cross-Site Scripting (XSS)

The Document Object Model (DOM) within the browser allows for cookies to be created and overwritten with JavaScript. If XSS exists somewhere in the application prior to authentication, then JavaScript can be used to overwrite the current session token cookie with an attacker's predetermined session token. One catch with this attack vector is that if the current session token cookie was created using the HttpOnly flag, then the cookie will not be accessible through the DOM and cannot be overwritten. However, XSS on another application within the same domain may bypass this restriction. More on this in a moment. META tags are another option for overwriting cookies where HTML injection is possible. Below are examples of injection payloads that create or overwrite a browser cookie.

  • JavaScript
<script>document.cookie='SESSION_ID=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=google.com; path=/'</script>
  • HTML Injection
<meta http-equiv=Set-Cookie content="SESSION_ID=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=google.com; path=/">

An application won't arbitrarily issue a new session token if a session token already exists. Therefore, an attacker may be able to use a XSS vulnerability in another application on the same domain to create the cookie for the target application before the victim visits the site and is issued a HttpOnly flagged session token cookie. This is possible because any host within a domain can create cookies that will be passed to the root domain and any host associated with it. I tested this functionality with Google using Chrome's Developer Tools and JavaScript Console.

First, I added an arbitrary cookie to the DOM of the application running on mail.google.com to simulate writing a cookie via XSS.

I then visited the root Google domain and several other hosts on the Google domain. The created cookie was passed along to each resource.

This behavior allows us to bypass the HttpOnly restriction and fixate sessions on applications in the same domain via XSS.

I consider Session Fixation that is exploitable via XSS to be a medium risk finding as it still provides a likely vector of attack for privilege escalation, but requires another vulnerability to exploit. The XSS flaw is obviously rated separately and will probably receive the higher risk rating.

Preventing Session Fixation

Preventing Session Fixation is simple. If no pre-authenticated session is required, do not issue session tokens until successful authentication has occurred. If a pre-authentication session is required, always issue new session tokens upon successful authentication. This can be done several ways. The first option focuses on the session token itself. Create a new session token, associate the new session token with the existing session, disassociate the old session token, pass the new session token to the client. The second option focuses on the entire session. Create a new session, copy all of the session data from the old session to the new session, destroy the old session, pass the token associated with the new session to the client.


I'm certain that there are other ways to exploit (header injection via network attack) and prevent (anomaly detection) Session Fixation, but the approaches I mention here are the simplest and most common based on my experience as an Application Security consultant. I encourage you to continue researching the topic. I leave you with this flow chart for discovering and assigning risk ratings to Session Fixation vulnerabilities. I hope you find it useful. Enjoy!

WUDS: Wi-Fi User Detection System

Thursday, October 2, 2014

Several weeks ago I attended BSides Augusta. If you haven't been to the Augusta version of Security BSides, you're missing out. I've been attending BSides conferences for several years, and none have come close to the atmosphere, quality, and comfort of BSides Augusta. It's a classy deal all around in a city that supports it's InfoSec community. Well done Augusta.



I attended a BSides Augusta presentation by Tim Fowler (@roobixx) called When Zombies take to the Airwaves. During the talk, Tim discusses some really innovative ways that humanity could use Wi-Fi to track zombie population movement and communicate emergency instructions in a post apocalyptic environment. As Tim was speaking about using Wi-Fi probe requests to track infected cell phone carriers, the guy next to me, Ryan Wilson (@RyanWilson57), says something along the lines of, "You could use that same concept to alert you when zombies were approaching your house." And the idea for WUDS was born. Ryan also later named the tool. Thanks Ryan!

Technical Approach

Wi-Fi probe requests are a great source of information from which to detect the proximity of Personal Electronic Device (PED) users. Just about everyone nowadays carries a mobile phone, which is essentially a handheld computer with multiple means of data transmission. One means of transmission, which is enabled by default and rarely ever disabled, is Wi-Fi. Most of my readers are aware of this, but many people don't know that when a Wi-Fi connected device user walks out of range of a connected Access Point (AP), the device's Wi-Fi adapter begins to make probe requests, looking for APs that have been previously connected.

The application of this technology in a physical security context is simple. The combination of a white list of unique identifiers for devices that belong in the area (MAC addresses) and signal strength (RSSI) can be used to create a protected zone. With tuning, this creates a circular detection barrier that, when crossed, can trigger any number of alert systems. WUDS includes an SMS alert module, but the sky is the limit.

Now, when I say everyone carries a mobile phone, that includes criminals. In addition to alerting on the presence of foreign Wi-Fi devices, WUDS logs time stamps and probe request packet data. Having the time stamp and MAC address for all devices in an area during criminal activity can be quite useful. Law enforcement can take a MAC address to the cellular SP where the owner of the device can be identified. And not only can the MAC be used against a perpetrator, but probe requests also contain the ESSIDs of the networks that have been previously connected. Therefore, if a probe request is seen with the SSID of "Bag-Guy Wi-Fi", something like Wigle can be used to geolocate that SSID and provide additional attribution. Good luck avoiding arrest and prosecution when I can place your device at the scene of the crime during the time that the crime took place and prove that it was your phone through ISP records and a PushPin dropped on your house. Pwned.


Applying this concept in a densely populated area has it's challenges, as the white list and RSSI threshold must be highly tuned. In a rural area, similar to where I live, the system functions spectacularly. I accidentally left the system on the other day after I had been doing some testing the night before. In the middle of the afternoon the following day, an SMS message came through to my phone notifying me that someone had crossed my detection barrier. I was about to write it off as a false positive when the doorbell rang. It was a delivery service dropping off a package.

For my particular setup, I decided to use a Raspberry Pi as my WUDS server; the same Raspberry Pi that controls my whole home audio system. The wireless card I use is an ALFA AWUS036H connected via USB.

Guidance for installing and configuring WUDS is posted in the repository. A link to the repository can be found over on the Projects page.

Implementation Issues

For those that like looking at code, you'll notice that I am NOT using Scapy to sniff for Wi-Fi probes. Originally, I had been using Scapy, but was experiencing 100% CPU utilization while the system was running. I spent quite a bit of time trying to resolve the issue when I determined that using a raw socket and parsing the Wi-Fi packets myself would probably be a better approach. As it turns out, I was able to write my own parser using primarily builtin Python modules. For those that know me, you know that I really dislike relying on 3rd party dependencies, so this pleased me. Plus, it allowed me to avoid installing Scapy and all of it's dependences. The custom parser uses less than 1% CPU utilization on average. That is quite an improvement over Scapy.

I owe Joff Thyer (@joff_thyer) a shout out for pointing me towards Pcapy. At one point, I was having some difficulty inspecting the 802.11 frames at a deep enough level using raw sockets. Pcapy allowed me to gain deeper insight into the 802.11 frames and ultimately fix some of the issues I was having. Thanks Joff!


Here are some other resources that helped along the way.

Update 10/6/14

I've had a few folks report an issue with WUDS where the sensor is picking up probes that have a 0 RSSI, MAC addresses with a sequential first octet, and a garbled SSID. One of the users reported that commenting out the following line in the /etc/network/interfaces file fixed the issue on the Raspberry Pi.

pre-up wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

Apparently, wpa_supplicant is putting the wireless interface in a client state that is causing the issue. Killing the wpa_supplicant process fixes the issue temporarily. A permanent fix would be to make the above edit.