Bugging a Room With an IP Phone
by Malvineous
My employer recently changed all the analog phones in my building to VoIP handsets.
From the NEC DT700 series, the phones are quite nice. They are powered over the network cable (PoE), have a nice color LCD screen, and - most interesting of all (for me) - they run embedded Linux. Like all good hackers, I was keen to explore my new toy and, shortly after it arrived, I was surprised to find it was running an SSH server - if only I could find out the username and password...
I discovered that in the phone's menu system, you can see the IP address of the Private Automatic Branch Exchange (PABX) it has registered with. It also allows you to download files from the PABX via FTP if you know the filename. Trying my luck, I connected to the PABX from my PC with a normal FTP client, and tried logging in as the anonymous user. It let me in, and I was able to look through all the handset configuration files. But more importantly, I was also able to download the latest phone firmware to my PC.
Extracting this firmware archive revealed a handful of files, one of which contained a JFFS2 filesystem - a very common way of storing all the files needed to run an embedded Linux system like this. It was very refreshing to find this so easily, as most manufacturers go to a lot of effort to obscure the contents of their firmware images, so thumbs up to NEC for being developer-friendly here. Extracting the JFFS2 filesystem gave me copies of /etc/shadow from the phone. As any security researcher will tell you, getting hold of this file not only gives you a list of all the users on a system like this, but it's a big step towards getting hold of their passwords too.
Normally you would take the hashed passwords from this file and try to brute-force them with a utility like John the Ripper, but in my case I noticed immediately that of the three accounts - root, admin and tp - admin was the username mentioned in the docs for logging in via the phone's web interface. Trying to SSH in as the admin user worked! The password was the same as the web interface: 6633222 (the numbers you would dial to spell "NEC").
Again to my surprise, when I connected I wasn't greeted with a text-based config menu, but with a BusyBox shell!
Now that I was in, I could really look around the phone and see what was there. The tp account had a .history file that suggested it was used during manufacturing to test the handset. However, beyond finding information about the hardware in the phone by looking in /sys and /proc, there wasn't much else that could be done - the admin user did not have a lot of access. I did notice that inserting a flash drive into the phone's USB port would automount it as /mnt/usb-sda, despite the manual suggesting the USB port was for a headset only. Perhaps there is another avenue for access there, if the phone happens to autorun certain files found on a USB stick. Either way, to do anything more interesting, I knew I would need root access.
This, as it turned out, was much easier than I expected. After a dozen or so guesses, the root password turned out to be one that was mentioned in a document I had stumbled across earlier. It was 6633222444 ("NECI" on the dialpad - NECI seems to be an internal codename of sorts, as many of the phone's programs contain function names beginning with "neci_").
Now that I had root access, I had full access to the firmware and hardware, and could modify any files I liked. I could have installed a proper back door on the phone. However, as it turned out this wasn't necessary. Because the phone uses the standard Advanced Linux Sound Architecture (ALSA) system for audio, as well as shipping with the arecord and aplay utilities for working with audio, with a single command line and no firmware modifications, I was able to record audio from any supported input (handset, speakerphone, or headset), stream it live over the network (fully encrypted thanks to SSH), and then play it on my PC!
A command like this is all it took:
This command creates an SSH connection as the admin user to the phone at IP address 10.0.0.1. Instead of starting a shell like normal, it runs the su command to become root, then as the root user it runs the arecord command to capture audio.
This is all necessary because you can't connect via SSH as the root user (good security practice), but you do need to be root to access the audio device. The arecord command records audio from the default device (which happens to be the hands-free microphone) at a sampling rate of 48 kHz.
Because I haven't supplied a filename to record to, it sends the captured audio to standard output instead, which means it gets fed back over the SSH connection to the PC.
The pipe (|) then takes this audio data on the PC side and feeds it to the aplay utility, causing the PC to play the audio received over the SSH connection. Because no files are involved, the audio data is being streamed direct and you hear the audio live - there is a latency of about 500 milliseconds, which could be reduced by fine-tuning the buffer values, but in this situation a delay of half a second isn't a problem.
When you run this command, you need to type in the admin password (for SSH) as normal, but then you have to type the root password (for su) blind before the audio starts streaming. It's "blind" because you don't see the su prompt due to all remote output being fed to aplay.
(Instead you hear a brief click as su displays the Enter password: prompt, and is decoded as PCM audio data and played on the PC instead.)
All this means I had discovered a way of connecting to any phone on the network and using the hands-free microphone to record what was being said in the room at the time, without anyone knowing! This was especially interesting because when the phone is accessed via the web interface, the phone is temporarily disabled as a warning message flashes on the screen. Not so via SSH - in fact, the phone can be used normally while the recording is taking place, with the owner of the phone none the wiser.
The phone also has an illuminated "mic" button that can be used to silence the hands-free microphone during a call, however because I was using ALSA to access the hardware directly, the state of this button had no effect on the recording. I could hear what was being said in the room even if the microphone was showing as being muted.
Needless to say, this discovery caused a bit of a stir when I reported it to our telephony people! However, it only took two days until our network admins had blocked SSH traffic to the phone subnet, so the problem is - probably - solved for now.
The lessons?
Never trust a device or computer to only run services listed in the manual - always firewall it and allow only the services you use to go through - especially if it has a microphone or a camera in it! And if you're a fan of devices that run Linux, you would do well with an NEC IP phone.
The firmware is very easy to modify. Unfortunately though, like many companies, NEC violates the GPL as they refuse to release any source code or details about the firmware build environment saying it's proprietary, but what can you do?