Toll fraud with CDR field separator injection - part I

Overview

In case you ever worked with or for a service provider you probably know that CDR (Call Detail record) integrity is one of the most important issues.

The reason why CDR is so important is because it is the most common way for a provider to meter and record service consumption.

Normally, in post-paid billing scheme, when a subscriber places a call, the provider's switch generates a call record.
Most often the CDR file is a delimited flat file where each record in the file describes a single call (or call leg) and includes details such as - was the called answered or not, how much time did the call last, who was the calling party, what was the destination and lots of additional information regarding the call.

Periodically, the provider's billing system (directly or via a mediation system) parses the CDRs resulting in the charges associated with each record/call .

It is not hard to guess that if a call record for a specific call is missing or cannot be properly parsed by the billing system - the consuming entity (subscriber or peering partner) can avoid the charges associated with the call and the provider serving the call potentially loses revenue.

As previously mentioned, the CDR holds many details about the call. some of these details are actually taken from the signaling messages used throughout the call.
this is where it gets interesting - signaling messages may originate from possibly untrusted entities such as peering partner switches and subscribers. so it leads to the fact that potentially untrusted entities can affect the content of the most important information of a for-profit provider - the CDR.
Back in the old PSTN days this was less of a worry, ISDN Q.931 and SS7 ISUP were inherently limited in the information that could be injected into signaling messages. protocols were less extensible and specs were clearer and didn't update so often.
Going on to SIP, things are a bit easier for the malicious user - many fields in signaling messages can hold alphanumeric values, protocol specs tend to change frequently and when it comes to header field format validation in SIP stacks and application, well it nothing to write home about.

In part II I'll provide intimate details of a remote vulnerability I've discovered in known class 4 switch that allows a remote SIP peer to place international calls while avoiding termination charges by CDR corruption.
Note to blackhats and fraudsters - the vendor had been notified of this specific vulnerability, so don't hold your breath.