Some hacker in Palestine has the password for extension 122. At least two things are likely wrong. First, why are you allowing an unknown IP to access the system? But more importantly, how did he get the password? My suspicion is that your provisioning system is wide open and he guessed the MAC address for the device on ext. 122.
To which password are you referring? His extension password was produced by the system and is complex, as is the User password in the extension settings (both 32 characters). He is also the second person there to have his extension used for unauthorized calls. The customer uses Flowroute and only their IPs are entered in the Match field in the trunk configuration. What else can I do to secure this system?
This also happened to three other customers, so obviously I’m not closing all the holes, but as I mentioned in my original post, I did configure everything that I saw detailed in other posts like mine.
I’m not sure what you mean by the provisioning system being wide open; both the root account and the GUI admin account are equipped with 12-character complex passwords. I’m too much of a neophyte to tell right away what you identified, but considering that this particular system is not behind a firewall and has no edge device, and the same thing happened to boxes that were behind firewalls, I’m at a loss about how to stop this.
I will say that when I changed the Asterisk Trunk Dial Options by removing the T, and removing the Tt is the dialing options in Advanced Settings, the calls stopped. Could this be a case where the caller just called the business, entered the transfer codes through some sort of automatic dialing process, and made all those calls?
Make/model of the phone(s) used on this extension? How provisioned (TFTP, HTTP, HTTPS, etc.)? Provisioning data created how (manually, OSS EPM, commercial EPM)? What, if anything, prevents an intruder from accessing this data (which of course contains the extension number and password)?
Yes. In my opinion these are dangerous and obsolete options that are only needed if you use analog devices and only in few situations. These options should be disabled by default!
Possibly, you have had other fraudulent calls that used the transfer codes, but in this call, the attacker registered his software as if it were a normal device and made a normal outbound call.
I thought the “Disallow transfer features for inbound callers” = yes in Advanced Settings removes the ability for the *2 and ## in-call transfers from happening, for callers that enter from an inbound route?
There was a bug fixed. Maybe there’s another one. My point remains that if you don’t need this feature it should not be enabled. Most any modern SIP phone can do SIP transfers and this inband stuff is not needed.
Sangoma S505 is the make and model of the phone. Provisioning is done through HTTP and the provisioning was created through the Pro version of EPM, which is up-to-date.The device isn;t behind a firewall and has both WAN and LAN connections. Others, however, that have been exploited the same way, are behind firewalls that have specific port and IP rules in place.
Reviewing the post with the sngrep and the question “how do I stop it?” the answer is, you did. Look closely at that sngrep at the calls that didn’t go through, there is one packet. The initial attempt where the firewall went “Nope not allowed” and then after that all the other ones were dropped/rejected.
None of us can stop others from sending us requests. We cannot stop them from trying to flood requests. We can only handle those requests once they hit our network. So the best you can do is stop them at the door but you can’t stop them from walking up to the door.
Does the provisioning URL include a strong password that the attacker wouldn’t know? Otherwise, he can simply iterate through all Sangoma MAC addresses until he hits one that’s yours. Of course, you should also have firewall rules so the attacker can’t access the provisioning URL in the first place.
Check that the authentication is actually working. Try to access the URL from a browser without the username/password and confirm that the expected error occurs. Try again with the correct username/password to confirm that your test was valid.
Possibly, TFTP or unauthenticated FTP is also enabled. Try to pull files by TFTP and FTP to confirm that those servers aren’t running.
If this system has been around for a while, was it previously provisioned by insecure means? If so, the attacker could have stolen the extension credentials and waited patiently before using them.
Does the end user have another device (softphone, SIP app, etc.) on the same extension? If so, he knows the password and could have been careless about protecting it e.g.using it on open Wi-Fi.
Back the truck up for a sec, gabosch. I am going to repeat a CRITICAL bit of information everyone has apparently missed:
“I have four different customers using a mix of PBXact and Freepbx free distro that have been used to make calls to (for some reason) South Dakota (area code 605) and Iowa (area code 641)”
You are probably going to dislike me for saying this (I don’t care since most people do including the moderators of this board ha ha) but YOU are ASSuming that the “commonality” here is the FreePBX system. But you are missing another obvious commonality - YOUR system.
You have 4 customers, none related to each other. All are cracked with very complex unguessable passwords stolen. The cracker is making all calls to the same destination area codes. Therefore the most logical answer is that your own machine - PC, laptop, whatever - has a keystroke logger on it and has been p0wned.
You provision a phone with a complex password - the cracker steals it as you are provisioning it. That’s why they are just logging in normally with a normal extension. A fundamental rule of cracking is go through the easiest hole first. The easiest hole is since they have the phone passwords, and the FreePBX system is exposed to the Internet - walk through it’s front door. Trying anything esoteric like going in through the voicemail, etc. besides being a lot more work, greatly increases the risk of breaking something and getting noticed a lot earlier.
I have been running a FreePBX system that’s been open to the Internet for years. However because I’m a cheapskate all my phones are provisioned BY HAND. As a result I am intimately familiar with their icky configuration files and tftp servers and such. All my phones have complex passwords also. But none have been guessed even though I get hundreds of crack attempts every day. I don’t think that it’s really possible to brute-force guess a reasonably long phone password, even an 8 character password has 3 x 10 ^ 15th possible combinations:
(https://math.stackexchange.com/questions/739874/how-many-possible-combinations-in-8-character-password)
At least none of the bevy of attackers of my system has ever guessed any.
Therefore if brute-force is out then they just need to break into whatever system has the phone passwords. In my case it’s my Unix systems that have the tftp servers (which by the way happen to be different than the FreePBX system), and different than the DHCP server (come on guys, I’m not that obvious) and are locked down 6 ways to Sunday. I am ASSUMING that the “Pro version of EPM” you are using doesn’t have any stupid defaults set like allowing any tom-dick-and-harry on the Internet to pull a phone’s config file off the TFTP server, and that you have a firewall that blocks ssh and so on that the freepbx system is behind.
So like the saying goes, when the impossible is eliminated, that which remains, however improbable, must be the truth. The one other place the phone passwords are, is on your system - even though transient - when you type them into the provisioner and click Submit. If you web browser has a malevolent add-in that has inserted itself, it would be easy-peasy to harvest phone passwords I should think.
Another thing I just noticed is that your admin GUI and UCP are open to the world! Though I’m not aware of a current vulnerability, there have been several in the past that allowed an unauthenticated attacker to gain access. Also, if you shared the password among several sites, if the attacker somehow got access to one, he would have access to all. Or, if you used the same password on a website that got compromised, you are likewise in trouble.
The simple answer to the question that the OP asked is this:
Never, ever, expose your systems to the public internet. The PBX should always be behind a NAT firewall with IPTables configured to restrict inbound access to only allow necessary services from necessary IP addresses. This generally means that each phone comes from an IP address on the LAN and allowed access only to UDP Port 5060 and possible to the port for SFTP if you’re using that to configure your phones.
