Skip navigation
All Places > Metasploit > Blog > 2006 > July
2006

Originally Posted by hdm

 

 

Web browser flaws are nothing new, but the professional crooks are finding new ways to combine these flaws into a system for turning a quick profit. This post describes an example of how one web site is combining system fingerprinting, browser vulnerabilities, email spam, fake web forums, and buggy PHP applications into an automated malware installation system.

 

If you would like to test your system to see if it is vulnerable to these attacks, please visit the Metasploit Browser Assessment web page.

 

Every couple of months, one of my family members asks to me to take a look at their computer. It seems like no matter what browser they use, or what security software they purchase, someone finds a way to infect their system with malware. Malware has become a fact of life for most Windows users and no amount of careful browsing or antivirus protection seems to make much difference.

 

A common myth is that the only way to get hit by a browser exploit is to visit "bad" web sites. The reality is that it only takes a single line of Javascript code to send your browser off to the darker areas of the Internet. Many respectable web sites are inadvertently allowing attackers to target their users. Just last week, the media covered an example where a MySpace banner ad resulted in over one million malware infections. This banner ad redirected the user to a malicious WMF file, that when opened, installed an adware application. A similar attack occurred on the LiveJournal network just a couple months earlier. In both cases, the web site operators were not aware that the attacks were occurring until someone complained.

 

Although banner ads are one of the more effective ways to attack a user, there are stealthier techniques available that an average PC user will never notice. Most web site visitor tracking programs use a script include tag to load client-side code from the tracking service provider. The browser will connect to the service provider, download the tracking code, and then execute that code in the context of the current web page. This technique is completely transparent to the user and provides an efficient method of tracking web site usage statistics. The same technique can be used by attackers to exploit browser flaws and trigger a malware installation.

 

The key requirement is that the attacker must be able to force the user to execute a small piece  of Javascript code. There are a number of ways this can happen:

 

  • Embed Javascript into a Flash-based banner ad
  • Send an email to each user with a link to a web site
  • Post a link inside blog comment spam
  • Post a link inside a web forum comment
  • Exploit a XSS issue to embed Javascript into a trusted web site
  • Trigger a PostBack link into a high-profile blog
  • Flood popular sites with bogus referrers


For an effective campaign, the attacker must find a way to automate as many of these tasks as possible. They need a network of compromised systems that can be used to relay spam, proxy web attacks, and host the malware install scripts.

 

In most drive-by malware systems, there are three separate components:

 

  • The traffic generator
  • The exploit engine
  • The malware payload


The traffic generator is any process that drives users to the web site containing the exploit engine. Examples include standard spam email, blog spam, or cross-site scripting attacks on high profile web sites. The exploit engine is set of tools that result in the malware payload being downloaded and installed. This usually takes the form of a browser-based exploit, but can also masquerade as some form of shareware application. The malware payload can be anything, common examples are remote control "bot" software and adware installers. The attacker has one goal in mind, to make money, and whatever the payload is doing, it directly contributes to the income of the attacker.

A couple days after we published the Malware Search Engine, an individual who goes by "Dude VanWinkle" emailed me with a link to a web site that contained a half-dozen different browser exploits. This web site (www.jag.mews.ru [offline]) was serving up an Apache directory index:

The Internet Explorer exploits immediately caught my attention -- it is always interesting to see what the professionals are doing with exploit code. A quick Google search for ie0601.cgi returns about 150 results, all of which are spam linking to this attack, forum logs of folks complaining the site, or research reports from one of the antivirus or security firms.

The "ie0601.cgi" script is just one version in a series of drive-by installers called 'Web-Attacker'. This CGI script is a combination of exploit engine and statistics tracking interface for automating malware installation through exploits. Other versions of Web-Attacker in the wild include ie0509, ie0604, and most recently, ie0606. A handful of security companies have already written descriptions of the new Web-Attacker and IDS signatures are available for Snort from the Bleeding Snort project. The source code for Web-Attacker is reportedly for sale from a Russian web site for less than $20 USD.

The unusual thing about the Web-Attacker code is the level of fingerprinting it performs prior to attempting an exploit. The script detects the operating system, service pack,  Java Virtual Machine version, and the existence of two common antivirus products before selecting the exploit vector. This is different from the shotgun approach used by most malware install scripts and results in much higher hit ratio against the average PC user.

This script is capable of compromising any 32-bit version of  Windows, from Windows 95 to Windows 2003 (and Vista builds, if they bothered to enable the WMF exploit for that version). Windows 98 users who scoff at the flaws discovered in Windows XP will have to change their tune if they still have the default Microsoft Java Virtual Machine installed. Mozilla users are at risk as well, but only those using fairly old versions of the browser.

This combination of automated fingerprinting followed by a targeted attack should serve as wake-up call to anyone who believes that a patched flaw is no longer a significant threat. The Java ByteVerifier bug used in this script was fixed in April of 2003, over three years ago, yet still works well enough to be a key component of this malware installer. The fact is that an advanced malware installer is capable of attacking almost any browser or operating system and still succeed against enough people to make money for the attacker.

Windows is the most common target, not only because it has the largest user base, but because the adware and profitable forms of malware have not been ported to other platforms. As the market share of non-Windows operating systems rise, we should expect to see similar attacks appear as soon as the numbers make it worthwhile to develop them.

The success of any drive-by malware campaign can be measured by the amount of traffic reaching the exploit engine and the success rate of the engine itself. If the attacker can push 30,000 users through their engine a day and obtain a 1 in 10 hit ratio (a very realistic number with recent IE vulnerabilities), that is still 3,000 installs a day, with the adware company paying the attacker for approximately 1 out of every 5 installs (based on whether the victim uninstalls the adware or complains). Average payment, per successful install, is about $0.40 USD. This works out to about $240 USD a day or a little over $7,000 USD a month. 

A smart attacker can combine two or three adware affiliate programs to make double or triple this amount. Adware is only part of the equation though, with the appropriate payload, it is possible to make up to $1.00 per successful install, by abusing pay-per-search and pay-per-click business models. With any business, there are also expenses, and all of the things needed to drive traffic to the exploit engine also cost money. An anonymous source quotes a traffic cost of between $2.00 and $5.00 USD per 1,000 hits to the installer. This includes hosting costs for the installer and spam engines, as well as payments for banner ad distribution. These numbers are all estimates obtained from a few anonymous sources.

Switching back to our example, we also see a file called "shells.txt" sitting in the web directory. This files contains a list of URLs that lead to an administrative interface on 682 different systems. Every one of these systems is vulnerable to one or more PHP web application flaws that allows a remote script to be loaded and executed. The URLs cause each vulnerable system to the load the r57shell administrative interface from another attacker-controlled web site. This interface allows system commands to be executed, arbitrary files to transferred, and any local databases to be searched and modified. These 682 systems are used as drones to carry out the traffic generation phase of the campaign.

Another use for these drones becomes apparent if we look at the "ddos.php" page in the same directory. This PHP script (self-titled the "Cyber DDoS System") uses the list of URLs found in shells.txt to carry out large-scale denial of service on any target of choice.

Under the "seo" directory, we find a user interface for the "Forum Generator" web application. This tool is used to drive traffic to a web site by creating fake web site forums containing a specific keyword. This software is also available for purchase from a Russian web site.

More Web-Attacker resources:

RASMANS, DHCP, Registry

Posted by rapid7-admin Jul 13, 2006

Originally Posted by Pusscat

 

 

Last month, while working on the RASMANS "registry corruption" bug with HD, I noticed something odd.  The way the bug works is that every time you call the function, the current registry key is deleted and a new one is created with your custom information.  You control what is put into the registry key, and the value can be unlimited. The actual deletion and creation is done with windows api calls, and the RPC function is just a remote interface to the modification of those specific keys. Seems pretty safe. The only problem is that the API to modify a registry key has a little problem. If the key is over a certain size, a stack based buffer overflow occurs and you're in trouble.  The exploit works by just calling once to set the key to a huge value, then calling the function again to have our huge value deleted, thus triggering the overflow.

 

The overwrite occured inside the reg function, but nothing in ADVAPI was changed. So the problem was either ADVAPI or some argument to it... I forgot about this for awhile due to a flood.

 

Well, it's MS Tuesday again, and what do I see? MS06-036. A quick bindiff, and 15 seconds looking at the changed function, and I knew immediately what the vulnerability was. Registry registry registry.

 

I'll leave it as an exercise to the reader to find what other remotely accessible services let you write an arbitrary value to a registry key with RegSetValueExW.

 

UPDATED.
The bug exists in the improper use of the Registry functions. (Alex Sotirov clued me in to this.) Apparently, they take a buffer size in TCHARs rather than in chars (or bytes), and many functions that call them incorrectly assume the size is in bytes. So you can probably still find vulnerable functions, but the only way to fix it is to find every function that has incorrectly given the buffer size and fix it manually. This is no easy task in the least. My apologies to MS and to the rest of you for the misinformation ;)

 

Still, it's certainly worth the time to hunt down all remotely accessable functions that allow you to set registry keys to find this problem. Thanks Alex!

Month of Browser Bugs

Posted by rapid7-admin Jul 2, 2006

Originally Posted by hdm

 

 

Ove the last few months, I have taken an interest in web browser security flaws. This interest has resulted in my collaboration on a few fuzzing tools (Hamachi, CSS-Die, DOM-Hanoi), a blog post, and  a  SecurityFocus article. The vendors have been notified and the time has come to start publishing the results. I will publish one new vulnerability each day during the month of July as part of the Month of Browser Bugs project. This information is being published to create awareness about the types of bugs that plague modern browsers and to demonstrate the techniques I used to discover them. Enjoy!

Filter Blog

By date: By tag: