cpunks downtime

[coderman]

On 9/20/07, Tyler Durden wrote:
> ...
> Meanwhile, I suppose everyone on the list is familiar with the nifty Tor hack
> done recently?

the exit wall of sheep (embassy passwds) was lame but the control port
opener was nifty.

sequence for the control port payload injection:

- two vectors for form payload, a third for ip leakage across three
proxies on broadband

- javascript posts form automatically to localhost:9051 using:
 action="http://127.0.0.1:9051/" method="post"
enctype="multipart/form-data" target="stylearea"  [that last to keep
the response from the tor control part spewing over the current page -
this puts it in a hidden iframe]

- all existing <FORM's in exit requests modified via proxies to inject
the TEXTAREA with payload into a hidden form element while leaving the
appearance of a legitimate form page (so any submit pwns, too late.
even lynx on openbsd if your control port is on 127.0.0.1:9051 (or any
accessible port if you've got a motivated attacker...))

- IP leakage for all IE on win32 users that aren't using a transparent
proxy (janusvm) via SMB/NetBIOS and WebDAV to external host with
tracking nonce directory name.  even if the control port is not open,
this will leak the origin of the request as webdav is below the
browser, interpreted in the file system / win32 api context. (SMB is
not nearly as useful as webdav since most ISPs filter NetBIOS and
SMB/CIFS traffic even if you explicitly allow at the router.)

- the purpose of the payload was an interesting 150-200k+ command set
for the control port to apply.  among various things this performed
the following:

- redirect the notice log to /dev/null on *nix like systems or to a
webdav path on one of the proxies. (this leaks ip immediately on win32
in addition to routing ongoing notices messages to the proxy directly.

- invalidate all known authentic nodes on the existing Tor network via
ExcludeNodes with digests, configure three new rogue nodes as
authoritative directories and exits, and finally starting a hidden
service and posting the .onion name to the proxy server.

- map local ports to the hidden service onion allowing an anonymous
user on the rogue Tor network to arbitrarily connect to the client
onion and interface with their Tor control port in real time.

- vulnerable Tor clients (not using transparent proxy like janusvm)
start falling by the thousands into the rogue Tor network for the
duration of a few hours while the attack was being tested...


of course, vmware just got their asses handed to them recently as well:
http://secunia.com/advisories/26909/


qemu/virtual box looks much more promising; perhaps supported soon...