Blog: Fortigate CVE-2023-27997 (XORtigate) in the eyes of the owl
Third LastPass Hack
Published on
Update 06/01/2022: SSO, how it works with LastPass and how to check on Azure
LastPass has been hacked for the 6th time (3rd time this year) and this time your secrets are out!
(No, not really 😉)
LastPass is an online, cloud password vault hosted by the eponymous company. The idea is good: you have one place to store your passwords, accessible from anywhere and, in theory, secured. This allows you to have different passwords for each web site and all very strong (long and random). Well that’s if you really follow all the best practices 😉.
Normally, a secured password vault requires a secret (a so-called master key/password) to unlock (decrypt) all the other passwords. Therefore, the password vault editor does not know your secrets. Note that since you enter your password (or master key) on the LastPass portal, in reality they have it, it’s just that in theory , they don’t record it 😉. If an attacker manages to inject JavaScript into the web page of LastPass (or any other online safe), he will have your master key.
LastPass and Cybersecurity
These last years :
- 2019, vulnerability to potentially steal passwords of all users but fortunately little used https://www.forbes.com/sites/daveywinder/2019/09/16/google-warns-lastpass-users-were-exposed -to-last-password-credential-leak/
- 2020 Vulnerability in Almost All Password Vault Providers https://www.tomsguide.com/news/password-manager-hacks
- Christmas 2021, hacking of part of the accounts by brute force on the LastPass portal https://www.bleepingcomputer.com/news/security/lastpass-users-warned-their-master-passwords-are-compromised/ and https://news.ycombinator.com/item?id=29705957
August 2022, LastPass developer hacked and stolen source code and developer information but not customers https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/ . LastPass had communicated that no customer data had been stolen and that all was well “Move on, nothing to see”.
November 2022, intrusion into LastPass thanks to information recovered in August but no access to customer data. Moreover, the parent company of LastPass, the company “Go to” had published a press release that it had made “unindexable” to prevent search engines from indexing it and therefore avoid bad buzz. This is what you can see here with the “noindex” metadata:
view-source:https://web.archive.org/web/20221130211551/https://www.goto.com/blog/our-response-to-a-recent-security-incident In this press release it was indicated that customer data had still not been accessed <<Move around, there’s still nothing to see>>.
December 2022, leak of backups of user password vaults stored on online (cloud) storage. These backups contain:
- The names of companies and/or users, unencrypted;
- Billing information including addresses, unencrypted;
- Emails, phone numbers, connection IP addresses, etc., unencrypted;
- Vault with:
- General information (names of sites, web addresses/URLs, etc.), unencrypted,
- Secret information (passwords, notes, etc.), encrypted.
The press release: https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/
Risk ?
If you are a LastPass customer, attackers have your personal information and the URLs of sites whose passwords you store in LastPass. But do not panic ! Your passwords are (in theory 😉) encrypted with a key, derived from your master key by PBKDF2. This algorithm will make several rotations (iteration) in order to make obtaining the key used very slow. This would give: MySecret –rotation-> $D_è2 »to –rotation-> %M0»_$ –…-> The real key used to encrypt/decrypt From what I read, there would be 100,100 rotations (iterations). This therefore makes the operation very slow, several hundred milliseconds. The goal is to limit dictionary or exhaustive (brute force) attacks. For example, with the big machine we use to crack passwords, we are not able to crack a password longer than 8 characters, protected by PBKDF2 (with AES256) if we test all the possibilities (https://patrowl.io/casser-des-condensats-de-mots-de-passe-sans-violence/). On the other hand, from a dictionary, it takes between 1 and 5 days.
If an attacker wants to decrypt your vault, they’ll be more likely to use the passwords they already have for you (found in other data leaks) and then potentially a dictionary.
The risk is limited unless:
- Your master key is used elsewhere;
- You have a master key of less than 8 characters.
On the other hand, the attackers will surely carry out initial attacks on these safes, break part of them then resell this data leak to others, who will do the same then resell or give away the data… and this will end up happening on forums like breached.co or others and everyone will have access to them.
I won’t go into detail here, but with your name, your email, your phone number, an attacker can carry out several types of attacks ranging from phishing to attempts to circumvent your strong authentication via “SIM Swapping” (https ://patrowl.io/lauthentication-forte-cest-bien-quand-elle-est-securisee-cest-mieux/).
What to do ?
Do not panic
As I said: don’t panic 😉
Changing the vault provider (from LastPass to another) does not really make sense unless you want to host yourself because today, it is LastPass that is hacked, but tomorrow? By the way, do you know if the others have not already been hacked?
In your place, I would make a simple and reassuring communication to explain the problem.
I would suggest the following course of action:
- I would ask those with a weak master key or one used elsewhere to plan (by trusting them…):
- Quickly (within 5 days), a change of all passwords associated with accounts without strong authentication,
- On January, a change of all passwords.
- I would ask those with a strong master key to plan a gradual change of all passwords stored in LastPass, within 6 months (see below).
SSO
The diagram below describes how SSO works with LastPass:
Here are the details for Microsoft Azure but I imagine it’s quite similar with other identity providers.
For each user account, an extended attribute is added containing a K1 secret of 44 random characters (I hope 😉) mixing lowercase, uppercase, numbers and special characters.
This attribute can only be consulted as an administrator from Microsoft Graph with a request of this type:
The result will look like this, with the LastPass extension that can be found with its id “com.lastpass.keys” and containing the key K1 in “LastPassK1” (with anonymized values 😉 ):
{
"@odate.context": "https://graph.microsoft.com/v1.0/users/$metadata#users(id,displayName, mail,mobilePhone,extensions())/$entity",
"id": "9ac4e0f4-5477-4198-a1e8-81029e149be9",
"displayName": "Bob Smith",
"mail": "bob.smith@company.com",
"mobilePhone": "+33123456789",
"extensions@odate.context": "https://graph.microsoft.com/v1.0/$metadata#users('9ac4e0f4-5477-4198-a1e8-81029e149be9')/extensions",
"extensions": [
{
"@odate.type": "#microsoft.graph.openTypeExtension",
"extensionName": "com.lastpass.keys",
"LastPassK1": "*** clef secrete k1 ***", // <---- la clef K1
"id": "com.lastpass.keys"
}
]
}
A second K2 secret is stored at LastPass, elsewhere than where the stolen safes were… I hope so 😉. The 2 secrets are combined, iterated (see below with PBKDF2) and the result is the key to decipher the safe. The combination is made as follows: Base64( SHA256( K1 xor K2 )) The explanations are here (page 12 and 13 for Azure): https://support.lastpass.com/download/lastpass-technical-whitepaper
Why 2 secrets? Perhaps to avoid a compromise of the vault in the event of a compromise of an Azure account, an Azure admin account or LastPass, because to achieve this, you would then have to hack both Azure and LastPass.
Why change in 6 months?
It is defined at random but there is a chance that by then, safes have given way and/or have landed on several market places. In addition, password best practices now recommend very long passwords with a long life cycle too 😉. This is to avoid the famous changes every 30 days with users who only increment a number at the end: Toto1, Toto2, Toto3…
I recommend the ANSSI guide: << For accounts that are not very sensitive, imposing an expiration period that is too short (3 to 6 months for example) can be counterproductive>>, page 30 https://www.ssi.gouv.fr/guide/recommandations-relatives-a-lauthentication-multifactor-and-aux-mots-de-passe/
The recommended times are:
- Non-sensitive accounts, no limit but I would still recommend a maximum of 2 years (ANSSI Guide page 30, R24).
- Privileged accounts, duration between 1 and 3 years (ANSSI Guide page 30, R25).
And above all, you must use a second authentication factor such as a one-time code (OTP), a notification on the smartphone… (https://patrowl.io/lauthentification-forte-cest-bien-quand-elle-est-securisee-cest-mieux/)
Let’s say 6 months, to change passwords, this can fall into the life cycle defined above 😉. Knowing that changing passwords is restrictive because no site offers the same interface, the same system or standardized API.
Good luck to you and Merry Christmas 😉.
