full-disclosure - Observing the observer in VoIP communications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 14 Apr 2008 12:00:53 +0200
From: "michele dallachiesa" <michele.dallachiesa@...il.com>
To: darklab@...ts.darklab.org, ml@...urezza.org, 
	full-disclosure@...ts.grok.org.uk, outofthebox@...grafix.org, 
	bugtraq@...urityfocus.com
Subject: Observing the observer in VoIP communications

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/