Open Relay Abuse
The story
I really didn’t give much attention to the ‘Country analysis’ world heatmap tab on the SIP honeypot data web interface till I one day noticed that every hour there were over 100 unique IP addresses from the US attacking my honeypots.
Checking the database I noticed a pattern in the format of the stored headers in the database. Next I checked the source IPs of the suspicious traffic in Shodan.io and noticed that although the traffic was coming from different sources, judging from the SIP User-Agent header, two brands of SBCs that were sending it. About 90% were Ingate SBCs and the remaining 10% were IceWarp. It was obvious that it was some kind of distributed attack, but why these brands? I personally had never heard of them so I contacted someone who I thought might possibly have first hand information from penetration testing VOIP systems … Sandro Gauci of Enable Security.
Last year when I started this honeypot project of mine, I started out seeking answers to specific questions I had, so I structured the database to gather enough data to answer those questions. To fully answer what was happening in this case, I was lacking the data in the backend database. Sandro had not worked with these devices either but we had our suspicions. The only way however to confirm was of course to take raw pcaps from the honeypots… Ansible to the rescue. Within minutes I had pcaps from all the boxes and … Yes, we were correct. All these servers were open relays and SIP traffic was being proxied through them!!
Sandro advised I do the right thing and contact Ingate and inform them of the situation because at this point there were over 1000 devices proxying traffic. He offered to help and was able to get in contact with the CEO. Their response was that their customers had misconfigured the devices so it was not their problem. Fair enough, but why were so many of them relaying the traffic? In my experience if it is not a bug on the device, then the default configuration might have wrong options set. To confirm, I would need access to one of these devices.
Open relay
Every proxy technically relays traffic. SBCs as well, they accept traffic on one end, generate a new call and send it out the other end. The issue arises then the devices are ‘open’ to relay any traffic that comes their way. That is, they do not have any limitation on the type of source traffic they are accepting nor on the destination they are sending the traffic to, nor if they need to be handling that traffic in the first place. This makes them an open relay. All an attacker needs to do is to relay their malicious traffic through such server and to the attacked end device the traffic would appear to be originating from the open relay server.
In principle, identifying this type of traffic is easy, but you need to know what to look for 😉. There are multiple indicators that when analysed together in context of the call flow, point to the issue. The most important thing is to know your traffic so that such oddities stick out when you see them.
- The URI in the request. Do you own the domain? Should you be handling such a domain?
- The Via headers. For a proxied SIP request, the number of Via headers would give an indication of the number of hops the SIP request has taken. Based on your network, is the count correct?
- The Contact header. It indicates where final responses will be sent. Do you know the URI?
- The source IP address of the request. Should it match any of the previously mentioned SIP headers? Is it ??
Traffic from the example diagram above would look something like
The Kamailio default config blocks this kind of traffic and I know some people who have been tempted to remove that bit of code as a shortcut to allow some type of traffic flow without fully understanding the consequence. Understanding it goes a long way. If you are not sure how to control such traffic on your SIP edge device, let me try and explain the idea with the help of code from Kamailio.
if(from_uri!=myself && uri!=myself) {
sl_send_reply("403","Not relaying");
exit;
}
The idea is simple, if the subscriber/caller is not a local subscriber to your server and the destination they are sending the request to is not a destination/domain your server manages or is aware of, well then such traffic does not have any business on your device… Unless of course you are in the open relay business. In the Kamailio snippet above, such a call would be rejected with a SIP 403 response code.
The traffic
Back to the story…. With the pcaps taken from the honeypots, I was able to trace the traffic back to the original attacker. The IP address was of course registered to a VPN service provider. The service provider this time was in Afghanistan. They were offering a 1 month free trial so it was not a surprise that after a month of monitoring this traffic, it ended. The traffic was not aggressive but dare I say, nicely crafted. The attacker was scanning the extension range 100 - 1000 daily. Proxying the traffic across about a 100 different IP addresses every hour. Sending one request per extension but spreading the attack over multiple honeypots. To see the nice ‘pattern’, data from all honeypots had to be queried and sorted. Dare I say I admired the effort put into this attack. It looked like the attacker was not interested in actually registering any extension but more like they were perfecting their tools. It was really interesting to observe.
The day I noticed the traffic I ‘upgraded’ my honeypots to send more data. Ever since that attack ended, there have been very few similar attacks.
Test your SBC
To help with awareness around this issue, I have started running a free service where you can test your SIP server against relaying SIP OPTIONS, INVITE and REGISTER requests. To test, head over to kwanlabs.com and select the ‘SIP open relay test’ tab. You will need to provide the public IP address of the SIP server to test and the UDP port it is accepting traffic on. TCP is not supported as of now.
I hope you find the service useful.
