• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

I've been stupid !! - system hacked

Status
Not open for further replies.

TRINITYDIGITAL

Joined
Jun 25, 2010
Messages
1
Reaction score
0
Well I have been stupid - I have to admit it :oops:

I have been running the 3cx phone system for a while now on my 2008 small business server. I have only been running it in a test capacity and have been using it with one extension (a grandstream handytone) and connected to the voiptalk service.

I got an email today from them to say I was low in credit - odd I thought - I have hardly been using it and mostly for incoming calls anyway.

Looking at voiptalk's activity log the credit was all used on calls to Egypt - hmmmmm I thought - who do I know in Egypt??? - no one :lol:

I thought at first mt voiptalk acc has been hacked and someone has registered a voip phone directly to the service, but no.

Then I checked if my windows server had been hacked in general terms - all checks seemed okay.

Turns out that someone has registered a voip phone DIRECTLY TO my 3cx server as extension 100 and was bouncing calls off the server!!!

So I checked my firewall (A netgear prosafe) : I have only the udp 5060 and udp 9000-9007 open for incoming - no 3cx tunnel or anything like that.

On reading the documentation again and talking to a networking expert it seems that the 3cx will accept any voip phone connection to it - even if it is from the internet - so long as the id and pw match.

Someone was obviously port scanning me, saw that I have a voip service running and, yes you guessed it, tried the defaults of 100 and 100 for un and pw!!!

ARRRGGHHHHHHHH! :x

I hadn't realised that the 3cx would do this - I thought that these ports would only be for in/out calls and not extension connections.

I have updated all of my passwords and added a bit more credit :lol:

Oh well, just thought I would share my experiences - you never know - someone else might have made the same mistake.

Luckily this is a test setup before I consider buying it properly so I didn't have much credit on voiptalk anyway - about 15 quid - but it has taught me something valuable about security and about sip security and 3cx extension connection security.

Gareth
 
Gareth, I'm sorry to hear that happened to you.

You may also want to consider some outbound rules to restrict international calling to certain destinations - or certain extensions.
 
First thing they will do once they see an open 5060 port... Try the generic 10x extensions with the generic passwords... They may get lucky.

I see failed attempts in the log all the time. I really suggest you keep an eye on the log at least once every day just to see the activity on your server.

Cheers,

W.
 
well its simple really either remove your entire PBX off the outside network or secure it with hard to beat passwords. But hopefully users will learn from this post.
 
To help prevent this. Set your firewall to only accept traffic to port 5060 from your voip providers ip address unless you have mobile users who need remote registraions in this case use good SIP authentication policies. I typically use the MAC address as the SIP ID and then use keepass to generate a strong 10+ char random string for the password.
 
best way is just to restict the firewall from and to 5060 can be send and received.
Then you are save. for on the go use VPN or Tunnel. Most people out there will not go there and try this.
Ah yes, plz dont leave the tunnel PW on defaul, pretty easy to guess as well..
 
I do like Stephan says and only permit inbound 5060 from the networks of my providers.
Also, on every router I configure I block the private subnets from entering in via the WAN. Some routers permit IP spoofing packets in thinking that they belong on the inside network.
So I block 192.168.0.0 255.255.0.0 172.16.0.0 255.240.0.0 and 10.0.0.0 255.0.0.0 from entering in on the WAN.
Those using Cisco CME or UC5XX systems these ACL's are a must!
 
Stefan, while the tunnel is a great idea - it just doesn't work well for remote soft phones. I don't want to use 3cxPhone. I like it overall - but it is missing features that EyeBeam and Bria have. One of the biggest for me is G.729. I refuse to use G.711u - it just hogs too much bandwidth.

If you guys released a paid-version of the softphone - maybe one that is only available to licensed users of 3cx - or convinced some softphone mfr like CounterPath to include support for your tunnel - using the tunnel for remote extensions might suffice.
 
StefanW said:
best way is just to restict the firewall from and to 5060 can be send and received.
Then you are save. for on the go use VPN or Tunnel. Most people out there will not go there and try this.
Ah yes, plz dont leave the tunnel PW on defaul, pretty easy to guess as well..

What happens if you have "mobile" remote phones but no VPN?
 
Basically at that point you have to leave the SIP ports wide open and use long, secure, unique passwords and maybe TLS to secure them

OR

Use the 3cx tunnel. I have no idea if this will work, but if you are talking soft phones (and not the 3cx soft phone specifically), you could potentially install the tunnel software on each machine and test out using the localhost as the registration target in the soft phone. NO idea if this will work - I've been meaning to try it, though.
 
No softphones, I meant using "hard" phones like Cisco 500 series or Yealink's.
 
The first thing a hacker would do is try out the default passwords for any system.
By leaving them on default, you're just leaving the door open for him to enter and do as he pleases.

- Now if the hacker brute forced his way into your PBX, that's another story, you would see a lot of Authentication requests in the PBX logs. You could prevent this from happening by setting up your firewall correctly, which can be very tricky for SIP.
 
We also see allready attacks to our 3cx hosted servers. it is very important to use strong passwords and also more complex user ids for extensions. a complex password for tunnel and secure admin credentials. for a remote pbx it is also important to only allow https for management console an myphone portal. and if you want to use http api it is even more important to use https and open only necessary ports on fw.
 
matictec said:
We also see allready attacks to our 3cx hosted servers. it is very important to use strong passwords and also more complex user ids for extensions. a complex password for tunnel and secure admin credentials. for a remote pbx it is also important to only allow https for management console an myphone portal. and if you want to use http api it is even more important to use https and open only necessary ports on fw.

We are in the middle of implementing a feature to block such attacks.
We will most probably make a blog post for it showing the user how to configure his PBX for maximum security.
 
regomotiv said:
No softphones, I meant using "hard" phones like Cisco 500 series or Yealink's.

Well if they are truly mobile hard phones - you're probably out of luck. If they're just remote hard phones, you can still use the 3cx tunnel software installed on a computer at that office.
 
And, presumably, if you want to allow direct calls to SIP addresses, then you also have to accept all traffic in port 5060 as well, don't you?

On a related topic, I was trying to set up some forwarding rules to handle calls to my entry phone, and it seems that a 'forward all' 'external calls only' doesn't consider direct SIP calls as external.

I have an entry phone that's linked to the PBX, and when you call into it, it answers and then you can key in the door release code to release the lock. Normally, of course, it's the other way round, with the door calling to a ring group, and you only need to dial into the door phone to programme it.

I wanted to set a rule to forward all external calls to a digital receptionist, but it didn't work for the direct SIP calls (using 3CX 8 ). I can change the rules for the few times I do need to tweak the programming, of course, but sometimes you do get someone knocking on the door, and it's handy to be able to dial the entry phone and speak to them, even if they haven't figured out that pushing the button with my name on it is what they're supposed to do.

I've put this in the security thread, because it occurred to me that it's another potential thing to watch out for, if you have such an entry phone connected, and allow direct SIP. Someone (visitor, former employee) who knows the extension you've used for the entry phone, and the code to release the lock, just has to make a direct SIP call, wait for the entry phone to answer, key in the DTMF code, and open sesame. It's admittedly a fairly small risk for most people, but still something to be aware of.
 
I almost suffered a hack yesterday; I noticed the line indicators on my desk phone had gone out, and checked the 3CX system, to find shockingly slow response, Windows fiddling about with the virtual memory settings, and exception messages in the log.

Rebooting, I still couldn't get the system to behave - but I did eventually, by shutting down non-essential services, manage to get to the stage where I could check the logs again.

And there, I found loads of failed registration attempts, and call attempts, typically using extension numbers 349 and 123. These seemed to be coming in at the rate of several a second, and on the very low-spec machine I use, were more than enough to make the performance bad enough to be useless.

They didn't succeed; I don't have the default passwords for any extensions, and I'm not actually using three digit numbers, either. But the performance hit was still enough to render 3CX unusable, effectively becoming a denial of service attack against the phone system.

Obviously, there are some solutions, one of which is don't use such a cheap-ass low-spec PC. And the other is the alter the firewall, allowing connections to port 5060 only from the IP phone services that I use, which is what I've done now.

But that, of course, means that registering my numbers via an ENUM service, or giving people direct SIP addresses, is now pointless, as calls via those mechanisms won't get in.

Also, worth noting is that with logging level set to low, which is fine in normal use, the only address shown in the logs for these attempts were my own IP and 1.1.1.1, which I suspect is not the real address. Perhaps on failed invites and registrations, the source IP could be shown in the logs, even for the lowest level, to aid in diagnosing security issues such as this?
 
We have implemented a new anti-hacking feature for the Final release of V9 just for this purpose.

- After an XXX amount of failed registrations on your system, the IP attempting to register on your PBX will be blacklisted for an XXX amount of time. These XXX parameters are configurable.

- If the rate of incoming Invites / Subscribes / packets passes an XXX amount, this number will be blacklisted for an XXX amount of time.

After the next release, be sure you try V9 out again.


Also just for your security, be sure to have non default SIP ID's configured for your extensions. Leave nothing on default.
 
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Forum statistics

Threads
141,621
Messages
748,857
Members
144,735
Latest member
Hammad.k
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.