2FA 2 Factor Auth on Login

[hulk123]

Hi, the year 2021 is coming to an end and I'm sorry to report that the 3cx v18 still has no 2fa auth to offer! Please do not come to me with:

-Microsoft or Google have a solution if you connect it!

There must be a 2FA solution that runs with any APP.

Bruteforcing and data spying and you are already in the 3CX admin interface.

Tell me when you have it on your roadmap.

 

[Evolute IT]

Hi, the year 2021 is coming to an end and I'm sorry to report that the 3cx v18 still has no 2fa auth to offer! Please do not come to me with:

-Microsoft or Google have a solution if you connect it!

There must be a 2FA solution that runs with any APP.

Bruteforcing and data spying and you are already in the 3CX admin interface.

Tell me when you have it on your roadmap.

Indeed, if you use G Suite or Microsoft 365, like many many many businesses, 2FA is included.

Otherwise, just use strong passwords. 3CX said it many times they will not implement there own, at least for now.

 

[hulk123]

Just use strong passwords: It is not secure at all. Password can also leak!

 

[Evolute IT]

Just use strong passwords: It is not secure at all. Password can also leak!

I know, but if your users are properly trained and use a password manager and change their password every 45-90 days, the risk is extremely low.

Someone has to know the PBX FQDN to start brute-forcing it.

@BrenttG can properly explain it better than me.

 

[hulk123]

Someone has to know the PBX FQDN to start brute-forcing it: Easy going! Just use a 3cx header + Shodan

I know, but if your users are properly trained and use a password manager and change their password every 45-90 days, the risk is extremely low --> It's just not practical without 2FA. I don't know where the problem is to add a simple 2FA authentication. You can talk everything up here but a 2FA is missing and therefore 3cx is not up-to-date in my opinion!

 

[hulk123]

Here by the way what i mean with Header :
https://www.shodan.io/search?query=Content-Length:+905+port:"5001"

 

[Evolute IT]

@StefanW

 

[SweetAction]

A good middle option would be to block native login for all users except <insert a break glass account>. That way we can assure clients that all logins happen with 2FA.

 

[johnpi]

Another good middle ground option would be to offer RADIUS as a another method to authenticate. It would be very beneficial for many of us using 3rd party identity providers to not only secure O365 but a host of other services like client-server VPNs, secure portal services, AWS services, monitoring and management services, and pretty much any service that can either integrate with our IDP or has the ability to use the standard RADIUS protocol. What this would do for 3CX customers is allow their userbase to point to say an Okta RADIUS or similar MFA servers to validate the user authentication piece and in turn enhances the entire security of logging into the PBX without 3CX needing to figure out and integrate each and every MFA provider. It's then vendor agnostic. It's great that 3CX offers integration with G-Suite and O365 which can provide 2FA in themselves, but for us that secure our userbase via other IDPs, RADIUS could provide this bridge. One point of issue with this is mapping extensions to users. This would have to happen either by the RADIUS server returning an attribute value back to 3CX server, which of course would be the user's extension, or user extension mappings via an initial sync or import of the user accounts.

 

[BrenttG]

Someone has to know the PBX FQDN to start brute-forcing it: Easy going! Just use a 3cx header + Shodan

I know, but if your users are properly trained and use a password manager and change their password every 45-90 days, the risk is extremely low --> It's just not practical without 2FA. I don't know where the problem is to add a simple 2FA authentication. You can talk everything up here but a 2FA is missing and therefore 3cx is not up-to-date in my opinion!

the FQDN is not needed to brute force a server, just its IP Address is sufficient, This whole arguement is moot however, there exists several strong security plans already doable that tons of people are in fact already using, not to mention 3CX blocks brute force attempts so quickly that they have less than 1% chance of success.

1. Console Restrictions - This literally blocks login to the admin panel to IPs that are not in the Console Restrictions Allow List. This is what everyone who is paranoid about security should be using. Why do they not? 2 Reasons usually based on my talks with lots of 3CX Resellers.

A. They need to be able to access the 3CX Servers in an emergency from WiFi, Mobile Hotspots, etc.
B. They did not realize this feature existed in 3CX, because they do not fully read about the new features all the time.

Fixing B is as simple as explaining it to them, and they realize it helps security problems a ton.

Fixing A is actually as simple as cake now too. Because wait for it. PBXMonitor has this neat little feature now, that allows you to control the Console Restrictions setting on all your 3CX Servers remotely, From a secure mobile app, The app cannot add or remove allowed IPs, it can only turn the feature on, and off, meaning IF some emergency comes up, and you MUST access a PBX which has console restrictions in place from some random mobile hotspot in the middle of nowhere, You pull out your phone, login to the app, and flip a switch, and now as long as you know the PBXs credentials, you can login to it from your location. Then when your done, flip the switch back on, and the system is locked down again.

How does PBXMonitor do this, simple, You authorize PBXMonitors control IP in Console Restrictions when you first setup PBXMonitor, then from that point, the PBXMonitor Mobile app is able to toggle console restrictions for you.

The App i speak of, also requires 3 pieces of information to login, Your username, your password, AND, your PBXMonitor Account ID, meaning your account ID with us, that we use internally to identify your account. So the App is useless even if someone did have your username and password if they do not know your account id with us.

@hulk123 if you have any other curiosities around this subject feel free to ask, I am actually certified in:
CVA - System/Network Vulnerability Assessment
CPTE - Penetration Testing Engineer
CISSO - Information Systems Security Officer
Computer Forensics
Numerous others but those 4 are the ones pertinent to this discussion, i also work in the Critical Infrastructure field assisting the FBI, Infragard, regarding cyber security matters, and I have helped close cases across the US as a Computer Forensics Examiner. Little things like that...

 

[BrenttG]

Another good middle ground option would be to offer RADIUS as a another method to authenticate. It would be very beneficial for many of us using 3rd party identity providers to not only secure O365 but a host of other services like client-server VPNs, secure portal services, AWS services, monitoring and management services, and pretty much any service that can either integrate with our IDP or has the ability to use the standard RADIUS protocol. What this would do for 3CX customers is allow their userbase to point to say an Okta RADIUS or similar MFA servers to validate the user authentication piece and in turn enhances the entire security of logging into the PBX without 3CX needing to figure out and integrate each and every MFA provider. It's then vendor agnostic. It's great that 3CX offers integration with G-Suite and O365 which can provide 2FA in themselves, but for us that secure our userbase via other IDPs, RADIUS could provide this bridge. One point of issue with this is mapping extensions to users. This would have to happen either by the RADIUS server returning an attribute value back to 3CX server, which of course would be the user's extension, or user extension mappings via an initial sync or import of the user accounts.

What happens when the radius server that controls all your eggs in the basket gets popped, ive seen it happen numerous times, everything that is using it for C&C suddenly becomes compromised and must be checked to see if a threat actor accessed it or not. Lets not encourage people to make a hackers job easier...

There are lots of better options than radius. Radius is still used because it is already being used, and it is cost prohibitive for all the big industries that are chained to it at the hip to replace and uproot it. Not to mention having to retrain an entire backend workforce who is also used to radius. Hundreds of millions of devices use it, not because it is secure, or because it is a quality system, but simply, because it is already there as an established status quo, and it would mean re-inventing billions of dollars worth of equipment, everything from badge readers on doors and entryways to telecom systems, to industrial control systems at manufacturing plants, power plants, etc. Radius is buried to deep to be thrown out and replaced in any timely manner, but do not mistake that entrenchment for the meaning that it is a good, or the best, or a secure system.

 

[johnpi]

What happens when the radius server that controls all your eggs in the basket gets popped, ive seen it happen numerous times, everything that is using it for C&C suddenly becomes compromised and must be checked to see if a threat actor accessed it or not. Lets not encourage people to make a hackers job easier...

There are lots of better options than radius. Radius is still used because it is already being used, and it is cost prohibitive for all the big industries that are chained to it at the hip to replace and uproot it. Not to mention having to retrain an entire backend workforce who is also used to radius. Hundreds of millions of devices use it, not because it is secure, or because it is a quality system, but simply, because it is already there as an established status quo, and it would mean re-inventing billions of dollars worth of equipment, everything from badge readers on doors and entryways to telecom systems, to industrial control systems at manufacturing plants, power plants, etc. Radius is buried to deep to be thrown out and replaced in any timely manner, but do not mistake that entrenchment for the meaning that it is a good, or the best, or a secure system.

By "popped" you mean pwned? I don't think you quite understand how RADIUS servers work and how they're securely deployed. You don't expose them to the outside world Brentt. You secure them and allow specific traffic (RADIUS traffic) to them from specific hosts or services. Your argument is pretty weak from that stance. If you're deoploying servers and they're getting pwned, then you should probably move on to another profession, especially if the servers and services involved deal with the authentication process.

"There are lots of better options than radius. Radius is still used because it is already being used".
This is completely untrue Brentt. It's being used still for a numerous reasons, one of which involves allowing AAA functionality. But please feel free to tell us all these "lot better options" for allowing a secure MFA. Again, I don't think you quite understand how RADIUS works in modern environments. It's a very good, stable and secure method to allow for MFA and specifically TOTP 2FA when there is no integration with a particular SSO provider.

"Not to mention having to retrain an entire backend workforce who is also used to radius. Hundreds of millions of devices use it, not because it is secure, or because it is already there as an established status quo, and it would mean re-inventing billions of dollars worth of equipment"
It really seems like you simply joined several words together to attempt to form an argument, but the whole sentence doesn't make any sense, at least not from an English perspective.

 

[BrenttG]

1. I did not insult your language, if you want to insult mine find another site to do it on. You seem to be making a personal attack simply because you disagree with me.
2. Servers are compromised every day, that are supposedly securely deployed, with only specific traffic allowed to reach them. If you do not understand this, not much i can do to help you, zero days happen, systems that have access to those secure systems sometimes get hacked, and used to pivot into other secure systems, are you familiar with a pivot attack?

There was an attack at a defense contractor years back where they used a total of 4 pivot points all together to get into a system that was described as impossible to penetrate, well, it was hit, because a node in a low security area was compromised, used to pivot into a subnet that was more privileged, a node on that network was then compromised, and used to gain access to a system that sat in the middle between a maximum security network, and the intermediate level, then they managed with that access, to eventually penetrate a database server within the secure enclave and it was game over. As i recall the hack had been in process for a matter of weeks undiscovered before it managed to get that far. But it happened.

Any system, anywhere can be hacked, there is always a way though it can be made next to impossible with good security practices. Researchers in Israel were able to breach a system that was completely air-gapped, with ZERO network access to the outside world by passing malware to a thumb drive used to transfer data in and out of the system, the malware then ex-filtrated data by using the HDD activity light, being recorded by a camera from a distance far away. IT worked.
Reference: https://securityaffairs.co/wordpress/56583/breaking-news/data-exfiltration-hdd-leds.html

If you believe one of your systems is not hack-able, you are in lala land, everything can be hacked, some how, some way, it is our job as security professionals to first cover the bases of all the basic and intermediate threats, and then to do our jobs and stay at least 1 step ahead of the hackers each day, in finding new ways to attack systems, and then finding ways to prevent them.

Some examples:
FreeRADIUS - Allows hackers to login without credentials, sweet!
https://securityaffairs.co/wordpres...ius-tls-resumption-authentication-bypass.html

The mother load, reading through this gave me some new software packages to ensure i never use.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RADIUS

Another recent one
https://nvd.nist.gov/vuln/detail/CVE-2021-32642

Another good example of hackers logging in, without having to login at all
https://nvd.nist.gov/vuln/detail/CVE-2021-32642

FreeRADIUS especially seems to have reoccurring and ongoing problems with specially crafted input attacks allowing complete authentication bypass events to occur, lovely! Lets lock all the goodies behind that and hope no one breathes on the door.

 

[SweetAction]

@johnpi I think instead of RADIUS, it would be better to get real SAML, OpenID, or similar. Unless you plan to expose your radius server to the internet, how does a remote user authenticate? However, 3CX clearly has decided to go the route of Microsoft / Google.

https://www.3cx.com/community/threads/sso-via-saml-or-jwt.52046/page-2#post-294593 has more information on my thoughts about this.

 

[johnpi]

1. I did not insult your language, if you want to insult mine find another site to do it on. You seem to be making a personal attack simply because you disagree with me.
2. Servers are compromised every day, that are supposedly securely deployed, with only specific traffic allowed to reach them. If you do not understand this, not much i can do to help you, zero days happen, systems that have access to those secure systems sometimes get hacked, and used to pivot into other secure systems, are you familiar with a pivot attack?

There was an attack at a defense contractor years back where they used a total of 4 pivot points all together to get into a system that was described as impossible to penetrate, well, it was hit, because a node in a low security area was compromised, used to pivot into a subnet that was more privileged, a node on that network was then compromised, and used to gain access to a system that sat in the middle between a maximum security network, and the intermediate level, then they managed with that access, to eventually penetrate a database server within the secure enclave and it was game over. As i recall the hack had been in process for a matter of weeks undiscovered before it managed to get that far. But it happened.

Any system, anywhere can be hacked, there is always a way though it can be made next to impossible with good security practices. Researchers in Israel were able to breach a system that was completely air-gapped, with ZERO network access to the outside world by passing malware to a thumb drive used to transfer data in and out of the system, the malware then ex-filtrated data by using the HDD activity light, being recorded by a camera from a distance far away. IT worked.
Reference: https://securityaffairs.co/wordpress/56583/breaking-news/data-exfiltration-hdd-leds.html

If you believe one of your systems is not hack-able, you are in lala land, everything can be hacked, some how, some way, it is our job as security professionals to first cover the bases of all the basic and intermediate threats, and then to do our jobs and stay at least 1 step ahead of the hackers each day, in finding new ways to attack systems, and then finding ways to prevent them.

Some examples:
FreeRADIUS - Allows hackers to login without credentials, sweet!
https://securityaffairs.co/wordpres...ius-tls-resumption-authentication-bypass.html

The mother load, reading through this gave me some new software packages to ensure i never use.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RADIUS

Another recent one
https://nvd.nist.gov/vuln/detail/CVE-2021-32642

Another good example of hackers logging in, without having to login at all
https://nvd.nist.gov/vuln/detail/CVE-2021-32642

FreeRADIUS especially seems to have reoccurring and ongoing problems with specially crafted input attacks allowing complete authentication bypass events to occur, lovely! Lets lock all the goodies behind that and hope no one breathes on the door.

Ah Brentt, where do I start with your latest response?
1. I'm not insulting your language, merely pointing out the fact that your rambling statement doesn't make any sense and has no factual basis.
2. Yes, this is one point on which I can agree with you. Servers and services are compromised every day, day in and day out for a number of reasons. No one will argue with you on this point. Most of the time Brentt these events occur due to poor security practices including exposing unnecessarily systems and services to the Internet, un-patched poorly maintained systems and services, and I'll add in poor vendor vetting.

Reading up on your FreeRADIUS example from this CVE-10179148(https://seclists.org/oss-sec/2017/q2/342) which was revealed and patched back in 2017 pertains to TTLS and PEAP where FreeRADIUS skips inner auth when it tries to handle a resumed TLS connection, and the malicious actor must have direct access to the RADIUS server itself to exploit.

The CVE-2021-32642 example pertains to radsecproxy which is a generic RADIUS Proxy, not a RADIUS server. More on it's function here: https://radsecproxy.github.io/radsecproxy.html. So again, this doesn't support an argument against using RADIUS for AAA. This does however lead me to believe your knowledge of network and security concepts is lacking quite extensively for you to be attempting to make an argument that the use of RADIUS for authentication is a bad solution for 3CX, and in general a dated and bad security practice.

Let's get back to the original point of the OP statement, and that is that authenticating to a 3CX system would benefit from MFA, and the solution shouldn't be to use O365 or GSuite integration only. One way to do this is implement 2FA directly within the 3CX system. My point is as a good alternative option if 3CX could bundle in the ability to auth through RADIUS, it would allow users to leverage their current identity platform like Okta, or Azure, or Centrify, or GSuite, etc. Your point seems to be that RADIUS is a bad idea supported by a few articles you found from your favorite search engine.

And finally, I'm still calling you out on this one. I'm interested to read your long list of "lots of better options than RADIUS".
"There are lots of better options than radius. Radius is still used because it is already being used".
This is completely untrue Brentt. It's being used still for a numerous reasons, one of which involves allowing AAA functionality. But please feel free to tell us all these "lot better options" for allowing a secure MFA. Again, I don't think you quite understand how RADIUS works in modern environments. It's a very good, stable and secure method to allow for MFA and specifically TOTP 2FA when there is no integration with a particular SSO provider.

 

[johnpi]

@johnpi I think instead of RADIUS, it would be better to get real SAML, OpenID, or similar. Unless you plan to expose your radius server to the internet, how does a remote user authenticate? However, 3CX clearly has decided to go the route of Microsoft / Google.

https://www.3cx.com/community/threads/sso-via-saml-or-jwt.52046/page-2#post-294593 has more information on my thoughts about this.

SweetAction, I like the name first off. Anyway, I could not agree more. I would love to see a SAML solution for 3CX. You are completely right that this is a better solution than using RADIUS. However, in my experience implementing SAML takes a bit more dev effort than implementing RADIUS. If SAML 2.0 is offered I would choose this over RADIUS. My point with RADIUS is in lieu of an integrated SAML 2.0 SSO solution.
Regarding how RADIUS is implemented, it sits behind and within a secure zone, not exposed to the Internet. The 3CX server would then opens up a session to the internal RADIUS server which handles validating the user's credentials and returns back to the 3CX server an accept or reject to the auth attempt. This gets a little tricker when 3CX service is hosted up at 3CX, but it still could be do-able across a secure channel and limited to communicating with the 3CX server itself.

 

[BrenttG]

@johnpi Yourself as well as @SweetAction have listed a number of the better alternatives to Radius actually, but it seems like all you really want to do is argue with me, and split details, well, that is a fruitless endeavor, and we all have better things to be doing, like selling more 3CX, i have said my peace.

 

[johnpi]

@johnpi Yourself as well as @SweetAction have listed a number of the better alternatives to Radius actually, but it seems like all you really want to do is argue with me, and split details, well, that is a fruitless endeavor, and we all have better things to be doing, like selling more 3CX, i have said my peace.

It's not just you BrenttG, I'll debate with anyone that wants to take the same stance as you have in believing RADIUS is not a good and valid option for authentication when it's deployed in a secure highly available manner. It's a valid middle ground option to achieve MFA if implementing a SSO solution like SAML2.0 with MFA via an IDP as an option is too difficult or time consuming to integrate into the software or service, and in this case that software being 3CX.
Splitting details? I'm very much into the details Brentt as you should be too. My original intent was to provide a possible valid alternative option for MFA and 3CX.

Cheers

 

[SweetAction]

SweetAction, I like the name first off. Anyway, I could not agree more. I would love to see a SAML solution for 3CX. You are completely right that this is a better solution than using RADIUS. However, in my experience implementing SAML takes a bit more dev effort than implementing RADIUS. If SAML 2.0 is offered I would choose this over RADIUS. My point with RADIUS is in lieu of an integrated SAML 2.0 SSO solution.
Regarding how RADIUS is implemented, it sits behind and within a secure zone, not exposed to the Internet. The 3CX server would then opens up a session to the internal RADIUS server which handles validating the user's credentials and returns back to the 3CX server an accept or reject to the auth attempt. This gets a little tricker when 3CX service is hosted up at 3CX, but it still could be do-able across a secure channel and limited to communicating with the 3CX server itself.

The name comes from the boss - back in the day you had 1 account for 3CX for all employees and I kinda took over his login since I was handling 3CX items.

but I really came to say that yes, I misread your message. So many 3CX servers are hosted that I was like "radius over the internet" without actually thinking about a site2site tunnel. Of course that will not be so doable with Hosted by 3CX, but other things are not doable there either.

I'm all for options so we can hope radius, ldap, saml, openid, native totp, etc come at some point. But the one thing I have learnt over the years - never plan for what may come, only for what has already been delivered. In this case, native login is a risk in it's current form, no matter how strong a password is. For those who 100% cannot accept that risk in their business plan I have to recommend blocking port 5001 5060, 5090 (or 443) externally (which breaks all sorts of issues, etc) but prevents someone from using 3CX remotely. Hope that helps.