MSN messenger sends IP addresses Public and Private
MSN Messenger bug
Release Date:
10/12/2008
Versions Affected:
Msn messenger 8.5.1
-------------------------------
Description :
The protocol MSNP15 Windows Live Messenger Client 8.5.1 transmit to the
information on the IP address public and private. Everything happens
during a conversation that starts with you in our contacts list.
By analyzing the conversation with Wireshark can be noted that in
addition to passing the information, such as the sessionid, the Cal, the
Ringing, and also pass Ipv4ExternalAddrsAndPorts
Ipv4InternalAddrsAndPorts. Ipv4ExternalAddrsAndPorts indicates the
public IP address with its front door, Ipv4InternaladdrsAndPorts
indicates the private IP address and port logic of our interlocutor.
This happens because the server fails to properly manage the various NAT
Client. That is, the server should send its IP to another client and not
the client you are talking.
Here is a portion of the frame concerned:
MSNMSGR:aaaa@xxxxxxxxxx MSNSLP/1.0
To: <msnmsgr:aaaa@xxxxxxxxxx>
From: <msnmsgr:bbbbbb@xxxxxxxxxx>
Via: MSNSLP/1.0/TLP ;branch={D4CE435D-8C31-4D80-80EC-576A8294B3B3}
CSeq: 0
Call-ID: {00000000-0000-0000-0000-000000000000}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transudpswitch
Content-Length: 157
IPv4ExternalAddrsAndPorts: 79.2.165.233:3939
IPv4InternalAddrsAndPorts: 192.168.0.2:3939
SessionID: 729003413
SChannelState: 0
Capabilities-Flags: 1
We can also note the whole party in the case where Bridge conduct a
summary of the fields of our interlocutor.
This is the second part of the frame concerned:
Bridge: TCPv1
Listening: true
Conn-Type: Port-Restrict-NAT
TCP-Conn-Type: Port-Restrict-NAT
Nonce: {2DA8E1E7-CD08-4200-8E62-C2263EAC2D36}
IPv4External-Addrs: 79.2.165.233
IPv4External-Port: 3973
IPv4Internal-Addrs: 192.168.0.2
IPv4Internal-Port: 3973
SessionID: 275007100
SChannelState: 0
Capabilities-Flags: 1
Here is the full frame of the conversation:
MSNMSGR:aaaa@xxxxxxxxxx MSNSLP/1.0
To: <msnmsgr:aaaa@xxxxxxxxxx>
From: <msnmsgr:bbbbbb@xxxxxxxxxx>
Via: MSNSLP/1.0/TLP ;branch={D4CE435D-8C31-4D80-80EC-576A8294B3B3}
CSeq: 0
Call-ID: {00000000-0000-0000-0000-000000000000}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transudpswitch
Content-Length: 157
IPv4ExternalAddrsAndPorts: 79.2.165.233:3939
IPv4InternalAddrsAndPorts: 192.168.0.2:3939
SessionID: 729003413
SChannelState: 0
Capabilities-Flags: 1
######A#########g#######g#######¶8»#############INVITE
MSNMSGR:aaa@xxxxxxxxxx MSNSLP/1.0
To: <msnmsgr:aaaa@xxxxxxxxxx>
From: <msnmsgr:bbbb@xxxxxxxxxx>
Via: MSNSLP/1.0/TLP ;branch={31DB585D-3119-40AF-B02B-3D9BAEF32CD0}
CSeq: 0
Call-ID: {9A68685A-1FCF-86A1-B639-BA769BA9B514}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transreqbody
Content-Length: 270
Bridges: TRUDPv1 TCPv1 SBBridge TURNv1
NetID: -375061937
Conn-Type: Port-Restrict-NAT
TCP-Conn-Type: Port-Restrict-NAT
UPnPNat: true
ICF: false
Hashed-Nonce: {D8F5EEB9-2568-FAE8-9460-3FF8DB908381}
SessionID: 275007100
SChannelState: 0
Capabilities-Flags: 1
#####MSG 49 D 155
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: bbbb@xxxxxxxxxx
####_áEu########g#################A#¶8»#g###########ACK 49
MSG 50 D 555
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: bbbb@xxxxxxxxxx
####^áEu######################ÔùH(############MSNSLP/1.0 200 OK
To: <msnmsgr:bbbbb@xxxxxxxxxx>
From: <msnmsgr:aaaa@xxxxxxxxxx>
Via: MSNSLP/1.0/TLP ;branch={31DB585D-3119-40AF-B02B-3D9BAEF32CD0}
CSeq: 1
Call-ID: {9A68685A-1FCF-86A1-B639-BA769BA9B514}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transrespbody
Content-Length: 83
Bridge: TCPv1
Listening: false
Nonce: {00000000-0000-0000-0000-000000000000}
#####ACK 50
MSG bbbb@xxxxxxxxxx [c=28][i]BBBB[/i][/c] 143
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: aaa@xxxxxxxxxx
######A#########################^áEuÔùH(###########MSG bbbb@xxxxxxxxxx
[c=28][i]BBB[/i][/c] 815
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: aaaa@xxxxxxxxxx
######A######### ####### #######àe»#############INVITE
MSNMSGR:aaaa@xxxxxxxxxx MSNSLP/1.0
To: <msnmsgr:aaa@xxxxxxxxxx>
From: <msnmsgr:bbbb@xxxxxxxxxx>
Via: MSNSLP/1.0/TLP ;branch={5BDF5F91-90FF-4C0F-ACA6-F65A9E30986C}
CSeq: 0
Call-ID: {9A68685A-1FCF-86A1-B639-BA769BA9B514}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-transrespbody
Content-Length: 326
Bridge: TCPv1
Listening: true
Conn-Type: Port-Restrict-NAT
TCP-Conn-Type: Port-Restrict-NAT
Nonce: {2DA8E1E7-CD08-4200-8E62-C2263EAC2D36}
IPv4External-Addrs: 79.2.165.233
IPv4External-Port: 3973
IPv4Internal-Addrs: 192.168.0.2
IPv4Internal-Port: 3973
SessionID: 275007100
SChannelState: 0
Capabilities-Flags: 1
An attacker could have free access to the router or network situations
and commit illegal actions or damage other networks.
------------------------------------
Possible fix/workaround :
This bug could be resolved in Sever which operates the Nat Protocol
MSNP15 and possibly creating a new protocol that does not create
problems of this kind.
--------------------------------------
This bug was discovered using the software installed in Pidgin 2.2.0
Linux distribution Slackware 12.0, during the various conversations with
users who use Windows Live Messenger 8.1 and 8.5.
Please send suggestions or comments to:
carmelobrancato@xxxxxxxxx