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 (
geocities.com/dharan6/library) (
geocities.com/dharan6)