Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2010-11-03 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Vulnerability in Internet Explorer Could Allow Remote Code Execution (CVE-2010-3962)

Published: 2010-11-03
Last Updated: 2010-11-07 14:30:10 UTC
by Kevin Liston (Version: 6)
5 comment(s)

Microsoft has announced a vulnerability in all currently-supported versions of Internet Explorer (6 through 8) that could allow the execution of arbitrary code (advisory 2458511- http://blogs.technet.com/b/msrc/archive/2010/11/02/microsoft-releases-security-advisory-2458511.aspx.) This would likely be leveraged in a drive-by-exploit scenario. They state that DEP (Data Execution Prevention) and Protected Mode are mitigating factors.

 

UPDATE: Symantec has details on the targeted attack here: http://www.symantec.com/connect/blogs/new-ie-0-day-used-targeted-attacks

UPDATE2: Added MSRC Blog link.

UPDATE3: Added CVSS Base.

UPDATE4: Noting that exploit code is in the wild.

UPDATE5: IDS signatures are available

CVSS Base: 9.3
Exploit code: publicly-available
Workarounds: available, DEP, EMET, and CSS-override.
Patches: unavailable
IDS signatures: available

Keywords:
5 comment(s)

Defeating Drive-by Downloads in Windows

Published: 2010-11-03
Last Updated: 2010-11-04 02:05:47 UTC
by Kevin Liston (Version: 5)
19 comment(s)

The Problem

Drive-by Downloads have been a problem for a number of years now. This avenue of attack has become more popular as attackers have developed more techniques to direct visitors to their exploit websites. The three most common scenarios are: Search Engine poisoning, malicious forum posts, and malicious flash ads. These are complex, multi-step attacks that build upon each other to eventually install some sort of malware on the victim's machine. I call this series of steps the "Chain of Compromise" (I've also heard this described as the kill-chain.) It's our job as the defense to break that chain as early as possible. If we allow it to complete, then we have a real incident on our hands.

Countermeasures

There are a number of system countermeasures that you could use to defeat drive-by attacks. I've got an incomplete list below comparing their average cost to install, both monetarily and a vague measure of the amount of technical effort required.

 

Countermeasure

Cost

Tinker-Factor

Anti-Virus

Free to $80 USD

Low

Web-filter

Free to Thounsands

Medium to High

Alternative Browser

Free

Low to Medium

No-script

Free

Medium

Adblocker

Free

Low

Flashblock

Free

Low

OpenDNS

Free

Medium

Alternative Document Viewer

Free

Low to Medium

Executable Whitelist

Free to Hundreds

High

Full-proxied Environment

Hundreds to Thousands

Medium to High

IPS

Free to Thousands

Medium to High

Disable Administrator rights

Free

Low to Medium

Masqurade User-Agent

Free

Low

DEP/ASLR

Free

Low to Medium

 

  • Anti-Virus: not much to say about this, everyone has it now, and it's the countermeasure that gets the most attention by attackers. It's easily evaded with minimal effort.

  • Web-filter: this could be on the system itself, or injected through a web proxy. Free options include K9

  • Alternative Browser: something other than IE or Firefox. By moving to a less-popular browser you stepping out of the line of fire in most cases. At least is reduces your attack surface to your office/document viewers (e.g. Flash, Acrobat, etc.)

  • No-script: allows you to block execution of javascript on new/unknown sites.

  • Adblocker: typically used to avoid annoying advertisements, a bit controvertial since websites are supported by their ad revenue, but more often becoming a necessity due to poor quality-control/security-measures by ad-servers.

  • Flashblock: like no-script, but for flash. Allows you to run flash when you need it, and block it from unknown/unexpected sources.

  • OpenDNS: if you use OpenDNS for your domain name resolution, it can block requests to suspicious/malicious destinations.

  • Alternative Document Viewer: use an alternative PDF viewer to avoid a number of Adobe Acrobat vulnerabilities and avoid executing unnecessary code. You'll likely lose the ability to use interactive PDF forms, but you could always keep a copy of Acrobat Reader handy for the few times you need it.

  • Executable Whitelist: this is ideal defense against unknown code executing on your system. It's also extremely difficult to maintain over time.

  • Full-proxied Environment: don't let your systems have direct access to the Internet. Proxy all out-bound requests. This is extremely effective against most backdoors and infected systems reaching out to command and control servers via something other than HTTP/HTTPS (those ofen hijack the browser for this purpose and thus inherit the proxy settings.)

  • IPS: Either a host-based or network-based IPS system capable of blocking known exploits.

  • Disable Administrator Rights: is the victim account is not running as administrator some of the follow-on damage from a compromise can be limited. However, this does not prevent the compromise in most cases.

  • Masquerade User-Agent: some browsers and some add-ins allow you to alter the user-agent and other identifying information to thwart targeted attacks.

  • DEP/ASLR: Data Execution Prevention or Address Space Layout Randomization helps protect Internet Explorer from certain classes of exploits at the cost of some functionality.

Now we'll see how these countermeasures stack up against the attackers in a few scenarios.

Scenario 1: Search Engine Poisoning

In our first scenario, the attackers have set up a network of compromised websites that redirect the visitor to one of their exploit servers. The exploit server has some javascript on it that effectively scans the potential victim for the versions of the browser, java, flash, and PDF client. Based on the results of the scan and the geo-location of the victim's IP address the exploit server launches a targeted attack against any vulnerable browser, java, flash or PDF client on the system. If this attack is successful, the victims machine will download a payload from their payload server. This is exploit-as-a-service, where this criminal group offers the delivery of another criminal group's payload to a certain number of IP addresses in a certain geographical region. This is how they make their money: they build an maintain the infrastructure of redirect servers, exploit servers, and download servers, this infrastructure is then rented out to other groups. In addition to building the infrastructure, they also spend a lot of time promoting their redirect sites in common search engines.

So, in our scenario, our victim goes to their favorite search engine looking for "holiday cookie recipes" and in their search results are a number of links that lead to one of our attacker's redirect sites. Let's say the victim queues up a number of requests in their browser tabs.

  1. The browser will open up a connection to one of the redirect sites, it will have a meta-refresh, or iframe, or return a 302 to direct the user to the exploit site.
  2. The exploit-site delivers a set of javascript routines to the browser.
  3. These routines identify version information for: the browser, java, flash and PDF reader.
  4. The exploit server returns the exploit that is most likely to succeed.
  5. The victim's application is exploited and commanded to pull down and execute the downloader code (either from the exploit site itself, or the downloader site)
  6. The downloader code is executed on the system, this downloads additional payload and executes this on the victim's system.
  7. Victim's system now needs to be re-imaged.

Use this table below to map out which countermeasures are effective at which stage in the attack. Keep in mind that the earlier you break the chain, the better it is for your environment. Compare this to the costs above and see if you can identify the best defense strategy for this scenario.

 Key: "-" denotes no impact, Potential means that under the best conditions the countermeasure is effective, Likely means it's effective more often, and Complete is near-certain that it works.

 

Redirect Site

Exploit Site

Java-script Recon

Browser Exploit

Flash Exploit

PDF Exploit

Download Site

Downloader code

Secondary Payload

Command and Control Established

Anti-Virus

-

-

-

-

-

-

-

Potential

Potential

-

Web-filter

Potential

Potential

-

-

-

-

Potential

-

-

Potential

Alternative Browser

-

-

-

Likely

-

-

-

-

-

-

No-script

-

-

Complete

-

-

-

-

-

-

-

Adblocker

-

-

-

-

-

-

-

-

-

-

Flashblock

-

-

-

-

Complete

-

-

-

-

-

OpenDNS

Potential

Potential

-

-

-

-

Potential

-

-

Potential

Alternative Document Viewer

-

-

-

-

-

Potential

-

-

-

-

Executable Whitelist

- -

-

-

-

-

-

Complete

Complete

-

Full-proxied Environment

-

-

-

-

-

-

-

-

-

Likely

IPS

-

-

Possible

Likely

Possible

Possible

-

Possible

Possible

Possible

Disable Administrator rights

-

-

-

-

-

-

-

-

-

-

Masquerade User-Agent

-

-

-

Possible

-

-

-

-

-

-

DEP/ASLR

-

-

-

Possible

-

-

-

-

-

-

Scenario 2: Malicious Forum Post

In our second scenario, our same attacker group is hosting an exploit infrastructure and getting paid to install malicious payloads. Instead of using search engine poisoning and redirect sites, they are exploiting vulnerabilities in common forum software to inject iframes into forum posts. Here our victim is reading up on solutions to a pesky automobile problem, and is search internet forums for advice. They happen upon a thread that one of the attackers has placed a malicious comment. This kicks off the series of events very similar to Scenario 1.

 

 

Forum iframe

Exploit Site

Java-script Recon

Browser Exploit

Flash Exploit

PDF Exploit

Download Site

Downloader code

Secondary Payload

Command and Control Established

Anti-Virus

-

-

-

-

-

-

-

Potential

Potential

-

Web-filter

-

Potential

-

-

-

-

Potential

-

-

Potential

Alternative Browser

-

-

-

Likely

-

-

-

-

-

-

No-script

-

-

Complete

-

-

-

-

-

-

-

Adblocker

- -

-

-

-

-

-

-

-

-

Flashblock

-

-

-

-

Complete

-

-

-

-

-

OpenDNS

--

Potential

--

-

-

-

Potential

-

-

Potential

Alternative Document Viewer

-

- -

-

-

Potential

-

-

-

-

Executable Whitelist

-

-

-

-

-

-

-

Complete

Complete

-

Full-proxied Environment

-

-

-

-

-

-

-

-

-

Likely

IPS

-

-

Possible

Likely

Possible

Possible

-

Possible

Possible

Possible

Disable Administrator rights

-

-

-

-

-

-

-

-

-

-

Masquerade User-Agent

- -

-

Possible

-

-

-

-

-

-

DEP/ASLR

- -

-

Possible

-

-

-

-

-

-

There's really not much different in this table, so an effective strategy targeting malicious search engine results is similarly effective against malicious forum posts

Scenario 3: Malicious Flash Ad

Much like the above two scenarios, but this one differs in how the victim reaches the exploit. In this case, during their lunch hour they browse over to their favorite news website. It's in your company's web-proxy whitelist because it's a "trusted site." Unfortunately, that website's advertisement broker didn't detect the redirect code hidden in the flash ad, so now your victim, who didn't click on the advertisement, is silently redirected to the exploit site.

 

 

Visit Exploited News Site

View Malicious Ad

Exploit Site

Java-script Recon

Browser Exploit

Flash Exploit

PDF Exploit

Download Site

Downloader code

Secondary Payload

Command and Control Established

Anti-Virus

-

-

-

-

-

-

-

-

Potential

Potential

-

Web-filter

-

Potential

Potential

-

-

-

-

Potential

-

-

Potential

Alternative Browser

-

-

-

-

Likely

-

-

-

-

-

-

No-script

-

-

-

Complete

-

-

-

-

-

-

-

Adblocker

-

Likely

-

-

-

-

-

-

-

-

-

Flashblock

-

Complete

-

-

-

Complete

-

-

-

-

-

OpenDNS

-

Potential

Potential

-

-

-

-

Potential

-

-

Potential

Alternative Document Viewer

-

-

-

-

-

-

Potential

-

-

-

-

Executable Whitelist

-

-

-

-

-

-

-

-

Complete

Complete

-

Full-proxied Environment

-

-

-

-

-

-

-

-

-

-

Likely

IPS

-

-

-

Possible

Likely

Possible

Possible

-

Possible

Possible

Possible

Disable Administrator rights

-

-

-

-

-

-

-

-

-

-

-

Masquerade User-Agent

-

-

-

-

Possible

-

-

-

-

-

-

DEP/ASLR

-

-

-

-

Possible

-

-

-

-

-

-

Example Strategies

My parents' computer was compromised last week by Smart Engine (a FakeAV program.) They were running an up-to-date patched version of Windows 7 running Internet Explorer and anti-virus. So, they really didn't stand a chance. The default strategy of: move to firefox and install no-script wasn't a viable option because I didn't want to have late night phone-calls talking them through how to enable javascript so they could get a random website working. My option was to focus more on OpenDNS and K9 to help keep them from getting redirected to known malicious websites to begin with. Yes, they're machine is likely to get popped again but it's a bit less likely, and I don't have the certainty of increased familial tech-support calls.

If you look at the tables above, you'll note that the average user running Internet Explorer, Shockwave, and Acrobat Reader relying only on Anti-virus doesn't stand much of a chance. On the other end of the spectrum, an environment that relies only upon Executable Whitelist will certainly break the compromise chain, but very late within the event and at a likely-large cost of effort. When we give advice we often recommend, firefox since it can support addons like adblock, flashblock, and no-script. When we make such recommendations it never fails that someone will complain how their environment and circumstances are different. This is the primary motivator behind my capabilities-matrix approach. You can evaluate what countermeasures are appropriate/affordable/possible in your situation and perhaps help determine if the payoff of a countermeasure is worth the investment.

A Note About Virtualization and Sandboxing

An alternative strategy to breaking the chain of compromise is to make it a non-issue if the machine gets compromised.  This is where one-use virtual sessions (or something like DeepFreeze) come into play.  If you want to reimage/rebuild they system after every work session that too is a pretty good strategy of making the drive-by exploit problem go away.  It's all about what works for your environment and organization.

 

UPDATE: to add IPS, Disable Administrator Rights, and Masquerade User-Agent countermeasures.

UPDATE: added DEP/ASLR

UPDATE: added Virtualization and Sandboxing

UPDATE: replaced "none" with "-" in tables to improve legibility.

Keywords:
19 comment(s)

Adobe Shockwave Player "Shockwave Settings" Use-After-Free Vulnerability

Published: 2010-11-03
Last Updated: 2010-11-03 15:12:16 UTC
by Kevin Liston (Version: 1)
0 comment(s)

Juha-Matti reports that an odd Shockwave vulnerability has been identified (http://secunia.com/advisories/42112/.) I call it "odd" because it's not the typical "download crafted flash file and it executes code." The victim has to open the Shockwave settings window while having the malicious website open. It's a new hurdle, but I'm not sure that it's insurmountable.

There is currently no CVE or response from Adobe.

Keywords:
0 comment(s)

SQL Slammer Clean-up: Roundup and Review

Published: 2010-11-03
Last Updated: 2010-11-03 02:14:11 UTC
by Kevin Liston (Version: 1)
1 comment(s)

Cyber Security Awareness Month is over and with it the SQL Slammer Clean-up Exercise. While SQL slammer is still very much present on the Internet, many unstated goals of the exercise were met. There was a bit more going on behind the scenes that I would like to now share.

Why an exercise?

Firstly, why have a CSAM exercise? Quite a bit of effort goes into the CSAM daily topics over and above the daily Incident Handler's tasks. Some thought that this exercise should have been put off until November. I wanted to have something during the month that technical, non-policy-makers could participate in. It was intended to be a Technical Track to supplement the Policy Track. Also, I wanted to experiment with a new Handler Diary format, linking together a number of articles produced while I'm not actually the Handler of the Day.

Games are great way to teach people, it gets them involved, and there are few methods that teach a skill more effectively than actually doing it. The exercise was modeled as a game. It has boundaries, a beginning and end, and a way to keep score. This particular game was co-operative (although I suppose you could consider it as "Us" versus Slammer,) the boundary was the Internet, it started October 1st, 2010 and ended November 1st, 2010. For the purposes of scoring, I'm using my darknet sensors and a single snort rule to determine a Slammer attack from a simple MSSQL scanner (more on scoring below.)

Why slammer?

SQL Slammer was chosen as the exercise target for a number of reasons. Although it is well-understood (http://www.sans.org/security-resources/malwarefaq/ms-sql-exploit.php,) it was chosen largely due to its ubiquity. There are very few networks that don't see these packet on their perimeter-- this meant that everyone could participate. Unlike other bot-nets and malware in recent circulation, there isn't a criminal organization behind it, so there should have been little risk for the participants.

My expectations

When I proposed this idea to the other Handlers, I was cautioned to not set my expectations too high, or make a wild claim or promise to rid the Internet of SQL Slammer in a month.

My expectation was to get perhaps 30 people or so involved and if we were really lucky and/or diligent we might get 4 to 5 of the top-talkers cleaned up.

Skills we developed/exercised

Now, for the insidious ulterior motive of the exercise. The primary intent of the exercise wasn't the eradicate SQL Slammer-- it was to get people looking at their logs again, and manually participating in the abuse reporting process. There's been too much reliance upon automated reporting, and the automated response to reports. It's just too easy to fire-and-forget with an abuse notification. Some organizations even set up XML services like ARF-feeds (Abuse Reporting Format see: http://www.shaftek.org/publications/drafts/abuse-report/) so you can have everything handled automatically. With the right infrastructure, this can be quite effective, but I think we can all agree that if a network has Slammer running loose on it, it probably lacks the infrastructure to support ARF.

I hope that the participants looked at their logs differently than they usually do, or that people who would normally quietly watch and study an event instead picked up the phone and contacted someone to get a system cleaned up.

Also, we learned a bit about what it's like when the shoe is on the other foot, when someone else is trying to contact us. Perhaps you found found something in your own WHOIS or abuse contact information that needed to be cleaned up.

At the very least, participants had to develop or exercise the "contact a third party" part of their incident response process. Did that run smoothly? Did the use of the spreadsheet to track the notification and response help you capture effective metrics for your process?

Finally, the results

If you pull up port 1434 on DShield it looks like the exercise did more damage than good. It started off the month with a low outlier of 165 sources and ended the month with an average or 235. the problem with the DShield data is that TCP and UDP are merged in that particular report. For scoring this exercise I'm relying on my own darknet sensors that monitor a couple of /16 netblocks. It has the advantage that I know that the monitored space and number of sensors hasn't changed in during the course of the exercise and I have full packet captures so that I can create alerts on only Slammer packets and rule out any other UDP/1434 traffic that may be present.

The Snort signature that I was using for the exercise:

alert udp any any -> any 1434 (msg:"W32.SQLEXP.Worm propagation"; content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|";
content:"|04|"; offset:0; depth:1;) My sensor saw a similar distribution of infected sources.  October 1st saw a low of 54 IP addresses and ended the month with 79.

The question remains: did I see any of my repeat visitors go offline during the exercise?

I filtered the results down to all of the IP addresses that visited more than 10 days in October, which gave me 47 systems to plot out over the month. Nearly 13 look to have gone potentially-silent during the month. I base this on the number of systems that don't have a mark present on the last few days of the month.  On the other hand there appear to be 2 that were potential new-infections. This sent me off on a focused analysis of just those two systems, the first (in Algeria) appears to be new visitor to my sensor, while the second has been a regular visitor for a long time, typically 4 to 7 visits a month.

Things I learned

Like any worthwhile exercise, I too learned a thing or three from the process. I was introduced to NFSen (http://nfsen.sourceforge.net/) and Abusix (http://abusix.org/)

One thing that I would have changed in managing the exercise is that we should have set up a role-base email address to handle the correspondence. This would have made tracking the participants of the exercise much easier and allowed me to organize and prioritize the emails more effectively.

Previous articles

Each entry was tagged for convenience and are available here: http://isc.sans.edu/tag.html?tag=slammercleanup

Cyber Security Awareness Month Activity: SQL Slammer Clean-up (http://isc.sans.edu/diary.html?storyid=9637)
SQL Slammer Clean-up: How to Report (http://isc.sans.edu/diary.html?storyid=9664)
SQL Slammer Clean-up: Reporting Upstream (http://isc.sans.edu/diary.html?storyid=9712)
SQL Slammer Clean-up: Picking up the Phone (http://isc.sans.edu/diary.html?storyid=9778)
SQL Slammer Clean-up: Switching Viewpoints (http://isc.sans.edu/diary.html?storyid=9811)
SQL Slammer Clean-up: Contacting CERTs (http://isc.sans.edu/diary.html?storyid=9841)
SQL Slammer Clean-up: Roundup and Review (http://isc.sans.edu/diary.html?storyid=9871)
 

Keywords: slammercleanup
1 comment(s)
Diary Archives