Unauthorized calls -- is there a definitive answer?


(Luke C) #21

Agreed


(Gabosch) #22

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.


(Tom Ray) #23

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.


#24

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.


(Gabosch) #25

Yes, the password that was supplied by the system was used. That password is 16 complex characters.


#26

OK, so just guessing here:

  1. 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.

  2. Possibly, TFTP or unauthenticated FTP is also enabled. Try to pull files by TFTP and FTP to confirm that those servers aren’t running.

  3. 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.

  4. 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.


(Ted Mittelstaedt) #27

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.


#28

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.


#29

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.


#30

and if you don’t use udp or 5060 you reduce your risk by many orders of magnitude more


(system) closed #31

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.