Tuesday, 6 July 2004

Jumping the hurdles: how Download.Ject infected

I thought I'd take a look at how Download.Ject infected, and the security barriers it managed to breach. I've gathered this together from what analysts have hinted at, so some information may be wrong.

Firstly, the attacker had to infect the web server. IIS has a feature which allows you to set a footer to be appended to every page. Internet Explorer parses content outside the <html> tags - but so does Firefox. Try this file:

<html>
<head>
<title>Test Page</title>
</head>
<body>
<p>Body</p>
</body>
</html>
<script language="javascript">window.alert( "Hello" );</script>

Opening this in a local file on XP SP2 gives you the Information Bar again; the Local Machine Zone has been locked down. You don't get the popup. Firefox gives you the popup.

Download.Ject exploited the Private Communications Transport (a secure sockets channel) flaw reported in MS04-011 to upload and execute arbitrary code. This uploaded code manipulated the metabase to add a footer containing a script.

The script in the footer, if run on Internet Explorer, exploited a vulnerability reported in MS04-013 which allows code to run in the Local Machine zone. It also repurposed the ADODB.Stream class, which is marked safe for scripting, to download files from the attacker's server to the victim's computer. The download was necessary to get code loaded into another process on the victim's computer. The effect of SP2's Local Machine Zone lockdown is that the script forced into the LMZ couldn't run. Note that no vulnerability in ADODB.Stream was exploited: it simply permits something that in retrospect is too permissive.

So the attacker had to have worked out how to exploit PCT, how to get arbitrary code running on the system with the user's full privileges, and how to get extra files downloaded onto the user's system. Administrators could have prevented the first by applying a megapatch; users the second by applying a patch.

No comments: