how-to block ads
|
jansson_mark
Markus Jansson
Premium
join:2001-08-05
Finland
edit:
August 3rd, @02:07PM
|  Anti-DNS pinning & DNS-rebinding attacks!
In short, anti-dns pinning and dns-rebinding attacks can be used to make your browser think it can send information X to site B, since site B belongs to same site as site A (which is some good site). This can be exploited simply over the browser window using javascript, java or flash. Using this kind of attack, the owner of any www-page can get access to your internal network, such as router, external firewall, other computers in your LAN, etc. etc. because your computer is being told that site B is located on the same domain/IP that the site A is (and your computer thinks it safe to send such information there therefore).
Now, browsers have been protected against this kind of attacks for some time now. However, javascript, java and flash arent. They are still vulnerable.
This sound pretty damm serious if you have anything inside your own LAN that is not firewalled or if you dont have good passphrases on your router/modem!!!
More information in here
- »www.digitoday.fi/page.php?page_i···00718532 (finnish only)
- »crypto.stanford.edu/dns/
- »www.doxpara.com/DMK_BO2K7_Web.ppt
- »crypto.stanford.edu/dns/dns-rebinding.pdf
Tests
- »www.jumperz.net/index.php?i=2&a=1&b=7
- »www.jumperz.net/index.php?i=2&a=3&b=3
- »www.jumperz.net/index.php?i=2&a=1&b=9
--
My computer security & privacy related homepage »www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. | |
NetFixer
From my cold dead hands
Premium
join:2004-06-24
Murfreesboro, TN
 ·AT&T Southeast
 ·Vonage
 ·Cingular Wireless
·AT&T CallVantage
 ·Comcast
edit:
August 3rd, @03:23PM
| I don't have the time at the moment to analyze the rebinding paper, but I will certainly try the test links.
*****Click...Click...Click...
*****Yawn*****
Sorry, I clicked on the test links and fell asleep while waiting for something to happen. 
--
We can never have enough of nature.
We need to witness our own limits transgressed, and some life pasturing freely where we never wander.
Test your firewall. | |
swhx7
Premium
join:2006-07-23
Elbonia
·RoadRunner Cable
| reply to jansson_mark
Good stuff jansson_mark. The pdf is fascinating.
Browsers are supposed to protect against this by "pinning", i.e. requiring the IP-to-domain-name match-up to remain the same for an interval. But Jackson et al. in the pdf make clear that the major browsers don't do this very well. So even without plugins, there are some big gaps.
You can protect against outside access to other LAN devices by hardening within the LAN and by patching your firewall to not allow external names to resolve to internal addresses. But the browser can still be expoited to send spam or direct attacks at other external computers in which case the victim will appear responsible.
There's more I haven't read yet. Mozilla, Microsoft, Apple and Opera need to get on this. | |
Steve
R.I.P. 3B2
Consultant
join:2001-03-10
Tustin, CA
| reply to jansson_mark
I had never heard of this before, but it's fascinating. I'll try to present an executive summary.
DNS Rebinding attacks
In the old days, browsers were susceptible to DNS rebinding attacks, which the paper notes have been known for a decade.
The idea is that you visit my website, which might be www.badguy.com, and your browser's first order of business is to look up the name in DNS to get the IP address. The DNS server for badguy.com — which I also control — hands out that IP address with a very short lifetime (the "TTL").
At this point your browser fetches whatever content is on my website, which in my case is malicious Javascript. But then my DNS server does something tricky: it changes the address of www.badguy.com that it hands out to this client.
When the Javascript code tries to reconnect to www.badguy.com, it again fetches the name from DNS (the old one having expired from cache), and this time it gets that new internal address. But since the browser thinks it's already cleared this hostname (same origin), it allows it.
If it's an internal address, this is rooting around for private resources, such as a company's internal confidential website, or if it's an external IP address, it could be an external address of a public webserver where the Javascript will attempt click fraud.
It's even possible to serve up a CNAME up record as the second address, so something like hr.corp.example.com and have the browser's own resolver look up the actual IP. But this is still treated as if it were the same origin as the original hostname.
This is DNS rebinding - the name is re-bound to shifting IPs over the course of a transaction.
DNS Pinning
Because this has been known for some time, browsers counteract this by using DNS pinning - this is a kind of internal cache that keeps name-to-IP lookups around longer even if the DNS record's TTL is very low: once it connects to a site by that IP, it's going to use it for a long while.
This explains, among other things, why when you change the IP address of your website in DNS, your browser requires a restart even if you flush DNS in all the resolving nameservers involved: the browser caches DNS data and does not honor TTLs.
DNS Pinning Weaknesses
All modern browsers support DNS pinning, though some of them can be fooled.
•IE6 and IE7 pin for 30 minutes, but if the hostname resolves to multiple IP addresses, it's possible for a clever attacker to force the "other" IP address to be used before the pinning time expires.•Firefox pins for 1-2 minutes (and the Javascript code and predict exactly when the pinning expires by looking at the system clock), and it can further be fooled to rolling over to a new IP more quickly than that.•Safari 2 pins bindings for one second, and I don't quite understand how that helps anything.•Opera appears to pin for around 12 minutes, but it can be tricked to rebinding sooner But this is just covering ways of fooling single-entity pinning: sometimes there is more than one party at the party.
Multi-pin vulnerabilities
The plugins such as Flash and Java also maintain pinning databases, but they are separate databases. This means that the web browser might bind www.badguy.com to one IP, while Flash binds to another. This leaves open all kinds of avenues of shenanigans.
One example is hijacking Flash to send spam via port 25/tcp, often using the enterprise's own mailserver to send it - Flash and Java can both be fooled this way.
These sometimes do require some elaborate orchestrations to make work, and some work only sporadically (some are hit or miss), but for things like click fraud they can be far cheaper than renting a botnet - the paper suggests one or two orders of magnitude cheaper.
Wow.
What this is not
This is not compromised DNS servers — the zones in question are all "legit" in the sense that they are authoritative for the domains being hosted. It does not involve DNS poisoning that we see here now and then, and in all cases the nameservers are operating within spec.
This is also not phishing, because it's not presenting one website as another. All this bad stuff goes on mostly in the background, and the user is mainly not aware of it.
How to fix this
... involves actually reading the paper. I've just tried to touch on the high points that survey the area. The PDF is good, and though it's technical, it's done at a useful reading level.
Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Tustin, California USA | my web site | |
bobince
join:2002-04-19
DE
| reply to jansson_mark
DNS pinning is a hack around the real problem - it is no surprise it doesn't really work. Even with 'properly' pinned DNS you can still have longer-term attacks like cookie sniffing.
This is why when running a site with accounts or other sensitive interaction, you must tie it to a virtual host (ensuring that the browser has set the Host: header to the right domain).
Attacks like this are well-known. | |
dips1110
join:2007-10-16
411014 | reply to Steve
pls give more information on DNS pinning and web proxies.....  | |
|
