Rudolph7

By David Hale

1. What is the purpose of the first malicious wish text, and how does it work?

The purpose of this text is to alert the hacker when an administrator has viewed his wish in a browser, and to save pertinent information about the computer they are using such as IP address, etc.

First, by submitting these hacks, the hacker is assuming that their text will be viewed in a browser by the admin and will be interpreted as HTML. If it were to be viewed as text only, this method would be foiled.

It is using a standard image HTML tag, which is generally benign. The height, width, and border are set to 0 so that the administrator will not even know that this text has been executed in his/her browser. The real trick is how the JPG file is set up at the source web server. At a minimum, the hacker will be able to refer to their web logs and see who has been accessing this specific file. In addition, though client browser will need to receive a JPG file back (or a file of the same MIME type), the host server may actually have executable code inside Sample.jpg, which actually returns a JPG file after it is completed executing. Since this code is executed on the server rather than the client, it can only document information about the client such as IP address, etc, rather than doing something harmful to the client.

2. What is the purpose of the second malicious wish text, and how does it work?

The purpose of this text is to redirect the admin away from the current page that they are viewing, to another one located on the hacker's site. Cookies stored for one domain are normally not available to another domain, but by appending the DOM cookie object to the URL string, they will be passed to the next web server being redirected to on the URL line.

Like the first image hack, this works under the assumption that this text will be viewed in a browser rather than as plain text. This HTML tag is a JavaScript code snippet, using the document.location function to redirect the user to another URL. It is executed as the browser locates this section of text, discards the page being rendered, and redirects the browser to the URL specified.

The CGI application being called is executed on the web server, but since it is passed a URL string, it can store this data in a database, as well as other standard header data such as the referring page. The reason that this is a problem is that most session login data for web apps are stored in the cookie. As long as the web developer wasn't foolish enough to store the login and password in the cookie, it offers some security. But knowing the admin's session_id or other similar variables, the hacker may impersonate the admin, by manually setting the same cookies before going to the administrative application (based on the referring page), bypassing the normal login security as long as the admin hasn't already logged out of the application or that their session has timed out.

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 app can be modified on the form submission page to replace all HTML brackets with escape characters so that they are displayed as the same text as was typed rather than being interpreted as actual HTML code. Each text form field will need to be checked. This is easily done using JavaScript functions before the form is submitted. This assumes that the children should be allowed to enter these brackets as part of their regular text.

If the form is posted via a GET rather than a POST, the hacker can bypass this JavaScript check and modify the URL line and include the hacked text. So if this is the case, the application should be modified to use the form POST method rather than GET.

Another approach to modify the web app may be on the admin viewing page (rather than client submission page) to similarly replace all open/close brackets with their escape characters. So even if they have sumitted a bit of hacked text, the admin can see it for what it is, rather than having it executed in their browser.

Finally, the security settings on the Admin users can be set to not execute JavaScript or to accept cookies. The problem with this is that depending on how the Santa application is written, it may depend on both JavaScript and/or cookies. For added security if the elves don't need access to the entire internet, their proxy settings may be set to disallow access to external sites, or to only those which are known to be safe.

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?

These same problems exist when accepting HTML email. The text is executed as HTML rather than as plain text. The admin's email settings may be changed to only display the email as plain text. For more security but allowing HTML email, the browser proxy settings may be set to a proxy server which doesn't allow access to external sites or to only those which are known to be safe.

There are a number of spam filters which will review mail automatically for dangers such as this, and prevent them from arriving at someone's inbox, either deleting the message, putting it into quarrantine, or converting it into plain text. (It is better to have a site-wide detection method rather than depending on local users configuring their email correctly to block these email attacks)

Send me some e-mail