FusionPBX toll fraud - MISTAKES WERE MADE...

[MammerJammer]

Hello again, and thanks for all the responses to some previous queries. We continue to learn by doing, breaking, fixing, and breaking again.

So, apparently I have a great server out there if anyone needs to make some free calls to the Dominican Republic. Ok, actually it's fixed now, but I have no idea how the hack itself took place and I'd love to get some insight from the more experienced users. This is a test server and admittedly, we weren't watching it TOO closely. We weren't concerned about toll fraud because our endpoint termination with the SIP carrier didn't have international. However, after talking with the carrier (we can discuss specifics in PM, I'm not trying to smear anyone for a mistake) we found out that the DR was accidentally left in their Domestic Rate Deck. That explains how the calls were allowed, but not how our server was compromised in the first place.

I see the calls in our CDR coming from an extension registered to one of the endpoints we were doing some provisioning tests with, in this case a Polycom VVX400. This is a device in the lab on the local LAN, behind a NAT router, on a 192.X.X.X network. The calls were not physically originated from that phone, so they must have been able to compromise that extension through some other means.

To anyone willing to have a look and help shed some light, what can I provide to allow us to determine exactly what occurred?

 

[brb5548]

I would love to find root cause and learn from your mistakes. Just curious what kind of passwords did you have on the extension that was compromised? Simple? You might want to back up your logs to review in detail later.

On a side note; I old but decent talk on some security considerations to think about:

 

[DigitalDaz]

Out of the box an up to date version of FusionPBX should be quite secure. Most compromises come down to user error. Finding the root cause would be very difficult after the fact without a complete changelog of what you did after install.

What I can say is that with probably, over 20 FusionPBX servers, I have never suffered a hack in over six years.

 

[brb5548]

I would agree. This is what piqued my interest.

 

[bcmike]

Ok a few simple things to check for. First yes most of the Caribbean falls in the North American dial plan so anything not filtered with 011x is going to make it through. Some of those rate centers can be expensive. It's worth your time to put together a Caribbean route and deal with it accordingly.

Regarding you end point, check to see if it was call forwarded. Its the simplest way to commit toll fraud. baring that look at your log registrations, if your Polycoms extension was hacked you should see the registration flopping around between it and another Ip somewhere, that might give you a clue.

If your test server is behind a firewall there has to be an attack vector thats been overlooked. Lock it way down and work your way out from there.

 

[MammerJammer]

Most compromises come down to user error.

Absolutely zero argument here. I'm certain, as the title implies, the mistakes were of our own creation. We don't have a lot of experience with Fusion yet, so even the tools to catch these issues are unfamiliar. My hope here was that someone could give us a push in the right direction to sniff out exactly how it occurred.

What seems most plausible to me is that someone here created an extension with a soft password and someone was just brute forcing common extensions and got lucky. What I don't know is how to prove or disprove that theory. There is a Polycom VVX400 registered to the extension used to make the calls. That endpoint is still registered. I don't see how they could have compromised the Polycom directly, and I don't see why Fusion would allow another device to register to that extension when the VVX400 was already registered. Any advice on where to look?

 

[KonradSC]

About 3 or 4 years ago I sent some demo Polycoms to a college and the next day we got hacked with someone using the phone's SIP credentials. The lesson that day was to never use http for provisioning.

 

[tag915]

Its hard to say the main issue without more details but Fusion will allow multiple devices to register on the same extension. Is your pbx behind a firewall? Are you allowing all IP traffic or whitelisting? Have you looked at firewall logs during the time of the hacks? Was that account's password weak? Do you see multiple registrations or endpoints making the calls? Is the Polycom using default credentials? We have see actual endpoints hacked by a compromised computer on the network.

 

[markjcrane]

You mentioned polycom and its very likely as others mentioned that provisioning used http instead of https. Polycom's newer firmware will work with lets encrypt. Next thing make sure for default settings -> provision category that you used the cidr setting or http_authentication settings. If you didn't do one of those then you left the door open for someone to brute force your mac addresses so they could pickup the provisioning information through provisioning. So suggestions always use HTTPS for provisioning and use a good password with http authentication so the phone has to use a password to pickup the configuration. Others stated you limit access to only customer IP addresses for SIP. Make sure fail2ban rules are updated. Phone firmware is updated and the phone has a password in case the customer exposed the phone web interface to the internet. Make sure packages on the server are up to date. There are others things you can do as well but this list is a good start.