Bofra/IFrame After Action Review. At SANS we teach a six-step approach to incident handling (if you want to learn it, see our Security 504 class, Hacker Techniques, Exploits & Incident Handling, http://www.sans.org/cdieast04/description.php?tid=145 )

Saturday's banner ad incident that exploited the IFrame vulnerability in Internet Explore is an excellent case study in how to do incident handling on a global scale. Now that the dust has settled a bit, it is time to do step six, Lessons Learned.

Let's begin by walking through each of the steps as applied to this case.

1. Preparation. Prior to any incident, a trained incident handler already has in place notification lists, checklists, policies, and a host of other items to assist when an incident begins. The Storm Center maintains a contact list of people and organizations to call in case of an emergency. Because all of us are volunteers and not employees of SANS, we have standing procedures and policies for how we handle and disclose sensitive information in order to protect SANS as well as the individual volunteers. We also have the handler's diary, a web form for readers to communicate with us, and of course the DShield database (which is currently down, but we'll leave that story for another diary.) Preparation is what you do when there is no current incident under investigation. Think like a Boy Scout - BE PREPARED!

2. Identification. This incident was brought to our attention via an email from "Mark" early on Saturday morning. We rely on several channels for identifying emerging Internet incidents, and our online web form was the vehicle for finding out about this event. Other mechanisms we have are direct email contact, phone calls, the DShield database, plus most of the handlers are watching popular online chat groups and discussion forums for news of breaking events. Without a good mechanism for identification, it is hard to know that an event or incident is occurring.

3. Containment. When an incident is identified, the next step is to contain it so that it does not spread. After confirming that Mark's report was valid, we quickly notified the site that was affected (The Register) plus the UK's National Infrastructure Security Co-ordination Centre, which is the UK's government sponsored organization established to defend their Critical National Infrastructure (CNI) from attacks. Mark had also sent an email to The Register advising them of the problem. At that time, we did not know what the exact nature of the problem was, only that The Register seemed to be the source of the pain. Later we found out that it was a third-party advertiser, Falk eSolutions. Within an hour of the incident being reported, Falk had been notified by The Register and the problem stopped. Many incident handlers want to skip this step and rush into the next step, but we recommend thinking like a firefighter - contain the fire first so that it won't spread, then pour water on it.

4. Eradication. Once contained, the problem can be further investigated, hard drives removed from the servers for forensics or evidence gathering, and other steps taken to clean the intruded systems. The Register and other sites affected by this incident turned off their banner ads, effectively eradicating the problem from their web sites. However, they did this at great cost since their revenues are driven by banner ads. We do not know what Falk and the others did to eradicate the malware from their servers. In this step, it is important to ensure that further damage did not occur through the installation of root kits, key stroke loggers, or hidden back doors.

5. Recovery. Several of the affected web sites have yet to fully recover from this incident even though nearly three days have passed since it started. Not only is there a loss of revenue caused by turning off banner ads, but also a loss of customer trust in the sites. It may take days or weeks before the affected sites have fully recovered. We have not mentioned the potential damage to Microsoft's reputation but that also must be taken into consideration when you consider that except for WinXP SP2, the Internet Explorer has no patch for this vulnerability. It will come back again to visit more unprotected sites.

6. Lessons Learned. The hardest part of handling any incident is trying to figure out exactly what happened and to learn from it. A great technique to help in this step is to make sure that you are keeping good notes. Since last Saturday morning, I've been keeping track of what time certain things happen, who I talked to, what was said, actions taken, observations, etc. From my perspective, here is what I think happened:

- Some time last week one of Falk's load balancing servers was intruded into via a known vulnerability. Going out on a limb here, the most likely cause was that one of the servers got out of sync with the others and a previously applied patch was reversed, perhaps due to software upgrade or other routine maintenance operation. That's just speculation and I'm sure that eventually we will hear the true story.

- Once inside the server, the attacker was able to modify banner ad code to point to another compromised site (search.comedycentral.com, 199.107.184.146) where additional malicious code had been placed. It is not known when Comedy Central was intruded into.

- The first recorded incident in this intrusion set happened on Friday night, but we did not hear about it until Saturday afternoon. "Mike" reported that about 100 hosts in his network hit the Comedy Central site and downloaded malicious software the previous evening. We don't know how they reached the infected server, but it's likely that it was not through The Register since Mike's network is in California.

- Through the day on Saturday we received several other reports of sites that had pointed viewers toward the Comedy Central server. By mid-morning on Saturday the infected sites were off-line.

In summary, it looks like Comedy Central and perhaps some other sites were compromised first, followed by Falk. Then, Falk's site was configured to redirect visitors to Comedy Central. High-profile web sites like The Register use Falk's AdSolution Global service to place banner ads on their pages, and roughly one in thirty hits resulted in a re-direct to the hostile site.

The Register has a notice about the attack online, plus a statement from Falk:

http://www.theregister.co.uk/2004/11/21/register_adserver_attack/
http://www.theregister.co.uk/2004/11/22/falk_bofra_statement/

"Matt" has been keeping a running log of his findings at
http://www.finlandforum.org/bb/viewtopic.php?t=7685

Finally, LURHQ has their nice write-up at
http://www.lurhq.com/iframeads.html

One more thought on this, and a request for comments. The IFRAME issue does not affect Internet Explorer on systems running WinXP SP2. The question is "why?" Is it because SP2 turns off certain scripting features? Or is it the way SP2 handles buffer overflows (stack protection)? We'd like your thoughts on this. The reason is to better understand why SP2 protects IE users, and if there are any settings in SP2 that might make a user vulnerable to the IFRAME attack. If so, we'd like to get those settings made public so that users don't accidentally endanger themselves with unsafe IE settings in SP2.
Marcus H. Sachs

Handler on Duty

Director, SANS Internet Storm Center