Telecom protocols revisited - Not just a signalling problem

A look at the design of the currently deployed signalling protocols for core networks, both SS7 and Diameter (legacy and LTE). Peculiar quirks and how the poor design has lead to the industry failing to adhere to its own standards.

For the last couple of years we have been told over and over again about the weaknesses in the SS7 and Diameter networks and how the procedures defined for mobility management, short messaging, profile management and supplementary services are flawed, mainly due to the lack of authentication. The topic has been dissected extensively and we have seen examples of the same attacks being reproduced against network after network. The industry has responded with dedicated signalling fire-walling and recommendations on monitoring and filtering. Things have been getting better and even if the majority of networks are still unprotected we have seen a strong willingness among operators to begin securing the networks.

However… if the communication protocols and procedures are broken, perhaps the encoding is too? And if that is the case, are we doing enough to fix it?

What happens when you approach these encoding models with the mind of a child and discover that the specifications themselves allowed technologies to grow into a patchwork of hotfixes where misunderstandings or bad coding practice has become part of the accepted interworking. How SMS went from a single operation defined by a flag in the TPDU to multiple opcodes with application contexts and versions, these days used interchangeable and sometimes encoded in ways that defies logic or even the standard itself. We will look at how Diameter allows for near infinite nesting and almost invites stack depletion attacks. And we examine how choices of data types in SS7 allows an attacker to exploit the encoding models of ASN.1 and makes a parser perceive one block of data as a specific data type, despite the fact that it is not. The ability to nest MAP applications inside MAP applications and how the protocol was designed to allow for dual addressing modes using both TCAP and MAP addressing fields.

This talk doesn’t focus on any single specific attacks but rather places emphasis on method, madness and interesting examples that may introduce unexpected behavior at the receiving end, but more importantly should raise an eyebrow or two for the mere fact that they are accepted as part of the standard.