26th Sep 2002 [SBWID-5272]
	AOL Instant Messenger direct connect feature leads to remote exploit
	All versions of AOL Instant Messenger (up to 4.8 beta) on all  platforms
	of Windows.
	Noah Johnson posted this very fine analysis of AIM protocol weakness :
	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,
	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" 
	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
	 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
	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. )
	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...
	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 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
	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
	 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...
	Never accept a direct connection from anyone you don't trust.
	No fix yet.