Dec 27, 2010

Hacking Skinny: Technical and Business Notes on SCCP

by Frank Gifford

By Frank Gifford

Sometimes security means taking care of the obvious things. Your car windows are rolled up and your doors are locked as you run into a convenience store. You don't write down passwords where anyone else could find them. Common-sense stuff.

For networking protocols, this common-sense stuff includes using standard network byte order and only a handful of packets types to transmit data. Using something different than network byte order creates a potential area for a bug to hide. More packet types means more opportunities for a bug to stay hidden, especially if such a bug depends on a particular combination of previous packets.

I was reminded of this as I was working on our implementation of Cisco's Skinny Client Control Protocol (SCCP), which is used in some Cisco voice-over-IP (VoIP) phone systems. I understand that Cisco inherited SCCP and its code base when they bought the startup Selsius in the late 1990s. Beyond that, the over-engineering is, unfortunately, found in many different protocols, not just SCCP. But seeing how important SCCP is to everyday communications, it is critical that we address these issues as they come up.

Technical Risks

The big problems with this protocol, from a security perspective, are that it has 133 different packet types and uses little-endian byte ordering to transmit data. If any of those packets has a bug, or if any number transmitted in little-endian order is converted by the normal big-endian network byte order, then you are ripe for attack. Seemingly benign points of entry to your VoIP system – like the courtesy phone in your waiting area – can become points of attack. An attack could be as simple as a denial of service (DoS) or a bunch of charges to embarrassing phone numbers, or it could be made more complex with voice mail redirection.

One moderately complicated SCCP packet, for example, is the Update Capability Message, which looks like this:

4 bytes data_length
4 bytes reserved (0x00)
4 bytes opcode (Update Capability: 0x30)
4 bytes audio capability count
4 bytes video capability count
4 bytes data capability count
4 bytes RTP Payload Format
<variable length data>

The lengths are sent on the wire in little-endian format, as opposed to the more natural big-endian network byte order. Networking programs written in C are sprinkled with calls to convert 2- and 4-byte integers from the host operating system to and from network byte order. These are, for example, htonl() and ntohl() for converting a 4-byte integer. There isn't a little-endian equivalent for this, since network byte order is a well understood and agreed-upon standard.

This lends itself to a potential bug that could be introduced accidentally in future updates. The scenario isn't hard to imagine: A newly hired programmer is asked to work on the SCCP protocol and accidentally uses a ntohl() conversion -- the way it's done in all other networking protocols. Now, what would be a little-endian data count of 16 is interpreted as 268435456 in big-endian format, and the protocol decoder may actually use that invalid number. Again, it's easy to imagine a scenario where a vendor runs only a minimal set of tests to verify an implementation. Since four zero bytes is the same in little-endian as well as big-endian, tests run with zero bytes will succeed.

Testing is difficult, even when one is being methodical: A proper testing suite might require dozens of combinations and regression tests. But that's in the ideal world. The sad reality is that, for technology vendors, security is usually secondary to getting the product to work. So a product tends to ship once it works, not when it's been tested adequately. Certainly the vendor's phones will work with the vendor's server, even with the bug described in place.

It's worth repeating that there are 133 separate packets defined for this protocol, which multiplies this problem by orders of magnitude. If any one of those packets has a poor implementation, you could end up with an error message like this on your Cisco IOS console:

005815: *Nov 11 12:06:55.630 PCTime: %SYS-2-MALLOCFAIL: Memory allocation of 18188 bytes failed from 0x

Pool: I/O  Free: 976240  Cause: Memory fragmentation

Alternate Pool: None  Free: 0  Cause: No Alternate pool

 -Process= "Pool Manager", ipl= 0, pid= 6,  -Traceback= 0x4007D814z 0x40099DB0z 0x403895E0z 0x400B6D14zz

Such an error gives me pause. Considering this is a specialized piece of hardware doing nothing but handling phone calls, we shouldn't be able to consume resources and fail like this. I wouldn't be surprised if I could fiddle with the allocation amounts and cause more than just an error message.

Business Risks

As I hinted at already, a DoS attack on your VoIP system could be launched via the courtesy phone in your waiting area. The wire going into the phone is nothing more than a standard RJ-45 plug. A little perusal of the http://hackaday.com/ site can give you a sense of how easy it is for someone to build a tiny customized computer able to attack your system. And even if there is no phone in your lobby, the cleaning crew has physical access to every office. Can you trust every single member of that crew? If your company were in discussions with another as a takeover target, information about that transaction could be worth a lot of money to dishonest people. Thinking about another potential hack, can you be sure that your voice mail isn't being redirected? And at what dollar amount do you have to start thinking about these risks?

Maybe I'm nitpicking when it comes to something as banal as byte ordering, but these are the sorts of problems we work on daily, and it heightens my understanding of the technical and business risks connected to them. Seeing the above error message on my terminal doesn't give me a strong feeling that the protocol is bug-free, let alone genuinely secure. Hackers won't inform you ahead of time if they discover a flaw. Even something as simple as having your office phones knocked out for the day could be amazingly disruptive.

Without full code inspection, we can never be sure that something is secure against all attacks. It's worth it to lay your hands on the tools that allow you to do this, and to convince your company's decision makers that the work required is a fair trade for the added security – and the peace of mind – that it brings.

Lessons Learned

For the programmer:

Network byte order is the standard. Using a non-standard way to represent your network traffic can only invite headaches, with no benefits gained.
Your validation solution (you DO have one, don't you?) needs to generate malformed data and counts, too. The Update Capabilities packet, just to take one example, has four count fields, all of which need to be verified against each other. (Not to hit you over the head with an advertisement, but the BreakingPoint Storm CTM has all the functionality you'd need for packet fuzzing and counts. And, of course, SCCP coverage comes built-in.)
Don't be overly clever – or disorganized – by choosing 133 unique packet types. When you do, your validation system has to worry about packet combinations. Each packet is now a new code path that has to be examined in detail.
Your code should not blindly accept data being handed to it. Verify that all the internal counts add up and that they are all reasonable before you allocate memory.

For the business owner:

Any device that communicates with any other device, no matter how simple, must be evaluated for potential risks.
This is especially true when such a device can ever be in control by a person who might want to attack you or steal from you. Certainly your business has had its share of interview candidates who were turned away. And those people were just a few feet away from a variety of vulnerable equipment.
Risks should be evaluated from a likely-case mindset. In the case of an attack against your phones, for example, the likeliest risks are international phone calls that are charged to you, or a denial of service that renders your phones unusable. You can prioritize other risks after that.

Your job should be working on your business, not having to pick apart the details of every electronic device in your office. But sometimes the due diligence of building your business comes in exactly that process of handling gory details. (Again, we'd love to help.)

Actions to Take

Force every vendor to certify their equipment from a security standpoint. This at least puts them on notice that your company cares about security and will hold them accountable.
Arrange a trial run of the equipment and then hammer that equipment. Ask some employees to come in on a weekend to try their luck. Give a bounty for issues they discover.
Insist that the vendor explain all the unexpected messages that appear in the logs to the satisfaction of you and your best programmer.

Those are the key technical and business lessons that I took away from implementing SCCP. If you have questions or comments, I'd love to hear them.