How the SolarWinds Hackers Bypassed Duo’s Multi-Factor Authentication

How the SolarWinds Hackers Bypassed Duo’s Multi-Factor Authentication

This is interesting:

Toward the end of the second incident that Volexity worked involving Dark Halo, the actor was observed accessing the e-mail account of a user via OWA. This was unexpected for a few reasons, not least of which was the targeted mailbox was protected by MFA. Logs from the Exchange server showed that the attacker provided username and password authentication like normal but were not challenged for a second factor through Duo. The logs from the Duo authentication server further showed that no attempts had been made to log into the account in question. Volexity was able to confirm that session hijacking was not involved and, through a memory dump of the OWA server, could also confirm that the attacker had presented cookie tied to a Duo MFA session named duo-sid.

Volexity’s investigation into this incident determined the attacker had accessed the Duo integration secret key (akey) from the OWA server. This key then allowed the attacker to derive a pre-computed value to be set in the duo-sid cookie. After successful password authentication, the server evaluated the duo-sid cookie and determined it to be valid. This allowed the attacker with knowledge of a user account and password to then completely bypass the MFA set on the account. It should be noted this is not a vulnerability with the MFA provider and underscores the need to ensure that all secrets associated with key integrations, such as those with an MFA provider, should be changed following a breach.

Again, this is not a Duo vulnerability. From ArsTechnica:

While the MFA provider in this case was Duo, it just as easily could have involved any of its competitors. MFA threat modeling generally doesn’t include a complete system compromise of an OWA server. The level of access the hacker achieved was enough to neuter just about any defense.

Sidebar photo of Bruce Schneier by Joe MacInnis.

iDevices finally get key-based protection against account takeovers

iDevices finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated second-class citizens when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

iPhones and iPads finally get key-based protection against account takeovers

iPhones and iPads finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated to second-class citizenship when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

Humble Bundle alerts customers to subscription reveal bug

You’ll want to check your mailbox if you have a Humble Bundle account, as they’re notifying some customers of a bug used to gather subscriber information.

bug notice

Click to enlarge

The mail reads as follows:

Hello,

Last week, we discovered someone using a bug in our code to access limited non-personal information about Humble Bundle accounts. The bug did not expose email addresses, but the person exploited it by testing a list of email addresses to see if they matched a Humble Bundle account. Your email address was one of the matches.

Now, this is the part of a breach/bug mail where you tend to say “Oh no, not again” and take a deep breath. Then you see how much of your personal information winged its way to the attacker.

Oh no, not again

For once, your name, address, and even your login details are apparently in safe hands. Either this bug didn’t expose as much as the attacker was hoping for, or they were just in it for the niche content collection.

The email continues:

Sensitive information such as your name, billing address, password, and payment information was NOT exposed. The only information they could have accessed is your Humble Monthly subscription status. More specifically, they might know if your subscription is active, inactive, or paused; when your plan expires; and if you’ve received any referral bonuses.

I should explain at this point. You can buy standalone PC games on the Humble store, or whatever book, game, or other collection happen to be on offer this week. Alternatively, you can sign up to the monthly subscription. With this, you pay and then every month you’re given a random selection of video game titles. They may be good, bad, or indifferent. You might already own a few, in which case you may be able to gift them to others. If you have  no interest in the upfront preview titles, you can temporarily pause your subscription for a month.

This is the data that the bug exploiter has obtained, which is definitely an odd and specific thing to try and grab.

Security advice from Humble Bundle

Let’s go back to the email at this point:

Even though the information revealed is very limited, we take customer trust very seriously and wanted to promptly disclose this to you. We want to make sure you are able to protect yourself should someone use the information gathered to pose as Humble Bundle.

As a reminder, here are some tips to keep your account private and safe:

  • Don’t share your password, personal details, or payment information with anyone. We will NEVER ask for information like that.
  • Be careful of emails with links to unfamiliar sites. If you receive a suspicious email related to Humble Bundle, please contact us via our support website so that we can investigate further and warn others.
  • Enable Two-factor authentication (2FA) so that even if someone gets your password, they won’t be able to access your account. You can enable2FA by following these instructions.

We sincerely apologize for this mistake. We will work even harder to ensure your privacy and safety in the future.

Good advice, but what’s the threat?

One could guess that the big risk here, then, is the potential for spear phishing. They could exploit this by sending mails to subscribers that their subscription is about to time out, or claim problems with stored card details. Throw in a splash of colour text regarding your subscription “currently being paused,” and it’s all going to look convincing.

Phishing is a major danger online, and we should do everything we can to thwart it. While the information exposed here isn’t as bad as it tends to be, it can still cause major headaches. Be on the lookout for dubious Humble mails, especially if they mention subscriptions. It’ll help to keep your bundle of joy from becoming a bundle of misery.

The post Humble Bundle alerts customers to subscription reveal bug appeared first on Malwarebytes Labs.