| 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