Saturday, December 15, 2012

Tracking an Internet User with VoIP

I started taking a closer look at SIP traffic last year, looking for areas to explore - especially information leaks. Of course, if you're receiving a VoIP call plenty of information leaks out: source and destination phone numbers, source and destination IP addresses, client versions, NAT traversal data (internal IP addresses), etc. But you're part of the call, so it's not particularly significant that you're getting some detailed technical information about the caller. But what about when you call someone else, or even just scan SIP services without establishing a call?

Here's something I pulled from http://shodanhq.com, from one of their SIP scans. Notice anything peculiar?



SIP/2.0 200 OK
From: "default";tag=6263663836643163313363340132393135323939393136
To: "default";tag=102a0650-1c6df8bc-13c4-40030-7410-6b0ccc7a-7410
Call-ID: 998491705710175513741509
CSeq: 1 OPTIONS
Via: SIP/2.0/UDP 12.173.169.116:5060;received=184.82.238.216;rport=5060;branch=z9hG4bK-1127167280
Supported: replaces,100rel,timer,UPDATE,INFO
Accept: application/sdp
Contact: sip:9668111181076@188.248.109.28:5060
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,INFO,NOTIFY,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 230 

Take a close look at the contact line:

Contact: sip:9668111181076@188.248.109.28:5060

I'll save you the trouble of looking it up: the IP address is in Saudi Arabia, and the 966 number is a Saudi telephone number - conveniently in international format. After seeing a few SIP responses like this I began to wonder how frequently this occurs. It turns out that it seems to be common to a few VoIP platforms, and they tend to be concentrated in certain ISPs. How dense? Some IP address blocks returned telephone numbers for 80-90% of the IP space scanned:

[...]
188.248.0.129 9668111109021
188.248.0.130 9668111050616
188.248.0.133 9668111407972
188.248.0.137 9668111413580
188.248.0.139 9668111155046
188.248.0.140 9668111077874
188.248.0.142 9668111164706
188.248.0.143 9668111190109
188.248.0.146 9668111384916
188.248.0.151 9668111371254
188.248.0.154 9668111108233
188.248.0.157 9668111372775
188.248.0.159 9668111248360
188.248.0.160 9668111023206
188.248.0.162 9668111101803
188.248.0.163 9668111047273
188.248.0.165 9668111429021
188.248.0.166 9668111020807
188.248.0.168 9668111013657
188.248.0.170 9668111059589
[...]

Saudi Arabia happens to have some very dense distributions of VoIP systems that leak the user's telephone number. Jordan has some clusters as well, leaking either 6-digit local telephone numbers or the VoIP username:

mada90120  178.77.153.78
maen       178.77.129.131
maher      178.77.153.140
mhk        178.77.142.212
moon       178.77.144.158
omar222    178.77.159.45
reyad      178.77.151.107
samer1975  178.77.145.232
tabuk      178.77.156.148
zain8afil8 178.77.151.238

Does it really matter?


From a privacy perspective, I believe that it does. If you're running a vulnerable device, it takes only a single UDP request to your IP address for a website operator to figure out your telephone number and have a strong identifier to track you across sessions and IP address changes. This selector can often be directly tied to a name, since phone books tend to be public and inclusive. While projects such as the EFF's Panopticlick show us that we can still be tracked by unique features of our browsers, this takes some effort and still just gives a probability that the correct association has been made. With VoIP/phone number tracking, one UDP packet can very confidently identify you.


P.S. If you'd like to try this out and create a log of the telephone number to IP mappings for an IP range to see how many devices are vulnerable, try running Sandro Gauci's excellent SipVicious tool and executing tshark like this at the same time to extract the meaningful tidbits:



tshark -i eth0 -R "sip && (not icmp) && sip.contact.user!=\"\" && sip.contact.user !=100 " -T fields -e frame.time_epoch -e ip.src -e sip.contact.user -e sip.contact.host