Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

3CX compromised and toll fraud

Discussion in '3CX Phone System - General' started by IT247, Dec 7, 2018 at 5:53 PM.

  1. IT247

    Joined:
    Friday
    Messages:
    4
    Likes Received:
    0
    We have some 3cx instances hosted with a 3rd party. Three times in the past six weeks are so, we have had extensions compromised and fraudulent toll calls were able to be placed until the sip provider noticed this and shut it down. (happened after hours and they caught it in about 4 hours). High tolls were charged.

    I'm trying to determine how this is happening and harden the system.

    Originally we were using default 3 digit extension numbers as auth id with 5 character random alpha numeric characters for pw. Also the default 3cx security of lockout for 30 minutes after 25 failed attempts was in place.

    After the first compromise, this was changed to use 16 alpha numeric mixed case strings (for Auth ID and Password) and lockout was configured to lockout for a year after 5 failed attempts. The other passwords for Yealink web ui and others were changed also.

    Since that last change at least one of the same extensions that was compromised previously was compromised again. Very doubtful if not impossible to brute force random 16 character STRONG user id and separate 16 character STRONG pw in five attempts.

    The 3rd party host is pointing to security issues w/ 3cx. Specifically they are suggesting the provisioning url is public facing and this is being brute forced. I reviewed the provisioning url they provided and it contains two separate random strings in the url, so I think brute force is highly unlikely. However, if the url is truncated to include just the first random string and then the macaddressofphone.cfg is appended to it, the full config is visible. Grant it a bad guy would need to figure out the first random string and also know the mac address of a phone on that system which doesn't seem likely unless this information was leaked somewhere.

    Even with the random strings in the provisioning url, should this be public facing at all? I asked about locking it down to an ip address, but was told that would break connections for the mobile and desktop apps.

    If it was leaked and now that information is secure, how would one change the provisioning url so bad actors in possession of it can't use that compromised link anymore?

    Any help or thoughts are appreciated.
     
  2. Marari

    Marari New Member

    Joined:
    Sep 16, 2007
    Messages:
    207
    Likes Received:
    47
    @IT247

    As for locking it down to an IP address, the mobile softphone client uses port 5090 (by default) as a tunnel port to the PBX. If you leave 5090 open, you should be fine and lock down port 5060/5061 to just your voip provider(s) IP address(es).

    Is your PBX cloud hosted with a provider? Do you have access to the admin management console? Who else has access to the management console?

    Are you using 3CX SMTP or your own SMTP for the welcome email?

    When you re-register an extension, a welcome email is usually sent out that contains the connection specific info. Is it possible that someone's mail credentials have been compromised?

    There are a lot of possible ways for someone to 'backdoor' in to a system - all of them start at the user and admin levels.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #2 Marari, Dec 7, 2018 at 6:03 PM
    Last edited: Dec 7, 2018 at 6:09 PM
  3. DSXDATA

    DSXDATA New Member

    Joined:
    Oct 20, 2015
    Messages:
    185
    Likes Received:
    64
    A common compromise happens because a user's email is hacked and then data-mined for the welcome message which has the extension credentials in the clear. The credentials are sold on dark web so there is a usually a several day/week time spam between email hack and the intrusion.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    3cxnub likes this.
  4. IT247

    Joined:
    Friday
    Messages:
    4
    Likes Received:
    0
    Thanks for your reply,

    The PBX is cloud hosted with a provider. I have access to the admin management console and it has a strong password. Besides me, it would be the provider with access. During all incidents only a subset of the extensions were showing evidence of compromise not the entire install base so I'm guessing this didn't come from management console login compromise.

    As I understand it, the extensions register over 5060 to the cloud 3cx instance. If we were to lock it down to just the voip provider (sip service?), how would these extensions register with 3cx.

    SMTP was with cloud provider, but that was changed to use our SMTP with authentication and strong password and only from their network. After the previous incidents, welcome emails were sent to many other extensions and those aren't showing compromise.

    One of the extensions in question has 2FA for email and there has been no evidence the mailbox was compromised, so I don't think welcome email in recipient's mailbox is source.
     
    #4 IT247, Dec 7, 2018 at 6:16 PM
    Last edited: Dec 7, 2018 at 6:25 PM
  5. Marari

    Marari New Member

    Joined:
    Sep 16, 2007
    Messages:
    207
    Likes Received:
    47
    You use a Session Border Controller which communicates with the cloud-based PBX over the tunnel port (5090 by default). The nice thing about the SBC is that you don't have to poke any holes in the firewall/router of the phone network - the request is outbound and NAT points it back to the SBC.

    As for the other issues, you have a hole somewhere. I suspect one of the following possible scenarios:

    - A user was phished and gave up their credentials for their email account.
    - A user inadvertently allowed a trojan or keylogger to be installed on their system.
    - The welcome mail was forwarded or sent over unencrypted channels (not using SSL/TLS for email)
    - There is a malicious user or purposeful tampering by someone with access.

    There could be other ways too. I'm simply suggesting that, in all of my experience where a breach has occurred, a user has been at fault.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. florink

    Joined:
    Feb 8, 2018
    Messages:
    30
    Likes Received:
    10
    It is almost impossible for anyone to just brute-force multiple provisioning URLs (even one). From what you are describing it seems like the attacker has already what they need to access those extensions. If they got the provisioning URLs, it wasn't through the PBX.

    Also logs is your best friend. Don't just play the guessing game. The logs will either give you a definite answer as to what happened, or guide you to a certain direction. You might also enable extra logging to see what requests are made to the server.

    You might also consider changing the host of those instances as you cannot trust or know who has access to the machine..
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. IT247

    Joined:
    Friday
    Messages:
    4
    Likes Received:
    0
    I had verbose logging enabled prior to this last incident. I see the ip (from Palestine) that registered and began making the fraudulent calls. I see a bunch of others that got blacklisted after 5 attempts. The previous compromises were from the same region, so I'm thinking this is the same group. I'm not sure what else I should be checking in the logs.

    From the previous breach, I do believe the attacker does have access information for the extensions in question (provisioning url and mac address). With the provisioning url and mac address of a device, I believe they were able to again pull down a config and obtain the new hardened plain text passwords present within.

    From what I understand, there is no way to change the provisioning url to some other random string other than reinstalling to a new instance and setting everything up from scratch. I"m told a backup and restore to new server would retain the compromised provisioning url. Can anyone confirm this?

    I would look into deploying an sbc on premise, but the current host is telling me you can't lock down 5060 inside of 3cx to specific ips, and there hosting infrastructure doesn't have that capability currently.
     
  8. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,590
    Likes Received:
    239
    You don't need to lock down 5060 to specific IPs. You simply check the box 'Disallow use outside of LAN' for the extension. Tunnel connections are considered internal.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    3cxnub likes this.
  9. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,590
    Likes Received:
    239
    Another option is to move the instances away from the provider to something you have a little more control over. Since you are already in the cloud everything should be provisioned via FQDN so it shouldn't be too difficult. AWS (Not lightsail)/Azure/GCE would give you more granular firewall control if you did run into a scenario where you wanted to block IPs
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. IT247

    Joined:
    Friday
    Messages:
    4
    Likes Received:
    0
    Thanks for the replies,

    If I select disallow use outside of the lan, how would my extensions on premise and on a different lan subnet connect to the cloud 3cx instance on its own subnet?
     
  11. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,590
    Likes Received:
    239
    So the disallow outside of LAN is per extension. So you would set that for all your softphone/3CX Client extensions and those that are behind a SBC. If you can setup a routed VPN using RFC1918 IP ranges those will also connect with that enabled. Everything else will have to have that box unchecked. Might not work for all phones but will greatly reduce the number of endpoints that can be compromised. You can also look at disabling calls after hours for extensions.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...