Security Bits Logo no alpha channel

Security Bits — 25 September 2022

Feedback & Followups

  • 🇺🇸 Google have gotten SEC approval to pilot their controversial political ad spam by-pass feature with a limited number of campaigns in this year’s US mid-term elections —…
  • 🇺🇸 The recent revelations of how Meta abuse in-app browsers to monitor user activities has become a US federal class action suit —…

🧯 Deep Dive 1 — Understanding the MS Teams Auth Token Weakness

The Short Version

A security company tried to make a lot of noise around a weakness it discovered in the cross-platform Microsoft Teams desktop client, which is implemented in Electron. The app, like other popular Electron apps including Slack, stores cookies on the file system, and that includes authentication cookies. If an attacker has access to your file system, they can read the user’s ephemeral Microsoft authentication token from the cookies file and theoretically use it to impersonate the logged-in user on Microsoft’s services for a while.

The security researchers attempted to drum up publicity by claiming this was an MFA (multi-factor authentication) bypass, but that’s not really accurate. To underscore why no one needs to stress about this, none of the CERTs (Cyber Emergency Response Teams) I subscribe to even bothered putting out a notification about the vulnerability, and the SANS Internet Storm Center podcast only mentioned it to say they would not be talking about it because it’s not worthy of their time!

Note that browsers and other browser-based app technologies like Electron have been storing cookies in files for years, and the world has not ended. Teams is not doing anything unusual here, and you could write the same headline about Slack, and Discord and …

The bottom line is that this is one of those “If you’ve already been hacked the attackers can also …” stories. If you’ve already been hacked you have much bigger problems, you’ve already been hacked!

The Nerdy Version

No matter how you log in to anything, once you prove to the service that you are you it its satisfaction, it will generate some kind of time-and-scope-limited token that it will return to the client as a kind of digital equivalent to a visitor’s armband in fair ground. Each time you try to access something secured, you have to produce the token.

The exact detail of the trust the service puts in a token is up to the service, but they will all have a finite lifetime (the length of your login session), and if the organisation is large enough, they might only provide access to a subset of the features.

Remember that these tokens are issued after authentication, so whether you used just a password, 2FA, MFA, or a passwordless solution like a FIDO token or a Passkey, you’ll get an auth token when you’re done. Otherwise, you’d have to re-do the login dance every time you moved from one page to the next or one app screen to the next!

The security researchers justified their hyperventilation about bypassing MFA because this token happens after MFA, so the attacker can use the token without passing MFA. The implication is that they found a flaw that goes around MFA, but they didn’t, they just found a way to steal your session after you’ve done MFA. A true MFA bypass would open every single account on the system to attack by password stuffing (trying credentials from password breaches), but this absolutely does not do that.

So, how powerful are these tokens? That depends on the servers that issue them. A really poorly written service could encode a policy that tokens are accepted on all the company’s services for years, and they can be used from any IP address at any time, with as many concurrent connections as the server can handle. A very securely written app could accept the tokens for only 5 minutes, only on a small subset of services from a single IP, and only allow a single simultaneous connection. A securely written service could also invalidate a token the moment something unexpected happens.

In reality, all services fall on a spectrum, and many offer the user configuration options.

Microsoft allows owners of Tenancies (corporate accounts) to configure the level of security they would like, and a big part of that configuration is how security tokens should be issued and trusted. Microsoft also aggressively monitor the use of the tokens they issue, and they automatically invalidate any token that’s being used suspiciously. If you examine your security logs in an Office365 tenancy that’s securely configured, you’ll see lots of notifications about sessions being terminated for ‘impossible travel’, that alert is triggered when a token appears from two IP addresses in geographically different locations with a time gap that’s too short for a human to make the journey!

So, if you are already hacked, and you have Teams installed and are logged in, the attacker can steal your current Microsoft authentication token, but if you work for an organisation that has properly configured Office365, then as soon as the attackers try to use your token Microsoft are very likely to invalidate it on the server side!


Deep Dive 2 — The Recent Uber & Lastpass Hacks

Last Pass Update

The last time we recorded details on the LastPass hack were scant, but we were pretty sure users were safe, we now know that for sure, and, we now have a much better understanding of just how good LastPass’s security posture is.

We now know the attackers got in by getting malware onto a developer’s machine, but the investigation wasn’t able to discover how the malware got in.

We already knew the end-to-end encryption designed into the system kept customer vaults safe, but we now know the attackers didn’t even get at any customer data because LastPass have designed their systems well. Most importantly (and impressively), their development network is physically segregated from their production network, and no real data is ever fed into the development network, so the attackers were trapped in a virtual sandbox with pretend data!

The detailed summary of the report from Naked Security (linked below) is well worth a read.



Uber were hacked by the LAPSUS$ group, a loud and boastful group probably consisting of a bunch of teenagers, one of which may or may not have been re-arrested shortly after the hack (as described in the excellent summary from Naked Security linked below).

Initially, we didn’t know how bad it was, and there was a lot of media coverage based on very little info. Because LAPSUS$ seem to have done this hack for bragging rights, they put a lot of effort into making their hack look as damaging as possible, and many people assumed the worst, but Uber have since released a report with their initial findings, and it seems they too have well-designed systems.

In this case, the hackers got in by targeting a contractor with a barrage of MFA notifications until they approved one. Again, this only got them into a developer network (no mention of it being physically separated from production, but it seems it was adequately separated). The attackers were able to access but not alter the source code, and to access the portal used to manage the company’s bug bounty program, but they only got details of bugs that have already been patched. Again, there was no real customer data in the dev network for them to steal.


Final Thoughts

In both cases, a good design build around defence in depth, and good data hygiene saved the day. It’s very tempting to test new code on old production data, but that’s spectacularly dangerous, and thank goodness neither of these companies were naive enough to got that route.

Older security models were built around the concept of a strong perimeter enforced by an edge firewall and a pretty free flow of traffic inside the network. That idea has massively fallen out of favour, with zero trust‘s ‘assume breach’ principle guiding modern architectures intended to keep customer data safe even when hackers manage to get past some of the defences. The new model worked in both these cases, and I’ve actually ended up with more respect for these companies after the breach than before. Like bugs, hacks will happen, the question is how companies and their systems respond, and both Uber and LastPass have come out of this looking like they know what they’re doing and are actually taking security seriously instead of just saying they are.

❗ Action Alerts

Worthy Warnings

Notable News

Interesting Insights

Palate Cleansers

  • Bart: 🎧 If the Margot/Alexi storyline in For all Man Kind fascinated you, this real-life spy story is for you: Season 2 of The Bomb podcast from the BBC
  • Bart: 🎧 Science podcaster extraordinaire Sean Carroll interviews XKCD-creator Randall Munroe: Mindscape 210 —…


When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart.

Emoji Meaning
🎧 A link to audio content, probably a podcast.
A call to action.
flag The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
📊 A link to graphical content, probably a chart, graph, or diagram.
🧯 A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
💵 A link to an article behind a paywall.
📌 A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
🎩 A tip of the hat to thank a member of the community for bringing the story to our attention.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top