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..
This works as expected, and if the hamster-meister clicks his [cookies] link, you get to execute script in his browser..
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 email@example.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..
This gets us the ability to run simple script in the hamster-console with no attacker intervention at all..
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:
which ends up with:
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..