AOL Instant Messenger (AIM) protocol information and password decoder
by james@foo.org

A quick note: please, do not kick and scream if this is old news; I
don't really watch these things and this is the first I've seen.

 AOL Instant Messenger doesn't seem to make too much a point of
 security. Security really isn't very friendly though, and it sure
 would slow a large system like AOL down.

 I've successfully signed on to the AIM network illicitly using
 a couple  different methods. You may say "So? This is just a chat
 network." That excuse doesn't work, look at how many people use
 it every day.


 First, the hash that AIM uses to "encrypt" user passwords going
 over the network is awful. I can only assume that it's not meant
 to provide any security at all, in which case .. *sigh*

 An AIM password must be between 4 and 16 characters. I got this from
 the AIM "Change your Password" screen. When the AIM client signs on
 to the authorizer, the encoded password presented is the same length
 as the decoded form. After a little number crunching, I've found
 that the hash used to encode the password looks like this:

 u_char hash[16] = { 243, 179, 108, 153, 149, 63, 172, 182,
                     197, 250, 107, 99, 105, 108, 195, 154 };

 The user password is simply XOR'ed with this. All the server has to
 do is XOR this hash with the encoded password to get the original
 text. In other words:

         for (i = 0; i < 16; i ++)
           crypt_pw = cleartext_pw[i] ^ hash[i];

 As far as I can tell, this data is static; it's used by all the
 clients I've played with anyway (AIM for Windows '95 and AIM for
 Java version 1.2). It may be different for different versions of the
 client, but the client sends it's version information over the wire
 too so this is a moot point.

 If you sniff a user's connection to the authorizer you have yourself
 the user's cleartext password and can do with it what you will.
 Impersonate them, deny them access to AIM, etc.

 There are a number of alternative ways to do this simple password
 authentication, and not all of them require fancy (read: slow)
 encryption.

 This next method isn't as sexy as the previous, but it works nonetheless.

 Once the AIM client has authenticated once, it never has to do it again.
 The server sends it a cookie, much like a Kerberos KDC gives a client a
 TGT. The cookie lets a user signon quickly to another service.

 But what happens if you can get that cookie? You can steal a user's
 cookie, flood the user or reset their connection so that they can't
 reach the destination server, and login with their cookie yourself. I
 have only tried this with the BOS server; it will probably work just
 as well with the ad servers, chat & chatnav servers, and the directory
 servers. I assume they all run basically the same server software,
 with software modules that plug-in to provide the various services.

 The server's appear to be doing some sort of traffic filtering at the
 transport level. If my host hasn't been given a cookie, it won't let me
 connect to any services. This traffic filtering does not seem to be tied
 to the cookie however; as long as you have a legitamate reason for
 connecting to the server it will let you on.

 Wouldn't it be fun to sneak up on an AOL staff person, sniff their
 traffic, and find out if they have access to any "hidden" commands? :-)



 21 June 1998, james@foo.org