We recently decided to work with Sangoma Connect so that our employees could access the PBX on their smartphones.
Everything was fine and I had worked with this document in order to try to make it secure, but a couple of days ago someone was able to start making a bunch of toll calls from one of our extensions and it triggered the fraud alert at our SIP trunk provider. Luckily we had disabled International calling and the monetary damage was negligible.
I’m not sure where to begin trying to figure this out. I checked the secret on the extension and it was generated by the system and fairly long. All of the other details in that document are in place other than white-listing my clients as I don’t have a way to do that.
Where else should I look? What logs to read in order to figure out where the hackers came from or got in? We’re running the latest distro and it’s entirely patched up.
For now we’re running with toll calling disabled at the vendor.
The asterisk log should show the IP address used by the given extension so you can determine where they came from.
(Though I don’t use Sangoma Connect, so don’t know if all remote phones using it show up with the actual device IP in the SIP registration on the PBX itself). You can check this by checking the IP info shown in asterisk for a cell phone using Sangoma Connect. i.e. pjsip show endpoint XXXX
Ok, I can see in the asterisk “full” log the contact being added. But there isn’t anything else in there that looks different than any of my sangoma connect users, other than a few failures on a different extension from the same ip before it was successful.
But I’m not sure where that leads me. Does that mean that the hacker supplied the correct secret? If so, can I not use the auto-generated secrets?
The most common cause of this problem is insecure provisioning data e.g. if the attacker guesses the MAC address of the phone, he can pull the config (including secret), usually by TFTP or HTTP.
However, it’s also possible that you have a misconfiguration allowing him to make calls without knowing a secret, or he somehow gained access to the admin GUI or UCP.
I think I have it configured correctly in order to require authentication, just following the aforementioned document from the wiki. I don’t know how else to check that configuration.
I’m pretty sure that SIP is the only protocol allowed on the firewall from the internet (well, Letsencrypt put a rule in there I guess) and it is set up with responsive firewall.
Call trace alone is not useful. All you can see is that 3208 dialed outbound, not what IP was used to register. You need to look in the full log(s) to find successful registrations and what IPs they come from.
Usually, when a call is answered, you can see the IP addresses where RTP is negotiated with. It does not seem like this call was answered, or OP removed that portion.
But what configurations would allow a user to connect to an extension without the secret? Where do I start looking? I would assume the default is to require a password.
Use sngrep it will reduce your hundreds of lines of log to a three line synopsis, ultimately the hangup cause was 127 “Unspecified” so the call didn’t complete and there was no actual fraud just annoyance.
As ever just don’t use UDP/5060 and you won’t see that sh1t anymore
Only if you specify one at the server end, and not always then.
Generally phones will not challenge for authentication when they are the server and won’t volunteer it when they are the client. If configured for use with a phone, Asterisk will challenge, but only if it is acting as server. This means that, if you configure a password on the phone, but not in Asterisk, nothing will fail.
(For a typical ITSP trunk, the ITSP will challenge, when acting as server, but Asterisk won’t challenge when it is the server (incoming call), because most ITSPs won’t know what to do if challenged.)
Unless you go off the reservation, every SIP transaction will be initially be sent a 401 and be required to retry with an 'Authorization " header that is accepted, that second REGISTER would need to include the username, secret hash, realm etc. to be accepted. Only then would the session be able to progress
I looked at the http provisioning section of the firewall. It had Local and “Other” selected. Is that “Other” zone the issue perhaps? I’m not sure what it means in this context.
Also, if I change the udp port will that affect my sangoma connect clients?
Given you have changed the port number, I’d want to check the full log output with “pjsip set logger on” during a call attempt from the legitimate extension, to make sure it gets challenged for authentication.
Although this is technically correct, very rarely is the problem that a providers is trying to make illicit outbound calls through an established ‘trunk’ everyone else SHOULD be getting the good old 401 first.
There is a ton of information in the log and I don’t know how to grep into pastebin what you want to see. The “supplying good information” only covers getting the call-id out.
So I guess back to figuring out how they got the secret. As far as I know I am not exposing http provisioning to the internet. When I looked at that service on the firewall it had “local” and “other” selected. What does the “other” button represent? Is that possibly where I had a hole?
The only other rule that was for port 80 was the responsive firewall letsencrypt rule which I believe only opens the port when a certificate update is due to happen. Or is it always leaving the port open and I need to switch my http provisioning to a different port?