The Client-To-Client Protocol used by ICQ is even worse. It does no
authentication of any kind and places all trust in the client. Spoofing
messages from arbitrary ICQ users is easy, as is sending file and chat
requests. Even worse, if the client gets anything it doesn't expect it
crashes(!) sometimes taking Windows with it. There is also no flood
protection and packet replay is possible. A few thousand messages will
slow my P166 to a crawl. The only good thing ICQ did was pick a different
port number for each session (well, not really its usually around 1024 as
windows seems to allocate port numbers in order.) So, an attack would go
as follows:
1. Port scan the target IP looking form 1024-2000 or so.
2. Send some random data to crash it. Using netcat is good for this. (or)
3. Take a valid ICQ message and resend it a million times. (or)
4. Take a valid ICQ message and change the User Identification Numbers. (or)
5. Be creative :)
To reverse engineer the protocol, simply study the results of different ICQ
activities with a sniffer or some type of Winsock watcher. I have figured
out quite a bit about the protocol and will release a more formal writeup
soon. Anyone with a few hours should be able to writeup a suitable client
message spoofer. I am writing this as I have been exploiting these
vulnerablites for quite some time and I haven't seen anything about this on
usenet or the mailing lists. As an example, I have provided the transcript
of a message.
This is an example of a simple message (there are many other types of
traffic) of "12345" from UIN 3399052:
>> 0000: 2D 00 <- Prefix (if this is wrong bad things happen)
>> 0000: 8C DD 33 00 02 00 EE 07 00 00 8C DD 33 00 01 00
>> 0010: 06 00 31 32 33 34 35 00 82 D7 F3 20 82 D7 F3 20
>> 0020: 09 04 00 00 04 00 00 10 01 ED FF FF FF
<< 0000: 28 00 <- Post fix and ACK
<< 0000: 5D 29 35 00 02 00 DA 07 00 00 5D 29 35 00 01 00
<< 0010: 01 00 00 82 D7 F3 25 82 D7 F3 25 22 07 00 00 04
<< 0020: 00 00 00 00 ED FF FF FF
Simply send this alot for a flood using netcat (ignoring the responses of
course). I wrote a few simple exploits, but they used the socket faq
library and seem redundant at this point, so I leave exploitation as an
exercise to the reader.
Seth M. McGann / smm@wpi.edu "Security is making it
http://www.wpi.edu/~smm to the bathroom in time."
KeyID: 1024/2048/5FC59C0A
Fingerprint F315 1C37 CF3C 3612 3B28 BC84 C430 BC22 5FC5 9C0A