Hacked Server?

Status
Not open for further replies.

gbrown100

Bronze Partner
Basic Certified
Joined
Feb 22, 2011
Messages
126
Reaction score
13
Hi,

We've had some erroneous calls made through our PBX at OVH, looking at the call log I see below:

03/17/2019 1:34:04 AMMain House (202)375294751122Not Answered
03/17/2019 1:06:59 AM37529475110337529475112200:56:02
03/17/2019 1:06:52 AMMain House (202)37529475112200:00:07

I don't understand how there can be a call that originates from something other than an extension on the second one down. At this time of the morning all calls forward to a voicemail that is on a different extension, is it possible they have used the voicemail to route back out somehow, rookie mistake, that voicemail extension was allowed to make external calls.

Further the call is to Belarus, we have only allowed UK calls on this PBX.

9858

Any suggestions as to how we can troubleshoot this? Should we be calling 3CX?

We're not using an SBC so they are authenticating through the cloud.

Thanks

Graham
 
Last edited:
Hi,

We've had some erroneous calls made through our PBX at OVH, looking at the call log I see below:

03/17/2019 1:34:04 AMMain House (202)375294751122Not Answered
03/17/2019 1:06:59 AM37529475110337529475112200:56:02
03/17/2019 1:06:52 AMMain House (202)37529475112200:00:07

I don't understand how there can be a call that originates from something other than an extension on the second one down. It would suggest the PBX has allowed a call from an non authenticated source? Further the call is to Belarus, we have only allowed UK calls on this PBX.

Any suggestions as to how we can troubleshoot this? Should we be calling 3CX?

We're not using an SBC so they are authenticating through the cloud.

Thanks

Graham
The first thing I would do is change all SIP Auth details to stop this reoccurring. Looking at the activity log may show more information.
 
Using the 3CX Activity Log will give you more information(and you can increase the detail) as to how the call actually routed within the PBX, not just what number was dialled. Callers that reach a voicemail cannot normally dial back out. You can if you check your own messages, which means you have the PIN. Guessing the PIN would require a number of attempts and should be noticed. If the "hacker" knew the PIN, then it is possible. It should probably be changed immediately, as a first step.
 
Thanks Rhys, first thing I did :)

@leejor yeah, not entirely sure how they got the pin but I'm guessing that's how it was done. Admin interface locked down to our IP and with complex PW's so not through that way. Would have thought the anti hack rules in 3CX would have made that quite tricky.

So, the main problem was caused by the engineer not following build specs, they included the voicemail ext in the group allowed to make outbound calls.

Will need to come up with better outbound call routes. The 12 digit number sailed through without being touched by the Country Code Blocking as E164 was denoting 00 as the international dial code so ignored it and our trunk provider clearly doesn't require the 00!
 
Ah spoke to soon:

9860

I have reset the UserID, Password, Phone PWD and PIN and yet they have registered again. The UserID is the new one.
 

Attachments

  • 1552858649512.png
    1552858649512.png
    39.7 KB · Views: 8
Ah spoke to soon:

View attachment 9860

I have reset the UserID, Password, Phone PWD and PIN and yet they have registered again. The UserID is the new one.
They seem to be registered locally, that suggested they have access to your server/management console. How do you register devices to your server normally STUN?

Are there any VPN connections to your OVH server?
 
They seem to be registered locally, that suggested they have access to your server/management console. How do you register devices to your server normally STUN?

Are there any VPN connections to your OVH server?

It's a public server with STUN. There's no LAN, No NAT, No VPN and the 192.168.1.x range is not present at my customers site either. This reveals their Public IP in Palestine:

03/17/2019 9:51:37 PM - Updating device Dev(1269449098):[sip:[email protected]:7155 / 202] by message: DevUpd Recv Req REGISTER from 82.205.7.135:7155 tid=-d87543-908475547-1--d87543- Call-ID=9b5bc415fe6c272b: REGISTER sip: <Redacted>

I have had to firewall back 5060 to SIP provider and primary connections for my client, their backup connection is currently dynamic IP so will simply not work but at least no-one is registering.
 
So does anyone have any idea how they have been able to immediately log back in with the new credentials once I have changed them? They definately don't have access to the management interface, quite apart from the lockdowns I have enabled login notifications for it.

Could they have somehow breached the firmware on the W60B they use?

Thanks

Graham
 
This reveals their Public IP in Palestine:


I would imagine you have blocked/blacklisted this public IP. The issue with this is that normally a hacker will change their public IP regularly.

A straight but not practical fix would be to change the public IP they are getting access in on and thus lose your location potentially ?
 
Last edited:
The server is not hacked... the W60B is hacked.
I assume the W60B is provisioned by 3CX? Yes? then this is probably caused by errors in the template.
The template do not setup the password of the user account (bug!!!!) and still has the standard password "user".
3CX knows about this issue and will solve this in v16, they say.
 
@eddv123 if they found the phones through port scanning, they can find them again

@gbrown100 consider setting up an SBC at the site for more security, with encryption enabled. Was your phone's web interface accessible over the internet before?
 
@eddv123 if they found the phones through port scanning, they can find them again

@gbrown100 consider setting up an SBC at the site for more security, with encryption enabled. Was your phone's web interface accessible over the internet before?

@eddv123 Yeah, blacklisted them but was sure they would return. Have now firewalled 5060 but will cause issues if they bounce to their backup connection with dynamic IP. Did think about reprovisioning from scratch as it is a small install, may still do it.

@JohnS_3CX Well, another IT person is involved as this is the business owner's home connection, it could well have been if he allowed it... Maybe we'll be able to take over management of the connection in future. I already instructed them to remove any forwards but I didn't check myself. It's certainly not active now. Re: SBC, as it is in my client's home I didn't want yet another box clogging up, different if it is a larger install. My biggest issue with SBC is the lack of visibility and reporting on it's status. That said, better than getting hacked.

@complex1 So are you saying that all W60B phones are provisioned with a user called "User" and a default password? I already had issues provisioning two extensions to one Base Unit and had to tweak manually so going back in and killing that user is fine. We normally VPN access to our clients so would not port forward a phone from the web!
 
All Yealink DECT bases have two accounts: user and admin
The 3CX template setup the admin password only, not the user password.
So the user password is the default password: “user / user”
You have to tweak the template and add a user password.
Only from now the base is 100% secured with passwords.
 
Hello guys,

I just want to inform you that W60 is not providing the login information when the user is logged in using the "user" account ("user/user").
1. The login credentials are greyed out and "user" can't modify them:
9885

2. The Provisioning settings are not available, so "user" can't get the provisioning URL and download the config file manually:
9886

3. Even if the "user" will export the config file, he will not see the passwords there:
9887

So, there is no chance that the hacker got the login credentials from the W60.
Please try to re-check the PBX configuration and find from where he can get login credentials.

At the same time, the provisiong of the "user's" password is a good idea and we will add it in the future versions of the 3CX Phone System.
 
Status
Not open for further replies.

Forum statistics

Threads
111,916
Messages
589,722
Members
164,786
Latest member
supuni_rathnayake