DISQUS

Matasano Chargen: The Wild World of VoIP

  • Chris · 1 year ago
    yes, voip services by large carriers or inside enterprises are horridly built (from a security standpoint at least). One very large telco has/had (they are migrating away finally as I recall) a SBC implementation built by them before the 'SBC" even really existed. That's nice, it's innovative, it sucks rocks... more than 30 call setups/second and poof it dies. This from a company that does more than a billion minutes a month on their network, so the ought to understand call setup rates, scaling, etc...

    One of the prime vendors for this telco actually, when asked to help design a solution for a particular VoIP problem turned over a set of documentation (very thorough and long) for the solution... They forgot to search/replace the competitors name in the documentation, they also couldn't be bothered to understand that in the original specifications there were large flashing notes about: "This will be deployed on the public network". Most of the docs, when they danced around 'security' would say: "and this must be deployed on a private network or behind a sip aware firewall", fine... got any firewalls that have ATM/oc-12 interfaces?

    Security isn't even a 'feature' for the vendors, and the operators rarely care about anything other than 'fraud' issues... 'Jane calls Joe, Joe tells the SIP gateway that the call ends prior to the 1min mark, since the media goes peer-to-peer jane/joe talk for a month for free on an open line, giant-telco loses 1mon of call time charges, boo!' No current production telco (and even enterprises rarely do this) voip system does p2p media, they all push everything through an SBC so that CALEA and other 'features' can be enabled on calls.

    ugh... voip-security-hotbutton.
  • wbrown · 1 year ago
    Yeah, I've noticed that the standard vendor response is to use a SBC, or a SIP proxy. But it doesn't really solve issues with the protocol stack or implementation. They're not going to be doing deep packet inspection on the headers, mainly just rewrite them. So if there were overruns or other issues discovered, the SIP proxy or SBC is not going protect you.

    And the marketing of such devices seem to be as a magical bandaid, much like firewalls. And they're priced accordingly, in the hundreds of thousands of dollars.
  • Matt · 1 year ago
    I just want to say: Hooray! The blog is back.
  • dre · 1 year ago
    Well I think it's great that you're working on VoIP. Just don't go reading my voicemail!

    In any case, great to have Matasano back, although I hate this commenting system and the new look and feel. Posting comments off-site to disqus forums is creeping me out. And the flash is double-creeping me out. Kthx.

    I'm curious if there are any libraries or component frameworks out there to help VoIP implementers. I know you speak of Wireshark as a guideline, but I was thinking of something more commercial, such as Coverity Extend (particularly for embedded devices). Or maybe something in between. I guess asterisk with PaX/GRSec wouldn't be a poor implementation choice, but I'm looking for something with a bit more assurance.
  • wbrown · 1 year ago
    You're safe from me listening to your voicemail -- not like I can do so without jumping through some pretty serious hoops!

    Good question. My slant on things has mainly been from the perspective of attacking existing VoIP implementations. Apparently there are VoIP implementations out there, such as Trolltech's Qtopia -- http://osdir.com/Article7982.phtml -- but I can't attest to their security, as I've never looked at this particular implementation.

    Most of the freely available implementations are oriented towards being a client, rather than being a VoIP switch and router. Perhaps there's a market here!
  • David Remahl · 1 year ago
    Hear hear, welcome back from the hiatus. You’ve been missed!