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.
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.
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
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