Full Disclosure mailing list archives
Observing the observer in VoIP communications
From: "michele dallachiesa" <michele.dallachiesa () gmail com>
Date: Mon, 14 Apr 2008 12:00:53 +0200
hi all, I've written a little article on detecting not-so-passive voip tapping systems. probably it won't work in the most cases... I think/hope police uses well coded sniffers that can't be detected. anyway, who knows, maybe somewhere in this sick sad world it may work. have fun! *** Intro The most diffuse VoIP protocols, SIP and H.323, have a Web bug you can use to (try to) know if someone is tapping your conversations. It may also help to make their sniffing work harder but it's less relevant and interesting, if you really want confidentiality and privacy you must use encryption and anonymized endpoints. *** Scenario You suspect someone is trying to sniff your VoIP conversations, you want to investigate. *** Know your adversary The VoIP tapping systems work sniffing network traffic from privileged network points where they can see everything of everybody, seeking for SIP/SDP messages, using them to detect and reconstruct the RTP streams. Any packet is recorded for later use/analysis. This simplification is ok in order to understand the technique. *** Attack I'll describe what to do with SIP,something similar should work also with H.323. The SIP protocol uses the SDP protocol in order to send the RTP stream parameters. If what I've said sounds too strange, go RTFM and come back! Consider the following SDP message: v=0 o=Michele 123456 654321 IN IP4 192.168.2.8 s=A conversation c=IN IP4 192.168.2.8 t=0 0 m=audio 7078 RTP/AVP 0 111 110 3 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:111 speex/16000/1 a=rtpmap:110 speex/8000/1 a=rtpmap:3 GSM/8000/1 a=rtpmap:8 PCMA/8000/1 m=video 9078 RTP/AVP 97 98 99 a=rtpmap:97 theora/90000 a=rtpmap:98 H263-1998/90000 a=rtpmap:99 MP4V-ES/90000 Description: Michele announces he is listening for an audio and a video stream respectively on UDP ports 7078 and 9078 at the same IPv4 address 192.168.2.8. The rtpmap records are used to map RTP payload type to encoding formats, something not relevant for our purposes. The interesting line is "c=IN IP4 192.168.2.8", from RFC 2327 - SDP: Session Description Protocol: If a unicast data stream is to pass through a network address translator, the use of a fully-qualified domain name rather than an unicast IP S is RECOMMENDED. In other cases, the use of an IP address to specify a particular interface on a multi-homed host might be required. Thus this specification leaves the decision as to which to use up to the individual application, but all applications MUST be able to cope with receiving both formats. As stated in the specification, any valid Fully Qualified Domain Name (FQDN) may be used to specify the destination address, so you can set it to "myip.dnslogger.freeasbeerdns.org" if it resolves to the correct IPv4 address.If you have also the control over its authoritative DNS, you can log any resolution attempt… catching the observer too! In fact, the hypothetic VoIP tapping system should consider the FQDN announced in the SDP messages in order to know the correct IPv4 addresses and UDP ports of the RTP streams. If it uses the IPv4 addresses of the SIP messages, it will fail to recognize correctly the RTP stream endpoints in particular SIP configurations (like with not transparent SIP proxies). If this happens, it will probably loose completely the RTP stream content, and bye bye voice! In practice, if "freeasbeerdns.org" is a free DNS service that allows you to be the authoritative DNS for any subdomain and you have registered "dnslogger.freeasbeerdns.org", any DNS query to "*.dnslogger.freeasbeerdns.org" will be forwarded to "dnslogger.freeasbeerdns.org", where you have Bind running, logging everything and resolving myip.dnslogger.freeasbeerdns.org to your IPv4 address. This solution is costs-zero, apart your-time cost :) Final note, you can change in the same way also the IPv4 address in the "o=Michele 123456 654321 IN IP4 192.168.2.8″ line. This shouldn't be necessary, anyway who knows… an heuristic implemented in the VoIP tapping system may detect the incongruence! *** Final considerations If something like rtpbreak is used, nothing can be done… anyway this is not the case, if you are lucky and I'm not around :> There are many different ways to implement a VoIP tapping system, the described technique may or may not work! -- Michele Dallachiesa 'xenion' http://xenion.antifork.org Antifork Research, Inc. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Observing the observer in VoIP communications michele dallachiesa (Apr 14)