Thursday, October 21, 2004

If it's on your image, you must patch it

Patches were released and risk assessment on Microsoft Internet Explorer vulnerabilities was requested. I'm sorry to report that risk assessment of this particular type is rather simple. I can describe it in three steps. (1) The risk of the vulnerability being exploited is real, and high. The nature of the vulnerability itself doesn't much factor into the assessment. What matters most is how many systems do you have running the software with the vulnerability, and how important are those systems. If history is any guide, these vulnerabilities will be exploited by dozens, hundreds, or even thousands of variants of malware, over the next days, weeks, and months. Recently announced vulnerabilities affecting the Microsoft Internet Explorer can be used to install and execute software on the system, when that system has accessed a malicious or benevolent-but-compromised web site. Vulnerabilities like this one have been exploited by literally hundreds of bits of malware in the last year. They are very difficult to trace back to an origin, but it is likely that at least one of our "W32.spybot.worm" infections came in via one of these types of holes. Most organizations presently have no defense against MSIE holes, other than patching. Most don't filter outbound http connections, and have no protection in place against this vulnerability. Most organizations don't offer a more secure web browser to their staff, such as Mozilla FireFox, as an alternative to MSIE. Even if they did, it's not practical to remove MSIE from the system image, and therefore one must patch MSIE anyway. (2) The potential cost of an infection on our network is very, very high. For most organizations, the patch management strategy is not perfect. Remote exploits in Windows within the last six months have resulted at one client site in at least 1,000 total compromised machines on the network. Most of these also contacted one of several outside IRC servers (overseas), for further instructions. (That's how these infections were detected). One of these systems was infected on October 4, 2004, several days before the Intrusion Detection System (IDS) was able to detect the infection (the ruleset to detect the new threat didn't exist on October 4). A few files left behind on the system indicate that it was able to receive instructions via the IRC channel to install other spyware and adware. Who knows what else happened on that box, and the other hundreds of boxes infected. MSIE holes can be used to launch attacks from the compromised host to the rest of the internal network, bypassing the firewall. The software installed on a single system through one of these browser holes could be a "bot" with the ability to probe inside the network looking for one or more other security holes and using them to propagate automatically to all vulnerable systems. Chaining unrelated security defects like this is a proven technique that has been used by malware (see "Virus, Worm, and Malware Evolution", which links to articles describing a very complex chain exploited this past spring which involved a number of compromised "trusted" web sites). Bots like this install adware and spyware, attempt to disable antivirus software, steal passwords, steal identity information, attempt to spread via many different types of exploits to other systems both within our network, and out to other networks, and allow external operators to execute arbitrary instructions on the compromised systems. In other words, they can, and do, anything they want to do on the compromised system. (3) In this risk assessment, there is no "step 3". Risk assessment on individual Microsoft Internet Explorer vulnerabilties is not meaningful. This is true for any and all other software on your Windows system image as well. Defects which appear to be low risk can be easily chained together with other system defects to result in a dramatically elevated risk. In some sense, this complicates the assessment of risk, and reduces opportunity to save operational costs by choosing which patches to deploy. Fortunately, the simple rule, "If it's on the image, we must patch it" can be used to mitigate these large, growing and very real risks due to exploit chaining. By the way, exploit chaining receives very little attention in the anti-virus dominated trade press. You will find only 16 references to the quoted exact phrase in google, including a few "how to hack" guides, a few analysis papers, and zero articles. However, please be advised that this technique has been known and used by "black hats" for several decades. Within the last year, automated exploit chaining was demonstrated to great effect. The Grim Reaper, the Bearer of Bad News (TM) am I. But really, I think that all is not lost. Most organizations do some stuff which helps reduce the extent of damage that they can suffer from these threats, and there is more that can be done. If you can't sell all these Windows PC things on eBay and replace them with Mac OS X systems, you have certain other options available to help with prevention of this type of browser-crawl-back exploit and the resultant, inevitable and extant exploit chaining. I recommend:
  • Apply all security patches to Microsoft Internet Explorer, and to Microsoft Windows, as soon as is feasible following their release. We have observed a few recent infections were confirmed to come through a hole in Microsoft Outlook. The client organization elected not to patch it, ostensibly because they don't use the software. Like MSIE, Outlook cannot be easily removed from the system image. If it's on our image, we must patch it.
  • Deploy a web proxy architecture with an antivirus plugin which allows you to filter http connections and provide some degree of meaningful protection against these browser crawl-back exploits. There are client-side and network based options. I prefer the network based systems because it eliminates the need to maintain Yet Another Software Package on the PC.
  • Deploy FireFox as an alternative web browser, and encourage staff to use it to the greatest extent possible. (Certain web sites employ proprietary techniques which work only is MSIE browsers, and sometimes only on Windows.) The design of the FireFox browser makes it much, much simpler to package and distribute than MSIE, so that on those occasions when FireFox needs to be patched, it can be patched at a much lower operational cost.
  • Require all web sites developed by the organization to be web standards compliant (XHTML, CSS2, etc.) and require that they be tested and work specifically with Mozilla FireFox.

Wednesday, October 06, 2004

Slow Scanners & Sniffer worms

The discovery of the worm, which employed the technique of network sniffing, has shone a bit of light on a dark corner of the worm universe. W32/Sdbot-UJ has sometimes been reported as the first worm to perform network sniffing, but almost certainly it was not. It may have been the first such to be captured and analyzed by an AntiVirus vendor, I don't know. This worm employs a technique thought for years by some security professionals to be used by "slow scanners". I say "thought to be used" because it turns out this particular class of worms is difficult to study and not perceived universally as much of a threat. Some professionals even dispute whether Slow Scanners exist, yet. (Everyone seems to agree that if they don't, they will soon enough.) Slow Scanner worms are not widely reported in the media, partly because they are not as flashy as the worms that hit millions of machines in a day and whose propagation efforts are so aggressive that they bring the internet to a crawl. Slow Scanners are typically memory resident -- they don't write anything to the filesystem, they blink out of memory if you try to inspect them. They don't they don't do anything to the machine they infect. They don't write to the Windows registry, they don't open trojan backdoors, and they don't attempt to spread rapdily. Instead, a Slow Scanner performs reconnaissance of the local network environment, very, very slowly. They may send only a few packets an hour or a day, looking for certain open ports or other responses indicating a system type (say a router, or a Windows server or a BIND server) for example, or a particular vulnerability. The worm may not probe anything at all for hours or days. Slow scanners gather data about a network, often by "scanning", sending packets out to see what sort of response comes back. But Slow Scanners don't just scan, they also gather data by sniffing and keystroke logging. After gathering data for a while, the worm will report back out to a web site or IRC channel or email address. After sending a single report, it may blink itself out of memory. Other worms do most of this stuff too, but Slow Scanners are very difficult to detect because they try to fly low and slow -- under the radar -- to evade detection. Once in a while they try to spread to another machine, but never to all other vulnerable machines they can find, just the occasional one, usually not within the same network segment. Slow Scanner Worms hint at a dark corner of the cracker underground, hidden beneath the noise of the script kiddies and their thousands of variant mass propagating worms, and the drone of frantic AntiVirus efforts. People running corporate and government networks want to believe the popular profile of the virus writer -- worms are written by bored teenage kids seeking attention in their peer group -- other bored teenage programmers -- and they don't really mean any harm. Increasingly there is evidence that at least some worms are written for profit, not fun, and possibly for other purposes, perhaps even tailored to a given victim network, such as espionage. Slow Scanners sport all the hallmarks of being written for a stealthy and sinister purpose: they are designed to perform network reconnaissance as a precursor to a sophisticated, targeted intrusion. They propagate very slowly, so as to evade detection, even by sophisticated heuristics (rules of thumb) in modern IDS/IPS and AntiVirus systems. Here are some links to stories about one of the first widespread sniffing worms. It wasn't a Slow Scanner, but it almost certainly borrowed a technique that's been used for years.

Technorati Tags: , , , , , , ,

Monday, July 19, 2004

Exploit Chaining: Virus, Worm, and Malware Evolution

All y'all might be interested in these articles. I've slogged through hundreds in the last week of evenings, and these are some of the most interesting. The first few regard using Internet Explorer features and defects for installation of trojans. With last Tuesday's release of several new Windows and IE vulnerabilities, it became clear that it was possible to chain together remote-non-root exploits and local-root-exploits, to gain Administrator access on a Windows system remotely, though indirectly. It seemed to me at the time that this would be somewhat complicated and we probably wouldn't see these types of exploits until the universe had harvested the low-hanging-fruit of remote-root exploits. After reading up a bunch this week (someday there will be pop music bemoaning the lonely nights spent with google...) I'm revising that opinion. There already exist documented examples of complex MSIE-exploit-chaining malware in the world, so we can expect to see more. Internet Explorer carved up by zero-day hole Hackers Manipulating Internet Explorer Add-Ons Internet Explorer Being Exploited Mozilla Feeds on Rival's Woes Trojan horse technology exploits Internet Explorer (This one is from 2002, but contains a good description of an interesting exploit, which, if I recall correctly, remains unpatched, and it's possible that some other Windows browsers are vulnerable to similar techniques.) The following articles discuss recent virii and worms using stealth techniques to avoid detection. This is just a sample of information I found on this area, and they don't even mention the simpler techniques used by most worms these days, like selecting process names that resemble or are identical to standard system processes, and polymorphic techniques like changing the process name at start time so it's different on different systems, etc. Stealth Virus is Stealthiest of them All Worm Sleeps to avoid detection Finally, here are some interesting related but miscellaneous bits. The "Worm Design" article is a five-year-old description of an experiment to fold many techniques into a single worm, and despite the poor grammar it's got some interesting and relatively clear descriptions of worm tricks. A few of these techniques have appeared in worms in the last couple years, and a few are becoming "standard" in modern worms. Worm Design Techniques This other article gives a hint about the complexity of virus and worm analysis, and I find it amusing. The author seems to have started out intending to simply explain at a high level how it's done, but then kept thinking of variant and exception cases that required different tools and techniques. The take-home lesson there is that even the people engaged in analyzing these things on a full time basis with the right tools and a well equipped lab have a hard time keeping up with just the technology evolution, let alone all the actual variants. Virus Algorithm Analysis - Kaspersky

Technorati Tags: , , , , , , , , ,

Wednesday, May 05, 2004

Virus naming & The Public Good

This appears to be a case where publicity about a particularly nasty worm has suffered because it was named something different by all the major antivirus vendors. Gaobot, which appears to be the Symantec name for this family of worms, isn't even in the title of this document. Microsoft machines and NDemon/Phatbot/Agobot Worms -- 19 Apr 2004 [Updated: 2004.04.27] It would be helpful to their customers if the AntiVirus vendors would agree to a common naming convention, and certain other standards related to identity of malware threats. A checksum should be provided with all descriptions, as well as standardized means to reference the known capabilities of threats. This probably won't happen unless an open source project, perhaps related to ClamAV finds itself so strong that the weaker AntiVirus companies suddenly find it to their advantage to play along. It's more likely that Microsoft will kill off the weaker AntiVirus vendors before that happens. The stronger AntiVirus vendors will eventually get out of the market, too, leaving a defacto standard -- the Microsoft Way, whatever that will be. It'll probably change every 18 months anyway.

Technorati Tags: , , , , , , , , ,