Using Burp Suite’s Collaborator to Find the True IP Address for a .Onion Hidden Service

On this Thanksgiving day I’m going to write about something near and dear to all our hearts: stuffing. I’m not talking about the delicious pile of bread you’ll have on your plate this afternoon, I’m talking about stuffing payloads into websites to look for vulnerabilities.

We stuff things into web sites all the time. We stuff ‘ or 1-1 ; — and hope for SQL injection, we stuff ; cat /etc/passwd and hope for command injection, we stuff alert(“BEEP!!!”) and hope for cross site scripting and we stuff our credit card number in and hope that this is an authentic Tribble from the 1967 Star Trek episode.

Sometimes we receive instant feedback on our payloads and can confirm a vulnerability in seconds. If I put in ‘ or 1=1; — and bypass a login screen, I can break out my SQL injection dance then and there. The problem comes when you’re injecting your payload somewhere with a delayed response. What if the payload I fire at a website right now doesn’t get executed until an admin is looking at the logs Monday morning? If we want to be able to detect the payload working, we need to set up persistent infrastructure to listen 24 hours a day.

Burp Suite made this MUCH easier when they launched “Burp Collaborator” in 2015. Collaborator, which is included with Burp Suite Professional at no additional cost, is a server set up to listen 24 hours a day, 365 days a year for your payloads to fire back to it.

In the screenshot above, I can click “copy to clipboard” and generate a unique URL that I can utilize in any payload I want.

If anyone or anything looks the URL up or visits it, I will get a notification back in my Burp Suite collaborator client.

This is amazing and unbelievably powerful. We now have the infrastructure in place to generate payloads and listen for them no matter how long of a delay we’re dealing with. As the official Burp Suite twitter feed said earlier this week, if you’re not doing Out-of-band Application Security Testing (OAST), you’re doing it wrong.

Ok, now that we’re all excited about this and see how easy it is, where do you think we should stuff our new payloads? If you excitedly said “EVERYWHERE!!!!”, I like your style and agree with you!!! Fortunately, a brilliant guy named James Kettle agreed with you too and wrote a Burp Suite Professional plugin called “Collaborator Everywhere” earlier this year. The author wrote a fantastic blog post called “Cracking the Lens: Targeting HTTP’s Hidden Attack-Surface” where he introduced the world to his plugin. My friend Kat sent me a link to it during Blackhat and I sat at an outdoor bar in Las Vegas and read it on my phone from start to finish. I’m that much of a nerd and it was that good.

Collaborator Everywhere wants to help us identify back end systems and processes by automatically injecting these collaborator payloads into our web surfing done through Burp Suite. What does it actually do? Check out some of these headers it automatically inserted when I just visited my blog.

Visiting a particular site with that I got a DNS lookup from one of my payload injections:

 

 

 

 

 

 

 

 

James did a Blackhat talk you can watch here where he talks about all of the great work he’s done using these techniques. While I was watching the talk, I thought that this technique could potentially be utilized to identify the true IP address of a TOR .onion hidden service.

I fired up my TOR browser bundle and configured Burp Suite to go through TOR. I then surfed to multiple .onion hidden services to see if any of them would give me a collaborator pingback. Finally on about the twentieth site I visited, it worked 🙂

I now had the true IP address for a server associated to an .onion hidden service due to it looking up a header it was fed.

I encourage you to use these techniques on websites which you own or legally have permission to test. They’re easy to use, fun and extremely effective.

 

11/24/2017 Update:

The tweet I sent out announcing this got quite popular and led to a great sidebar conversation among several people including , and . One of the key points of the thread was that this pingback is from the DNS resolver which may be located very close to the host server, but not necessarily so. The thought was in my head which is why I used the phrase “associated to” instead of “hosting” but it absolutely warrants increased clarity.

Feedback like this is part of what makes the infosec community the amazing place that it is 🙂 My goal was never to publicly out anyone’s .onion service which is why I sanitized all my screenshots but in this case, based on the site’s content, the resolver IP address was inline with what I would expect for a hosting location and I believe it was very close to the host server.

Resources to Help Identify Password Hash Formats

One question that I get asked a lot when I’m teaching the password cracking section in the SANS SEC504 class is “Once I get a password hash, how do I figure out what type of hash it is?” I mention a few resources in class but thought it would be worthwhile to put together a quick write-up to help past and future students after the class.

The first thing I always mention is that you will likely know exactly what type of hash it is based off how you acquired it. If you use meterpreter to dump hashes from a Windows system, grab the hashes from an /etc/shadow file or capture a hash using Responder, you know exactly what type of hash it is based on the method you used to capture it. If you obtained the hash from an encrypted file as I discussed in this blog post on the SANS pen test blog, you know exactly what type of hash it is.

With that out of the way, let’s talk about what to do when you’re not sure what type of hash it is.

Option 1: Have a program identify the hash for you

Some password cracking programs like John the Ripper will try to identify the hashes you ask it to crack for you, but it’s not always right.

Another option is called HashTag and is available here. HashTag is a python program that can look at a single hash or a text file full of hashes and attempt to identify them for you. It will generate a list of the hashes it found and what it thinks they could be.

It appears to detect 269 different hash formats and even includes a handy excel spreadsheet of those formats complete with examples.

Option 2: Check the Wiki that Hashcat maintains for examples

When you’re trying to figure out what a hash it’s, it’s always import to ask yourself what seems likely. If the hashes come from SQL injection attack against a custom web app running on an Apache server, LanMan hashes seem highly unlikely. In that scenario, options like md5 would be much more likely.

If you have an idea of what the hash might be, Hashcat maintains a fantastic wiki of example password hashes for different formats at: https://hashcat.net/wiki/doku.php?id=example_hashes

Option 3: Ask for help

Hashcat maintains a fairly active forum at https://hashcat.net/forum/. You ARE NOT allowed to post hashes in the forum (doing so is grounds for getting banned), but if you sanitize the hash you can post it, provide what details you can about the source, and ask if anyone has advice on what it is and how to deal with it. I’ve seen veterans go the extra mile on edge cases where things like a custom salt encoding were used.

Summary:

As I stated in the beginning, we usually have a really good idea of what the format of a hash is. If the hashes come from a custom web app or some other obscure source, we now have a few resources we can check so that we can correctly identify them, and more importantly, start cracking them 🙂