Emma from Marketing heard that the company started using a cool app that used artificial intelligence (AI) to improve the text of that press release she’s working on. “That’s exactly what I need to finish this thing and go home! So amazing, my awesome company bought it for everyone,” she thinks. “Where’s the App Store icon? Aha. What’s the name?-something like… downloading!” Everything looks great so far. Next, the app asks Emma to sign in. “Username/password or sign-in with Google?” are the options (Emma’s company uses Google Workspace, like many SMBs.) Emma is too smart to enter her username and password to some random app. She remembers that mandatory boring security training video. “Sign-in with Google is more secure!”
Oh no! The app doesn’t do what Emma expected. Oh, and someone has access to Emma’s account!
Facebook recently published a warning about malicious apps, apps that are pretending to be useful but actually designed to steal user accounts. This attack is not new. Google’s YouTube is frequently attacked too. Is this limited to social networks and creators? No. The same thing could (and does) happen to Google Workspace users who accidently download malicious apps.
One of the largest recent attacks against Enterprise Identity Access Management solutions used that exact technique. I’m talking about Lapsus$, of course: “Lapsus$ victim and authentication firm Okta said 2.5 percent of customers were affected in its own Lapsus$ attack.”
I wanted to elaborate a little on the nuance of what’s happening, the lessons of this attack, and how they apply to enterprise identity and access management.
How does it work?
The article explicitly says the malicious app will probably ask you to “sign in with Facebook in a safe and secure way.” You might wonder, “if it’s so secure, and I didn’t even enter my username/password, what’s the issue?” That’s what Emma from Marketing also thought. Well, the app is after something else. It’s after her session cookie.
When the user opens the app, say “Ads Pages Manager”, it asks the user to sign in. The moment the user does that, and regardless of how they did it, the app steals the session cookie.
What’s a session cookie?
The HTTP protocol is stateless. That means that for every request, the server must look at that one request and fulfill it every time you load or refresh a page. But we need a state. So, for example, when we authenticate to Facebook or Google, we want the server to know and remember who we are so that we don’t need to authenticate every time we navigate a site or refresh the page.
“Session cookies” solve that problem.” A small piece of data is stored on the client – your browser. The data was put there by the server, and the client is responsible for sending it every time it makes a request.
A session cookie is an identifier. “Hey, Facebook! Can you GET the page that shows how my ads campaign going? Oh, BTW, I’m Emma. I entered my password yesterday, and you gave me a certificate to store in my Cookie store for the next few days so that I can prove to you who I am. Thanks!”
Having a Session Cookie bypassed any checks, like password, 2FA, or device policy… That’s why the hackers are after your cookie!
Why doesn’t the attacker just ask for the user/pass?
First, most users don’t know their passwords. So, asking for the password is unnecessary friction for the attacker. Hackers worry about ease of use, too, you know.
And most password managers have “Phishing protection”, which prevents auto-filling credentials in the wrong places.
So, why does FB ask users to change their password if it was never stolen?
When you change your FB password FB revokes all session cookies issued with the old password, including the stolen cookies. That requires some form of re-authentication and rendered the stolen cookies useless.
What about 2FA? why does the article recommend I enable that?
2FA will not stop this attack, no matter how hard some Enterprise vendors try to claim their 2FA is a panacea. That’s why these attacks are becoming popular. 2FA is working and hackers have to find another way. So, you absolutely should enable it!
What can we do better?
Let’s boil this down into Prevention, Detection, and Response.
- Can we make this problem go away? Session cookies can be stolen in most scenarios and protocols. The difference is the scalability, the “attack surface,” i.e., how easy it is for the attacker to target 1, 10, or 100,000 employees. The good news is that this attack is hard to scale because MFA is becoming more prevalent – good job on enabling 2FA, you!
- This attack is a type of malware. So, we need to ensure our endpoints are clean. Many will tell you to lock down your front door, trust nobody, make sure your employees only use a sterile phone, laptop, and network… Let’s be honest; not everyone is ready for that uphill battle. Maybe you’re a 100 or 500-person startup. Is this the right time? We’ve all been or heard what happens when it goes wrong. Employees start to hate IT. Work slows down. IT drowns in support tickets of users getting locked out. And all the new tools and people are expensive! Employees hate it, especially the remote ones. Plus, it’s often distracting from your company’s core mission! I get it. We’ve been there. That’s why we created YeshID…
- Let’s see what better, even if not perfect, looks like. Let’s optimize for are faster-detection and faster response.
- WebAuthN, the north star of getting rid of passwords, recommends implementing a counter to detect some variations of this attack. Still, adoption is problematic, especially with the emerging cross-platform keys.
- Some service providers implement the counter within the session cookie — the thing that’s being stolen. This requires a lot of maintenance and has many issues I won’t get into now. But it helps! The question is: does your IAM implement it?
- WebAuthN recommends each RP figure it out. (RP, Relaying Party, is a server providing access to a secure software application.) That makes sense. WebAuthN is a password replacement, not an identity management protocol. But it also speaks to the complexity of the issue.
- SAML has Single Logout (SLO). It’s the opposite of Single Sign-in (SSO). SLO simply means that the Identity Provider (IdP, part of IAM) can push to all the services you SSO’ed to via SAML to tell them to invalidate a credential. That’s an excellent feature! It’s too bad that SAML kinda sucks at being human-friendly. Plus, there’s that expensive sso.tax… seriously! Check out sso.tax. You’re spending a lot more for SAML.OIDC’s (OpenID Connect, the authentication protocol behind “Sign in with Google/Facebook/Apple/etc.) workaround is a very short session half-life. For example, Google Workspace allows admins to set sessions as short as 1 hour before requiring re-authentication and can also differentiate between first-and-thirty party applications for a little less friction.