1

I am trying to setup Burp Suite so I can be tamper with HTTP requests and run security vulnerability scans against a .NET application that uses Kerberos for authentication(i.e. windows integrated authentication w/Kerberos support only). To access the app normally in IE, I add a set of credentials to Windows using Credential Manager, which then uses the credentials during authentication. I setup Burp Suite and can see requests/responses they pass through from the browser, however I cannot tamper with requests in Repeater/Scanner because Burp Suite does not update the Authorization header automatically.

I know Fiddler supports Kerberos, so my thought was to chain Burp to Fiddler. I first made sure I could get tampering to work in Fiddler (using this link as a guide). I then set Fiddler to be Burp's upstream proxy, but when I tampered with a request in Burp I still got a 401 Unauthorized when issuing requests.

Any other ideas on how I could get Burp to do Kerberos Authentication?

tifkin
  • 526
  • 6
  • 14

1 Answers1

2

If you use Fiddler's Rules > Automatically Authenticate menu option, Fiddler will automatically respond to HTTP/401 login challenges using NTLM, Digest, or Negotiate (Kerberos) using the current user's login credentials.

If the login credentials for the site are different, you need to do this:

Rules > Customize Rules. Scroll to the OnBeforeRequest method. Add the following:

if (oSession.HostnameIs("targetsite.com"))
{
  // Don't forget to use a double \\ in the string below
  oSession["X-AutoAuth"] = "domain\\user:password";
}

Fiddler will use the specified domain\user and password to respond to HTTP/401s from targetsite.com.

EricLaw
  • 56,563
  • 7
  • 151
  • 196
  • Got it working with a few more modifications. I did what you said above, ensured Fiddler was setup to decrypt the HTTPS traffic coming from Burp(Tools - Fiddler Options - HTTPS - Decrypt Traffic From All Processes), and then I had to start Burp with the commandline option -Dsun.security.ssl.allowUnsafeRenegotiation=true. I also added Fiddler's certificate to java's trusted certs, but I'm not sure if that actually did anything (see http://stackoverflow.com/questions/22569356/soapui-not-working-with-fiddler-for-rest-service-testing). – tifkin Oct 23 '14 at 13:33
  • Ok, it's only partially working, but at least it's something. The app I'm working on authenticates to multiple domains, and apparently something is going screwy with SSL in Burp. I can issue requests to one domain in Burp, but when I try to issue requests to another I get a "server certificate change is restricted during renegotiation" error. Sounds like a JVM issue, but can't tell what it is exactly yet – tifkin Oct 23 '14 at 14:20
  • "server certificate change is restricted during renegotiation" implies that the server (or your intermediaries) is returning different certificates for a single host. – EricLaw Oct 23 '14 at 18:41
  • Yeah, maybe it's fiddler then because right now the request path is Burp(repeater) -> Fiddler -> App (a.app.tld, b.app.tld, etc). From one instance of Burp I can hit a.app.tld just fine, but if I try to hit b.app.tld it fails with the renegotiation error. But if I open a new instance of Burp, I can then hit b.app.tld, but then I can no longer hit a.app.tld because of the renegotiation error. – tifkin Oct 23 '14 at 19:21