Upcoming Critical OpenSSL Vulnerability: What will be Affected?
Some here may still remember Heartbleed. Heartbleed was a critical OpenSSL vulnerability that surprised many organizations, and patching the issue was a major undertaking. Heartbleed caused OpenSSL and other open-source projects to rethink how they address security issues and communicate with their users. OpenSSL started to pre-announce any security updates about a week ahead of time.
This week, OpenSSL announced they would release OpenSSL 3.0.7 this coming Tuesday. It will fix a critical vulnerability [1]. The OpenSSL definition of critical:
- CRITICAL Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
In short: This is something you will need to worry about!
The update will only affect OpenSSL 3.0.x, not 1.1.1. Now is the time to figure out where and how you are using OpenSSL 3.0.x. For most systems, you will be able to use the openssl command line utility:
% openssl version
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
Here is a quick list of OpenSSL versions for different operating systems:
OpenSSL 3.0.0, the first stable version of OpenSSL 3.0, was released in September 2021, about one year ago. Any older operating systems are likely using OpenSSL 1.1.1, which is not affected.
macOS: macOS, by default, uses LibreSSL, not openssl, installed. But openssl may be installed later by other software like Homebrew and MacPorts.
[thanks to all the contributors to this table. Let me know if you have additional entries]
| Linux Distro | OpenSSL Version |
|---|---|
| CentOS Linux release 7.9 | 1.0.2 |
| CentOS 8 | (1.1.1) |
| CentOS Stream 9 | (3.0.1) |
| Debian 11 (bullseye) | (1.1.1) |
| Eneavour 2022.09.10 | (1.1.1) |
| Fedora 34 | (1.1.1) |
| Fedora 35 | (1.1.1) |
| Fedora 36 | (3.0.5) |
| Fedora Rawhide | (3.0.5) |
| Kali 2022.3 | (3.0.5) |
| Linux Mint 21 Vanessa | (3.0.2) |
| Mageia 7 | (1.1.1) |
| Mageia 8 | (1.1.1) |
| Mageia Cauldron | (3.0.5) |
| OpenMandriva 4.3 | (3.0.3) |
| OpenMandriva Cooker | (3.0.6) |
| OPNsense 22 | 1.1.1 |
| OpenSuSE Leap 15.2 | (1.1.1) |
| OpenSuSE Leap 15.3 | (1.1.1) |
| OpenSuSE Leap 15.4 | (1.1.1) |
| Proxmox 6 | 1.1.1 |
| Redhat EL 9 | 3.0 |
| Rocky Linux release 9.0 (Blue Onyx) | 3.0.1 |
| Slackware 14 | 1.0.1 |
| Ubuntu 20.04 | (1.1.1) |
| Ubuntu 22.04 | (3.0.2) |
| Unifi Cloudkey 2.5.11 | 1.1.0 |
| Unifi NVR | 1.1.0 |
[1] https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Supersizing your DUO and 365 Integration
As soon as defenders started implementing multifactor authentication, attackers tried to get around it. One of the most common methods attackers are currently using is Push or Call Annoyance. Attackers try multiple times to authenticate and annoy the user until they accept the request. Several options address this attack method. This article shows how to use more advanced MFA options on a strategically risky subset of users without a massive rollout to your entire organization. This will allow for more agile adjustments and lower helpdesk calls.
With Office 365 and Microsoft Authenticator, their integration and authentication methods based on risk are nice. If you are using Duo with O365, it's more challenging, but we will be upping our game to increase the difficulty for the attackers. Depending on your Duo license, they have additional options for protection on their backend, but this works for all Duo license levels.
Prevent Annoyance Attack
- Only allow code authentication or hardware tokens(No push or call)
- Use Verified Duo Push, MS Authenticator with Number matching (users can not just accept the request)
App Code only authentication is where the only method allowed for multifactor is a passcode from the Mobile App or Hardware Tokens to keep attackers from prompting users. The biggest issue with this is user education and convenience.
The second way, and the way we are going to cover in detail, is the new Verified Duo push method(1). The user will verify their identity by entering a code into the app. The code is displayed on the device you are using to log in. Microsoft version of this tech is called MS Authenticator number matching (2).
While this does continue to prompt the user for authentication by the attackers, without the code, they can not approve access. It would take additional social engineering to get past this process. I believe this is a more user-friendly experience than just using the code in the app.
What if you don't want to apply this to All logins?
With our initial deployment, we didn't want every 365 users to do a Verified push every login. As previously stated, MS and DUO do not have the tightest integrations, so to do this risk-based takes some additional setup. We created 2 Duo integrations, one for "Normal Auth" and one for "Secure Auth." The "Secure Auth" had separate Duo and conditional access policies to meet the new requirements.
Supersize Setup
1. New Duo 365 Application
You need to create a new Duo application. It will require you to use your 365 global admin account during that process. Name the new application integration something like 365 Secure.
2. Setup a new policy for the Duo 365 Secure App
The policy should look like the below picture as you want this to be very restricted for risky authentications. In this case, it has Verified Duo Push as the only method for authentication. Instead of using the verified push here, you could also use the Mobile code only and hardware token option. Just don't allow SMS, phone, or standard push.
3. Create a new Custom control in MS 365 Conditional Access.
(Following Duo Instructions as needed). But before importing, you need to change the Name and ID like below so you can have two instances of DUO with different names. By default, it wants to use the same name and will error on the import.
4. New 365 Conditional Access Policy
Here is where you should determine what settings you want for the new protections. At a minimum, I think High Sign-in risk. If you do not have many users from outside the US, add location-based too. If you manage and clear risky users, also add that as an option. By tuning the Conditional Access policy right, you will get a few legitimate users that get the policy reducing helpdesk calls while adding much-needed protections.
To get a good idea of what's currently going on with your sign-ins, go to portal.azure.com, search for "security" and select Risky Users, Risky Signs and others on the bottom left.
5. Stop Evil
Below is what would have been a typical annoyance attack that would have been successful without the additional controls in place.
Are you using some sweet 365 settings or a neat way of using Multifactor? Leave us a comment.
(1)https://duo.com/blog/verified-duo-push-makes-mfa-more-secure
(2)https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/new-microsoft-authenticator-security-features-are-now-available/ba-p/2464386
Comments