« JavaScript Code Flow Manipulation, and a real world example advisory - Adobe Flex 3 Dom-Based XSS | Main | Tamper Data Cross-Site Scripting »

June 23, 2008

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d835130c5153ef00e5536930428833

Listed below are links to weblogs that reference Cross Environment Hopping:

Comments

Ory Segal

Hello,

We have had some technical issues with the original posting of this write-up. During the process, we lost some comments from Kuza55, which I would like to present here:

>> Comment #1 >>

Interesting info on the fact that old IE controls don't check ports.

However, how does your attack work in light of the fact that Java now supposedly does a reverse DNS on the ip it gets to ensure that it is connecting to the host it's meant to be: http://sunsolve.sun.com/search/document.do?assetkey=1-26-103078-1

Flash also now requires a 'socket policy file' to be hosted by the server before allowing socket connections.

I have no idea about Quicktime though, and have never heard of it being able to open socket connections, do you have any information/code on this?

In any case, there are cooler things you can do with xss vulns in localhost like http://heasman.blogspot.com/2008/06/stealing-password-hashes-with-java-and.html and http://r00tin.blogspot.com/2008/03/local-web-servers-are-dangerous.html

>> Comment #2 >>

Oh, and regarding the Java fix, the reason the reverse dns issue may prevent this is since (when I tested this) 127.0.0.1 has a reverse dns record of localhost.localdomain, and for me localhost.localdomain doesn't resolve...

kuza55

I still don't see how you addressed my comments about the DNS rebinding fixes.

I realise this attack has nothing to do with DNS Rebinding, however it would seem that it would be affected by the protections put in place to stop DNS Rebinding.

I tried running the LiveConnect code you posted and I get a security exception:
Error: uncaught exception: java.security.PrivilegedActionException: java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException

Now I do have a beta build of Java installed, so this may explain why I get this exception, but does it still work for you in light of the DNS Rebinding fixes in the latest Java client?

Anyway, I disagree with your comment that they are more relevant now than ever. They would more relevant if they worked as described, however while the XHR stuff works (and again, props for finding that, I looked up the docs and they flat out lie), it's not much of a win since the XHR objects aren't fixed for plain old DNS Rebinding and that works in Firefox as well as IE.

Yair Amit

Hello kuza55,

Thank you for your comments. :)

The LiveConnect scenario was last verified to work under Firefox 3.0 with JRE Version 6 Update 6 (The latest (non-beta) version as far as I know. In matter of fact, many people probably still have Update 5 since Update 6 isn't fully deployed yet. I had to explicitly install it since the updater claims Update 5 is up-to-date).

Which code did you use in your experiment?

Please note that the code presented under the "Local Proxy Exploitation"/"Accessing Non-HTTP Services Using the HTTP CONNECT Method" sections aim to establish full-duplex intranet communication by taking advantage of a locally installed proxy server.

In order to validate the attack works, try altering the code to connect and communicate to another locally installed server on your machine (you can do this by changing the new java.net.Socket(…) and write.writeBytes(…) according to the service you connect to).

I'll be happy to read your remarks in case the beta version of the JRE does not handle the code as expected.

Regarding the recent protections against DNS Rebinding attacks in the JRE:
In a DNS Rebinding, the attack starts in an attacker controlled IP (in that point, malicious content/scripts are loaded) and then the attack fools the browser/plug-ins to execute the malicious commands under a sensitive context (local machine / local network) – the same origin policy is practically circumvented.
As far as I know, the protection tries to make sure the content (Java applet, for example) is in fact originating from the final IP before executing it.
Since Cross-Environment Hopping works under the same origin policy restrictions, and does not violate them during the attack, when malicious LiveConnect code is loaded and executed it is all done from the localhost and therefore looks 'legitimate' to the infrastructure…

kuza55

I used the second block of script code when testing, and the socket call raised the exception I listed, so it won't let me connect anywhere.

The protections *are* just trying to make sure that you can actually host content on that IP, but the how of that should prevent this from happening.

E.g. in Java (it says) it does a reverse dns lookup on the ip then checks that it matches the domain we're trying to connect to, and like I said 127.0.0.1 resolves to localhost.localdomain which itself does not resolve and in Flash (it says) you need a socket file somewhere.

Dan Kaminsky

kuza55--

Most, though indeed not all nameservers reverse 127.0.0.1 back to localhost. Many resolvers are also open, so if you get the occasional localhost.oogabooga.com or localhost.localdomain, you can just XSS the user against http://localhost.oogabooga.com.

I wouldn't have thought it, but it does appear the Flash protections ended up stronger than Java's.

; > DiG 9.2.5 > @209.97.223.122 1.0.0.127.in-addr.arpa ptr
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER> DiG 9.2.5 > @216.125.212.81 1.0.0.127.in-addr.arpa ptr
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER> DiG 9.2.5 > @66.77.162.45 1.0.0.127.in-addr.arpa ptr
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER> DiG 9.2.5 > @63.196.15.67 1.0.0.127.in-addr.arpa ptr
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40157
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 3600 IN PTR localhost.

Dan Kaminsky

Er, those digs got munched. Suffice it to say most servers look exactly like that last one.

kuza55

Thanks Dan, that helps clear things up :)

Ory Segal

Hi,

Here's probably the world's worst description of CEH.

http://www.0x000000.com/?i=602

rvdh

It's not a description that is at fault, it's the layout of the mechanics beneath it that confuses some and the buzzwords I read here, in my opinion.

I guess everyone here needs to read again the real meaning of tricking victims in launching this attack and which techniques are being used. For instance, the vehicle is still CSRF, with XSS -or- SQL injection as payload. I wrote before that SQL inecting local servers is a piece of cake. Let alone injecting PHP shells -I did some research about this in 2006- Which can be used to 'hop' a network also.

I assume everyone was knowledgable about the risks involving local services that listen on TCP ports like 80, 8080 -in the case of a proxy- Let alone the SQL ports which I don't see you talk about? And services like Java, Flash, or JS for that matter are still running locally abusing other vulnerable services through an unautorized request. That still makes CSRF it's vehicle for attack.

Of course, with a local proxy or insecure local webserver and/or insecure databases like SQLlite it's the end of your security defacto.

So what's new here?

rvdh

Here's what I talked about before:

http://www.0x000000.com/index.php?i=525

Somewhat exotic, but basically does the same. Not to mention abusing NamedPipes in the same breath, on which I talked a couple of times also.

Still, it stays CSRF :)

The comments to this entry are closed.

Follow us on Twitter

AppScan Free Trial


Try IBM Security AppScan software at no charge.

Become a Fan