20 July 2008
If you're not a US resident, you know how annoying the Internet can be sometimes. All those "US only" sites really manage to get under my skin. Especially when it's the really good ones that block access, like Pandora or Hulu, for example.
The obvious answer to the problem is a proxy. Yet, free proxies tend to be really slow. They certainly do not fit a purpose such as streaming audio or video. There are paid solutions, but if paying for a proxy/tunnel/VPN is out of the question for you, today is your lucky day.
All you need is a free php hosting provider and 2 scripts. One script resides on your free hosting, and one on your local system. The only catch is that the host mustn't block functions like fsockopen(), otherwise proxying would be impossible. Luckily, from what I've seen, most hosts don't block it.
The script on the host is a regular php file. It forwards HTTP requests via a socket to the destination host, and outputs the response.
The client script is written in perl. It acts as an HTTP server on a local port of your machine (don't forget to firewall it). Then, it forwards the incoming requests from your browser to the php script, and does a similar thing for the response. The upstream is encapsulated in multipart/form-data POST requests, allowing binary data to be transfered without encoding it.
Please note, however, that this sort of usage will most likely violate your host's TOS. It's only a matter of time until they ban you. Then again, they are probably abused by worse things all the time.
Your bandwidth is obviously capped by what the free hosting package lets you have, but you could register many accounts with multiple hosts.
On the upside, the speed this proxy gives you is incredible. A quick speed test has shown me that I was downloading as fast as my connection would allow. Some downloads can actually be FASTER with the proxy, based on the geographical location of the host.
Ping times are a bit high though, in the 500ms range (the host is half-way around the world for me), but this is barely noticeable.
Most importantly, is that if your free host is based in the US, you'll have full access to "US only" content. I'm using Pandora with this, and it works great. Hulu doesn't work for some reason, but it's a temporary bug that I'm hoping to fix.
File uploads also don't seem to work, but I'll try to fix this as well.
Finally, here are the scripts:
proxy.php - This goes to the free hosting account
proxy.pl - This runs on your machine
Usage:
1) Change $authToken in both scripts to the same secret value. This will prevent others from using your proxy.
2) Alter the $proxyServ and $proxyPath values in proxy.pl so they link to the proxy.php file correctly. $localPort can be arbitrary and defaults to 13268 (make sure it's not taken, though).
3) Run the proxy.pl script in the background when you want to use your proxy.
4) Set up your browser's HTTP proxy to 127.0.0.1:13268. This is the default address the script will listen on.
Enjoy!
P.S.
Don't forget that the admins of the host you're proxying through can be bad people too :)
Posted by: kGen | In category: Free code | Comments (2)
30 June 2008
It's my fault this thing won't work on IE as planned.
Apparently, IE doesn't allow "third party cookies" by default. For instance, cookies that are set by an image that is hosted on another domain.
So if I put the following code on this blog page:
<img src="http://own-the.net/setcookie.php">
The "image" will be able to set cookies on own-the.net.
But if I call something from another domain:
<img src="http://other-domain.com/setcookie.php">
It won't be able to set cookies on other-domain.com. (And obviously not on own-the.net)
So it happens, that my DNS rebinding demo relies on a cookie set by an image on another domain. Thus, in it's current state, the demo won't work on IE.
However, this is not critical. The cookie is just used for some "internal business" of the demo. It's very much possible to rewrite the thing to work without it. I just don't know when I'll do it, though.
Posted by: kGen | In category: DNS | Comments (0)
27 June 2008
It took me longer than I expected, but I finally made it work.
In short, this proof of concept uses the browser cache along with DNS Rebinding in order to circumvent the Same Origin Policy of the XMLHttpRequest object. After a successful execution of the attack, this PoC reads the HTML from http://127.0.0.1:80/ on your machine. If you don't have a local HTTP server running, this won't look very "impressive", though.
For the sake of this PoC, I didn't implement anything that could let you alter the "victim" IP. It IS possible, but I don't know if I should do it.
I could alter 127.0.0.1 to Google's IP for example, but this isn't as impressive as reading/writing data from/to your internal network. Maybe I'll add this some time later, so those of you who don't have a local HTTP server running could still see the attack in action.
In essence, this is a two stage attack. The first stage involves your browser caching some HTML code from a certain URL for a really long time. You probably don't know it yet, but the first stage of the attack has already hit your browser.
<img src="http://evil2.us.to/poc/rebind/redirector.php" style="width: 1px; height: 1px;">
The code above is embedded on this very page. "redirector.php" redirects your browser to the evil "doit.php" file the first time you visit it. "doit.php" tells the browser to cache it for a year. When you reload this page for the second time, "redirector.php" will then simply redirect to a harmless image. The cached "doit.php" file, however, will stay unaltered on it's own URL.
In order to understand this better, you should read the source files I link to at the bottom of this post.
At the same time, on the server side, once "doit.php" was visited by your browser for the first time, the script has altered the DNS entries for it's hostname on the local DNS sever (which is authoritative for the domain evil2.us.to).
The next stage of the attack is waiting. 2 minutes if you run Firefox, 30 minutes if it's IE. It depends on how the browser implements the DNS pinning protection. On any browser, closing it and opening a new instance will work immediately. In practice, a malicious attacker will just wait. Since the page is cached, it's not going anywhere. The attack could be continued when the attacker desires.
For the sake of this PoC, however, exit your browser and then come back to this page.
Now when you're back...
After the DNS pinning has expired, all the attacker has to do is give the victim a link to click on.
http://evil2.us.to/poc/rebind/innocent.php
This could be a completely innocent looking page with an iframe to the previously cached "doit.php" file. A JavaScript on the cached page could use XHR. This would cause the browser to do a new DNS lookup, and eventually resolve to 127.0.0.1.
As I explained earlier, the implications of this are severe. All the HTTP based web services on your network could be owned.
Conclusion
Despite this PoC sounding incredibly long and complicated, the basic stages of an attack are these:
1) Post an "image" on a blog or message board that your victim visits (make sure he "sees" it).
2) Wait for as long as you want.
3) Make the victim to click a link. (via a PM, IM, or whatever).
You may or may not see an attack that requires user interaction as a good one. Still, you must remember, that modern security isn't so much about attacking the system anymore. Rather, it's about attacking the operators (or users) of the system.
You can agree with me that anyone who wants to poke a hole right through a corporate firewall, could use this attack.
Finally, the true problem isn't that it's possible to do this. What's really bad is that it has been possible to do this since 1996. This flaw isn't a bug, it's here
by design.
Here is a link to the sources of this PoC. Everything is well commented.
http://own-the.net/poc/rebind/source/
Enjoy.
Posted by: kGen | In category: DNS | Comments (0)
14 June 2008
DNS rebinding has been a widely known issue since 1996. 12 years later, the attack is still alive.
I've spent quite some time researching what's still left of the attack, and did find out that most known vectors were patched or mitigated by now. However, the attack is still very real, and could be fully exploited on most (if not all) modern browsers.
I've compiled a list of vectors that I had dealt with during this brief research. Most were discovered to have been fixed in one way or another, some only partly, but a few are still exploitable.
Disclaimer: This is not a how-to. This post deals only with what could or could not be done on today's systems. A step-by-step explanation of every vector described would be irrelevant.
Methods to break DNS-pinning in browsers:
1) Trying to load a page from a closed port (http://rebinding-domain.com:81). -
Hardly works. Doesn't break the 120 second pin on Firefox. Does, however, break the half-hour pin on IE. Still, this requires a couple of reload attempts (3-6, don't know why) so it's quite slow.
2) Using the Flash or Java plugins, since they have their own pinning-database for Sockets. - This no longer works. The issue had been patched on both platforms in the beginning of 2008. Adobe has recently enhanced Flash's security model significantly. Now in order for a Flash movie to open a socket, a policy file has to come
from the same IP as the destination IP of the socket connection (and not only the same domain - thus mitigating DNS rebinding).
References:
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html (scroll down to "DNS hardening")
3) Shutting down (or firewalling) the HTTP server on the attackers machine in order to force the browser into a new DNS lookup. - Doesn't work on Firefox. It seems as though no matter what you try, Firefox would never give up those 120 seconds of pinning. On IE, yet again, this works after a couple of reload attempts.
4) Using the browser's cache in order to store the attack page. - Works great, but has its drawbacks. The DNS record should be altered right after the victim downloads and caches the page. If the page is revisited after the DNS pinning had expired, any XHR request would force the browser into a new lookup, and complete the attack. The obvious pitfall is that the page needs to be visited twice.
On the bright side, an attack page could be held inside an invisible iframe, well hidden from the unsuspecting user. The iframe could be located on many different sites and linked to in many different contexts. As such, even mass-attacks should be possible. A targeted attack, with the help of very basic social engineering skills, could easily work every time.
Methods to rebind DNS on the nameserver/cache level
1) 0 TTL records. - This works, but not always. Many DNS servers force a minimum TTL of 300 seconds. Some even reject 0 TTL records as invalid (rare, but I believe it happens).
2) One domain with 2 "A" records. - Works, but only on
non-local IPs. If you point a domain to both 209.40.204.211 (own-the.net) and 192.168.0.1 (a local IP), the browser
won't choose one of them randomly. The local IP will always be chosen. Yet, if the second IP would have been 72.14.207.99 (google.com) this method could still work. The browser would choose a random record after every lookup attempt. (you'll have to retry one or two times with different host-names). If the server on the chosen IP appears to be down (firewalled), the browser will instantly connect to the second IP, thus creating a rebinding scenario.
3) Setting up a CNAME sub-domain in order to force the DNS cache into revising the original record upon lookup (regardless of TTL).
evil.com. 0 IN A 1.1.1.1
1.evil.com. 0 IN CNAME evil.com.
- Works fine, on almost all name servers. I've seen this technique on a DefCon 15 video. A very great video on the subject, by the way. The guy shows how you could use DNS rebinding in order to VPN into a corporate network, through a web browser. Ouch. (This was possible back in 2007). Video:
http://video.google.com/videoplay?docid=3470502418262982787
A realistic scenario:
1) The domain evil.com points to the attacker's server at 1.1.1.1 .
2) The victim is lured to a specially crafted page on http://evil.com, that tells the browser to cache it for a very long time ("Cache-Control: max-age=999999999, must-revalidate")
3) On the server side, the page invokes a script that alters the DNS records of evil.com and points it to the victim's server, at 2.2.2.2 . (At this point, it would be smart to use the CNAME "CNiping" trick to force the DNS cache to update. This is nicely described in the video above).
4) The attacker needs to wait between a minimum of 2 and 30 minutes (depends on the victim's browser) before proceeding. As the page is cached for a long time, there is no need to rush the attack.
5) The attacker lures the user back to the same page on http://evil.com . The page will be recovered from the browser's cache.
6) A script on the page would invoke an XMLHttpRequest to evil.com (that now points to 2.2.2.2) and finalize the attack.
Necessary "tools"
1) A domain name. Get free ones at
http://afraid.org
2) A server with root access. Dedicated / VPS / compromised machine.
3) LAMP (Linux, Apache, Mysql, Php) installed on the server.
4) A DNS server (BIND 9) installed and configured.
5) Patience and time.
All of this costs me about $7 a month. Thank you, Open Source.
Conclusion
I have actually made a proof of concept based upon the scenario above, and it works fine in every browser I tested it in. Even the new, shiny Opera 9.5 is as vulnerable as the rest.
Surely you can say that the chances of conveying such an attack successfully are low, but I beg to differ. If a serious attacker would put some thought and creativity into it, he/she could easily sneak into a corporate network using the steps mentioned above.
And even if the chances of success are low, the consequences of such a penetration are severe. XHR allows you to alter HTTP headers, send GET/POST requests, and read the responses. This also allows you to send XML SOAP requests. Thus, you can pretty much own any HTTP based web service on the network.
UPnP (a control protocol supported by devices such as routers) is also based upon SOAP requests, and here is something worth reading about what arbitrary access to your UPnP device could do:
http://www.gnucitizen.org/blog/hacking-the-interwebs/ (another great read, although the Flash vector no longer works).
Changing the primary DNS servers of a machine? How about that? On success, this literally means "pure ownage".
Finally, a PoC will be posted as soon as I find the time to get it done (some work is still necessary).
In the meantime, I hope you found this post helpful.
Posted by: kGen | In category: DNS | Comments (0)
Copyright (C) 2007-2008. Some rights reserved. Distribute freely, but don't forget to link to the source.
