Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Noah Johnson (nmjbluehotmail.com)
Date: Tue Apr 16 2002 - 02:45:35 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    ('binary' encoding is not supported, stored as-is) AIM's 'Direct Connection' feature could lead to
    arbitrary file creation
    Author: Noah Johnson ( nmjbluehotmail.com )

    Affected versions:
             All versions of AOL Instant Messenger (up to
    4.8 beta) on all platforms of Windows (as far as I can

            AOL may have patched their servers to prevent
    the wave of DoS attacks recently discovered, but this
    bug - related to the 'Direct Connection' feature -
    cannot be filtered through the server itself, and
    therefore requires a new realease to be patched.
            Because direct connections (almost always)
    require user approval, the severity of this bug is
    somewhat smaller than others recently discovered,
    however exploitation is fairly simple and could result
    in anywhere from arbitrary script execution to
    overwriting of critical files, and so I think it's still
    worthy of being noted and fixed soon.

              The problem arises in AIM's handling of
    embedded objects during direct connections with
    other users. These 'direct connections' supposedly
    make it easier for users to share multimedia with
    each other during conversations. When a direct
    connection is to be made, the initiating side acts as a
    server - on port 4443 - for the recipient's client to
    connect to (if the request is accepted, of course).
    After this connection is made, all activity between the
    two users is passed through it, relieving the AIM
    server of its job for the time being.
             When a user sends a picture or a sound to his
    buddy, an <IMG> tag is appropriately inserted into the
    conversation source, while that file's data lies in a
    separate <DATA> tag immediately proceeding the
    HTML (see below). The client responds to this <IMG>
    tag either by displaying the picture in the conversation
    or by displaying an icon of the MIME/file-type that has
    been sent. Along with the standard parameters of this
    <IMG> tag (HEIGHT, WIDTH, DATASIZE, ID, etc...),
    the client also specifies the name and path of the
    original file that was sent. This information is included
    in the "SRC" parameter, and is the one of importance
    here. The client uses this information in a few ways -
    including the default filename suggested when the
    user opts to save whatever the hell was sent.
    So, why does anyone care?
           One last nifty feature I forgot to mention... When
    the client parses the file and recognizes it as a
    RIFF/WAVE type, it will play that file instantly via
    the 'SndPlaySoundEx' API function. Instead of playing
    the buffer directly from memory however, it is instead
    downloaded into the Windows 'temp' directory and
    read from there. But for some odd reason, THE
    TEMPORARY FILE! (Can you see where this is
            With very trivial parsing of this "SRC" parameter,
    AIM is left wide open to the old ("..\..") directory
    traversal attack. So now we can choose ANY path on
    our buddy's system to save our file to simply by
    appropriately sculpting the "SRC" information. Here's
    an example of what might be sent from the direct

    Data Headers (explained later)
    <HTML><BODY>Hey, what's up?<IMG
    SRC="\..\system\johnny.important_file" HEIGHT="0"
    WIDTH="0" DATASIZE="50"

           Assuming that the temp directory on Johnny's
    computer is [c:\windows\temp], this would
    write/overwrite whatever file was thus specified. No
    obvious signs of this would be noted, as the WAVE
    icon would never show up in Johnny's box (notice the
    HEIGHT and WIDTH values).

    Fooling the Client:
            As noted earlier, AIM only saves this (semi-)
    temporary file when it identifies it as valid RIFF/WAVE
    data and tries to play it. So what good is this if we can
    only write WAVE files? ("HOLY SHIT! YOU MEAN
    Unfortunately for Johnny, the client only looks at the
    first 12 bytes before concluding it is indeed a valid
    sound file. These bytes ideally look like this (see
    wave file specifications):

    Offset Data
    0,1,2,3 ASCII 'RIFF'
    4,5,6,7 DWORD Wave File Size ( <- can be
    anything, we don't care;
            neither does the client. )
    8,9,A,B ASCII 'WAVE'

          Keeeping this as a base, we can then sculpt any
    file we want (sample exploits next). As long as these
    12 bytes are respected (actually, only the ASCII parts
    of them really matter), the file is saved.
          The fact that the header is already determined
    severely limits the danger of this bug (we cannot, for
    example, create an executable file). There are a few
    ways around this...

           Besides the potential of overwriting files, there
    are plenty of file types that can be bullshitted in the
    first 12 bytes without losing functionality of the entire
    thing (think scripts, for example). By placing these
    files in the Start-Up folder, you can see where this
    could lead...

    For example:
            A sample .BAT file
            C:\Windows\Start Menu\StartUp\exploit.bat
            Any dos command here
            Any dos command here
            While I originally assumed the '-'s would be
    the ASCII character 0x08 (backspace, which would
    delete the 'WAVE' and 'RIFF' so the shell would not
    try to execute these commands, give an error and
    then quit), it turns out that even if an error is
    encountered ('Invalid command or file name'), it will
    not stop the rest of the script from executing upon

    Another example:
            A sample .VBS file
            C:\Windows\Start Menu\StartUp\exploit.vbs
            RIFF____WAVE = ""
            Any vbs code here
            Any vbs code here
            Here, the first line (RIFF____WAVE = "") is
    a valid declaration, which means no error will occur in
    scripting and anything else can be put in afterwards.

    ... You get the idea. I'm sure there are plenty of other

          It's just like they tell you... Never accept a direct
    connection from anyone you don't trust. If you MUST,
    I suppose you could change your Windows temp
    directory to thwart a maliciously located file, but I
    would hardly consider that a 'fix'.

    A Few Things to Note:
          Because AIM only allows multimedia to be sent in
    Direct Connection sessions (not quite true, see note
    on Buddy Icons), and because AIM filters out HTML
    tags (such as our <IMG> tag here) when inserted
    directly into an IM message, in order to exploit this
    bug a user must be able to control the raw data being
    sent. The most obvious way is to simply take control
    of the port that the connection is to be made on
    (before the client does) and sculpt the data on your
           But sequence numbers are used in the
    transmission of data during these sessions. The
    base sequence number is randomly selected by the
    initiating side, and is sent to the buddy's client as part
    of the request for a connection (Port # is sent at the
    same time). This sequence is incremented every
    time an entire chunk of data is sent (which could
    span any number of packets; the size of every data
    piece is sent right after the sequence number). If the
    sequence number or data size is wrong, the direct
    connection will be closed immediately. You can
    experiment on your own on port 4443.

         The simplest way I can think of to test this bug
    (avoiding dealing with sequences and protocols) is to
    let the client handle everything - the connections and
    all - and manually edit the conversation source [with
    the 'wave file' already inserted] just before it's sent
    out (SendWindowMessage (WM_SETTEXT) on the
    RichTextBox or use SoftIce and search for the data in
    memory or something to that nature). I won't publish
    a full-out exploit; I think you get the picture.

    * A Note on Buddy Icons *
           If you send this same type of forged WAVE file
    as a Buddy Icon (no direct connection needed), the
    client does the same thing described earlier, even
    before the "Accept Buddy Icon" prompt appears. I
    don't know if this is intentional on the part of AOL, but
    as far as I can tell it's impossible to specify your own
    file name. Instead the client uses some default name
    of its own. It's just odd, because I was under the
    impression that Buddy Icons were supposed to be
    graphic files >>> (Possible DoS in this - send a
    corrupt wave file to buddy's computer? I don't know,
    anyone care to investigate?)
          Also, when a buddy is sent your Buddy Icon, the
    file is downloaded onto their computer and saved
    Located in their AIM user's 'picture' folder and
    named 'T.id', THEORETICALLY one could use this
    place to store an executable file to be renamed and
    executed later via script. Just a thought, but you didn't
    hear that from me...