« July 2004 | Main | September 2004 »
Virus Bulletin Conference 2004 Abstracts
Abstracts for the 2004 Virus Bulletin Conference, taking place September 29 - October 1, 2004, at the Fairmont Chicago, Illinois, are up and look interesting. Here are a few abstracts that may look especially interesting to wormblog readers:
At VB 2003, Neal Hindocha and Eric Chien presented on the dangers of malware for instant messaging (IM). Commenting on the high rate at which this malware could spread, they stated that throttling approaches were unlikely to be successful.
Virus throttling is a technique to slow the spread of worms and viruses that prevents infected machines infecting others. It works well if the traffic generated by a spreading virus (contacting many different machines at high rate) is significantly different from normal traffic. Previous work has shown this technique to work well for most TCP/IP traffic and email. This paper applies the idea to instant messaging.
We have analysed data from the normal usage of a reasonable sized instant messaging server (710 users) and show that throttling is not only possible, but would be effective at slowing and stopping IM malware. We have also analysed the network over which this malware would spread, by looking at the buddy lists of all the users. We show that given the actual network connectivity, IM malware will not spread as quickly or as fully as Hindocha and Chien predict, and that if throttling were used, the effects of malware are much reduced. The throttling solution would be relatively easy to implement at the messaging server.
Source: Virus throttling for instant messaging, Matthew Williamson and Alan Parry.
It should be noted that appearantly AOL and other IM messaging servers already do throttling. You can see this by sending someone messages as fast as you can, you'll be told to come back and try again later.
This paper looks very interesting, essentially taking some cues from the human immune system by sampling potential antigens and reacting on the basis of heuristics applied to the observations.
This paper rejects as unrealistic the assumption that unknown novel viruses can be prevented from entering networks, and argues that the best solution to the new and unknown virus problem is rapid detection and elimination of viral spread. It presents a novel and minimally disruptive method to solve this problem that takes a proactive intrusion prevention approach on corporate email systems, and demonstrates an effective defense against a real attack. A user-definable number of records are read from the end of the Exchange Server tracking logs at definable intervals. Originator information is extracted and mapped onto a two-dimensional grid that represents the organizational structure of the company. As well as this being an automated solution the novel visual representation allows an administrator to manually monitor viral spread across the company and drill down to individual client machines. To minimize false positives, any machine emitting an above threshold number of emissions as defined by a user-profile database is quarantined and all suspect sent messages are put into recall on all destination company servers. After viral laboratory analysis of any suspicious sample, messages are allowed to continue or are deleted.
Source: Unknown virus detection and prevention, Paul Hodgson
The early email worms did not pay much attention to their target selection. They either picked all names from the address books, or any text similar to an email address from the web browser's cache. If they directly targeted other computers, then the IP address selection was completely random, resulting in a huge percentage of useless probes. Some new worms introduced more careful techniques trying to avoid unnecessary network probes. Overcoming the limitations of email address stores, they started generating possible email addresses themselves. The IP address selection also evolved, first concentrating more on the subnet of the infected computer, then using weighted selection of target subnets. Also, the Internet worms did not bother about the operating environment expect them on the targets. Some new worms already bring with themselves everything that is needed: if they use SMTP to spread, then include an SMTP server inside themselves; if they spread using infected web page, then install a simple web server on the target thus enabling the spread.
Mathematical modelling proves that the success of a worm depends on the initial seeding. Virus authors use various methods (bot networks, email seeding, Usenet) to start up their creations. The presentation will cover in detail these new techniques.
Source: Advanced survival techniques in recent Internet worms, Gabor Szappanos.
A good test environment has long been one of the most useful tools at the disposal of a malware researcher. While static disassembly of malicious code is the basis of understanding how it behaves, accurate information can often be derived faster by running the code in an isolated test environment.
The prominence of Internet-aware malicious software has led to several changes in the way malware is analysed. First, the speed at which a threat, such as an Internet worm, can spread, demands immediate information on just how dangerous it is and how it can be mitigated. On top of this, malware tends to rely more on Internet services in order to function. This complicates the process of testing the code in a secure, isolated system.
This paper will discuss using VMWare to create a test environment for malicious code. It will look at using VMWare systems for both automated and manual analysis, specifically concentrating on attempting to create a "virtual Internet". The aim is to fool malware into behaving as it would on the real Internet.
The paper will outline the advantages of such a "Virtual Net" - as well as some of the limitations - when analysing viruses, worms, IRC bots, DDoS agents, "blended threats" and more.
Source: Trapping worms in a virtual net, Hamish O'Dea.
August 30, 2004 in events, papers | Permalink
| Comments (2)
| TrackBack
Tell others: digg submit
del.icio.us this
Internet Motion Sensor
One of the things I have had the pleasure of participating in is the Internet Motion Sensor project at the University of Michigan. This project utilizes a novel, distributed architecture to capture and characterize emerging threats like worm propagation.
Networks are increasingly subjected to a broad spectrum of threats that impact the reliability and availability of critical infrastructure. In response, researchers and network operators have increasingly relied on monitoring to characterize and track these threats. This paper introduces the Internet Motion Sensor (IMS), a globally scoped Internet threat monitoring system whose goal is to measure, characterize, and track threats. The dark address sensors in the IMS extend simple passive capture using a novel transport layer service emulation technique to elicit payloads across all services, thereby addressing the issue depth of service coverage. To achieve breadth of coverage, the IMS employs a distributed infrastructure and utilizes sensors that are aware of their address diversity and their position in the actively routed topology. Finally, the IMS uses an innovative signature encoding and data warehousing system combined with a hierarchical architecture to realize a system that is not only time and space efficient, but is also scalable to a global deployment. We explore the various architectural tradeoffs in the context of a 3 year deployment across multiple dark address blocks ranging in size from /24s to a /8. We show how the current architecture emulates services across a diverse set of routed and address topologies in a scalable manner. Results from three recent events are presented to illustrate the utility of such a system: the SCO Denial of Service attacks (December, 2003), the Blaster worm (August, 2003), and the Bagle backdoor scanning efforts (March, 2004).
source: The Internet Motion Sensor: A distributed global scoped Internet threat monitoring system, Evan Cooke, Michael Bailey, David Watson, Jose Nazario, and Farnam Jahanian, in a University of Michigan CSE Tech Report .
August 29, 2004 in Blaster, papers | Permalink
| Comments (0)
Tell others: digg submit
del.icio.us this
HP Shelves Virus Throttle
According to this PCWorld article, HP is going to shelve its virus throttling project for the time being. This project grew out of research at HP Labs in the UK with people like Matthew Williamson's Throttling Viruses: Restricting propagation to defeat malicious mobile code (2002). Implemented in a variety of ways, including as a host-based stack change, it can slow the spread of various, as shown by researchers in simulations and by HP Labs in direct studies.
All is not lost though, as Windows XP SP2 TCP/IP stack changes includes this mechanism to implement connection throttling. While this breaks NMAP and other such tools for some people, the greater good of slowing scanning worms has a huge potential impact on worm propagation.
HP hasn't offered any timeframe when they plan to offer this technology, but others have adopted it, including Sendmail 8.13.0 and Postfix's anvil(8) feature. It's simple and has the chance to be one of the tools used to prevent worms from spreading faster than people can react to them.
August 26, 2004 in tools | Permalink
| Comments (0)
| TrackBack
Tell others: digg submit
del.icio.us this
Blaster Revisited (ACM Queue)
A recent issue of the magazine ACM Queue has an interesting piece on the August, 2003, Blaster worm. Written by Jim Morrison, who works for Symantec Security Services, it's a detailed and unboring look at the Blaster worm:
Four hours had passed since the first calls; most of the stores would be closed within the next two hours, giving the techs and developers a chance to work into the night to find the source of the problem. The network administrators were contacted to assist in troubleshooting the problems within the payment systems. Joining the group assembled in the development lab was a member of the security team. He had just been informed of a new worm that was spreading rapidly and reported by the security vendor. Early information indicated that the Microsoft DCOM (distributed component object module) vulnerability had been exploited. The vulnerability was described in Microsoft Security Bulletin MS03-026. The bulletin revealed a buffer overrun using RPC (remote procedure call), remotely using TCP/UDP port 135.
source: Blaster Revisited, ACM Queue vol. 2, no. 4 - June 2004, by Jim Morrison, Symantec Security Services.
August 7, 2004 in Blaster, papers | Permalink
| Comments (0)
Tell others: digg submit
del.icio.us this
Updated worm removal tool from Microsoft
Microsoft is attempting to leverage their infrastructure for updates and automated configuration to help users remove worm infections. They have released version 4.0 of this worm removal tool, as described in this knowledge base article:
This tool helps to remove the Mydoom.A, Mydoom.B, Mydoom.E, Mydoom.F, Mydoom.G, Mydoom.J, Mydoom.L, Mydoom.O, Zindos.A, Doomjuice.A, and Doomjuice.B worms from infected systems. Once the tool has run—after the End-User License Agreement (EULA) is accepted—it automatically checks for infection and removes any of the targeted worms that are found. If a machine is infected with the Mydoom.B worm, the tool also provides the user with the default version of the hosts file and set the "read-only" attribute for that file. This action enables the user to visit previously-blocked Microsoft and antivirus Web sites.
source: Mydoom, Zindos, and Doomjuice Worm Removal Tool (KB836528), posted 7/30/2004, Microsoft corporation.
Microsoft has released statistics before on how many worm infected hosts there are, often significantly higher than other reports (ie from direct network measurements or inferred from dark IP measurements). There's still been no full understanding on why this discrepancy exists. It could be due to literally millions of hosts behind NAT devices, or it could be a flaw in the tool, or something else. I'm still waiting to work with them to account for these differences, it's in the better interests of everyone.
August 2, 2004 in tools | Permalink
| Comments (3)
| TrackBack
Tell others: digg submit
del.icio.us this
Sophos claims one German teen responsible for lots of worm activity
A report by the computer security firm Sophos makes a bold claim: over 50% of the recent worm and mail virus activity is due to one person. Sven Jaschan, an 18 year old German teenager from northern German, has confessed to being the author of the Netsky and Sasser malware. Sophos claims that this accounts for over 50%, as much as 70%, of the malware traffic in the first part of 2004 when totalled by volume.
"For a single German teenager to have such an impact on computer security is simply staggering," said Graham Cluley, senior technology consultant for Sophos. "If one of Jaschan's friends had not informed Microsoft about his identity then the situation may have been even worse."
source: 70% of virus activity linked to one man, Sophos report reveals, July 29, 2004.
August 1, 2004 in media, sasser | Permalink
| Comments (0)
| TrackBack
Tell others: digg submit
del.icio.us this