lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20040325140401.GA33056@garbarek.hsc.fr> From: Jean-Baptiste.Marchand at hsc.fr (Jean-Baptiste Marchand) Subject: ISS 'Witty' Worm Analyzed * mattmurphy@...rr.com <mattmurphy@...rr.com>: > I have completed an analysis of the 'Witty' worm that impacts multiple ISS > products. The worm is spreading via a very simple UDP propagation > algorithm. The unique nature of this worm made it a fascinating piece of > code to analyze. The analysis gets into the details of the worm's > propagation mechanism, and is designed for a more technical reader, but > does include a basic description of the worm, and the list of products > vulnerable to it (as published by ISS). Very interesting document, thanks! By the way, if people are trying to decode Witty with Ethereal (http://www.ethereal.com/), you might be surprised not to see the same decoding of ICQ messages as shown in Matthew's paper. Because Witty sets the Session ID field to 00 00 00 00, the Ethereal ICQ dissector is confused and dissects Witty messages as client-to-server messages instead of server-to-client messages. (extract of packet-icq.c, available on http://www.ethereal.com/cgi-bin/viewcvs.cgi/ethereal/packet-icq.c) if (unknown == 0x0L) { dissect_icqv5Client(tvb, pinfo, tree); } else { dissect_icqv5Server(tvb, 0, pinfo, tree, -1); } As presented in the following document: http://www.cs.berkeley.edu/~mikechen/im/protocols/icq/icqv5.html client-to-server ICQ messages start with: 2 bytes 05 00 VERSION Protocol version 4 bytes 00 00 00 00 ZERO Just zeros, purpouse unknown ... and server-to-client ICQ messages start with: 2 bytes 05 00 VERSION Protocol version 1 byte 00 ZERO Unknown 4 bytes xx xx xx xx SESSION_ID Same as in your login packet. ... In Witty case, the SESSION_ID is set to 0 and the ethereal dissector believes that the ICQ message is a client-to-server one. It might be a good idea to add a test to the ethereal dissector to determine if a given ICQ messages is a client-to-server or server-to-client one, examining the source port (if source port is set to 4000, it might be a good indication that this is a server-to-client message...). I will probably propose such a modification on ethereal-dev@. Thus, to properly dissect Witty ICQ messages with Ethereal, you just have to modify one of the 4 bytes that constitute the session id and set it to 0x01 instead of 0x00. With such a modification, Witty ICQ messages are properly decoded, as shown in the following tethereal output: ... ICQv5 SRV_MULTI_PACKET (len 1211) Header Version: 5 Session ID: 0x00000004 Command: SRV_MULTI_PACKET (530) Seq Number 1: 0x0000 Seq Number 2: 0x0000 UIN: 0 Checkcode: 0x00000000 Body Number of pkts: 2 ICQv5 SRV_USER_ONLINE (len 44) Header Version: 5 Session ID: 0x00000000 Command: SRV_USER_ONLINE (110) Seq Number 1: 0x0000 Seq Number 2: 0x0000 UIN: 0 Checkcode: 0x00000000 Body UIN: 0 IP: 1.0.0.0 Port: 0 RealIP: 0.0.0.0 Status: ONLINE Version: 02410000 ICQv5 SRV_META_USER (len 577) Header Version: 5 Session ID: 0x00000000 Command: SRV_META_USER (990) Seq Number 1: 0x0000 Seq Number 2: 0x0000 UIN: 0 Checkcode: 0x00000000 Unknown (0x0000) Failure This corresponds exactly to the manual decoding presented in Matthew's paper. Jean-Baptiste Marchand -- Jean-Baptiste.Marchand@....fr HSC - http://www.hsc.fr/
Powered by blists - more mailing lists