Critical Vulnerability: Default Configuration Can Leave Unenrolled Accounts (Including 'root') Exposed about duo_unix HOT 3 CLOSED

The behavior of the new user access policy that you describe is documented here: https://duo.com/docs/policy#new-user-policy.

At the default setting of "Require enrollment", our service would have returned an enrollment message for the unenrolled user, preventing auth completion. It's a good idea to read through the outcomes of different new user policy settings before changing from default, especially if selecting "Allow access without 2FA".

non-enrolled accounts ought to be able to return some kind of DUNNO status

But it's not really "Dunno", it's "The policy is set to allow access without 2FA therefore access was allowed without 2FA".

Am I misunderstanding that the policy was intentionally set to allow access without 2FA?

from duo_unix.

Thanks for the prompt reply Kristina!

The behavior of the new user access policy that you describe is documented here: https://duo.com/docs/policy#new-user-policy.

Perhaps "Critical Vulnerability" was a bit harsh, but like I say, I was pretty shocked how easy it was for me to end up in a situation where ssh root@server-01 "Just Worked".

I don't know if you have control over the docs and/or webapp panels, but maybe a simple, amber-colored alert that said something like, "Note: Setting this means all attempts to log into unenrolled user accounts will succeed, possibly bypassing additional security restrictions. See the New User Policy documentation for more details." would at least suffice to raise a flag for unsuspecting sysadmins to alert them of the potential security risk. «shrug»

At the default setting of "Require enrollment", our service would have returned an enrollment message for the unenrolled user, preventing auth completion. It's a good idea to read through the outcomes of different new user policy settings before changing from default, especially if selecting "Allow access without 2FA".

So yeah, I understand what's going on; it just feels like a bouncer at a club: if you're on his list, you need an ID, but if you claim to be the President of the USA, and the President of the USA isn't on his list, he'll happily tell everybody, "Yup, he's President of the USA!"

Am I misunderstanding that the policy was intentionally set to allow access without 2FA?

Basically, our goal is to employ 2FA for administrators, but transparently fall back to password-based authentication for everybody else... When I tried either Require Enrollment (which we don't want to have to put them through) or Deny Access, it wouldn't allow me to enter a password at all...

ChallengeResponseAuthentiation yes

printed:

Please enroll at https://api-XXX.duosecurity.com/portal?code=CODE&akey=AKEY # Require Enrollment
Access is not allowed because you are not enrolled in Duo. Please contact your organization's IT help desk. # Deny Access

But then every subsequent password attempt just returned Permission denied, please try again.

ChallengeResponseAuthentication no

basically did the same, but without the error messages.

Accounts like root seem especially pernicious, because there are a small handful of people who, in the middle of the night, might actually need to log in that way, depending on who's on duty...

Is the "Best Practice" to enroll root as a "User" and add each person's phone? That could work, but it seems like it would run afoul of autopush — unless there's a way to enable autopush on an account-by-account (and/or user-by-user) basis... «hmmm»

[UPDATE: I did find https://duo.com/docs/duounix-faq#can-i-use-login_duo-to-protect-a-shared-root-account? which explains how to use SSH keys to select which Duo user to authenticate as. Check!]

Another Alternative

I've discovered I can get 97% of what I want by setting:

• New User Policy: Deny Access
• ChallengeResponseAuthentication yes
• And adding auth sufficient pam_unix.so nullok try_first_pass after the pam_duo entry in /etc/pam.d/sshd

My 3% "Nice-To-Haves" would be:

• The ability to silence the Access is not allowed because you are not enrolled... message — perhaps with a quiet argument at the end of the pam_duo.so line? (I ought to be able to patch/PR that pretty easily...)
• Personally, I'd rather have SSH's more verbose user@server-01's password: prompt over pam_unix.so's more spartan Password: but "Meh."
• And of course, we ALL wish it could display the Autopushing login request to phone... message immediately, but I understand that's likely out of your-all's hands. (#73)

Thanks again! :-D

from duo_unix.

Thanks for your detailed response. I do have control over some of the things you mention (warnings), and will pass on the other feedback.

Basically, our goal is to employ 2FA for administrators, but transparently fall back to password-based authentication for everybody else...

Another idea is to use the groups config option to include admins/exclude users.

I am going to close this issue though, as it isn't a vulnerability or problem with the application per se. When we see someone say "Critical Vulnerability" we definitely take the report seriously.

Thanks for using Duo!

from duo_unix.