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