Recording VoIP Calls (And Recording Other People's VoIP Calls)

Excerpted from my book VoIP Hacks (O'Reilly Media)

Logging and Record VoIP Streams

Biblically-speaking, there's not a whole lot Cain and Abel had to do with Voice over IP. But the program that bears their names is a really cool VoIP tool.

If you're not a Unix fan or just don't have the time to compile vomit and its dependencies in order to record a call, I've got the solution for you. There's a program for Windows called Cain and Abel. It uses the WinPCap library (just like Ethereal) for packet-sniffing, network device identification, password recovery, reconnaissance and literally dozens of other intriguing tasks. Cain and Abel is literally a Swiss Army knife of handy networking goodies.

Not least among these goodies is a VoIP call sniffer/recorder that's slicker than a wet rock. It provides a sortable, date and time-stamped listview that logs any VoIP calls it picks up during a sniff. It assumes any RTP (realtime transport protocol) traffic is VoIP, and attempts to decode it and record it into a WAV file. According to the Cain and Abel web site (http://www.oxid.it/cain.html), the program can decode calls in uLaw, ALaw, ADPCM, LPC, GSM, iLBC and a host of other codecs. Of course, it can't interpret any streams that are encrypted, so it's still nearly impossible to record a Skype call from another host.

Cain and Abel has a ton of password cracking and networking snooping stuff built-in, so be sure to abide by the local policy of the network you're working on, or you could end up in a heap of trouble.

The Easy Way to Intercept Calls

To record a call from the local computer where Cain and Abel is running-that's the easiest way-install the program on a machine with X-Lite or a comparable softphone that can place calls in one of Cain and Abel's supported codecs. Of course, this technique will only allow calls placed to and from this machine, not sniff out calls between other computers or IP phones.

Fire up Cain and Abel. Then, launch the Cain and Abel configuration dialog by selecting the Configuration menu option in Cain and Abel. Click the Filters and Ports tab, check the SIP/RTP entry to ensure you'll be capturing VoIP traffic. Then click OK.

When the Configuration dialog disappears, click the “Start/Stop Sniffer” icon on the toolbar. Now, place a phone call on the locally-running softphone. This could be X-Lite, Firefly, NetMeeting, or whatever, as long as it uses SIP or H.323 for signaling and RTP for voice transmission (just about all VoIP applications do). Click the Sniffer tab, then the VoIP tab (on the bottom of the GUI) to reveal the call list.

Notice that, as you place and receive VoIP calls on the machine where Cain and Abel is sniffing, your call log will begin to fill with entries on the VoIP tab. The call log will tell you the source and destination IP addresses of the media stream used in the VoIP call, the codec that is employed (if Cain and Abel recognizes it), and the port numbers involved in the RTP media path.

After you stop the sniffer by clicking the “Start/Stop Sniffer” button on the toolbar again (it toggles on and off), you'll see the file names where Cain has saved the recorded calls. The WAV files produced by Cain end up in \Program Files\Cain\VoIP, and you can play them opening them in your favorite sound player, or by right-clicking them here in the Cain GUI.

Intercept Calls Using Port Spanning

If you want to record a call between two devices that can't run Cain, like a call between two IP phones or a call from a Mac softphone to a Linux softphone, then the method described in the previous section won't work. Instead, you need to enable your Ethernet switch to “share” packets destined for the devices involved in the VoIP call with your PC running Cain. With your PC connected to a particular port, a typical managed Ethernet switch allows you to “listen in” on traffic on the other ports-like the ports where a VoIP call participant is connected.

On a non-switched network, like a hub, you can use the “easy way” to monitor any device that's connected to the hub.

Cisco switches use a technique called Port SPAN to mirror the packets sent or received on one port to another port. In this manner, the switch administrator can inconspicuously capture all traffic on any port he chooses. To record a VoIP call, you'll need to set up port spanning between your PC's port and the target VoIP device's port. For the moment, I'm going to assume you're eloquent enough with Cisco configuration that you can at least get into your switch's command prompt and Enable Mode. If you've no idea what this means, you might want to invest in James Boney's insightful Cisco IOS in a Nutshell (O'Reilly).

Let's say the VoIP device we want to record packets from is connected to port 5 on the switch. Use this command to mirror packets into what Cisco calls a “SPAN Session”, a place we can retrieve them from on another port:

Switch(config)# monitor session 1 source interface fastethernet 5/1

Now, traffic to and from port 5 is mirrored to SPAN Session 1. Next, we need to reflect that traffic to the port where the sniffing PC is connected, say port 4:

Switch(config)# monitor session 1 destination interface fastethernet 4/1

So now, traffic from port 5 will also occur on port 4, where the Cain PC can sniff it. (Don't forget a “write mem” if you want to keep the switch configured this way permanently.) Now you can use Cain (and vomit, for that matter), to record calls that traverse your switched network, even if you can't install a recorder on one of the participating VoIP devices.

Secretly Record a VoIP Call Without Access to the Switch Config

This is the ultimate sneaky way to intercept and record VoIP calls--do it at your own legal risk.

I'm going to demonstrate why people say VoIP isn't secure. If you've got a laptop and a patch cable, you can record calls from a Cisco CallManager IP telephony network or even from a Vonage subscriber. More specifically, you'll be doing this without the need for port spanning on the switch [VoIP Hacks: Log and Record VoIP Streams] and without installing a recorder or sniffer on the device you're trying to record [VoIP Hacks: Record VoIP Calls Secretly].

Instead, you'll be resorting to a tactic that's, well, unnatural. In fact, if you do this outside the test lab, it could be considered unethical, too, so be careful. I am about to teach you how to secretly listen in on other users' VoIP calls without having any direct contact with their VoIP phones or PCs, and without being the administrator of the local network. Be advised, though, I'm am not recommending that you ever do this in the field-just passing on some knowledge I picked up while working as a networking consultant.

An Ethernet switch has anywhere from 4 to 48 ports where Ethernet devices like PCs and IP phones can connect. Each device connected to the switch has a 32-bit hexadecimal address, called a MAC address. Ordinarily, the switch knows which port to send a particular packet because address resolution protocol (ARP) has been used by the sender (or by the closest router) to address the packet to the correct MAC address. All the switch has to do in order to get the packet to the right destination is transmit it on the port where the device with a matching MAC address is connected.

The secret to recording another person's VoIP calls is in making the switch think your MAC address is a valid destination for the VoIP traffic that's bound for that person's VoIP device. Specifically, when the sending device uses ARP to resolve the IP address of the intended recipient, your PC must respond by saying, “I am the holder of that IP address-send the data to me!” This hack, which rather goes against the prescribed way an Ethernet LAN is supposed to work, is called ARP poisoning. The result is that your PC intercepts the packets destined for the intended MAC address, so you can do with them whatever you like.

Once intercepted, the packets must be forwarded to the correct MAC address, or a denial of service will occur on the device you're snooping. In the case of VoIP, your PC can record (or play in realtime) the media stream before passing the packets to the actual intended receiver. A classic man-in-the-middle hack, this technique is simplified by the outstanding network tool, Cain and Abel.
To get started, use Cain's host discovery tool. Click the Sniffer tab, then the Hosts tab at the bottom of the GUI. Then, click the + in the toolbar. This will pop open a dialog where you can tell Cain to discover all of the devices on your network. I used it to discover the IP and MAC addresses of my Cisco 7960 phone (10.1.1.104), and my Asterisk server (10.1.1.10).

The reason you're discovering all of these hosts and resolving their actual MAC addresses is because Cain will need these details in order to perform the ARP poisoning. Once you can see the host you want to monitor in the list, click the APR tab and then click the + toolbar icon again. You'll see the New ARP Poison Routing dialog, as in Figure 6-21. Select the host you want to snoop on the left, and then select one or more of the destinations related to that host on the right. This way, you'll only be poisoning ARP requests for the snooped hosts if they're sent from certain IP addresses. I wouldn't recommended ARP poisoning a large group-this could cause difficulties on the network, including a rather comprehensive denial of service-so stick to one IP address on the left and one on the right until you've got the hang of it.

Ideally, the address on the right will be the host on the other end of the call, but it doesn't have to be. If the VoIP call is to a user on the Internet somewhere (via the default gateway), you would choose the IP address of your Internet router on the right side. In fact, if you wanted to sniff your Vonage calls, you would pick the address of your Vonage ATA on the left, and the address of your Internet router on the right. Once you've got a pair of addresses selected for monitoring, click OK.

Now, start the sniffer and the ARP poison router by clicking the “Start/Stop Sniffer” icon and the “Start/Stop” APR icon (which looks like a radiation symbol). Wait for a VoIP call to be placed on the targeted host-or place one yourself on that host-and watch the call list in the VoIP tab. In a moment, an entry will pop up, indicating that the call is in progress and being recorded into a WAV file by Cain.

Pretty amazing, eh? One more thing-I can't emphasize enough how unethical this hack would be if performed in an environment where you aren't authorized to do so. I strongly urge you to be responsible with this type of hack, and keep yourself out of trouble while you learn about VoIP security. Unless you have administrative authorization and the express right to monitor users' calls on the network where you're working, you should keep ARP poisoning confined to the test lab.