Another Open Relay Scan

In May this year, the number of SIP scanning started increasing again. Such an increase in scanning can be easily noticed when looking at the free, publicly available honeypot data that I provide. For example, data like the one in the picture below where you see IP addresses, usually from the same subnet, with a low count of requests made to the honeypots, is a strong indicator of automated scanning.

Fred Posner, the main developer behind APIBAN, the free service that helps block unwanted traffic from hitting your system, frequently gave updates on the most active IP address subnets.

It wasn’t until someone in the APIBAN support channel reported having their IP address listed in APIBAN did I decide to take a closer look at these scans. The only reason for an IP address to be listed in APIBAN is:

1. If it is actively scanning/attacking
2. If a server has been exploited and is being used to actively scan/attack other servers

My initial suspicion was that the server was acting as an open relay. I quickly responded back in the channel asking to be privately DM-ed the IP address in question so I could take a closer look. My suspicion was correct. I had the evidence in my honeypot data and I also confirmed it using the free “SIP Open Relay test” I am hosting at kwanlabs.com. The user was able to rectify the issue on their server and later worked with Fred to remove their IP address from APIBAN.

With the high volume of scans happening and the fact that an open relay exploit is really a low hanging exploit, I knew there had to be more ‘victims’ so I decided to do a quick query in the honeypot database. To understand what I was looking for, lets take a quick detour …

Detour …

“What is an Open Relay?” In simple terms, it is when you are able to send/proxy/relay traffic through someone else’s server to a final destination. To that final destination, however, the traffic does not look like it came from you but from the proxying/relaying server. Something like:

A previous post Open Relay Abuse has a section on open relays and ways to protect yourself against it.

The information necessary for SIP routing is in the SIP headers. The good news is that the headers are in plain text so it is easy for humans to read 😄. There is a header called Via which means exactly that, I arrived to your server via or by passing through this other server at this IP address. So the more hops you make through SIP servers, the more Via headers you will have stacked up in order. Replies then reverse the sequence and hop their way back.

As with every rule, there is an exception, the Back-to-back User Agent aka B2BUA. You could consider the B2BUA as a new starting point. Amongst other functions, it stores in memory how a packet came to it and re-writes the headers so that it looks like it is the originator of the packet. That means that if a packet that had 5 Via headers arrived at a B2BUA, it would memorize these headers, create one new header with its IP address and send the packet on its way. The side effect of this is that, it in a way, ‘hides’ your internal topology and that is one of the main features sales representatives LOVE to talk about. There are ways of detecting relayed traffic through a B2BUA but that mainly depends on how the B2BUA has been configured, knowing what was sent or preferably monitoring the destination. It can get a bit complicated.

… Back on track

I have to confess, ever since the Open Relay Abuse, I really wasn’t checking on a regular basis to see if such attacks were still happening. The attack back then was mainly an exploit on 2 server vendors. When I did do a check, I would notice just a couple, nothing really interesting.

I guess it was time to go back to the honeypot database and run another check. Let’s see what happened in the month of May (2023.05).

Quick check

A quick check would be to simply see how many IP addresses sent a request with multiple Via headers to the honeypots in the month of May 2023.

Result:

+-------------+
| open_relays |
+-------------+
|        2099 |
+-------------+

😱 😱 😱

The count from the previous exploit was about 1000. This is just the minimum number because remember, if a B2BUA is susceptible to this exploit, it would have just one Via header. I decided to look closer at the requests and look for patterns. Down the rabbit hole I went …

Looking for patterns

Looking at sample captures, I immediately saw a pattern. I was initially surprised, but then thinking from the standpoint of the attacker, it was a logical progression. Let me explain.

Below are sample headers to point out the pattern. Using these patterns I tried to see if I could detect to some high probability, where a B2BUA is involved. Remember I said depending on how the B2BUA is configured, there are ways of telling if a B2BUA is acting as an open relay? IP addresses have been masked to protect the innocent.

+----+----------+---------------------------+--------------------------------------------+--------------+-----------+
| Nr | Method   | Call-ID                   | User-Agent                                 | Contact_IP   | from_user |
+----+----------+---------------------------+--------------------------------------------+--------------+-----------+
| 1  | REGISTER | e5f4a82339253e4f7a80      | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.1.0.4     | 80        |
| 2  | REGISTER | e5f4a552976086e4f7a200    | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.0.0.4     | 200       |
| 3  | REGISTER | e5f4a533455359e4f7a00     | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 85.x.x.x     | 00        |
| 4  | REGISTER | e5f4a714970683e4f7a00     | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.2.0.4     | 00        |
| 5  | REGISTER | e5f4a185336905e4f7a533    | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.1.0.4     | 533       |
| 6  | REGISTER | SDhmklf01-79c6f0c358..us2 | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 93.y.y.y     | 533       |
| 7  | REGISTER | e5f4a60109170e4f7a692     | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 5.z.z.z      | 692       |
| 8  | REGISTER | e5f4a68489778e4f7a416     | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.0.0.4     | 416       |
| 9  | REGISTER | e5f4a310252320e4f7a176    | PayCall                                    | 10.0.0.4     | 176       |
| 10 | REGISTER | e5f4a756863974e4f7a775    | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.1.0.4     | 775       |
| 11 | REGISTER | e5f4a453878700e4f7a575    | PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085 | 10.3.0.4     | 575       | 
+----+----------+---------------------------+--------------------------------------------+--------------+-----------+

The obvious similarity to all the samples is that the SIP request method is REGISTER.

The next observation is the User-Agent. Almost all have PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085. This is what surprised me…
In the blog post I wrote ‘Massive SIP Attacks with VPN?’ a very similar User-Agent was used. It was PolycomSoundPointIP SPIP_550 UA 3.3.2.0413. Also the Call-ID header was similar, they all had the pattern ’e5f4a’ + [random number] + ’e4f7a’ + [from_user]. Where ‘from_user’ is the user part of the From header.

… But then I remembered what I speculated in my conclusion of that blog post

I suspect the hacker behind this traffic is just sharpening their tools/skills.

So then I was like, “Hmmm, nice upgrade.”

Next observation, looking at rows 5 and 6, we see that with a change in Call-ID, the User-Agent was the same. The fact that the from_user value is the same on these 2 different REGISTER requests with the same User-Agent hitting different honeypots, rules out the fact that this was a stray but legitimate Polycom device.

Also, the private IP address range of the Contact header IP address, ‘Contact_IP’ is always 10.0.0.4, 10.1.0.4, 10.2.0.4 or 10.3.0.4 unless it is re-written by the relay proxy.

Last observation, looking at row 9, a change in User-Agent but a maintained pattern in the Call-ID shows it is the same attacker.

Searching for more

Seeing the patterns and relationships in User-Agent, Caller-ID and the hints in the Contact header IP address, I decided to see if I could find some B2BUAs acting as relays. I started with the following idea:

What if I look for packets with one Via header, but have a different Call-ID pattern (indicating a B2BUA) but with the known User-Agent hitting different honeypots?

Someone would say, “Wait, what if it is a legitimate device trying to register?” My response, “Seriously, on different honeypots?”

Still looking at the month of May, I found 11 unique IP addresses. And the patterns were beautiful. It was difficult to draw any definite conclusion without some speculation so …. you guessed it, …. back to kwanlabs to run open relay checks 😉. That brings me to …

How many are still active?

Considering that a few more cases were resolved for some users and small telco owners both in the APIBAN support channel and elsewhere on the net, and also taking into account that test servers are spun up on the internet all the time, I decided to see how many of the original count of 2099 + (possibly) 11 in May, were still active 😬. To test, all that is needed is to send one harmless packet to one specific port at these IP addresses and observe what happens. This is not any form of DDoS or attack on the servers.

Out of the 2099 IP addresses, 1870 were still active. Out of the 11, one was still active, making a total of 1871 IP addresses! I can still hear the impatient asking, “What type of servers are these?”, and that brings me to …

Who are they?

I decided to do a public service and answer this question as well. It had absolutely nothing to do with me being curious 😉. Again another script to send one harmless packet to one specific port at these IP addresses and observe what happens. The data from the results is based on the User-Agent, Server or similar identity header returned from these servers. To present a high level picture of the results, I did not consider vendor/brand/application versions, just the vendor/brand/application. Also I will just show products up to a count of 2

SHOCKING!!! RIGHT?? OpenSER on this list?!! What is even more shocking is the fact that the servers are in a well defined IP subnet. Conclusion: Must be a telecom. The shock does not end there, the version they are running is version 1.3.2 from May 15 2008. I am sure it does the job but, seriously? The interesting thing is that they are aware of their problem so they are hiding from Shodan (Shodan is like the Google of exposed ports on the internet). Their IP addresses are not listed as having open ports. Not sure if they are using the same technique I wrote about in this blog post. Well I have news for them, “They know you are out there!”

HIDDEN in the table identifies the servers that do not send out their identity. 2nd, 5th and 7th on the list are no strangers. They are the same from the old post on Open Relay Abuse.

Kamailio being on the list is just crazy! By default it is not an open relay. It looks like the users in their wisdom think that it should act otherwise so they took the effort to delete that bit of code. Crazy!

OpenSIPs too by default is not an open relay, looks like these users think otherwise as well.

Great question - Revealing answer

“All these IP addresses must have been scanned to test if they were open relays before being exploited. Were the honeypots also scanned?”

Awesome question! Yes they were!! Guess what the User-Agent was? Correct, PolycomSoundPointIP-SPIP_450-UA/3.3.4.0085. In order for the attacker to test this, they have to play the victim. They send a packet through your server and wait at the other end for it. As with similar attacks, you need a command center. So as long as you have active workers out there actively collecting intel, the command centre must be in service for them to report back.

So yes, I know the IP address. It is in a range assigned to a telecom company in the United States. The server at the far end is up and has an open UDP port for SIP! Interestingly I have no evidence of that source IP ever attacking any of the honeypots. The perfect command center indeed.

Thoughts

So there you have it, an interesting month of May. Understanding SIP is needed to test out an open relay. Our attacker seems skilled not only in SIP but automation as well and is testing out ways of staying anonymous. First by the use of VPN and now by finding and making use of open relays. This is no script kiddy. They have the skill and curiosity to cause some potential damage if they choose to.

You can check for free if your server is an open relay at kwanlabs. There is no real reason for your server to be on open relay on the public internet. If you are unsure of how to go about preventing this, use these points as a guide:

1. The URI in the request. Do you own the domain? Should you be handling such a domain?
2. 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?
3. The Contact header. It indicates where final responses will be sent. Do you know the URI?
4. The source IP address of the request. Should it match any of the previously mentioned SIP headers? Is it ??

Also an always smart solution to have running in the background is APIBAN. It should help block these kinds of scans.

On a side note, whilst going through the data I saw some really interesting patterns which I hope to write about again. Till then, I will continue to keep an eye on this.

Thanks to those who have sponsored the running of the honeypots. If you would like to join them just click this link.