View and vote on the article here: Eavesdrop VoIP calls - Voice over IP Security
Eavesdrop VoIP calls - Voice over IP Security| Category | | | Summary | Phoning over Internet/Intranet seems perfect. You can increase costs and the administration of phonecalls within a IT-Structure becomes easier for SysAdmins. But there is at least one point, every admin should think about: security!
Without some prev |
| | Body | One of those hype-applications for IP-based networks, this means the Internet as well, that could be important in the very near future is VoIP (Voice over IP). In the very first beginning the most used argument for VoIP have been the costs compared to a PSTN (public switched telephone network). Since within mosts countries there is a liberation of the telecommunications market, the 'costs argument' is no more this important. But there are more arguments for VoIP, like the convergence of the networks (Everything over IP) and the integration of the most important communication devices to computer based applications. Also VoIP can more then only offer a base for simple phoning, it also supports videoconferences and distributed cooperative working et cetera.
To understand the following passiv attack on IP-telephone calls, you'll need some knowledge/experience with multimedial applications who are internet based. To control a session you need a signalisation protocol. With those protocol the two user can control the session (call, hang up, knock et cetera) and choose the necessary parametres like codecs, transport adresses and so on. As soon as the signalisation is done, the endpoints can open one or more media channels/connections and in the case of VoIP transmit voicedata. Currently established signalisation protocols are H.323 and SIP. The transfer of the mediadata (voicedata) is realized via RTP/UDP. For example the often used (yea, you never use microsoft products, I know) MicroSoft NetMeeting is based on H.323 for signalisation adn RTP for the media transfer.
------------------ signalisation ------------------
| | - - - - - - - - - - - - - | |
| multimedia app 1 | | multimedia app 2 |
| | - - - - - - - - - - - - - | |
------------------ data ------------------
The eavesdrop of a IP-based phonecall is easy to realize with some ordinary tools. For example you can use a
simple Sniffer like Aldebaran to eavesdrop the mediastream and you can reproduce the stream using the Java Media Studio (JMS). Aldebaran allows you to forward filtered packets via UDP-datagrams to any host, and not only to show you a text like some Sniffer do (tcpdump, etherreal). Since real-time orientated applications use UDP as the transport protocol, Aldebaran can create a copy of the packetstream. In case at the endpoint host, Aldebaran sends the UDP-datagrams to, there is a media-player listening at the port Aldebaran sends the datastream, you just need to configure the Player to be able to open and reproduce the RTP-packets. Within the headers of the incoming RTP-packets the media player can read the used codec, and can (if a decoder is added) reproduce the stream decoded. The JMS can open RTP-sessions and includes many public used codecs, so it's my number one choice, but you can seek for any other media player that can reproduce RTP-packetstreams. JMS includes the codecs G.711 (ISDN-quality), G.723 and H.263 (both used for videoconferences). In case you choose to seek for another media player then JMS, make sure those codecs are supported. The JMS is included in the optional packet Java Media Framework (JMF). For Linux there is a ported version of the JMF available at Blackdown.
Let's imagine a situation like this one:
gabbana
Dropkick - - - - - - - - - - - - *** - - - - - - - - - - - - Overlord
1.1.1.1 1.1.3.1 1.1.2.1
Dropkick and Overlord want to phone with each other via VoIP, and gabbana wants to eavesdrop this communication. Actually this works like every other eavesdrop/sniffing of communication. You get access/control over a routing point of this communication, intercept the data, and send a copy of them to yourself.
Gabbana would need to do the following to realize this process, without leaving traces for Overlord or Dropkick:
aldebaran -i eth0 -h 1.1.3.1:5000 \
-r ip src host 1.1.1.1 and port 5000
aldebaran -i eth0 -h 1.1.3.1:5002 \
-r ip src host 1.1.2.1 and port 5000
This example shows that both directions need to be intercepted seperate and been forwarded seperated. The program you use for the reproduction needs to listen this way at port 5000 and port 5002! Within my favorite program JMS you can initiate this within the setting 'Open RTP Session...'. The flowing settings (address, port and TTL) need to be customized to the stream you wanna eavesdrop.
eavesdrop multimedia streams
But like I mentioned in the introduction, I'll show you also how to eavesdrop nearly every multimedia stream. The process is the same as above. Something about the 'technical part': Aldebaran is currently available in the version 3.0.2, but only for linux(-like) systems. Since nearly all network sniffers are based on the libpcap and a port named WinPcap exist, it's a simple task for a experienced C/C++ coder to port Aldebaran. For those, who love Java when it comes to network apps (like me), you can use the Jpcap, and implement easily network sniffer based on this lib-interface. With the Jpcap developers have the chance to use a Java Native Interface (JNI) to libpcap or WinPcap. This way you can do the eavesdrop on every system that has a JVM.
Most of you will now say: yea, nice, but getting control of one of the routing points it the step I won't be able to do, whenever I want to. You don't even have to, incase you want to eavesdrop someone within your local area. No, I'm not talking about WLAN's, that would be to easy ;)
In case the both endpoint use the same routing point, the described passiv attack is still possible. Networks that are structurized via switches are no exception for experienced users. MAC-Spoofing with tools like arp0c or dsniff or Random MAC-Flooding with angst can confuse the switch and force the switch to send the packets to all ports and 'degenerate' the behaviour of the switch to the functions of a hub. The conclusion is, that networks that are structurized via switches are not secured against this eavesdrop attack.
How to secure real-time communication based on VoIP
Beside the security solutions of the vendors of the RTC-applications (which are nearly 0% interoperative), standards like IPSEC can do the end2end-encryption of the IP-packets. This solution is independent from the VoIP application you use, but includes a load of administrative jobs you'd need to do. Beside of this argument, the platform you use need to support a IPSEC implementation. Within the H.323 protocolsuite there is currently a development on a improved H.235 standard, including encrypted RTC-Payloads.
Another solution is the currently discussed SRTC (see IETF's website for the project AVT-WG), but this solution is still only a draft, and waits get become beta finally.
Until there are no up-to-date security solutions for all of the stated flaws, happy eavesdropping (for educational use only).
gabbana
|
|
This article was imported from zZine. (original author: gabbana)
There are no replies to this post yet.
|