SolarWinds hackers have a clever way to bypass multi factor authentication

Hackers who hit SolarWinds compromised a think tank three separate times.

Read the whole story

 

[Azethoth666]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

If you practice Mnemonic memory techniques a little bit, you'll find that memorizing a 16+ character random password generated for you by a good passgen isn't hard.
Actual brute force attacks aren't that common, most attackers use permutating dictionary attacks. By using real words, no matter the rarity, you're reducing the possible combinations to a tiny fraction of the total... and more importantly that possibility space is what will be checked first.

Agreed. The only thing that matters is total entropy under the system of encoding. Memorizing 16 random characters takes effort. Remembering it two weeks later is even harder. The equivalent entropy from a passphrase would be 5 to 8 words. By "brute-force", I was assuming a dictionary attack. Any good brute-force attacker will, at a minimum, bias their guesses towards probable distributions.

Security comments do not need this circle jerk of incompetence the two of you are in.

1) use best practices. For pass phrases it is https://xkcd.com/936/ with maybe an extra word or so thrown in to overcome smaller dictionary sizes. Not the ignorant post OP wrote.
2) use best practices. For random gen it’s a password manager and long unique passwords for each site or app or whatever. You only memorize your recovery email(s), password manager and machine logins.
3) use best practices. Don’t make shit up. Google security best practices. Your 2nd factor needs to be a yubikey or cryptographic equivalent. Nothing else is acceptable. Everything else is inferior. Yes your bank is bad at security.

This article is about incompetent software that did _not_ use yubikey.

Subscribe to Ars for a nice yubikey as sign up bonus.

 

[Azethoth666]

So the server is trusting client input to be good? Isn't this day one infosec?

I think you got downvotes because in the series of fuckups here, the very tiniest part is accepting user input with no attempt at verification or uniqueness or anything.

On the other hand you are right that if they did not and generated a nonce or anything at all to validate a session it would have been harder to exploit and certainly not bypassing logs.

Furthermore this is a good demonstration that there is cryptographically secure 2nd factor (yubikey or equivalent) and there is useless security theater crap, which is what they used. You cannot imitate someone’s yubikey without getting mittens on it.

Sign up to Ars for your own yubikey!

 

[Hadestech]

Novel indeed.

These cookies are used for "Trust This Device"-type settings right, given that they had to present the username and password? If the user/organisation required a new MFA confirmation for every login would that "overcome" this particular problem?

I mean, Dark Halo still gained admin access to the network, so there's a few other problems there.

Also, I despise the Outlook Web App.

 

[henryhbk]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

If you practice Mnemonic memory techniques a little bit, you'll find that memorizing a 16+ character random password generated for you by a good passgen isn't hard.
Actual brute force attacks aren't that common, most attackers use permutating dictionary attacks. By using real words, no matter the rarity, you're reducing the possible combinations to a tiny fraction of the total... and more importantly that possibility space is what will be checked first.

Agreed. The only thing that matters is total entropy under the system of encoding. Memorizing 16 random characters takes effort. Remembering it two weeks later is even harder. The equivalent entropy from a passphrase would be 5 to 8 words. By "brute-force", I was assuming a dictionary attack. Any good brute-force attacker will, at a minimum, bias their guesses towards probable distributions.

Security comments do not need this circle jerk of incompetence the two of you are in.

1) use best practices. For pass phrases it is https://xkcd.com/936/ with maybe an extra word or so thrown in to overcome smaller dictionary sizes. Not the ignorant post OP wrote.
2) use best practices. For random gen it’s a password manager and long unique passwords for each site or app or whatever. You only memorize your recovery email(s), password manager and machine logins.
3) use best practices. Don’t make shit up. Google security best practices. Your 2nd factor needs to be a yubikey or cryptographic equivalent. Nothing else is acceptable. Everything else is inferior. Yes your bank is bad at security.

This article is about incompetent software that did _not_ use yubikey.

Subscribe to Ars for a nice yubikey as sign up bonus.

Unless I’m not understanding the hack in the article, wouldn’t yubikey be equally vulnerable, since the hack here was to make the server think duo had said “it’s all good”? So remote hardware or not, if the server thinks it already asked, doesn’t that negate the power of a hardware key? The way it seems in the article that duo’s APi checks if it has an akey locally and if so doesn’t ask for a duo push?, when it should be programmed to always ask for just this reason. Sure it saves a little bit of bandwidth but seriously. Even with quantum entanglement or some unobservable magic like that, if the server doesn’t bother to ask, it’s not gonna matter how secure the software authentication is...

As to all the folks commenting remote hardware keys are impervious to retrieval, if there is one thing spectre, meltdown, etc taught us, that is not exactly true. Even apple’s vaunted T2 got compromised at this point.

 

[Aguyd]

Novel indeed.

These cookies are used for "Trust This Device"-type settings right, given that they had to present the username and password? If the user/organisation required a new MFA confirmation for every login would that "overcome" this particular problem?

I mean, Dark Halo still gained admin access to the network, so there's a few other problems there.

Also, I despise the Outlook Web App.

If you configured your server to require new MFA confirmation for every login, the hackers could just turn that setting off. Or do something else. Fundamentally, MFA is intended as a mitigation for client compromise (e.g., due to phishing, password reuse, etc.) . MFA does not protect against server compromise.

 

[Azethoth666]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

Bank sites tend to have low length caps that cramp this style, unfortunately.

Depends. The banks and brokers and 401K/Roth operators I deal with all accept at least 20 characters now (the default length of what Keepass generates). That's still too short to use a decent passphrase, true. But it's way better than they were even a few years ago. They all, also, offer 2FA, though so far they don't accept use of an authenticator app (like MS or Google) or a hardware key like a Yubi, at least for consumer accounts. And finding the 2FA setup options can be a hunting expedition in their options forest.

Getting a Yubikey for signing up with a paid Ars account was a good pitch. Unfortunately, I've found almost zero places that actually let me use it.

For me the important places use yubikey:

Gmail, LastPass, GitHub, Cloudflare, Dropbox, Linux, ProtonMail

Next I need Apple and MS to fix their OS to use yubikey on login + password instead of some goddamned pin or memorized 20+ char password. Although the Apple Watch unlock is nice and hopefully equivalent. But when that fails, I want some 2nd factor action.

 

[TexasFight]

Depends. The banks and brokers and 401K/Roth operators I deal with all accept at least 20 characters now (the default length of what Keepass generates). That's still too short to use a decent passphrase, true. But it's way better than they were even a few years ago. They all, also, offer 2FA, though so far they don't accept use of an authenticator app (like MS or Google) or a hardware key like a Yubi, at least for consumer accounts. And finding the 2FA setup options can be a hunting expedition in their options forest.

Getting a Yubikey for signing up with a paid Ars account was a good pitch. Unfortunately, I've found almost zero places that actually let me use it.

Not sure that hardware 2FA would help here. If they have access to master secrets it's like encryption where the bad guy knows all your keys.

At that point it's game over. Which is why the whole cloud thing is so insecure. You do not have control over keys so there is always at least the cloud provider who has full access to all your data.
Add to that SSO which promotes use of very short and simple passwords as you have to type it in bazillion times a day to login into your computer and it's not surprising that security is a joke in most places.

Edit about 20 min after the original post:
Now that I think about it. dedicated hardware on both ends might work for 2FA as there is no way to remotely extract secrets out of the hardware. This might also work for some types of encryption. But if your entire system is compromised it's hard to defend anything even with dedicated hardware backing.

I'd agree with your comment about cloud 2FA (aka "outsourcing of your 2FA") - if one ran their own YubiKey OTP validation infrastructure, and protected the OTP secrets at-rest with YubiHSM 1 devices, it would considerably raise the bar.

 

[Steve-D]

So say we all!

If you want secure there is only one way and this man knew how:

Or did you mean " S0 $@y W& A11? "

[edit for typo]

 

[Deleted member 161099]

Novel indeed.

These cookies are used for "Trust This Device"-type settings right, given that they had to present the username and password? If the user/organisation required a new MFA confirmation for every login would that "overcome" this particular problem?

I mean, Dark Halo still gained admin access to the network, so there's a few other problems there.

Also, I despise the Outlook Web App.

If you configured your server to require new MFA confirmation for every login, the hackers could just turn that setting off. Or do something else. Fundamentally, MFA is intended as a mitigation for client compromise (e.g., due to phishing, password reuse, etc.) . MFA does not protect against server compromise.

Indeed.

Furthermore, for the most common 2nd factors - rotating numbers (like Google Authenticator, Authy etc.), and for SMS (which are typically generated from the same seed as the 'real' token, just done server side and SMSd to you instead of being done in your auth app) - if you have the secret key you can just generate the response numbers yourself.


That's why I don't see anything clever here. If you have the keys to the 2FA system, you can evade the 2FA. News at 10.

 

[Abhi Beckert]

I used to memorize random passwords like bahopre3[...] Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words[...]

Your short random password is is 36^8, or 2 821 109 907 456 possible combinations.

Your passphrase is 1000^3 or 1 000 000 000 combinations.

Really neither one has acceptable entropy, but the passphrase is clearly worse.

If you made the password just a bit longer, maybe some mixed case or symbols and don't just slap a number on the end it should be in the middle, that would be the way to go.

Also, the use case matters - is your password stored in a plain text database somewhere? That can be compromised no matter how strong and you better not use it elsewhere. If it's only ever used as a decryption for password vault software with a good key derivation function? Nobody's going to crack even a fairly weak password in that scenario.

The FBI required months and millions of dollars to crack the san burnidino iphone which was only six digits (or possibly four digits?). Only high value targets will ever face that level of effort.

Passwords are hard. There is no simple solution that is secure... you really need to use password management software and even then know what you're doing.

 

[Chuckstar]

Can someone clarify how the cookie helps them compromise the login?

My best guess is that they are constructing a cookie to feed from the browser. The cookie would either be (1) the confirmation that the user clicked “Always Trust Thus Computer” last time they logged in, so that MFA is not required for this login — only validation of the signature (or whatever encrypted code) on that cookie is required or (2) it’s the cookie that says “user already logged in and is in the middle of a session”. For #1, I don’t even know if Duo has such an “Always Trust...” setting that can be used that way, though. For #2, I’ve always assumed some kind of cookie like that gets placed during a session, otherwise how does the server know not to ask for re-login upon page reload (and if that’s not how it works, then I’d appreciate being enlightened).

Since I’m obviously no expert, “my best guess” should hardly be considered authoritative. Entirely possible I’m just way off.

Thanks in advance.

 

[Nora Lenderbee]

Once hacked, the only safe thing to do is rebuild everything.

A friend of mine's wife worked at a large company with a high profile CEO (donated lots of money and took sides on political issues). They got hacked by a foreign hacker group that was on the opposite sides of those issues, the hackers defaced their websites and stole data. They ended up purchasing, re-rack, rebuild everything. Nothing that was there before was trusted, not network infrastructure, not servers, not storage.

So, nuke it from orbit as the only way to be sure?

 

[BradTheGeek]

I am confused... according to other articles (on Ars and elsewhere) the SolarWinds hack was Russia/Cozy Bear.

This is Dark Halo, and it is stated they have no known ties to other groups.

Why then does the title put this thinktank breach on the same hackers as SolarWinds... it doesn't seem to be true. Is it a mistake, or an attempt to gain clicks since the SW breach is big news right now?

 

[jhodge]

Once hacked, the only safe thing to do is rebuild everything.

A friend of mine's wife worked at a large company with a high profile CEO (donated lots of money and took sides on political issues). They got hacked by a foreign hacker group that was on the opposite sides of those issues, the hackers defaced their websites and stole data. They ended up purchasing, re-rack, rebuild everything. Nothing that was there before was trusted, not network infrastructure, not servers, not storage.

Two questions:

1. What do you do if you can’t afford to demo and rebuild everything thing? (better hope it’s not your smart building automation!)
2. How do you operate the business during the demo/rebuild?

I think a reformat/restore (reflash firmware) is going to need to be hard enough for most organizations. Given the frequently woeful state of backup/restore procedures, even that may be beyond the capacity of many.

 

[MrReaper]

I’m a bit confused by the writing: is this saying that Dark Halo, APT29, and Cozy Bear are all the same?

Yes.

Also: I’m not managing to work out message flows for the 2FA thwart. Probably because I don’t sufficiently understand how Duo works, but the article assumes I do.

Fair enough. Essentially 2FA expects two things in order for you to login: 1) A password hash that matches the hash value in the password database. 2) A value that was generated by a 2FA server and sent to a device owned by the user.

This hack bypassed the second of those, by hacking the 2FA server. This hack unveiled the secret the server uses to generate 2FA values. With knowledge of this secret a hacker can generate their own 2FA keys without ever contacting the server again.

When a 2FA server is compromised, it's game over for 2FA. Basically period. The primary advantage for a hacker in generating their own values, is there is less chance of getting detected. By compromising the 2FA server once, there are fewer logs/sessions indicating the server was compromised. It helps them remain stealthy longer. So either way this attacker could have bypassed 2FA. But the method they used was clever for stealth reasons.

I don't think they hacked the 2FA server itself. The article describes that the attackers stole an "akey" from the OWA server, and used that to generate a token that bypasses 2FA auth.

Regular flow:
1. User accesses OWA server
2. OWA server asks for user/pass
3. User provides user/pass
4. OWA server checks user/pass, it's good, redirects to 2FA server
5. 2FA server does its thing, authenticates user.
6. When 2FA is done, user can ask "don't authenticate me using 2FA again for xxx days". 2FA server generates a cookie, based on the shared "akey" between it and OWA server, and hands that back to user.
7. 2FA server redirects back to OWA, saying user is authenticated.
8. OWA logs user in.

Optimized flow:
1. User accesses OWA server
2. OWA server asks for user/pass
3. User provides user/pass and the cookie from (6) above
4. OWA checks user pass, and verifies cookie is ok, gives access.
5. OWA logs user in.

The issue is that attackers can generate a valid token for step (4), because they had access to the shared secret "akey" between OWA and 2FA, and apparently that's all it takes to generate a good cookie.

(edited to answer doubts below - I'm still a new poster, can't reply directly...)

I believe the "akey" method for generating the cookie is used so that OWA can check its authenticity without contacting the 2FA server. Supposedly only OWA and 2FA know about akey.
A better method would be for 2FA to sign the cookie info, and OWA could still check it without contacting 2FA. No need for sharing a secret that can then be exposed...

But if OWA is completely compromised, attackers could just hijack the login method anyways... this just made it easier.

 

[John Savard]

I don't think they hacked the 2FA server itself. The article describes that the attackers stole an "akey" from the OWA server, and used that to generate a token that bypasses 2FA auth.

Yes!

And thank you for the explanation of how that worked.

However, I am a bit puzzled.

Once the 2FA server tells the OWA server that the login is good, why does the OWA server need an akey shared with the 2FA server to generate a cookie? Why can't it generate a cookie all on its own, without using a secret shared with anyone else?

Not that this is necessarily a vulnerability, if the 2FA server is much more secure than the OWA server, but it seems like sharing that secret doesn't help anything.

 

[mmiller7]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

Works great until you have some security-czar who decides words are bad and bans dictionary words or anything more than like 3 letters long without a number/symbol from being any sub-string regardless of how long you intended to make it.

I also like rules where they say no more than 2-3 letters that are any other part of your account information. For example, at university I learned "WhatTheHeckThisIsTheStupidestThingEver" is too similar to "Matthew" to be permitted.

Generally I've noticed the more certifications they have in their signature, the more absurd they will make/enforce the rules. People with 1-2 are okay, people with multiple lines wrapping on an email-signature are impossible to work with and find fault with everything including pre-approved whitelisted stuff.

 

[Rudde]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

Works great until you have some security-czar who decides words are bad and bans dictionary words or anything more than like 3 letters long without a number/symbol from being any sub-string regardless of how long you intended to make it.

I also like rules where they say no more than 2-3 letters that are any other part of your account information. For example, at university I learned "WhatTheHeckThisIsTheStupidestThingEver" is too similar to "Matthew" to be permitted.

Generally I've noticed the more certifications they have in their signature, the more absurd they will make/enforce the rules. People with 1-2 are okay, people with multiple lines wrapping on an email-signature are impossible to work with and find fault with everything including pre-approved whitelisted stuff.

Umm, "WhatTheHeckThisIsTheStupidestThingEver" and "Matthew"

 

[Scathian]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

Bank sites tend to have low length caps that cramp this style, unfortunately.

It's pretty sad how bad financial institutions and trading companies tend to be at security. One bank I use has a requirement of 8-12 numbers... nothing else, no letters, no symbols, just numbers. It's so incredibly stupid.
And I had to use an education site for a certificate once that mailed my password in plaintext (hunter2) after I had created it...I emailed them and they said they were aware...and covid was causing delays...for the last 10+ years.

 

[Phone Sterilizer]

Protecting the container that holds your trusted secrets is the most import thing there is in security. Period. This why Apple devices are more secure and what the US government tries to do with FIPS 140. 2FA doesn’t matter if you think you’re communicating with a legit sever.

 

[unsigned]

The akey is needed to authenticate to the Duo service when it’s time to phone home to Duo and initiate second factor auth. So the interesting bits here are how exactly the akey was compromised, but more so... how the actor was able to use that akey to bypass the call to the Duo service. Was it configured not to prompt for MFA on every login?

It's common to have session and location/network aware rules for 2FA. Inside the corporate network make it unneeded, or just once per session or maybe time period. Outside or untrusted networks would require it per session, or at every auth request. May vary based on personal or corporate systems as well. This was OWA, but that doesn't mean external access.

Folks tend to complain a lot about it, so this is seen as a way to reduce the end -user impact and still maintain a good level of security.

 

[AxMi-24]

Depends. The banks and brokers and 401K/Roth operators I deal with all accept at least 20 characters now (the default length of what Keepass generates). That's still too short to use a decent passphrase, true. But it's way better than they were even a few years ago. They all, also, offer 2FA, though so far they don't accept use of an authenticator app (like MS or Google) or a hardware key like a Yubi, at least for consumer accounts. And finding the 2FA setup options can be a hunting expedition in their options forest.

Getting a Yubikey for signing up with a paid Ars account was a good pitch. Unfortunately, I've found almost zero places that actually let me use it.

Not sure that hardware 2FA would help here. If they have access to master secrets it's like encryption where the bad guy knows all your keys.

At that point it's game over. Which is why the whole cloud thing is so insecure. You do not have control over keys so there is always at least the cloud provider who has full access to all your data.
Add to that SSO which promotes use of very short and simple passwords as you have to type it in bazillion times a day to login into your computer and it's not surprising that security is a joke in most places.

Edit about 20 min after the original post:
Now that I think about it. dedicated hardware on both ends might work for 2FA as there is no way to remotely extract secrets out of the hardware. This might also work for some types of encryption. But if your entire system is compromised it's hard to defend anything even with dedicated hardware backing.

I'd agree with your comment about cloud 2FA (aka "outsourcing of your 2FA") - if one ran their own YubiKey OTP validation infrastructure, and protected the OTP secrets at-rest with YubiHSM 1 devices, it would considerably raise the bar.

Exactly. You need to have dedicated hardware on both ends that is incapable of leaking codes. One that "gets a request and outputs answer" and one "that outputs requests and a clear verified/not verified". Nothing else. If there is a need to update something you have to replace it. If you allow modification of firmware you are back to software based solution with extra steps pretending to add security.

Any system that relies on software is iffy. The main issue is that if someone steals the HSM you get a warning that someone has fucked around with HSM. When it's all in software it is much less likely that you will figure out that someone has been there messing with the keys.

 

[brokensyntax]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

LENGTH adds entropy quickly. Words have a tendency to add length.
Which is fine if you're brute forcing digit by digit/character by character, but that's not what people do.

People compile lists of common words/phrases, and then mutate them in a number of ways. (All A becomes 4, all e become 3, every other A etc.)
I wrote a parser that would take a language dictionary and dump out a bunch of the mutations pre-calculated, then concatenated in a bunch of different common methods.

Without those mutations you look at a phrase like "correct horse battery staple" and see 25 to 28 (spaces?) characters or points of entropy.

I look at a phrase like "correct horse battery staple" and I see 4 points of entropy.

With those mutations, there's a few more points of entropy, but by running common mutations against the words, it's still not a computationally significant difference, because you can treat each word, and each variation of the word (Case shifting, vowel replacement etc.) as a single point of entropy, or a single character, if you will.

And this is why password managers are such a huge recommendation, so you need only memorize one computationally complex password to access all of your other computationally complex passwords, but then questions about the best way to store/access etc.

Noting that every level of security, is a loss at some level, of usability.

This is also what pushes projects like SQRL (( https://en.wikipedia.org/wiki/SQRL || https://www.grc.com/sqrl/sqrl.htm))

It's why for decades Linux admins have been issuing client/server key pairs for SSH logins, and indeed, why MFA exists. But how you apply and use that MFA will carry the same balance of security vs. usability. (Enforce MFA at every interaction? Or allow the use of a stored session cookie, for instance.)

 

[Phone Sterilizer]

The akey is needed to authenticate to the Duo service when it’s time to phone home to Duo and initiate second factor auth. So the interesting bits here are how exactly the akey was compromised, but more so... how the actor was able to use that akey to bypass the call to the Duo service. Was it configured not to prompt for MFA on every login?

It's common to have session and location/network aware rules for 2FA. Inside the corporate network make it unneeded, or just once per session or maybe time period. Outside or untrusted networks would require it per session, or at every auth request. May vary based on personal or corporate systems as well. This was OWA, but that doesn't mean external access.

Folks tend to complain a lot about it, so this is seen as a way to reduce the end -user impact and still maintain a good level of security.

Yup. You have to authenticate when crossing a system boundary.
And that’s usually inconvenient.

 

[brokensyntax]

The akey is needed to authenticate to the Duo service when it’s time to phone home to Duo and initiate second factor auth. So the interesting bits here are how exactly the akey was compromised, but more so... how the actor was able to use that akey to bypass the call to the Duo service. Was it configured not to prompt for MFA on every login?

Not that I have any actual idea. But Having used Duo in the past there is an ability to disable 2FA for a particular account. Presumably one would need to have that akey handy in order to update that setting

No need to have the akey handy to modify the account's expectation of MFA. Depending upon how it was setup. If they gained access to a Duo admin dashboard, because the admin chose not to have MFA on dashboard access (I've seen such egregious mistakes in the past.), or accessed the dashboard from a compromised network with a MITM attack and had their session hijacked.

Alternatively, I've seen AD accounts configured so that members of specific groups must use MFA, or members of specific groups are MFA exempt. In those instances, a compromised AD environment through other channels could enable/disable the requirement on account for MFA.

As for the akey itself, I suspect the akey was simply stored as a file, or part of a config file, and that file was compromised either via an insecure IIS or FTP configuration. Once the akey was known as stated in the article they were able to craft a session cookie to serve with the password attempt that said "You already authenticated me today, don't worry about calling home." - Age old problem of usability vs. security. Reduce security, by making it so users are only asked every 3rd login, or once every 2 hours, etc. etc.

 

[mmiller7]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

Works great until you have some security-czar who decides words are bad and bans dictionary words or anything more than like 3 letters long without a number/symbol from being any sub-string regardless of how long you intended to make it.

I also like rules where they say no more than 2-3 letters that are any other part of your account information. For example, at university I learned "WhatTheHeckThisIsTheStupidestThingEver" is too similar to "Matthew" to be permitted.

Generally I've noticed the more certifications they have in their signature, the more absurd they will make/enforce the rules. People with 1-2 are okay, people with multiple lines wrapping on an email-signature are impossible to work with and find fault with everything including pre-approved whitelisted stuff.

Umm, "WhatTheHeckThisIsTheStupidestThingEver" and "Matthew"

Well there ya go -- I can't even make an example without falling over the rules worse than I realized.

If that doesn't prove how dumb it is, nothing does!

 

[NetMage]

For those suggesting that once compromised, MFA could just be disabled, the point was to avoid notice. Even among typical users, someone will notice if they aren’t asked for the MFA when they logon to email, and among my users, they will call and complain, worried they had broken something.

So they need an attack that doesn’t involve a noticeable change in settings.

 

[RickRoyLeonPrisZhoraRachael]

If you want secure there is only one way and this man knew how:

This is the way. Um, I mean, "So say we all. "

Spoiler

Wait, Adama was technically a bot...ergo Cyclon

Anyway, I'm on the user end of Duo support and you don't get how many users insist to have that cookie. They complain immediately, that when they can't check the box for their browser to remember them for 90days, its too inconvenient for them. They even whine this up the chain of command to then have the CISO have to allow support to permit this 90day retention.
No, not everyone uses a FIDO or fob for 2FA on this, but it becomes a frustration that you have to Duo several times in a minute for each login or access. True, some don't object as they might use a Applewatch and just touch the auth when needed. But that means another device in the ecosystem to be wary of (appstore).
I now dread that this "feature" will be removed or disabled to preserve security. Retirement can't come soon enough!
I've pretty much ruled it that when some normalcy returns to the world and businesses get open, I am rewarding my waitstaff and bartenders with my patronage. Cheers!

 

[tgx]

"After having gained administrator privileges on the infected network..."

The issue wasn't Duo. If you've got someone with admin rights parked on your network, all bets are off.

 

[fyo]

The best passwords are easy for humans to remember and hard for machines to brute-force. Phrases of unrelated words tend to be ideal.

I used to memorize random passwords like bahopre3 (one digit away from one of my old passwords that was compromised). But random numbers and symbols add entropy less quickly than just adding words.

Something like "purple dog flowers" or "social squash Augustus" is trivially easy to remember, but surprisingly difficult to brute-force. If there are 1000 common English words, then each word is about as good as 2 to 3 letters. If you use one or more obscure words, the passphrase gets radically stronger. Despite having more letters, I've found that pass-phrases are faster to type than passwords, and rather than mess with capitalization, numbers, and symbols, which are all slow to type, I prefer to just add more words.

Also, best to use a password manager so that you only need one or two actual passphrases.

LENGTH adds entropy quickly. Words have a tendency to add length.
Which is fine if you're brute forcing digit by digit/character by character, but that's not what people do.

People compile lists of common words/phrases, and then mutate them in a number of ways. (All A becomes 4, all e become 3, every other A etc.)
I wrote a parser that would take a language dictionary and dump out a bunch of the mutations pre-calculated, then concatenated in a bunch of different common methods.

Without those mutations you look at a phrase like "correct horse battery staple" and see 25 to 28 (spaces?) characters or points of entropy.

I look at a phrase like "correct horse battery staple" and I see 4 points of entropy.

Your "points of entropy" definition is odd. If by points you mean bits, then it's just wrong.

In the first example (treating pwd letter by letter), each letter/digit (is this your "point of entropy"?) can take roughly 60-90 possible different values (depending on the character set in use). Each digit in a base-10 number would have 10. The total entropy is thus 60^n, where n is password length.

In the second example, each word can take anywhere from a few thousand to a few hundred thousands of different values, leading to an entropy of 3000^n, where n here is your "point of entropy".

So your "points of entropy" cannot be compared. One "point" in one is worth a lot more entropy than one "point" in the other.

So the entropy in the first case is 60^25 = 3*10^44 bits of entropy.
In the second case just 3000^4 = 7*10^13

While certainly a massive difference, that's pretty much a worst case example (only 3000 words in our dictionary, no misspellings, no punctuation, no numbers, etc).

A completely random 16 character password with a length 60 character set has an entropy of about 3*10^28. Using just the 3000 most common words, you would need about 8 words for the same entropy.

The point being that a sentence of 8 words (letusjustgetthroughthisyearsafely) is A LOT easier to remember for most people than a completely random 16-character password. (Yes, my example didn't use caps, so shoot me.)

 

[Hacker_is_not_a_criminal]

It's not clear to me what's clever about this. "Steal the secret key" is the canonical, brute-force way to evade a security measure.

If they'd find a way to do it *without* access to the keys, it would be clever (and much more worrying.)

The clever part of this attack is maintaining persistence without any internal indication that the attacker still has access. The attacker can effectively authenticate mimicking MFA, with only one factor that they already have. There is no code, backdoor, or any other evidence that this access is owned by the attacker.

It would be difficult to find access activity in the logs as many people authenticate to email from different devices and a sophisticated attacker can probably launch attacks from within a reasonable geography. That is if one even bothered to research an unusual login when MFA was in place.

If there were a way to do this without access to the secret keys, then it would be vulnerability that would get a CVE and a patch.

Edited to add:

Carmakal said the hackers took advanced steps to conceal their actions. “Their level of operational security is truly exceptional,” he said, adding that the hackers would operate from servers based in the same city as an employee they were pretending to be in order to evade detection.

from an article on the FireEye/Solarwinds attack https://www.bloomberg.com/news/articles ... g-own-hack

 

[w_dave]

Volexity refers to the state-sponsored hacker group as Dark Halo.

"Dark Halo"? Stop giving them cool names.

Whoever came up with Cozy Bear or Fancy Bear or any of the other Care Bear names had the right idea.

 

[Ed1024]

I have to say password policy is one of my recurring gripes. At work, they insist on a time-expiring alphanumeric 8-character password: forcing you to repeatedly make (and remember) a new one is counter-productive and enforced 8-characters is laughably insecure these days.

Not a week goes by without needing to create a password to do something and it is odds-on that a reasonably secure browser-generated item will fail one or more of the arcane rules that most sites seem to require. “Must have between 9 and 11 characters”, “Can’t have more than three numbers”, “Must have one but no more than four capital letters”, “Can't have a lower-case ‘q’ in it”, ”Must be typed using only the left hand, except on Tuesdays”, etc.

I know for a fact that if I have to create a password myself, it will likely have nowhere near the entropy that an automatically generated one will of the same size, and probably include some unconscious biases that would make it orders of magnitude easier to crack.

My simple lay point-of-view from outside of the security industry is that the more artificial constraints you place on a password, the easier it becomes to determine. On the other hand, I appreciate having a rough idea of how relatively secure a particular phrase is, especially if it might be being reused or already forms part of a password database - quite a few sites seem to be implementing things like this.

 

[kasala]

Once hacked, the only safe thing to do is rebuild everything.

I agree with this in spirit and when a client of mine suffers some sort of compromise I state just this that the only way to "Guarantee" that your systems are clean is a full on rebuild from the ground up.

The reality though is that the cost to productivity, the impact to business operations, etc. wins out over doing the right thing.

In all cases but one the client has opted for the "do your best" to secure / clean up but don't wipe and reload as you should.

The silver lining though is that the clients are must less resistant to implementing proper security measures going forward once they've felt the pain of an incident. Suddenly that "$50 / month / user for a next gen endpoint protection solution isn't so painful where as before the incident the $15 per user per month for Webroot was a travesty.

 

[AxMi-24]

I have to say password policy is one of my recurring gripes. At work, they insist on a time-expiring alphanumeric 8-character password: forcing you to repeatedly make (and remember) a new one is counter-productive and enforced 8-characters is laughably insecure these days.

Not a week goes by without needing to create a password to do something and it is odds-on that a reasonably secure browser-generated item will fail one or more of the arcane rules that most sites seem to require. “Must have between 9 and 11 characters”, “Can’t have more than three numbers”, “Must have one but no more than four capital letters”, “Can't have a lower-case ‘q’ in it”, ”Must be typed using only the left hand, except on Tuesdays”, etc.

I know for a fact that if I have to create a password myself, it will likely have nowhere near the entropy that an automatically generated one will of the same size, and probably include some unconscious biases that would make it orders of magnitude easier to crack.

My simple lay point-of-view from outside of the security industry is that the more artificial constraints you place on a password, the easier it becomes to determine. On the other hand, I appreciate having a rough idea of how relatively secure a particular phrase is, especially if it might be being reused or already forms part of a password database - quite a few sites seem to be implementing things like this.

We have the same issue and I firmly blame the idiocy that is SSO. In order to remotely access all our corporate data (yeay for MS cloud, not) I have to use the same password I have to type in bazillion times every day. A password that we have to change every few months. Guess the effect. Every single person has a "password#" that is slowly incremented. Since you are typing it so often it's a simple one and there you go for security. Sure 2FA is supposedly turned on but doesn't seem to do much (only time I was asked for it was when I went to check my settings that it is in fact turned on).

In a sane world we would be using hardware 2FA (something MS still struggles with for a simple windows login). Slightly more expensive but at least it avoids the issue of super simple passwords being used for everything.

 

[kasala]

Next I need Apple and MS to fix their OS to use yubikey on login + password instead of some goddamned pin or memorized 20+ char password. Although the Apple Watch unlock is nice and hopefully equivalent. But when that fails, I want some 2nd factor action.

The pin on Windows is actually fairly secure. The pin is tied to the specific device that you set it up on and it prevents you from typing you MS Account password to login which precludes the ability of a keylogger from grabbing your password. It may get the pin however the pin is useless without the specific hardware it was configured on.

 

[cephasthelionheart]

I’m a bit confused by the writing: is this saying that Dark Halo, APT29, and Cozy Bear are all the same?

Also: I’m not managing to work out message flows for the 2FA thwart. Probably because I don’t sufficiently understand how Duo works, but the article assumes I do.

I use Duo for work. You can set it to remember a computer and then you only have to do the 2FA once a month. I believe that’s what they’re exploiting with the cookie.

 

[Ed1024]

We have the same issue and I firmly blame the idiocy that is SSO. In order to remotely access all our corporate data (yeay for MS cloud, not) I have to use the same password I have to type in bazillion times every day. A password that we have to change every few months. Guess the effect. Every single person has a "password#" that is slowly incremented. Since you are typing it so often it's a simple one and there you go for security. Sure 2FA is supposedly turned on but doesn't seem to do much (only time I was asked for it was when I went to check my settings that it is in fact turned on).

In a sane world we would be using hardware 2FA (something MS still struggles with for a simple windows login). Slightly more expensive but at least it avoids the issue of super simple passwords being used for everything.

Funny old thing, that’s what a lot of my peers do when faced with this kind of mounting inconvenience. If I were trying to break into someone’s account at my organisation, I would assume a 2-3 number prefix or postfix to a simple password. When real security is made difficult by those enforcing, it generally goes out with the bath water...

 

[Defenestrar]

Novel indeed.

These cookies are used for "Trust This Device"-type settings right, given that they had to present the username and password? If the user/organisation required a new MFA confirmation for every login would that "overcome" this particular problem?

I mean, Dark Halo still gained admin access to the network, so there's a few other problems there.

Also, I despise the Outlook Web App.

Unfortunately you must use the OWA (on Chrome) if you plan to exclusively use hardware MFA (e.g. Yubikey) via an Android device because neither Outlook for Android (or Firefox's Android browser) support FIDO2, U2F, etc... I'm still not clear why Firefox broke its mobile support for U2F or why it's taking so long to get fixed.

You are correct about the cookies though. They are usually issued after a successful MFA and set to expire after a term set by the organization's policy. The "trust me" cookies can also be set to expire based on the application used and not just the device/client as a whole.

Edit: I'm also not sure why the O365 (an Android) family doesn't support hardware U2F yet because theoretically their own internal browsers run Edge and Edge is now Chromium....

 

[unsigned]

I’m a bit confused by the writing: is this saying that Dark Halo, APT29, and Cozy Bear are all the same?

Also: I’m not managing to work out message flows for the 2FA thwart. Probably because I don’t sufficiently understand how Duo works, but the article assumes I do.

I use Duo for work. You can set it to remember a computer and then you only have to do the 2FA once a month. I believe that’s what they’re exploiting with the cookie.

Correct... with the additional info that the concept of setting a cookie for long term access is admin configurable.

For instance, in our admittedly small Duo rollout, I DON'T FUCKING ALLOW THAT.