This group should mostly be dealing with how web applications enable networking security issues that are otherwise not there. Everything is being tunneled over port 80 now so what does that enable and how do we fix it?
I read the article written by Martin Johns.
http://shampoo.antville.org/stories/1451301/
It was very interesting for me, and I made an online demonstration.
http://www.jumperz.net/index.php?i=2&a=1&b=7
Changing DNS record ( IP address of the attackers host ) to a private address, and
stealing information from Intranets. Please try this.
( Please don't send sensitive informations :)
By the way, DNS issue is very compricated.
If the web browser caches DNS record forever, there will be a problem about dynamic DNS.
( a scenario written at https://bugzilla.mozilla.org/show_bug.cgi?id=162871#c10 )
And if the web browser updates DNS record, attack like Martin's article( and my demonstration ) will become possible.
What do you think?
IMHO, it is a vulnerability of DNS protocol itself, not of web browsers.
I've been meaning to play with the idea myself, but I never got around to it. Any chance you could give us a write up of how you actually implemented the attack?
"Kanatoko Anvil from jumperz.net found out that it is not necessary to shut down the web server. It is sufficient for the malicious script to access a closed port on the intranet server (e.g. attacker.org:81) to cause the web browser to initiate a new DNS query. See here for a demo. Wow."
So without actually seeing the code, it appears he has a daemon running that closes the unique port after a few seconds. Cross domain policies doesn't apply to ports. Poof. Great find!
jungsonn, kuza55, rsnake, Thank you for your posts.
Technical details of the demo.
#I'm very sorry for my poor English
( I wrote URLs as 'htp://', not 'http://' to avoid auto link )
1. The user enters his private IP address ( for example, 192.168.0.1 ) and click 'start'.
2. The form executed, the browser jumps to htp://www.jumperz.net/exploits/dnsp2.jsp, with a parameter 'address=192.168.0.1'.
3. An unique string is generated ( actually a time, milliseconds like '1166986089765' ).
This string will be used as a 'one time subdomain'.
A DNS record is added to the configuration file of djbdns( http://cr.yp.to/djbdns.html ).
In this case, the line added to the configuration file will be '=1166986089765.jumperz.net:218.45.25.195:8'.
This line means:
hostname = 1166986089765.jumperz.net
ip address = 218.45.25.195
ttl = 8 seconds
4. A system command that makes djbdns reload the configuration file is executed.
5. The HTTP response is sent to the browser. This response looks like this:
---
HTTP/1.1 302 found
Location: htp://1166986089765.jumperz.net/exploits/dnsp3.jsp?address=192.168.0.1
---
6. The browser redirected to 'htp://1166986089765.jumperz.net/exploits/dnsp3.jsp?address=192.168.0.1'.
At this time, 1166986089765.jumperz.net is binded to 218.45.25.195( attackers web server ), So the browser access to 218.45.25.195.
7. dnsp3.jsp changes the DNS record and makes djbdns reload the configuration file.
In this case, a line in the djbdns configuration file is replaced as:
And the page that contains the malicious script is loaded to the browser.
8. The scripts starts.
9. After sleeping a few seconds, the script makes the browser to access to 'htp://1166986089765.jumperz.net:81/'.
At this time the browser try to access to 218.45.25.195.
Because the port 81 ( of 218.45.25.195 ) is closed, the request fails.
The script repeats this ( trying access to port 81 ) a few times.
10. The browser lookups DNS record.
As described at '7', at this time '1166986089765.jumperz.net' is binded to '192.168.0.1'.
11. The script makes the browser access to 'htp://1166986089765.jumperz.net/'.
The HTTP request is actually sent to 192.168.0.1.
The script can access the content of the HTTP response, because of the 'same origin policy'.
The data is set to the form element and sent to www.jumperz.net.
For more details, please see the sourse code of the dnsp3.jsp.
And if you have questions, please feel free to ask me.
Thanks
--
Kanatoko
http://www.jumperz.net/
Edited 1 time(s). Last edit at 12/28/2006 02:47PM by Kanatoko.
Thats awesome Kanatako, I never even considered trying to get it to connect to closed prots! But is there a reason you try to connect to port 81 multiple times? Because from what I've heard it should be enough to do it once, no? I'm just wondering if its possible to speed this up a bit.
rsnake Wrote:
-------------------------------------------------------
> Cross domain policies doesn't apply to
> ports. Poof. Great find!
Speaking of cross domain policies not applying to ports, you've probably already seen this, but just in case you haven't, this is another ineteresting way of exploiting the fact that cross domain policies disregard ports: http://blog.php-security.org/archives/62-Cross-Virtual-Host-Cookie-Theft.html
That's really interesting, Kuza55, thanks for sending the link... But if you had a PHP include vuln on that site, I'd be way more worried about other things like using it as a shell or as a robot or whatever...
rsnake Wrote:
-------------------------------------------------------
> That's really interesting, Kuza55, thanks for
> sending the link... But if you had a PHP include
> vuln on that site, I'd be way more worried about
> other things like using it as a shell or as a
> robot or whatever...
Oh of course, and if you had a php include vuln ina a site you would be able to do whatever you wanted, this is more for attacking sites on shared hosting. Either because you can get an account on the machine, or you found an include vuln in a site on the smae box.
I've read it more closely now, I understand it a little better and think it's really a mutual flaw. It's not actually a DNS flaw only. In the first example it requires the browser simply to cache and re-initiates a new DNS session, I've always saw the danger of caching things, cached sessions, cached history, cached scripts, cached ftp sessions etc. So it really only can be solved by the firewall. It seems a sort of firewall hole punching like i talked before. Is this the case?
At the moment i'm hacking a fresh copy of FireFox 2 to roll my own browser with a lot of modifications, and there is alot to be done: remove caching, no history, no password saver, strip the anti phishing filter, all phone home objects to mozilla, google, standard no-script & tor build in, stripping toolbars and more features. And i also plan to build a signal to noise function in it, which runs a low process in the background imitating a causual surfer while i'm browsing myself or when i'm idle. (this to prevent traffic analysis), which is the next big thing when everything is encrypted, It's very hard to protect your self from traffic analysis. Packets can be tunneled/encrypted, but remains vulnerable to traffic analysis. If packet A is this size encrypted, it should be this size unencrypted. If packet B is this size as a request, and the response packet C is this size from a website. I can calculate what the site is you are visiting, dispite tunneling. which can be analysed by looking at the packetsizes. So signal to noise could solve that.
btw kanatoko: where do you have the source? I can't find it on your site.
Edited 1 time(s). Last edit at 12/29/2006 05:40AM by jungsonn.
If you're tunneling you don't have to build that into your browser, you just need to build a tool to communicate over the tunnel at the same time. Of course you'd have to remember to turn it on, but it would probably be easier to write.
To make the browser refresh the DNS record, we need to...
--
Step1: wait to the DNS record ( already in the browser cache ) to expire.
Step2: make the browser access to a closed port.
--
::About Step1::
On IE and Opera, the time needed is same as the TTL value of the DNS record.
So this value can be very short.
I use 8 seconds in my demo.
On Firefox, the time needed is about 120 seconds at short.
This value ( 120 ) is regardless of the TTL value in the DNS record.
So we need to wait relatively long, to attack Firefox.
::About Step2::
There is no need to repeat this step multiple times.
Once is enough, on all browsers.
(kuza55 was right)
--
Kanatoko
http://www.jumperz.net/
Edited 1 time(s). Last edit at 01/10/2007 11:27PM by Kanatoko.
Hi all! I maybe miss the point, but why is this issue always discussed in the context of the intranet sites? Shouldn't it work for CSRF-ing any site in the Internet?
And, what about the following approach to the protection:
Application, when it is requested, checks for special cookie. If the cookie is absent, it is set with the explicit domain parameter and the browser is redirected to the app. again with additional parameter which is a hash of that cookie. If the cookie was not set successfully or is wrong, then DNS was spoofed.
bubenrazuma, it's not particularly good at CSRF, because cookies are not sent with the connection (since you are connecting to the IP address, and not the server name). That's not such a big deal if you are just talking about intranet scanning where you want to see if a host is there or not and potentially see what sort of webserver it is running or if it has no virtual hosts running. But yes, there are other potential uses, like this example: http://ha.ckers.org/blog/20070105/lessons-learned-from-adobe-pdf-xss-patching/#comment-13035
I thought that FLASH will pin the DNS cache so we need to use the
"classical" way ( shutting down the web server, using the closed port, using the firewall etc) same as JavaScript.
But FLASH does the name resolution by itself, not depend on the web
browsers ( maybe but depend on the OS ).
I mean, there is no relationship between FLASH and the web browsers on
the DNS cache and the name resolution.
The web browsers( IE, Firefox and Opera ) pin the DNS cache.
FLASH does not pins the DNS cache on the other hand.
FLASH discards the old DNS cache after the TTL has passed.
We don't need to use any techniques to make FLASH refresh the DNS cache.
We just need to wait.
So attacking FLASH is very easy.
I noticed this thing and updated my demohttp://www.jumperz.net/index.php?i=2&a=1&b=8.
The source code of the demo becomes very simple now ( because there is no
need to use the closed port ).
It may be inappropriate that I named this article as "Anti-DNS Pinning + Socket in FLASH" because there is no DNS Pinning ... :p
How should we name this attack vector( breaking the same origin policy based on the hostname, by changing the DNS )?
--
Kanatoko
http://www.jumperz.net/
Edited 3 time(s). Last edit at 02/05/2007 02:53PM by Kanatoko.
RSnake
>Can you supply us with the source to the Flash Actionscript?
Do you mean the source code of the FLASH file?
If so, it has been here. http://www.jumperz.net/exploits/aflash.mxml.txt
I have updated my demo and now it is faster than the old version as you say in your blog, but the FLASH file is not changed.
I just remove the JavaScript part.
WhiteAcid
Thanks to your information about Ubuntu!
I am little bit confusing about keywords...
I hope this is right :)
"DNS Spoofing"
-----
An attack technique that break the same origin policy based on the hostname, by changing the DNS
-----
"DNS Pinning"
-----
Can be called as "Anti-DNS Spoofing".
Pins the DNS cache.
Implemented by Browsers and Java Applet
-----
"Anti-DNS Pinning"
-----
Breaking the DNS Pinning by making the browser fail the connecting attempt.
(Please read the Martin's article for more detail )
-----
And, FLASH is simpley vulnerable to The DNS Spoofing :)
Yah, although this was 11 years ago, and resembles Anti-DNS Pinning in a lot of ways, it is slightly different. I think your work is different in a number of ways.
I know this thread is a bit old meanwhile but for those who want to catch up on DNS Pinning, this writeup may help:
http://christ1an.blogspot.com/2007/07/dns-pinning-explained.html
Regards,
- http://christ1an.blogspot.com
_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0
Following the news the other day that IE doesn't actively implement DNS-Pinning; it seems Firefox (2.0.0.4) DNS pinning is either non-existent or somewhat strange too.
Take a look and let me know what you think http://getahead.org/blog/mark .
