('binary' encoding is not supported, stored as-is) AIM's 'Direct Connection' feature could lead to arbitrary file creation ---------------------------------------------------------------------- - Author: Noah Johnson ( nmjblueat_private ) Affected versions: All versions of AOL Instant Messenger (up to 4.8 beta) on all platforms of Windows (as far as I can tell). Preface: 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. Summary: 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 ORIGINAL FILENAME IS USED FOR THIS TEMPORARY FILE! (Can you see where this is heading??) 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 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 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 WE CAN OVERWRITE THEIR AIM SOUNDS?!") 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... 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 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 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. ... You get the idea. I'm sure there are plenty of other ways. Fix: 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 own... 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 WHETHER THEY CHOSE TO ACCEPT IT OR NOT. 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... 4/16/2002
This archive was generated by hypermail 2b30 : Wed Apr 17 2002 - 00:29:29 PDT