Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Newbie
    Join Date
    Dec 2020
    Posts
    6

    Default Linux built-in VPN client bypasses OpenVPN MFA

    I have OpenVPN setup with password and MFA options. I use the Yubico Authenticator, but it's generic OAuth I think.
    Windows OpenVPN client works as expected. Connect with credentials, prompts for TOTP code.
    On my Linux device, I setup the built-in VPN client (I think it's part of the Gnome network manager - I use Pop!_OS 21.04) and it totally skips the MFA. Connects fine with just the username and password.
    Unless I'm missing something - this is not good.
    I did notice a new setting come up, "MFA Timeout" that doesn't seem documented. It was set to 0, or never. I changed it to 168 hours.

  2. #2
    Untangler
    Join Date
    Oct 2013
    Posts
    62

    Default

    This is probably exactly the issue I just posted about. It's easily bypassed by removing the TOTP line from the config file on Windows boxes as well... SCARY!

  3. #3
    Newbie
    Join Date
    Dec 2020
    Posts
    6

    Default

    I think you are correct, appears to be the same issue, guessing the Linux Network Manager client just ignores the MFA config by default so it has the same effect as removing it from the config. It is a major bug, renders MFA totally useless.

    I'm wondering if this is an upstream bug though - maybe need to take it up with the OpenVPN devs and then lobby Untangle to update the version in their software.

  4. #4
    Untangler
    Join Date
    Oct 2013
    Posts
    62

    Default

    I don't know... but it's a SERIOUS issue. I have a customer that is requiring MFA for VPN connections and I have to get them set up next week or they lose their insurance. I'm going to go ahead and set them up anyway, but good heavens - this needs to be fixed post-haste!

  5. #5
    Newbie
    Join Date
    Dec 2020
    Posts
    6

    Default

    As a temporary mitigation I created alerts for OpenVPN connect and disconnect events (log + email) so at least I can keep an eye on things.

  6. #6
    Untangler
    Join Date
    Oct 2013
    Posts
    62

    Default

    That's a good idea, but at the same time, most of the malicious actors are going to be doing their malicious stuff while I'm fast asleep!

  7. #7
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,554

    Default

    Insurance requiring MFA is silly in this circumstance anyway. If you use a username / password login, AND you require TOTP that's 2FA right?

    WRONG! You PRIMARY AUTHENTICATION is happening via the CERTIFICATE. TOTP in this case is now the THIRD FACTOR. Requiring a username / password login AND the certificate is already MFA. The TOTP is going even farther.

    The certificate enables mTLS. mTLS > MFA

    But insurance companies don't care about actual effectiveness, they just care about ticking boxes so they can avoid payouts. And for what? Llyod's is basically removing cyber protection one piece at a time anyway: https://www.lmalloyds.com/LMA/News/L...21-042-PD.aspx

    Good luck proving your event wasn't "state sponsored".
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  8. #8
    Untangler
    Join Date
    Oct 2013
    Posts
    62

    Default

    TOTP can and does help with BYOD VPN connectivity. If someone's home PC that they're using to connect to the work network (yes, people do this ALL THE TIME) has a malicious actor remotely connected to it, and the client has saved the password for the VPN (another feature that needs to be added - the ability to NOT be able to save the password), the TOTP would stop them from making the connection, theoretically. Every little bit helps...

    But yes, you're absolutely right with the 2FA. The second factor would be the username and password. Third would be TOTP.

    That said - TOTP auth is still VERY broken if there is nothing server-side mandating a TOTP password before allowing the client to connect...

    Do you think it would it make sense to shoot an email to support linking them to this topic?

  9. #9
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,554

    Default

    Yes, this is a bug and needs a ticket opened for it. You can reference the thread if you wish, but there isn't much actual data here.

    P.S. Nothing will save you from a bot running on an unmanaged endpoint you slapped a VPN client on. That practice is also against the insurance guidelines you're talking about here.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  10. #10
    Untangler
    Join Date
    Oct 2013
    Posts
    62

    Default

    Just heard back on my post and they now know about the bug. They provided the following info for fixing it, though they are going to be fixing it in an upcoming release. Below is what I was told:

    In the mean time you can fix this by editing the following file on your NGFW instance.

    File: /usr/share/untangle/bin/openvpn-auth-user-pass

    The last line in this file needs to be changed from

    result = openvpnApp.userAuthenticate(username, password)

    to

    result = openvpnApp.userAuthenticate(username, password, 0)

    Since this is a python script, tabs are important. If you need assistance with this, please contact support.

    You do not need to restart OpenVPN or NGFW after editing the script.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2