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 into eBay 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 @cchuatl, @albinowax and @einaros . 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.