DNS Rebinding, The treacherous attack it can be

Truly. An awful, awful thing to stumble upon. And luckily, most of the time you end up stumbling on it by accident, it’s not something that you find on purpose, most of the time. Granted, maybe it picks you to mess with your head, who can tell. Either way, I’ve been through that ringer, around four times… so far. Of four times, only once I actually got it to work.

This won’t be a story of how it worked until it didn’t, or something happened that caused it to stop working properly, etc. This is about how I actually got it to work, I got the results, and…. the aws instance in question didn’t belong to the bbp in question. Go figure.

What is it and how does it work:

First, why would you get into DNS rebinding attack, especially when doing bug hunting? Because you got a HTTP pingback, and bonus points the IP address resolves to aws.

But, what is DNS rebinding attack? In a simplest explanation (there are far longer and prettier visually presented essays, almost, on the subject, but this isn’t that) it is a way to trick a victim (or a headless web browser with javascript support, which is essential) to cause the attacker’s server to connect to it and then quickly to switch into a local IP address. With that “cover” attacker is able to extract internal network information that is usually blocking external IP addresses, but not the local ones. Which, in the case of aws, means that if you mask yourself as a localhost IP address then you will be able to get to the http://169.254.169.254/latest/meta-data and stuff underneath it as though you are the part of the internal network.

But, how do you get your server to trick the victim so that it appears as though it’s local IP address? Well, there are many, many tools/frameworks out there that require from you to do some adjustments like entering your vps IP address and available port(s) (usually 8080, or 8000, you get the point). The biggest problem, in all cases, as far as I have found, it does also require you to dedicate your vps to this attack until you’re either done with it, or you give up, whichever comes first because you need to stop the DNS service on your vps. What happens when you do that? In case you didn’t know, stopping DNS service like named and/or bind, makes your vps limited to communication with the outside by only allowing connections to it, and that’s pretty much it. You can’t use wget, you can’t ping anything (actually you can, but the ping will show local IP address) and similar. The only thing that you can actively use it for is to extract internal network info of the remote DNS rebind vulnerable server as soon as the victim (headless web browser) ends up triggering your DNS rebind payload (be it payload that does port scanning, aws data extraction, jenkins, IoT etc.)

Here’s the graphical simplification of this process (the code will come in time):

The Real World Attack — Part 1: Preparation

With the code/PoC with affected parties being changed/hidden.

I used the singularity, you can read about it and download the whole thing here: https://github.com/nccgroup/singularity

This is my DNS configuration on digital ocean, and the website address has been registered for free through freenom: https://www.freenom.com/ , where the nameservers are set to point to digital ocean.

This is my digital ocean DNS setup for this particular attack:

PLOT TWIST — Time for the change of how you’d expected the rest to develop because I was unable to get it working as per instructions (you may have better luck) but I still got the results.

Due to being unable to get my stuff to resolve to 127.0.0.1 at any point and thus being unable to trick the victim (headless web browser) to let me in, I went with 50–50 solution. Maybe even more like 30–70. As in 30% was my modification to receive the almost desired results (I say almost desired because I wasn’t able to use anything except the default aws path as in /latest/meta-data) to where I could read them. And 70% was the tool in its almost default mode (the default mode being the aws path as per https://github.com/nccgroup/singularity/blob/master/html/payloads/aws-metadata-exfil.js while the code that sent the output to me I had to add inside autoattack.html on my server).

Prerequisites:

1 — you need vps

2 — you need a paid webhost or freenom (you’d probably get further with a paid webhost than freenom, but for this PoC I used freenom)

3 — THE CRUCIAL REQUIREMENT — THE TARGET HAS TO SUPPORT JS

4 — (optional?) patience

First, you have to determine that the HTTP pingback (btw, in my case it was through Referer header) that you get supports javascript.

You can simply add something like the following:

<script src=//jstest.burpcollaborator.net></script>

and you can name the file index.html that way you will take care about the case where the pingback only goes for the root page. Sometimes it’s possible to go with /autoattack.html (in this case I was able to specify the page), but in most cases the safest bet is to go for index.html and then you can just use

Referer: http://yourserver.com/ and be done with it.

Now, the waiting. In order to ensure that you don’t wait for js that will never come you’ll need to either monitor the access.log or similar on your server or do one request with 1.burpcollaborator.net and then yourserver.com and then 2.burpcollaborator.net. If you get http pingbacks to 1 and 2 of burpcollaborator.net and nothing on jstest.burpcollaborator.net it may mean that it’s a no go on javascript support. And with that you have possibly avoided the likely headache of DNS rebinding attack which even if it succeeds it may still end up being out of scope for the bug bounty program in question. If it follows through with jstest.burpcollaborator.net, then I wish you luck.

The Real World Attack — Part 2: Here we go. The PoC

After I have determined that js is supported, it was time to go for it. I did have an issue with DNS server caching, which resulted in having to change the name of my freenom domain in order to go around it, but that was a quick fix.

I have downloaded the singularity and followed all the instructions to get it up and running.

I then edited various files under /root/singularity/html as per instructions

Then I tried it out, and… I ended up getting a lot of not found errors for js stuff especially. It was because the resolving of *.myserver.tk didn’t want to switch to 127.0.0.1 and therefore it was unable to access the locally hosted js files in sub folders. But, me being me, which in essence means finding ways around things, ways which aren’t ideal, but hey, it gets the job done, meant that I had to do somewhat clever editing of the code. I figured, if I could leave the default IP address inside autoattack.html while adding a block of code to send the output to my destination I wouldn’t have to worry about setting up anything beyond getting singularity up and running in its almost default mode on my server and then resolving of my freenom domain wouldn’t matter:

And then I sent this request in Repeater:

Also, the response doesn’t really matter. From my experience you may get 404 and still end up with a HTTP and/or DNS pingback days later.

And then I waited. And I waited. And I waited. And then:

The excitement that followed was me walking around my apartment, being all smug, and talking to myself “Who’s the man? I’m the man, yeah, that’s what I’m talking about” and such. It also had to do also with the fact that the bug bounty program in question was one of those that can afford enormous payouts for these sorts of bugs.

After the joy, the “I did it” type of feelings, and other tingling sensations calmed down, it was time to write the report and send it in.

And after a few back and forth messages, the bbp in question determined from the aws IP address that it wasn’t their aws instance. They believe it might have been some analytics aws that simply followed the Referer url on their (bbp’s) page and triggered the HTTP pingback from analytics end, and thus wasted a lot of my time. Well, maybe it wasn’t a complete waste of time, I learned a thing or two.

References:

These are some references and other tools that I had trouble getting to work, maybe you’ll do better, for those of you who dare risk your time, and at times nerves in pursuit of this awful, but nonetheless cool attack:

https://github.com/FSecureLABS/dref — I will say that I managed to get it working, a few years ago, had issues when I tried it out recently. But, I have also done a bunch of adjustments and whatnot to my vps configuration, especially when it comes to DNS and adding virtual hosts. Not sure if that had anything to do with it “breaking”, but figured better to provide disclaimer why I’m suggesting it here while not getting it to work recently.

https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-DNS-rebinding-ea7098a2d325

https://portswigger.net/research/cracking-the-lens-targeting-https-hidden-attack-surface — had to add this one, right :)