[NT] AIM's 'Direct Connection' Feature Could Lead to Arbitrary File Creation

From: support@securiteam.com
Date: 04/17/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Wed, 17 Apr 2002 12:12:30 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  AIM's 'Direct Connection' Feature Could Lead to Arbitrary File Creation
------------------------------------------------------------------------

SUMMARY

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 the AIM release 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.

DETAILS

Affected versions:
All versions of AOL Instant Messenger (up to 4.8 beta) on all platforms of
Windows.

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 was sent.

So, why does anyone care?
One last feature we forgot to mention is that when the client parses the
file and recognizes it as a RIFF/WAVE type, it will play that file
instantly via the 'SndPlaySoundEx' API functions. Instead of playing the
buffer directly from memory however, it is instead downloaded into the
Windows 'temp' directory and read from there. However, for some odd
reason, the original filename is used for this temporary file.

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 simply by appropriately
sculpting the "SRC" information. Here is an example of what might be sent
from the direct connection:

..
Data Headers (explained later)
<HTML><BODY>Hey, what's up?<IMG SRC="\..\system\johnny.important_file"
HEIGHT="0" WIDTH="0" DATASIZE="50" ID="1"></BODY></HTML><BINARY><DATA
ID=1">***WAVE FILE DATA HERE***</DATA></BINARY>
..

Assuming that the temporary 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?

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 do not care;
neither does the client. )
8,9,A,B ASCII 'WAVE'

Keeping 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...

Exploiting:
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
{
RIFF----WAVE----
Any dos command here
Any dos command here
etc...
exit
}

While we originally assume 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 start-up.

Another example:
A sample .VBS file C:\Windows\Start Menu\StartUp\exploit.vbs
{
RIFF____WAVE = ""
Any vbs code here
Any vbs code here
etc...
}
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.

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 own...

However, 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 we 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 only manually edit the conversation source [with
the 'wave file' already inserted] just before it's sent out (i.e. look for
the SendWindowMessage (WM_SETTEXT) on the RichTextBox).

ADDITIONAL INFORMATION

The information has been provided by <mailto:nmjblue@hotmail.com> Noah
Johnson.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Quantcast