OK.. So as i mentioned before, I saw Robert Graham from Erratasec demo hamster live on stage and wondered if hamster was doing useful input/output sanitization.. If it wasn't, he was setting himself up for a pop-up that read "owned on stage" or worse a re-direct to tubgirl.. He didnt get owned on stage, which suggested that either the crowd was really well behaved or the tool was doing some tidying up so i decided to wait till i got home to check..

Robert released the tool to the public on his blog on the 5th of August..

At first blush it seems as if hamster does do some sort of sanitization, since merely surfing to a location and including javascript in the URL doesnt harm the hamster interface..

But all is not lost.. As a quick test we have a webserver send us a cookie that contains JavaScript:

This works as expected, and if the hamster-meister clicks his [cookies] link, you get to execute script in his browser..

Now, although XSS has long been frowned upon as a decent attack vector, we need to keep in mind that we are effectively injecting JavaScript into our attackers browser.. Simply re-directing him to a backframe or beef hook will translate to making his browser a zombie..

But the fact that attacking our attacker needs him to click on [cookies] in pane-1 (pic below) is annoying.. We want click-free injection so we keep playing..

Now it turns out that when an IP in frame (2) is spotted logging in to his gmail account, hamster will list the users email address next to the IP-Address.. A quick look at the traffic shows that hamster makes this deduction based on it spotting the gmailchat=haroon.meer@gmail.com/12345 cookie value we used while talking to mail.google.com.

Now, this means if we can get the server to send us another value for that cookie, we should be good.. This sounds tricky, but its also unneccessary. Since hamster doesnt care which direction its sniffed traffic is flowing from (and needs to since it could miss a set-cookie due to late arrival on the network) it cant tell if we are using a cookie that was actually issued by the server at all.. This means, using netcat (or telnet) we can do the following:

And the hamster-console happily shows our new persona..

A quick check shows that there are no real length restrictions (or format restrictions) on what we can place there, except for one piece of protection that gets through by accident.. Since the email address appears to be taken as the value between gmailchat= and the /12345, the / has become a delimeter.. effectiving preventing us from using a </script tag..

We can still inject JavaScript without a "/" so make use of:

This gets us the ability to run simple script in the hamster-console with no attacker intervention at all..

Now any reasonable piece of JavaScript (even the simple redirect to beef/backframe) is going to need /'s even if just as part of the http:// .. So we need to get past the annoyance.. It turns out hamster actually escapes the \ char, preventing \/ type bypasses..

Instead we try a simple document.write piece of JS:

This works just fine:

Which means the game is just about over.. The interwebs gives us a handy JS encoder/decoder at: http://scriptasylum.com/tutorials/encdec/encode-decode.html So using this to encode the string (including both \ and /) we get:

We can then use JavaScripts unescape function to get:

which ends up with:

Now we can fully write huge long pieces of JavaScript, encode them, pass them to unescape within our gmailchat cookie and the Hamster console will execute it.. (Simple document.location redirect to www.sensepost.com starts of like this:

and ends up like this:

)

Of course, Since the hamster is running on your local machine, it will execute script in the context of "Local Intranet"

Which makes this even more fun..

(Of course: simply setting your gmailchat cookie to a piece of script that spawns a squillion windows will suffice too)

* We did inform erratasec about this, who responded that Hamster is not meant for public usage (which is reasonable.. ie.. it was a POC for a demo), so i dont suspect it will get fixed.. If you running it.. better start considering noscript..