Auto login to LiveID with Burp Macros/Session
February 24, 2012 Leave a comment
A common problem when doing a web app assessment is being logged out. This sort of thing sucks. It can happen for a variety of reasons. For example, I’ve run across sites that have short timeouts, and I’ve run across sites that log you out whenever a WAF fires. In scenarios like these, it’s handy to automate the process of logging back in.
This post is about how to do that using Burp macros and session handling against Live ID. The same technique could be used against almost any website with a login (gmail, facebook, yahoo, etc.) so this really isn’t a problem with Live at all. In 2010 I wrote a burp plugin that automated this same situation, but luckily since then Burp has improved and the plugin is no longer necessary.
To clarify what I’m trying to do
For the sake of clarity, say I want to be logged in to *.live.com, no matter what. For example, an unauthenticated request to mail.live.com might look something like this.
and notice burp’s cookie jar is also empty
But it doesn’t matter. The request goes through anyway, exactly as if I were logged in in the first place.
The same thing should happen if I’ve logged out, been logged out, my session expired, etc. The same thing should happen whether I’m in repeater, scanner, intruder, etc. I just want to always be logged in.
First, the easy way
If you load this burp config file it will have everything pretty much setup to auto login to live. All you should need to do is to add your creds to the ‘mail.live.com login’ macro in request 3 where it says YOURUSER and YOURPASSWORD.
The following steps are starting from scratch, but might be useful if you’re trying the same thing elsewhere.
1. Create a macro that logs in to LiveID
This setting is under Options->Sessions->macros. Here you want to create a rule that re-logs in. I used four requests to simulate a login to hotmail, though it could be various live.com sites. The requests looked something like this:
GET / HTTP/1.1 HOST: hotmail.com
Grab all the parameters from the request 1 redirect
GET /login.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI&wreply=http:%2F%2Fmail.live.com%2Fdefault.aspx&lc=1033&id=64855&mkt=en-us&cbcxt=mai&snsc=1 HTTP/1.1 Host: login.live.com
Request 3 – you’ll notice a csrf value in the page retrieved from Request 2 (PPFT). Grab that and put it in the request.
POST /ppsecure/post.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI&wreply=http:%2F%2Fmail.live.com%2Fdefault.aspx&lc=1033&id=64855&mkt=en-us&cbcxt=mai&snsc=1&bk=1328218331 HTTP/1.1 Host: login.live.com Referer: https://login.live.com/login.srf?wa=wsignin1.0&rpsnv=11&ct=1328218303&rver=6.1.6206.0&wp=MBI&wreply=http:%2F%2Fmail.live.com%2Fdefault.aspx&lc=1033&id=64855&mkt=en-us&cbcxt=mai&snsc=1 Content-Type: application/x-www-form-urlencoded Content-Length: 464 login=yourlogin%40live.com&passwd=yourpassword&type=11&LoginOptions=3&NewUser=1&MEST=&PPSX=PassportRN&PPFT=CqTbnZVc0cSaatYmid%21*X3vaE0zlJd%21CuSvWW5KR7oo821b05kJ*q*QI86LZ%21KAITFA45s%21j9AS1hbDBJ8l*Dm6WaSaeLkqwQoalApRiYR6JDKnYED4j*mxlN5aS1SOzap5Ny2ATyi041M1nfhrnlMUFQQxem5miQ1B1wSFtsmJyJyuJ1WxnC*1D6AVXpDYoUS7vQ9z6ybDQ3Zt3MsXM*DYw2yCpt0hnsRm2RmosTXhwBLxbtfIZQWCYJJ6Pimw4yg%24%24&idsbho=1&PwdPad=&sso=&i1=1&i2=1&i3=29830&i4=&i12=1&i13=&i14=1092&i15=1506&i16=9462&i17=
Request 4, actually might not be necessary… but just follow the redirect again.
One piece here is extracting information from previous requests. To do this, configure the individual requests and create a custom parameter in the response. For example, in request 2, highlight the PPFT value and burp will take care of adding it. It should end up looking something like this:
Most the parameters can be prefilled in request 3, but the canary takes that extra step.
2. Create Session Rules that Detect if you’re logged out, and if you are, call the macro from step 1
^^ this is the redirect check
If I am logged out, I tell the session handling action to call the macro we created.
The last thing that’s necessary here is to define the scope, both in terms of the tools and the sites. For me, I added all tools to the scope other than the proxy, and live.com to the URL scope.
3. Troubleshoot using sessions tracer
One essential debugging tool is to use the session tracer. A good trace should look something like the following:
Go through the requests one by one to make sure everything goes as expected, first the detection that you’re not logged in, then the various requests necessary to login.
Anyway, it took me a bit to get this working properly, so hopefully this is helpful. Have fun!