Got Hacked Toll Fraud 3

[Saiyan656]

Just want everyone to know we got hacked via a public IP to SBCE.
Seems like the user somehow registered to serval of my internal SIP phone's off SMGR and made 50k worth of toll fraud in 11 hours.
Luckily the provider saw this and shut down our SIP trunk. I have since turn down the public facing IP which I was planning on deploying for remote workers.
Just wanted to let everyone know, so they can protect themselves.

 

[janni78]

There's no information about how they managed to hack you so how would people protect themselves?

"Trying is the first step to failure..." - Homer

 

[kyle555]

Not using mutual TLS authentication for remote workers is a vector for attack. Without mutual TLS, then it's plain old client/server architecture where the server must prove it is trustworthy to the client - like Amazon.com offering you a cert that your browser trusts. Amazon doesn't care about your PC or require you to provide anything more than your username and password.

That's exactly what happens when not using mutual TLS for remote worker - anyone can packet capture a TLS handshake they attempt with your SBC, see the certificates the SBC offers, tell their PC to trust that, and then they can pass a username and password attempt through the SBC.

At the very least, you can specify user agent types. So, if they're only 96x1 Avaya One-X Deskphones registering, you can say "any user agent doesn't match iphone Avaya app/9600 phone etc, trash it!

 

[Saiyan656]

We had TLS enabled. Note sure what mutual TLS means. Reviewing now...

 

[kyle555]

Not just TLS. Mutual TLS.

Wireshark your one-x communicator registering. It'll look something like:
Client Hello!
Server Hello! (includes certificate issued to the SBC and the validation chain up to the thing that signed the SBC's certificate - either the Avaya default authority or SMGR)
Your One-X now decides if he can trust the SBC. If Windows has the authority cert in it's trusted root ca's, it'll agree and do a TLS handshake. certmgr.msc will show you the trusted authority certs - every OS ships with GoDaddy and various other publicly recognized authorities.

That's the same as when you go to

http://yourbank.com.

YourBank doesn't require your browser to offer a cert to it's webserver to bring up a webpage.

Mutual TLS would require a cert on each endpoint that tries to register. It could be the same cert. With that, the ability to send a SIP REGISTER would never happen as the SBC wouldn't handshake until the SIP client offered a cert it trusted.

 

[jimbojimbo]

I can only assume you did not have URI restrictions in the SBC, probably did not have it behind a firewall with restrictions on IP Ranges eligible to connect, and the passwords were easy to crack (such as being the same as the extension). Two years ago I was helping a customer with some SIP troubleshooting and they had to shut down the SBC external interface. I couldn't keep up with all the hack attempts. The last statistic I heard the average was only 15 minutes on the internet before you get hit with a hack attempt.

Mutual TLS would be preferred and can definitely help but requires detailed understanding of certificates for the soft clients and SCEP for the hardphones. Not a simple "plug-and-play" setup.

 

[Saiyan656]

Vendor confirmed with PKI certs and SRTP we had a good mutual TLS design and hack did not register a phone remotely. They gain access via SBC and somehow forced the phones to dial. The phones hacked were register to local IP, these phones are not built for remote (public IP) and have an internal IP/LAN configured.
I did see the IP came from a US state, so IP ranges would have not prevented this(internal users would be located in this state if we do a full roll out).

 

[kyle555]

That doesn't make sense. I mean, that you were actually doing mutual TLS, that a cert you issued was compromised and used to gain access strictly over an application layer protocol like SIP and used to hijack other phones.

I'd think it more likely that you're in a downtownish urban area near an apartment building and some dude found he could get on your guest wifi or something and decided to set up a shady free pbx on a laptop that registered extensions to your SM. Or somebody set up an asterisk on a raspberry pi and hid it on some POE port that had internet access and access to your SM.

I know it sounds paranoid, but if your SBC was compromised, they'd have had to register through it and it would never look like the calls came from IPs of local LAN phones. Did you track those local LAN IPs they referenced? Are they really just plain old Avaya telephones sitting on desks?

I'd think your internal toll fraud problem is more like the cleaning lady at night is playing switchboard operator at night transferring calls from your phones overseas.

 

[Saiyan656]

Not cleaning lady as I see the traffic in SBC via our public IP. Not saying the cert was compromised. I am saying they may have access a server on LAN and setup a softphone, so no cert needed.

ACK Message Out of Dialog 755199198018782 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog
ACK Message Out of Dialog 755199197753797 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog
ACK Message Out of Dialog 755199188467686 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog
ACK Message Out of Dialog 755199188362127 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog
ACK Message Out of Dialog 755199186456878 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog
ACK Message Out of Dialog 755199186361814 3:06 AM Protocol Discrepancy SBC001 General Method not allowed Out-Of-Dialog

Incident Type ACK Message Out of Dialog Category Protocol Discrepancy
Timestamp October 30, 2017 3:06:16 AM PST Device SBC001
Cause General Method not allowed Out-Of-Dialog

Message Data
Method Name ACK
Call ID 824ab8681b160261 From conf1@172.x.x.x
To +12647293469@172.x.x.x (SM IP) Source IP 66.234.x.x
Destination IP 172.x.x.x

 

[kyle555]

that error could just be miconfigured responses to SIP options pings. Your SBC might just send back a 503 unavailable to the carrier and the carrier doesn't care because you answered with a SIP response - even if it's bad.

Those logged errors indicate the SBC didn't let something through. It was helping. The method was an ACK - which is odd, because 'out of dialog' means there wasn't a session active that the ACK mentioned it was for. That could be a remote worker hanging up on an internal user, sending a BYE, SBC sends a 200 OK back and tears the session down, and the remote worker sends an ACK to say it acknowledges the 200 OK for the BYE. Because the SBC tore down the session at 200OK, it considers it out of dialog. Either way, that "incident" isn't indicative of any problem beyond less than perfectly clean signaling.

So yeah, I think we agree, they can't do anything thru the SBC beyond register a phone from the SBC. Compromising your network from the inside is a possibility but not relevant to the SBC ever being there.

 

[Saiyan656]

Then what explains source IP 66.234 (not a carrier IP and was traced to a home external customer modem) if its not external attack?

 

[kyle555]

A valid remote worker sending an ACK to a 200 OK it received to a BYE it sent for a call to anguilla in +1 264, a small country in the north american numbering plan. Is NPA 729 extra toll? Small countries with +1 NPA for their country and 7 digit numbers can assign NXX 900 like we do for 1-900 and it can be $25 a minute.

Do you have legit business there? If not, then a TLS handshake from an outsider was established to your SBC.

To get that far, either you have mutual TLS and the cert provided by the 66.234 endpoint obtained it maliciously or, more likely, you didn't ask him for a cert and he just started sending SIP REGISTERS until something worked.

 

[Saiyan656]

No we don't have any business in Anguilla and yes once our provider disabled international dialing they switch to Caribbean dialing which also has a high rate charge. Thanks Kyle for you assistance!! I will look into the certs... I believe since switching off of Avaya certs to PKI cert may be where the issue lies. This may have not been fully tested and we may have a fail in cert process.

 

[kyle555]

either way, public or Avaya, the client just needs to trust the server to handshake.

Look into the SBC security guide. you also have ddos settings. Like limit X registers per source per Y minutes and refuse anymore for a minute/hour/day.

Unless you're getting a specific certificate + private key signed by your internal authority, anyone can try to register. You can rate limit that down to make sure guessing extensions and passwords only works with a few combinations at a time instead of wide open guess till ya get it.

 

[Saiyan656]

UPDATE: Got Hacked again, but this time had international and dialing to Caribbean's deny in SMGR also found how they got in and got SIP username and passwords. They got in to our internal local private IP (won't explain in details how. Just want to let all know to change default passwords on URL access.