worm blog

Another "Good Worm": Anti-Santy

As noted yesterday, a new worm is making the rounds, Santy. It seems that a new worm is out about about to combat this, "Anti-Santy" ... No word yet on if the anti-worm actually works.

The vulnerability description suggests that the worm only needs to patch a couple of lines in the stock phpBB codebase to protect against Santy. However, I've expressed my thoughts on the good worm here already, and I'll reiterate the key points: you don't have the authority to make those changes, you don't know if they'll work correctly, and you don't know what they may have changed. All of this combines in a lethal fashion to create a situation where more problems are likely to be generated than are fixed.

You can search for Anti-Santy hit sites (using MSN search) by using the search string "Anti-Santy-Worm V4". Sites that have been indexed by the search engine will be returned. As of this morning it was 3 sites. A site that has been hit will look like this:

Originally noticed via the F-Secure AV weblog.

Worm Detection, Early Warning and Response Based on Local Victim Information

Worm detection systems have traditionally focused on global strategies and required a large network, say 2²⁰ nodes. The value of this approach is clear; however, worm detection techniques for smaller local networks have not been fully explored. In the absence of a global worm detection system, we examine the effectiveness of local worm detection and response strategies.

This paper makes three contributions: (1) We propose a simple two-phase local worm victim detection algorithm, DSC (Destination-Source Correlation), based on worm behavior in terms of both infection pattern and scanning pattern. DSC can detect zero-day scanning worms with a high detection rate and very low false positive rate. (2) We demonstrate the effectiveness of early worm warning based on local victim information. For example, warning occurs with 0.19\% infection of all vulnerable hosts on Internet when using a /12 monitored network. (3) Based on local victim information, we investigate and evaluate the effectiveness of an automatic real-time local response in terms of slowing down the global Internet worms propagation. (2) and (3) are general results, not specific to certain detection algorithm like DSC. We demonstrate (2) and (3) with both analytical models and packet-level network simulator experiments.

Source: Worm Detection, Early Warning and Response Based on Local Victim Information (PDF here), Guofei Gu, Monirul Sharif, Xinzhou Qin, David Dagon, Wenke Lee, and George Riley. To appear at the 20th Annual Computer Security Applications Conference.

These authors have been listed here before for their HoneyStat tool. The DSC algorithm described in this paper is worth studying and evaluating. It's much like a technique I developed, although they are not completely identical. As you may have guessed, I'm partial to things like naive detection systems (which can detect new and emerging threats) and behavioral characterization of the threat as opposed to specific attributes.

In this paper, a few potentially problematic spots creep up. The first is the percetage of the network that must be infected for the worm to be detected. The authors found a 0.19% infection percentage required to trigger an alert. Under all but the least aggressive worms which wont infect hunreds of thousands of machines, this percentage is still a large number of systems. Secondly, the DSC algorithm requires that the worm be propagating for it to be detected. The system looks for both sources and destinations growing over time. Thirdly, the rate of spread needs to be sufficiently fast for the algorithm to trigger an alert based on the rate of change of the obsrvations. Finally, if the worm uses multiple vectors to probe hosts and doesn't try any one of them too frequently (ie a round robin infection method attempt), the observations will lag behind the worm's spread. These limitations are also noted by the authors: "Clearly, DSC does not aim to detect all types of worms. It is unlikely any one algorithm could detect all manner of malware. Instead, DSC aims to detect scan-based, fast spreading worms. Further, we presume that the infection time for hosts is not very long. In other words, DSC may not effectively detect email worms, very slow scanning worm, or sleeper worms with very slow rates of infection." With these caveats in mind, the premise of DSC, and the finding published by the authors, are interesting and show promise against a major class of worms.

PHP Worm, Mobile Phone Worm

Two new stories to report (Wormblog has been running on auto pilot while I was away for a bit). These are based on external news reports and mailing list posts.

The first is a PHP worm dubbed "Santy". The worm attacks poorly constructed sites which are built using the PHP language, the worm itself appears to be written in Perl. Originally started as a worm to attack phpBB (a PHP based bulletin board) sites, it now appears that new variants attack various PHP scripts that do lazy includes and trust user-supplied input. These "PHP includes" are basically user-input driven PHP mockups of files. Before people would use them to read arbitrary files from a system, but they have developed a worm that uploads itself using this mechanism. The phpBB website has a vulnerability desription from November 18, 2004, which gives additional details. Because the worm doesn't attack anything specific to the architecture of the server, any platform running poorly constructed PHP code is at risk. The worm uses Google to search for infectable sites to attack, making it more efficient that brute force scanning. A decent analysis (in French) is from the K-otik website. Multiple variants have been found, all based on the same theme: Santy.A,  Santy.D, Santy.F (all from Trend Micro), Perl.Santy.B and Perl.Santy.C (both from Symantec). Additional comment from the F-Secure blog. A set of Bleeding Snort sigs for Santy have been made, as well. If you write PHP code, you should look at these resources for writing secure PHP code: Secure Programming in PHP, by Thomas Oertli, Robert Mandel's quick note on a web developer list, Ten Security Checks for PHP by Clancy Malcolm, and Writing Secure PHP Code from solidox. Again, while this isn't terribly sophisticated, it shows how a seemingly benign and "unwormable" vulnerability can be leveraged with the right mindset.
A site that is defaced by one of the later variants of Santy looks like the following:

Secondly, it appears that the Cabir worm's source code is making the rounds. This is based on the number of variants that have recently appeared and the improvements made to the code. Cabir is a worm that attacks cell phones (see this quick set of links from the F-Secure AV blog). See the following stories for more information: Mobile Phone Virus Augurs Growing Threat, by Jay Lyman, TechNewsWorld and Phone Worm Source Code Out, More Threats Expected, by Gregg Keizer, CRN. A worm like Cabir is interesting not only for the target platform and the method by which it spreads, but more specifically for the different mathematics involved in it's spread. Because the worm operates over Bluetooth, which is a short range ad-hoc networking technology, you have to be in close physical proximity to someone to get the worm. This looks more like epidemic spreading in physical, complex networks. Interesting stuff indeed, I hope to write more about this soon (the modeling and mathematics of worm outbreaks).

Update
There are some tips on getting rid of Santy on WordPress blogs on Careless Thought. Useful info to have.

Network Measurement with a Network Telescope

A decent tutorial on monitoring for worm activity comes from set of slides from Youngseok Lee at Chungnam National University, Korea, on measuring malicious network activity using a large scale monitor, also known as a network telescope. The presentation is entitled Measurement of Campus Network with Network Telescope, and the slides are in English (and in PDF form). Using a large-scale monitor, you can see DDoS backscatter and worm probes. A number of equations and examples are given, bringing together a number of resources.

Flow-based Worm Detection

Two of the main flow formats widely available are sFlow, from InMon, and NetFlow from Cisco. Juniper devices often create cFlow, which is compatable with Cisco NetFlow. Flow-based methods provide an advantage over packet capture in several areas:

1. You leave collection and flow construction up to your existing infrastructure. It's already instrumented and pervasive (if you've deployed capable hardware).
2. It's far more abstract than full packet captures since it's summaries of connections.
3. You can infer topology information.

While people often relied on hardware to create their flow, you can sniff traffic to generate flow records. Have a look at the list by Simon Leinen, who maintains a page with links to other NetFlow implementations, including libpcap-based capture sources.

Peter Phaal  posted a recipe describing how you can detect the Slammer worm using sFlow and basic capture and analysis techniques based on the InMon sflowTools distribution. It turns out that sFlow can report on the payload of the packets, not just the headers.

Worm detection using NetFlow is easily done using the flow-tools software, originally from OSU. Paul Dokas posted a Perl script to detect scanners, which is a simple way to detect active worm hosts. The current software distribution of flow-tools includes flow-dscan, which detects scanners based on flow input. There is also a set of examples which includes basic techniques to detect the presence of a worm on port 3127 by looking for scanners on port 3127:

touch dscan.suppress.src dscan.suppress.dst

flow-cat /flows/R | flow-filter -P3127 | flow-dscan -b

And finally,  Ray Burkholder posted a flow-tools configuration to detect SQLSlammer using nfilter, with the implicit assumption that no hosts should be sending traffic on UDP port 1434, the network service attacked by the SQLSlammer worm. 

All in all, flow-based worm detection is possible and relatively easy, although you'll want to do some secord-order analysis to correlate scanner activity and call it a worm. When coupled to other techniques like dark IP monitoring using NetFlow or sFlow, you can reduce the false positive rate and improve your accuracy and utility.

Worm Origin Identification Using Random Walks

We propose a novel technique for determining the origin of a quickly propagating worm or the worm’s entry point to an intranet, for law enforcement or diagnostic purposes. Our technique rests upon an architecture in which network routers or end hosts record flow records and make them available for querying. Querying these records, our search then walks backward randomly along paths of flows. Due to the “wide tree” shape of a worm propagation emanating from the source, those edges near the top of the tree emerge as edges more frequently traversed in random walks, thereby aiding in identifying the source. We detail the effectiveness of this approach using both analysis and simulation, and argue the feasibility of the architecture needed to implement it.

Source: Worm Origin Identification Using Random Walks, Yinglian Xie Vyas Sekar, David A. Maltz, Michael K. Reiter, and Hui Zhang.

An interesting paper, and one of the more interesting methods I've seen in a long time for worm host detetcion.

Active Worm Detection using ICMP Messages

Another paper on detecting worms using ICMP messages, from the same authors:

Internet worms have caused widespread damage. Knowing the connection characteristics of such a worm very early in its proliferation cycle might provide first responders an opportunity to intercept a global scale epidemic.

We are presenting a scalable framework for detecting, in near-realtime, active Internet worms on global networks, both public and private. By aggregating network error messages resulting from failed attempts at packet delivery, we are able to infer deviant connection behavior of hosts on interconnected networks. The Internet Control Message Protocol (ICMP) provides such error notification. Using a potentially unlimited number of collectors and analyzers, we identify 'blooms' of activity. The connection characteristics of these 'blooms' are then correlated to identify worm-like behavior, and an alert is raised.

Promising results have been produced with a simulated Internet worm, demonstrating that new worms can be detected within the first few minutes after release, depending on the level of participating router coverage.

Source: Designing a Framework for Active Worm Detection on Global Networks, Vincent Berk, George Bakos, Robert Morris.

Berk and Bakos also developed the worm detection using ICMP messages paper posted here in November. A similar paper, and also an interesting system for a large class of worms.

Netbait: Distributed Worm Detection

When you have large scale visibility, interesting things about worms start to appear:

This paper presents Netbait, a planetary-scale service for distributed detection of Internet worms. Netbait allows users to pose queries that identify which machines on a given net work have been compromised based on the collective view of a geographically distributed set of machines. It is based on a distributed query processing architecture that evaluates queries expressed using a subset of SQL against a single logical database table. This single logical table is realized using a distributed set of relational databases, each populated by local intrusion detection systems running on Netbait server nodes. For speed, queries in Netbait are processed in parallel by distributing them over dynamically constructed query processing trees built over Tapestry, a distributed object and location routing (DOLR) layer. For efficiency, query results are compressed using application-specific aggregation and compact encodings.

We have implemented a prototype system based on a simplified version of the architecture and have deployed it on 90 nodes of the PlanetLab testbed at 42 sites spread across three continents. The system has been continuously running for over a month now and has been collecting probe information from machines compromised by both the Code Red and Nimda worms. Early results based on this data are promising. First, we observe that by having multiple machines sharing probe information from infected machines, we can identify a substantially larger set of infected hosts that would be possible otherwise. Second, we also observe that by having multiple viewpoints of the network, Netbait is able to identify compromised machines that otherwise would have been dificult to detect in cases where worms have an affinity to certain regions of the IP address space.

Source: Netbait: a Distributed Worm Detection Service, Brent N. Chun, Jason Lee, and Hakim Weatherspoon.

They are using resources built on top of PlanetLab, a research overlay network. This gives them great flexibility and power using real global Internet data. An interesting news item from March 20, 2003 (their last update on the site):

It's unclear if there's any correlation between the resurgence of Code Red II (i.e., Code Red II.F) and the war against Iraq. In any case, there appears to be a significant of amount of activity since March 11, 2003.

You can view their data using their HTML reporting interface on the research site.

Plant Epidemiological Methods To Track Computer Network Worms

From Rishikesh Pande, a Master's thesis that I take notice of. He gets into some modelling I find interesting, correlation analysis, and applies techniques from other sciences to the problem of worm detection:

Network worms that scan random computers have caused billions of dollars in damage to enterprises across the Internet. Earlier research has concentrated on using epidemiological models to predict the number of computers a worm will infect and how long it takes to do so. In this research, one possible approach is outlined for predicting the spatial flow of a worm within the local area network (LAN).

The approach in this research is based on the application of mathematical models and variables inherent in plant epidemiology. In particular, spatial autocorrelation has been identified as a candidate variable that helps predict the spread of a worm over a LAN. This research describes the application of spatial autocorrelation to the geography and topology of the LAN and describes the methods used to determine spatial autocorrelation. Also discussed is the data collection process and methods used to extract pertinent information. Data collection and analyses are applied to the spread of three historical network worms on the Virginia Tech campus and the results are described.

Spatial autocorrelation exists in the spread of network worms across the Virginia Tech campus when the geographic aspect is considered. If a new network worm were to start spreading across Virginia Tech.s campus, spatial autocorrelation would facilitate tracking the geographical locations of the spread. In addition if an infection with a known value of spatial autocorrelation is detected, the characteristics of the worm can be identified without a complete analysis.

Source: Using Plant Epidemiological Methods To Track Computer Network Worms, Rishikesh Pande, Master's Thesis.

What's great about this format, also, is that there is plenty of room for code, meaning you can examine the implementation and learn from it. Give it a whirl, this is a great thesis.

Earlybird: Catching the Internet Worm

From UC Berkeley, an interesting project that focuses on worm detection:

Internet worms, or malicious programs that spread autonomously from computer to computer, have become a problem at the forefront of computer security concerns in recent years. Several different approaches to the problem provide partial solutions, but the general problem of detecting when a worm has entered a network has not been solved. In this paper, we apply machine learning techniques to the problem of worm detection.

We apply the tools of graphical models and statistical inference to the problem of detecting internet worms. Specifically, we model the problem as an HMM, in which the hidden state is either packet in- fected or packet clean, and the learner make observations on internet traffic. We survey current problems and solutions in the field of internet worm defense. We discuss approaches to modeling the problems, and we touch on several issues in representation and simulation. We describe models for normal network behavior and worm behavior that enable large-scale simulation of normal networks and worm infection, and we discuss simplifications and tradeoffs that aid in performing such simulation.

Finally, we discuss our experience with implementing a simulator and our frustrations due to persistent bugs. We analyze the (incomplete) results we have obtained, and we show that the simulator and learner do produce interesting behavior that shows evidence of learning potential once the bugs are eliminated.

Source: Earlybird: Catching the Internet Worm, Marco Barreno, Final project: CS 281A, December 2003.

While the paper is somewhat lacking in implementation details, the approach itself looks somewhat promising, looking at common traits of worm infected hosts and how you might detect them.