« January 2006 | Main | March 2006 »

Week in Review: Inqtana redux

It's been a busy week, but on the really interesting malware front, it's been pretty slow, so here are some comments on the Inqtana worm. A lot of hype surrounded it when it was first published a week ago Friday, but it turns out to be mostly hype.

In InqTana Through the eyes of Dr. Frankenstein, a post to the Full Disclosure mailing list, KF breaks down the malware and shows that it's not found in the wild, that it's nothing but a proof of concept sample and crippled to avoid spreading about the lab. While the press jumped on the "OS X malware" bandwagon, it appears to have been premature. Yes, the proof of concept is great, it demonstrates that there's a potential of a threat vector with Bluetooth of personal computers and there's a largely untested field of OS X malware, but the threat is not yet realized. It's some good analysis, although I dispute one of his claims:

"Putting all of that aside I think most people missed the point of this worm and its variants. The main focus was not on the usage of Bluetooth for the exploit medium, or the vulnerability used. The focus should have been on the usage of built in OSX facilities to spread malicious code. OSX contains features, which will certainly aid in the future of malware on OSX."

I think that it's just as important that it's Bluetooth on a personal, general purposes computer that makes it just as interesting as the fact that it's OS X. We've seen a lot of PDA and cellphone malware in 2005 (see the F-Secure weblog archives, it's quite interesting), mainly variants of a few families, and now we can have it on OS X, too.

Interesting times ...

Another interesting tidbot from the past week, it seems that MWCollect and Nepenthes are merging into one codebase. If you haven't looked at these tools to collect Windows malware, you should. They're useful and easy to deploy. It will be good to see efforts combined and the projects strengthen in the coming months.

And finally, another new tool to help network administrators defeat malware infestations. Quarantainenet looks lik a commercial tool to use your network segmentation tools to protect your network if you have untrusted or infected hosts on the net.

Quarantainenet provides network operators with a way of placing users in a quarantined environment, for example in case of a virus or worm infection.

Quarantainenet makes sure a user only retains the limited functionality that is necessary for fixing the problem. The big difference with simply disconnecting a user, is that quarantainenet usually enables the user to solve the problem himself while at the same time improving communication towards the user. The productivity of operators also heavily benefits from this.

If you run a network and have been looking for ways to implement quarantine segments, this may be useful for you.

February 26, 2006 in editorial | Permalink | Comments (1)
Tell others: digg submit del.icio.us this

The Domain Name Service as an IDS The Domain Name Service as an IDS

Kind of a neat way of tracking botnet activity. I wonder if anyone has deployed this operationally and gotten positive results.
SURFnet is looking for technologies to expand the ways they can detect network traffic anomalies like botnets. Since bots started using domain names for connection with their controller, tracking and removing them has become a hard task. This research is a first glance at the usability of DNS traffic and logs for detection of this malicious network activity. Detection of bots is possible by DNS information gathered from the network by placing counters and triggers on specific events in the data analysis. In combination with NetFlow information and IP addresses of known infected systems, detection of bots of network anomalies can be made visible. Also the behavior of a bot can be documented and additional information can be gathering about the bot. Using DNS data as a supplement to the existing detection systems can give more insight in the suspicious network traffic. With some future research, this information can be used to compile a case against particular types of bot or spyware and help dismantling a remote controlled infrastructure as a whole.
Source: The Domain Name Service as an IDS, How DNS can be used for detecting and monitoring badware in a network, Antoine Schonewille, Dirk-Jan van Helmond.

February 24, 2006 in detection, papers | Permalink | Comments (0)
Tell others: digg submit del.icio.us this

Recent PHP Worm Activity

For the past several months we've been seeing a lot of PHP-based attacks that have been related to a semi-worm toolkit. It's a Kaiten-based bot which makes the IRC connections, sometimes a Perl connect back shell, and finally an exploit toolkit. The targets are PHP based apps that use either command injection or XML-RPC attacks. Looking through my logs I see these IPs making the attacks for the month of February, 2006.

CountASNSource IPAS by name
1 3356    212.3.249.x  LEVEL3 Level 3 Communications
1 4986    69.10.171.x  INTERSTAR - InterStar Network
3 12322    82.238.26.x  PROXAD AS for Proxad ISP
3 852     142.59.19.x  ASN852 - Telus Advanced Commun
3 9200    195.85.176.x  ESSENTKABELCOM Essent Kabelcom
3 16276    213.251.165.x  OVH OVH
3 17676    219.184.148.x  JPNIC-JP-ASN-BLOCK Japan Netwo
3 22909    68.41.59.x  DNEO-OSP1 - Comcast Cable Comm
6 3269    85.45.227.x  ASN-IBSNAZ TELECOM ITALIA
6 8708    193.230.212.x  RDSNET Romania Data Systems S.
6 8762    193.92.9.x  TEI-OF-CRETE-AS Technological
6 10834    200.5.98.x  Telefonica Data Argentina S.A.
6 4837    202.107.54.x  CHINA169-BACKBONE CNCGROUP Chi
6 4808    202.108.248.x  CHINA169-BJ CNCGROUP IP networ
6 13749    207.44.240.x  EVERYONES-INTERNET - Everyones
6 6539    209.17.129.x  GT-BELL - Bell Canada
6 6619    211.189.39.x  ERX-SIGMA-NET Samsung Global M
6 4134    61.183.15.x  CHINANET-BACKBONE No.31,Jin-ro
6 9132    62.206.128.x  BMCAG-AS Broadnet mediascape c
6 209     67.128.88.x  ASN-QWEST - Qwest
6 15082    69.42.145.x  PRIMEINTER - Prime Internet Ne
6 12578    80.232.165.x  APOLLO-AS LATTELEKOM-APOLLO
6 2856    81.137.250.x  BT-UK-AS BTnet UK Regional net
6 6724    81.169.162.x  STRATO Strato AG
6 24915    81.29.237.x  ASN-TELEUNIT Teleunit S.p.A.
6 8767    82.135.33.x  MNET-AS M_net AS
8 3269    82.54.234.x  ASN-IBSNAZ TELECOM ITALIA
8 6467    199.227.64.x  ESPIRECOMM - Xspedius Communic
8 11468    216.83.6.x  NSDATA - Nova Scotia Data Ltd.
8 10738    64.84.32.x  MASTERLINK - MasterLink, Inc.
12 23236    65.222.97.x  NETV - Netvendor
12 278     132.248.103.x  Red Academica de Mexico
12 6677    157.157.88.x  ICENET-AS1 ICENET Autonomous s
12 34496    194.116.186.x  PLANET-SCHOOL-AS Planet School
12 1680    194.90.30.x  NetVision Ltd.
12 23974    202.143.162.x  MOE-EDNET-AS-AP Ministry of ed
12 3701    204.27.190.x  NERONET - Oregon Joint Graduat
12 12449    212.69.204.x  DSVR-AS1 DSVR Autonomous Syste

Keep your eyes on your logs, look for PHP attacks that use "wget" to call out and fetch a bootstrap script, and make sure your machine is up-to-date. The botnets that have been growing out of this are thousands of machines big and can do some damage

Update

Some technical notes. Kaiten is the name of a bot to which the source is available. It's written in C, is usually a single source code file, and has hardcoded IRC servers and channels. It's basically an IRC client that logs in to a server, receives commands from the users. You can issue commands like "!PDMGV SH ls / " (where "PDMGV" is the bot's nick) to have an arbitrary shell command executed, and you have access to scanning, DDoS attacks, etc ... Kaiten does not spread on its own. It can drive a scanner and an exploit tool, but it does not spread on its own. It's not the total of the "worm" kit here. (This harkens back to the late 1990's, where Eggdrop bots would appear on compromised Linux boxes. Eggdrop is not a worm, but it does give a compromised box access via IRC.) The propagation is done like this:

  1. Scan for web servers to attack in one way or another. Search or scan or whatever.
  2. Launch attacks, and issue commands to the victim to run "wget" to get a script from a server. Copy the script to /tmp, execute the script, and disconnect.
  3. The script is downloaded, launched, and it will "wget" two more executables. When run, they connect to the IRC server and can be used to launch attacks.
The name "mare" comes from an earlier version, "mare" was the name of one of the files. While the whole kit can be used to propagate automatically, Kaiten itself is not a worm, it's just an IRC bot tool.

If you'd like to read more about these threats, have a look at the following links:

February 21, 2006 in new trends | Permalink | Comments (3)
Tell others: digg submit del.icio.us this

Two new OS X worms: Leap and Inqtana

Argh I hate Typepad. This post keeps getting lost when I switch windows.

This week saw two new OS X malware families break out. I had a chance to look at one (and I'm sorry, but I can't share the report) but not both.

The first is Leap.A, an IM worm. If you want to see a good description of what it dos have a look at the Ambrosia Software writeup in their forums. Ambrosia also makes some nice games. While technically Leap.A is a Trojan horse, it qualifies as an IM worm.

Leap is important for a few reasons. Firstly, it's the first time we have seen an IM worm not use a central distribution site to propagate the malware. Instead, the malicious file is transferred from one user to another via iChat instant messages. This makes eradication harder (ie you can't just shut down one site, you would have to stop all messages between users with the malicious content). We've been expecting this for a while now, and this can be done with MSN Messenger, AIM, etc ... Secondly, Leap.A shows a classic virus trick, namely modifying other applications using the InputManager on OS X. Crafty ... And thirdly it's the first OS X specific malware. If you want to see more AV vendor writeups, follow the links from the CME-4 entry (Leap.A has this CME identifier).

Now, fast forward a day and you'll see Inqtana.A, a Bluetooth worm for OS X. Because many Macs have Bluetooth installed, they're vulnerable to these sorts of attacks. Inqtana uses a specific vulnerability (the Obex Push vuln) to issue commands to a vulneable machine. Bluetooth worms have been all the rage in some circles for cell phone and PDAs, and this extends it to general purpose computers.

Both are proofs of concepts, and both show what we can expect this year in terms of malware.

February 18, 2006 in new worms | Permalink | Comments (11)
Tell others: digg submit del.icio.us this

Botnets

I met Randy years ago at a SANS event. He had been key in several UNISOG related events, as I recall, and always got things done. This is no different, he's got a slide deck that gives you a great background in the bulk of today's botnets. Please download and look at Botnets by Randy Marchany (PPT slide deck).

February 17, 2006 in slides | Permalink | Comments (0)
Tell others: digg submit del.icio.us this

The Creation of a Botnet Tracking Web Application

A slide deck on tracking botnets (which is what I've been up to a lot lately) and an application to help do that. While it's not complete, it does give you an idea of what people are doing to manage this scale of information and the degree of response they're giving it. In The Creation of a Botnet Tracking Web Application (a PowerPoint slide deck from the ORAC meeting) by Micah Hoffman from the US CERT, you get an idea of what kind of data goes into this system. While it's lacking some of the details on detecting a botnet and focuses instead on the remediation aspects of their involvement, it looks neat.

February 16, 2006 in slides | Permalink | Comments (1)
Tell others: digg submit del.icio.us this

A Self-Learning Worm Using Importance Scanning

Another "smart worm" design paper. I don't think I see many of these sorts of things in the wild, but they're always fun to dream up and try and defend against.
The use of side information by an attacker can help a worm speed up the propagation. This philosophy has been the basis for advanced worm scanning mechanisms such as hitlist scanning, routable scanning, and importance scanning. Some of these scanning methods use information on vulnerable hosts. Such information, however, may not be easy to collect before a worm is released. Questions then arise whether and how a worm can self-learn and use such information while propagating, and how virulent the resulting worm may be. In this paper, we design a self-learning worm using importance scanning. An optimal yet practical importancescanning strategy is derived based on a new metric. A selflearning worm is demonstrated to have the ability to accurately estimate the underlying vulnerable-host distribution if a sufficient number of infected hosts are observed. Experimental results based on parameters chosen from Code Red show that after accurately estimating the distribution of vulnerable hosts, a self-learning worm can spread much faster than a random-scanning worm, a permutation-scanning worm, and a Class A routing worm. Some guidelines for detecting and defending against such self-learning worms are also discussed.
Source: A Self-Learning Worm Using Importance Scanning, Zesheng Chen, Chuanyi Ji.

February 15, 2006 in defense, papers | Permalink | Comments (0)
Tell others: digg submit del.icio.us this

Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds

A nice paper on Botnets that attempts to defeat some of their firepower and purpose. I spent much of my available time on Monday looking at a new bot, and it had all sorts of functionality: CD key theft, spam, DDoS of various sorts, proxying, etc ... I don't think that you can simply defeat the DDoS element and call it over with. One of the DDoS mechanisms was to repeat the same URL POST pattern repeatedly, and that's very easy to spot, trace back, and block at the ingress edge. No need to use something like this below, but this paper is still worth a read.
Recent denial of service attacks are mounted by professionals using Botnets of tens of thousands of compromised machines. To circumvent detection, attackers are increasingly moving away from bandwidth floods to attacks that mimic the Web browsing behavior of a large number of clients, and target expensive higher-layer resources such as CPU, database and disk bandwidth. The resulting attacks are hard to defend against using standard techniques, as the malicious requests differ from the legitimate ones in intent but not in content.

We present the design and implementation of Kill-Bots, a kernel extension to protect Web servers against DDoS attacks that masquerade as flash crowds. Kill-Bots provides authentication using graphical tests but is different from other systems that use graphical tests. First, Kill-Bots uses an intermediate stage to identify the IP addresses that ignore the test, and persistently bombard the server with requests despite repeated failures at solving the tests. These machines are bots because their intent is to congest the server. Once these machines are identified, Kill-Bots blocks their requests, turns the graphical tests off, and allows access to legitimate users who are unable or unwilling to solve graphical tests. Second, Kill-Bots sends a test and checks the client's answer without allowing unauthenticated clients access to sockets, TCBs, and worker processes. Thus, it protects the authentication mechanism from being DDoSed. Third, Kill-Bots combines authentication with admission control. As a result, it improves performance, regardless of whether the server overload is caused by DDoS or a true Flash Crowd.

Source: Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds, Srikanth Kandula, Dina Katabi, Matthias Jacob, Arthur Berger.

February 14, 2006 in defense, papers | Permalink | Comments (0)
Tell others: digg submit del.icio.us this

Defending against Hitlist Worms using Network Address Space Randomization

I don't think this one is entirely practical, though it was one of the better presentations at WORM05.
Worms are self-replicating malicious programs that represent a major security threat for the Internet, as they can infect and damage a large number of vulnerable hosts at timescales where human responses are unlikely to be effective. Sophisticated worms that use precomputed hitlists of vulnerable targets are especially hard to contain, since they are harder to detect, and spread at rates where even automated defenses may not be able to react in a timely fashion.

This paper examines a new proactive defense mechanism called Network Address Space Randomization (NASR) whose objective is to harden networks specifically against hitlist worms. The idea behind NASR is that hitlist information could be rendered stale if nodes are forced to frequently change their IP addresses. NASR limits or slows down hitlist worms and forces them to exhibit features that make them easier to contain at the perimeter. We explore the design space for NASR and present a prototype implementation as well as preliminary experiments examining the effectiveness and limitations of the approach.

Source: Defending against Hitlist Worms using Network Address Space Randomization, S. Antonatos, P. Akritidis, E. P. Markatos, K. G. Anagnostakis.

February 13, 2006 in defense, papers | Permalink | Comments (0)
Tell others: digg submit del.icio.us this

Worm propagation strategies in an IPv6 Internet

I like this paper, not only because it dispells a myth but it's also the same line of arguments I've been using for years. Thanks to Ismael for the tip. 

We discuss a number of strategies worms could use in an IPv6-based Internet to find new targets. We separate these into two categories, wide-area and local-area searches, somewhat mirroring the IPv6 address architecture. We argue that worms will use different types of information sources to first determine existing networks and establish a presence there, and then spread locally inside an organization. We hope to illustrate that simple reliance on the IPv6 address space for protection against scanning worms is not a wise defensive strategy, and we suggest areas where research could assist in detecting and limiting future worm propagation.

Source: worm propagation strategies in an IPv6 Internet, Steven M. Bellovin, Bill Cheswick, and Angelos D. Keromytis.

February 11, 2006 in IPv6, papers | Permalink | Comments (1)
Tell others: digg submit del.icio.us this