Rudolph8

By Derrick Jones

1. The first embedded URL, the invisible image, is logging the victim's IP address. The hacker has configured his web server to log any IP address that accesses "Sample.jpg". "Sample.jpg" is only referenced in this form. The log will thus only show IP's belonging to the victim.

2. The second URL hijacks the victim's web browser and dumps all of its cookies by converting them to a text string and passing that string to a malicious program on the hacker's website called "Grab".

There are two prongs of attack now, the victim's cookies and the actual victim.

Let's start with the cookies. "Grab" will at a minimum log the cookie dump. Assuming cookies are used for authentication and the cookies aren't encrypted, the hacker now has the admin password. If the cookies are encrypted it might be possible to hijack the session by setting ones own cookies identical to the victim's before the session expires then "hijacking" the session as if the hacker were the victim.

Lastly, if "Grab" is particularly sophisticated it might be able to restore the victim's session as if nothing happened. In this way it could log cookie dumps (along with all the other information web browsers typically leak) without creating any suspicion on the part of the victim. The hacker meanwhile reviews the logs and plans an attack fairly confident the inital hack went undetected. However, that type of attack would require multiple forms be sent. I'm guessing this is a poor surveillance-gathering hack.

Now let's look at the attack "Grab" can make on the victim:

Since "Grab" now owns the victim's session, it owns the victim. Some evil things "Grab" might do is present a spoofed "Invalid Password" dialog. The victim, assuming the password had a typo, re-enters it, giving it to the hacker. The look and feel of the "invalid password" dialog is known because the hacker intentionally attempted a login with a bad password and made careful note of the dialog's behavior, copying that behavior pixel-for-pixel in the decoy.

"Grab" might also "go for broke" and attempt to finesse the victim into opening a malicious executable program, preferably with a really convincing-sounding name like "DB2 XML Update". "Do you want to install DB2 XML Update?" The hapless Elf wouldn't know what hit him!

If the hacker gets in undetected with shiny new admin privileges embezzlement isn't far off; a single sign-on grants access to the toy inventory. One can almost hear the hacker's thoughts: "It's like Christmas in here!"

3. Web App, Attacks 1 & 2: The Web App should escape-out all user-entered text, so that if the user enters "<script>...</script>" that exact text reappears on the form. Yes, you entered a script command, and whaddya know, it came right back atcha. No joy, pal. The advantage of this security policy is that it's simple and leaves a BIG-ASS footprint of an attempted hack. Even a computer-illiterate knows something is wrong: "Hey, what's this <script> thingy doing here? IT dept, help!" The disadvantage is that escape sequence expansions might cause buffer overruns in poorly-coded parsers. You've been warned.

Browser, Attack 1: The image might be disallowed by turning off "Display Mixed Content", but honestly if the Web app allowed an image tag that doesn't belong into an HTML document the browser is going to want to try to display it. You can always turn off "show pictures", but browsers are supposed to display images, so forcing it not to seems a poor choice.

Browser, Attack 2: The browser can be secured most easily by disabling JavaScript. However, there might be more nuanced ways of dealing with the sudden domain change which is the signature of this attack, like disabling cross-domain data access, disabling userdata persistence, etc. I think Mozilla actually has a "hijack preventor" option proper, right alongside "disable pop-ups". There's also a "warn when switching from secure to non-secure", but that assumes administrator functions run over SSL.

Email Fix 1: Personal firewall. If you have an email server you can set ZoneAlarm (is there truly any other?) to only allow outgoing connects by your email client to your email server. That's how I'm set up, so spammers can't tag me. Since I still have the HTML skeleton in my email messages I can right-click the broken links and open them in browser windows if I really want to see them. If you don't have an email server or personal firewall you can't really use this trick conveniently.

Email Fix 2: Text-only. If someone sends you JavaScript you see their code ... instead of running it! (JPG bugs are the same: you see the tag instead of downloading the image.)

Email Fix 3: Since "personal firewall" is not part of the Email Client proper I haven't really met the parameters of the assignment with "Fix 1", so I need to come up with one more ... attack #2 (hijack) is a no-brainer; disable JavaScript. Attack #1 can be thwarted by disabling "show images", but that will disable images in your browser as well. This fix meets the parameters of the assignment, but I don't consider it very elegant. If my Mozilla install hadn't just gone bad on me, forcing me back to IE, I'm sure I would have a much better answer.

That's the best I could do. I hope it wins me a book! ;)

Derrick Jones, Software Developer

Send me some e-mail