Introduction to Diameter Security
In this blog we are going to take a look at security problems in the Diameter network used by carriers to control the LTE Network. We will see how insecure the Diameter network is and how people are attacking it. We will look at what hackers are accomplishing by attacking it, and finally, we will look at how carriers can fight back and protect their subscribers and networks.
Diameter is a protocol used for Accounting, Authenticating, and Authorization (AAA) in many applications, but we will be focused on its use in the core of the 4G or LTE Signalling network, called the IP Multimedia Subsystem (IMS).
This discussion assumes that you have a background in Telecom Signalling in either SS7 or Diameter, and are already aware that an insecure Signalling network is costing carriers and subscribers money and loss of privacy. You probably would have gained that experience in SS7. The goal of now is to apply some of those SS7 lessons and move them to Diameter and see what has changed. Not all of those changes have been for the better.
Diameter is a protocol used in the 4G or LTE Signaling network. In 3G this role was performed by SS7. SS7 was not secure. It is a protocol that was written before the need for security came about. SS7 was initially deployed by only a trusted community and used specialized hardware for TDM links. The services riding on top of SS7 has grown beyond the original vision.
Diameter is newer than SS7 and has improvements, but it is an all IP based protocol so access is easy, and there are a few other features that make it easy to hack. The number of ways to access Diameter is huge. For both SS7 and Diameter, one can lease access, but even after accessing the SS7 TDM network in the old days, specialized equipment was needed, because of the TDM links. The equipment to access the Diameter network, which is a modern IP network, is readily at hand for all of us.
The people using that access are professionals. They are hacking for money. It is not the hobbyist teenager you need to worry about – it is the professional teams of engineers, motivated by profit that you need to worry about.
Interested in further information? Try this document from the European Union Agency for Network and Information Security: Signalling Security in Telecom SS7/Diameter/5G.
Let’s take a look at why Diameter is easier to hack. We will go into details on this in this discussion, but this is the summary.
Diameter is easy to hack, because:
- It is a hop-by-hop protocol, meaning each stage will be able to read the packets.
- Responses are just sent to whoever asked the question, without much checking that they are who they say they are.
- DNS and NAPTER can allow for redirection of traffic.
- There are systems that ignore specific parameters like the Application ID
- Plus, and this is important… all the same Attack Vectors that SS7 had are still open in Diameter.
A lot of this material is covered by the GSMA. Your company will have to be members of the GSMA to get a hold of these documents, but look for: GSMA FS.19 Diameter Interconnection Security, and IR.88 – LTE and EPC Roaming Guidelines to start.
There is some good news. Firstly, most of the hacking we see today is still on the 3G network in SS7. This is because the majority of roaming is still on SS7, and the hackers are very successful on SS7. From their point of view: if it is working, why change?
Diameter is a flat protocol. This means that the technology to look at various parameters in a message and to compare then us much more straightforward than SS7.
Also, Diameter does allow for IPSEC and DTLS to be used between 2 systems. This doesn’t provide end-to-end security, but it is a good start.
Finally, the best piece of news is that 5G will move away from Diameter to a Web Services model, which is much more secure. That part of the 5G standards has not been finalized, but it is looking like a great improvement.
Let’s look at some of the specifics as to why I say that Diameter is less secure.
Firstly, Diameter is a what is known as a hop-by-hop protocol. By that we mean, that each step along the path has to open and read the message. In the example above, the MME wants to send an Authentication Request to the HSS. If this is for an outbound roamer, then it is going to leave the current network, and maybe go through an IPX provider before getting to the home network.
Each of the systems along that path is going to open up the message. They will need to look at the message type and the destination realm, but in looking for that information, they get to see the rest of the message. This makes looking at the contents trivial and makes changing the contents also very easy. This aspect of the protocol opens it up to man-in-the-middle attacks.
To deal with this problem of looking for the header information, but getting every field, can be dealt with by encrypting those non-routing AVPs. In other words, encrypt the fields that the man-in-the-middle should not see.
This is simple in concept but unfortunately is complex in the real world. It assumes that key exchanges have been performed and that the end nodes and even the intermediate nodes are prepared for these changes.
It has not been used much in the real world.
If you want to read further about the concept of end-to-end encryption, have a look at this document from the IETF.
Another reason that Diameter is not secure: Responses go back to the connection that made the request.
In SS7, systems made the response to the Global Title of the requester, and any intermediate STP looked up that Global Title to determine the next path along the way. It did leave open the idea of spoofing the Called or Calling party, but generally one had to lease a legitimate Global Title from a Carrier to hack the network of a different Carrier.
Diameter made that easier. Systems responding in Diameter don’t even need to look at who sent the message, but just what connection it came over. If you send the answer back down that same pipe, then the Diameter protocol is satisfied, and remember the actual destination may be a few more hops along. The sender does not need to look at the Route-Record AVPs, which we know from the hop-by-hop protocol can be modified. Even AVPs like the Requesting Origination Host and Realm don’t really need to be looked at.
However, they should. Even if the protocol allows the answering system just to send the response back on the same connection, they really should do some basic checking to see if that is an appropriate thing to do.
Above is another diagram showing the same thing, but here what happens through multiple networks, when each system just replies to the same connection as the request was made. If that Attacker on the right-hand side, has spoof himself to look like an MME, then the hacker can send requests and get answers. No one in the middle is really checking to see that the hacker is legitimate.
DNS and NAPTR are not strictly Diameter problems, because they are outside of the protocol. However, they are important attack vectors on the LTE/IMS core network running Diameter, so let’s discuss them.
In the LTE/IMS core network, DNS is called for to simplify addressing. However, one of the easiest ways to bring down a network is often by attacking the Domain Name Server (DNS). It is possible to secure DNS. There are a number of companies whose entire focus is to provide secure DNS. However, a frightening number of networks have unsecured DNS. This allows the attacker to re-route messages.
Name Address Pointer (NAPTR) is also used in the IMS network to determine routes or even to discover new DEAs. However, the idea that you would allow a new element on a signalling network to present itself and start to be used is just not something most operations staff would agree to. The GSMA no longer recommends using NAPTR. Signaling elements don’t get added often and adding them in the DEA or DSC is not that arduous. Manually add them with names and IP addresses that are known to you. Signaling network elements, as a rule, should not talk to strangers.
So, what about new instances of an existing network element in a Virtual environment?… sure, this is a great idea, as long as it is verified and known, and it is not simply scaling up to pass more DOS messages into the network.
Topology Hiding in the IMS network is often thought of as some sort of protection – it is not. The purpose of Topology Hiding is to hide the real names and numbers of network elements in your network. This may be thought of as some privacy protection, but it really serves no purpose.
If the DEA is going to have an internal table mapping external names to internal names, then the communication or Denial of Service attack is still going to take place, just using a different name.
Topology hiding can simplify things, but please don’t think it is protection.
How Hackers Attack Your Network
Next, we turn our attention on how to attack the network. These attack scenarios are already public knowledge. The hackers know them, so you might as well know them too so that you can defend against them.
This first attack scenario provides information in its own right but is often critical for the other attack scenarios that follow.
In this situation, the attacker has spoofed himself to look like an SMS GMSC. Spoofing himself means that the hacker has likely leased access from a carrier and just happens to send application IDs saying the hacker is a GMSC. The hacker probably is going to spend their time attacking subscribers on other networks, because their home network might detect what the hacker is doing and shut him down.
Looking like a legitimate system the hacker sends out a Diameter message for Send Routing Information for Short Message. That is a request, and as we know, most systems will just happily reply on the requesting connection, so the hacker gets an answer. That response is going to tell the attacker the victim’s serving nodes, which gives a pretty good idea of location. It also provides the HSS address and the IMSI, both of which we will use in subsequent messages.
Now let’s assume that the attacker wants to narrow down that location information on your subscriber. This is a loss of privacy for your subscriber and a chance for others to know about where your subscribers roam and exactly where they go.
The attacker, this time, makes himself look like and SGSN. This is simple… the attacker just sends a new application id in the message, the DEAs and DEAs usually set up all connections as relay, meaning they take any message type. The attacker didn’t even need to send new CER messages to the DEA.
Using the IMSI and HSS address the hacker discovered before, the attacker sends a User Data Request. The answer to this doe provides detailed location information.
In this scenario, let’s assume that the attacker just wants to deny service to your individual subscriber. Again, using the IMSI and HSS address the attacker sends a Purge UE request to the HLR. Now the VLR thinks the subscriber is still on the network, but the subscriber will not get any calls, because the HLR won’t send the correct location information. Even more sinister, is that the subscriber cannot correct the situation by rebooting their phone. The VLR will not forward on the Attach, because it thinks the subscriber is already on the network.
Now if the attacker wants to cause much wider spread network havoc, there are other methods. For example, posing as an HSS, the attacker can send Network Reset requests to the MMEs or SGSN, which will cause all the attached subscribers to reattach. Seeing this repeated every few seconds, or in a 5G environment with millions of devices, causes frightening scenarios. (Remember 5G is going to a more secure Web Services based model, but it is not there yet.)
In this example, the hacker provides fraudulent services to the outbound roamer. While your subscriber is roaming, the attacker pretends to be an HSS. The attacker then sends an Insert Subscriber Data Request and changes the Operator Determined Baring parameter. This causes the SGSN to provide services that the subscriber is not authorized.
This example is intentionally a little trickier. It pulls together a few concepts we have seen before. In this example, we are going to take over the subscriber’s SMS messages. This is very powerful when used with email phishing attacks, and has been successfully directed at executives at a European carrier, where the attackers gained access to banking. The email phishing attack, got the executives to reset their banking passwords, and two-factor authentication did little to help, as the attackers were in control of the SMS messages.
The first step involves the attacker spoofing a visited SMSC, and sending a Diameter Send Routing Information for SMS. The attacker only needs the MSISDN or the dialed number of the subscriber at this stage. The attacker gets back the IMSI.
Now posing as a visited MME, the hacker sends an Update Location to the HSS using that IMSI. Now when an SMS message comes in, the HSS will query the spoofed MME to ask for the local visited SMSC. Of course, the attacker is using their own spoofed SMSC for that purpose, and the SMS is sent to him.
Fighting Back
The industry has not sat back while these attacks take place. One particularly good place to go for information is the GSMA and its subgroup the Fraud and Security Group (FASG). There you will find a series of documents. I have a few of the most important ones listed above. Especially important are FS.11 and FS.19.
No matter what those documents say, it is still important to look at your data. I show some actions in the right-hand side diagram. Firstly, at the top, we need some data to look at. At this stage, you don’t need to capture every Diameter message, but you do need some macro-level data. How much signalling traffic are you sending to certain countries? Certain carriers?
Now it is time to think like an accountant and look for anomalies. Why is that much data going to (or coming from) that carrier? What types of messages are they sending to where in your network? Does that signalling traffic make sense when you look at the TAP files? How does it compare to the actual subscriber bill, and complaints about those bills?
This may cause you to act – to change rules on your Signalling Firewall, or just to add further gateway rules on your DSC/STP.
Great first step! But it turns out this process is not over. It is a never-ending cycle of looking for anomalies and comparing with other data, acting on it, and monitoring some more. The hackers are not resting and are trying new tricks every day, so you have to be equally vigilant.
So, you have done some analysis or looked at the GSMA suggestions and you want to block certain types of traffic. A signalling firewall really is the best place to do this.
But even if all you have is a DEA or DEA/STP combination, then I urge you to use them. They are better than nothing. Most of them can do simple message blocking and provide basic KPI information.
Going forward, the Signalling Firewall provides a much more robust and sophisticated rules engine. When we get to Category 3 messages, where the firewall must block depending upon the known location of the subscriber, then most STP/DEAs fall apart. For Category 3 messages we want to see queries made to the HSS, VLR or even handset to verify the status and location of the subscriber.
Also, we like to see a firewall in use, because it is one central place to go when understanding the rules, what is being blocked, and who is roaming where. It makes for complex troubleshooting if some messages are blocked in the STP, others in the DEA and others in the HSS, each with their own interfaces and reports. The firewall brings all this together and allows the operator to make sophisticated rules and judgments.
There are many ways to attack the Diameter network used for LTE services. The good news is that there are tools and best practices available to help you secure your network, and protect your subscribers. This does not need to be complicated and a full-featured Signalling Firewall can even simplify your future troubleshooting needs while protecting your network.
Categorised in: Blog