Security analysts have found a severe security vulnerability in the desktop app for Microsoft Teams that gives threat actors access to authentication tokens and accounts with multi-factor authentication (MFA) turned on.
Microsoft Teams is a communication platform, included in the 365 product family, used by more than 270 million people for exchanging text messages, videoconferencing, and storing files.
The newly discovered security issue impacts versions of the application for Windows, Linux, and Mac and refers to Microsoft Teams storing user authentication tokens in clear text without protecting access to them.
An attacker with local access on a system where Microsoft Teams is installed could steal the tokens and use them to log into the victim's account.
"This attack does not require special permissions or advanced malware to get away with major internal damage," Connor Peoples at cybersecurity company Vectra explains in a report this week.
The researcher adds that by taking "control of critical seats–like a company's Head of Engineering, CEO, or CFO—attackers can convince users to perform tasks damaging to the organization."
Vectra researchers discovered the problem in August 2022 and reported it to Microsoft. However, Microsoft did not agree on the severity of the issue and said that it doesn't meet the criteria for patching.
Problem details
Microsoft Teams is an Electron app, meaning that it runs in a browser window, complete with all the elements required by a regular web page (cookies, session strings, logs, etc.).
Electron does not support encryption or protected file locations by default, so while the software framework is versatile and easy to use, it is not considered secure enough for developing mission-critical products unless extensive customization and additional work is applied.
Vectra analyzed Microsoft Teams while trying to find a way to remove deactivated accounts from client apps, and found an ldb file with access tokens in clear text.
"Upon review, it was determined that these access tokens were active and not an accidental dump of a previous error. These access tokens gave us access to the Outlook and Skype APIs." - Vectra
Additionally, the analysts discovered that the "Cookies" folder also contained valid authentication tokens, along with account information, session data, and marketing tags.
Finally, Vectra developed an exploit by abusing an API call that allows sending messages to oneself. Using SQLite engine to read the Cookies database, the researchers received the authentication tokens as a message in their chat window.
The biggest concern is that this flaw will be abused by information-stealing malware that have become one of the most commonly distributed paylods in phishing campaigns.
Using this type of malware, threat actors will be able to steal Microsoft Teams authentication tokens and remotely login as the user, bypassing MFA and gaining full access to the account.
Information stealers are already doing this for other applications, such as Google Chrome, Microsoft Edge, Mozilla Firefox, Discord, and many more.
Risk mitigation
With a patch unlikely to be released, Vectra's recommendation is for users to switch to the browser version of the Microsoft Teams client. By using Microsoft Edge to load the app, users benefit from additional protections against token leaks.
The researchers advise Linux users to move to a different collaboaration suite, especially since Microsoft announced plans to stop supporting the app for the platform by December.
For those that can't move to a different solution immediately, they can create a monitoring rule to discover processes accessing the following directories:
- [Windows] %AppData%\Microsoft\Teams\Cookies
- [Windows] %AppData%\Microsoft\Teams\Local Storage\leveldb
- [macOS] ~/Library/Application Support/Microsoft/Teams/Cookies
- [macOS] ~/Library/Application Support/Microsoft/Teams/Local Storage/leveldb
- [Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
- [Linux] ~/.config/Microsoft/Microsoft Teams/Local Storage/leveldb
BleepingComputer has contacted Microsoft about the company's plans to release a fix for the issue and will update the article when we get an answer.
Update 9/14/22 - A Microsoft spokesperson sent us the following comment regarding Vectra's findings:
The technique described does not meet our bar for immediate servicing as it requires an attacker to first gain access to a target network.
We appreciate Vectra Protect’s partnership in identifying and responsibly disclosing this issue and will consider addressing in a future product release.
Comments
xafase - 1 year ago
<p>Yesyesyes. Let us all use MFA. It is more secure. A complete pain in the ass and a waste of time, but more secure. Except when, you know, the companies making the software do the same stupid thing that they did with the passwords which is why they are pushing MFA on everyone.</p>
NoneRain - 1 year ago
xafase, not a waste of time, and really easy to use.
In most scenarios, it's a must-have to protect users. Don't confuse one bad implementation with the security standard.
TheBigBearUK - 1 year ago
What applications would / could one use to monitor for the listed directories or file accesses?
Which one under the various platforms?
Does it need different apps and setups on each OS?
Or is there even a cross-platform solution?
NoUselessTech - 1 year ago
Out of the box, Windows supports this through the audit log. Example here:
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/apply-a-basic-audit-policy-on-a-file-or-folder
For Linux, consider using auditd
For MacOs, Jamf is commonly used for enterprise deployments and supports file activity tracking/monitoring.
orid - 1 year ago
You can use CyberArk's EPM (endpoint privilege management) in order to protect against such weaknesses and much more.
It can completely block access to such sensitive files and allow access only to the process you define (MS Teams in this case).
It's not free, but worth the price, especially if you are running a business.
Trustwave - 1 year ago
In short, any EDR with decent logging and archiving capabilities should be able to detect this access (even retrospectively).
But also there are numerous agents logging all file accesses, including Microsoft ProcMon and Sysmon, or (free) FileBeat from Elastic stack.
And last but not least - the native Windows file auditing options, although the output is the most difficult to reach, parse and create automated responses...
muzso - 1 year ago
The problem is not just that Teams stores the tokens in "cleartext" (on the disk), but that it implements its own secret/credential management. The tokens should be stored via the platform's own credential management API.
E.g. on GNOME based linux distros the GNOME Keyring is pretty much the "industry standard" for storing secrets/credentials. On KDE based linux distros there's the KDE Wallet. MS Windows has its own credentials management API and so do the various Mac OSes. All popular platforms have a time-tested solution for the task, so why not use it?
Obviously these are not without fault either, but they're pretty much the best bet an application developer can take.
A quick googling revealed that there're solutions to integrate a JS/Electron app with the platform's credentials manager.
E.g. https://github.com/atom/node-keytar
And btw. since 2021 (and v15) Electron has built-in support for using the platform's credential manager to store strings securely, so you can let go of keytar's native libs. :-)
https://www.electronjs.org/docs/latest/api/safe-storage
BlueTeamJK - 1 year ago
The vuln is one thing but this hot take on Electron is nonsense - "Electron does not support encryption or protected file locations by default, so while the software framework is versatile and easy to use, it is not considered secure enough for developing mission-critical products unless extensive customization and additional work is applied".
There are many, many ways to do crypto in Javascript that can be used in Electron, and I do not even know what this comment on "protected file locations" is supposed to mean - no desktop app should be storing data in "protected file locations", presuming it means OS folders.
NoUselessTech - 1 year ago
Microsoft in particular has some locations which are protected within the User profile that even the user may not directly access. For example, the Cookies folder that is soft linked in the %UserProfile% location. This is used by Edge, as an example, to keep secure information that a standard users requires but does not typically access by intention.
In the original article, KeyTar is recommended to support system credential management.
WhatDaBleepDoWeKnow - 1 year ago
The Teams client application runs as the user, and it must be allowed to read the files that store the tokens. So any encryption or filesystem DACLs that prevent that, will only add obscurity, but no real security. Protected file locations in the userprofile directory can't block access to an application running as that user. It would just break.
Teams could store creds in the credential manager. Similar to how OneDrive does it, but OneDrive is fully embedded as part of the OS. Teams is userspace app running with Electron. It might require a complete rework.
And it would need a rework on Mac and Linux (depreciated) too, in order to store in their respective keychains.
BH0 - 1 year ago
Im amused, I can see my tokens :D
Seems like MFA is useless, when app/process is designed by marketers, not programmers. In this case, MFA is just complicating users life, while the account could be overtaken by anybody who knows the stuff. Seems almost like some sort of backdoor to me.
Thats a schoolboy error. I dont know if the original Skype platform is to blame, but this proves, that they even dont know what they are vending.
NoneRain - 1 year ago
But being realistic, if an actor compromised your user profile, I think they won't even bother going for these tokens... Anyway, MS could address this in a better way.
SecurityDev - 1 year ago
Sorry, this is a complete non-story. There is no good solution to protect data held on locally compromised computers. 'Encrypt the tokens' doesn't work, because if the attacker has local access they can just get the decrypted versions from memory. Honestly if an attacker has local access they can just install keyloggers and screen recorders and nothing you do is safe.
This is one instance where Microsoft have got their response right. This is not an issue worth addressing.
BH0 - 1 year ago
I agree with the statement, that compromised computer is not safe, but disagree with the statement that it its not worth addessing. There are parts of the OS, where user has no direct access and the data could be encrypted (with TPM) and accessed only by SYSTEM. This could heavily harden the token mining.
SecurityDev - 1 year ago
If you use TPM to encrypt the data for a local application, that local application has to be able to decrypt it again. An attacker with local access can do the same. Similar to the advice above about installing tools or adding monitoring... A suitably motivated attacker with local privileges can just disable that tooling.
The weakpoint is allowing attackers access to the local system. I'm sure we all understand that at that access level it's like a rogue agent literally sat at your logged in computer with the same privileges you have. Once they're in there's very little you can protect against.
BH0 - 1 year ago
I agree again. Now, that is where AV could help. I personally think, that acessing this folder should be monitored by default by Windows defender. Same approach as Microsoft did with editing lmhost table, that is considered as hijacking/hacking now.
WhatDaBleepDoWeKnow - 1 year ago
Windows can monitor certain files/folders for modification or deletion. But just "reading" a file is something different. The Teams client application runs as the user, and it must be allowed to read the files that store the tokens. So any encryption or filesystem DACLs that prevent that, will only add obscurity, but no real security.
npeep - 1 year ago
Would a conditional access policy forcing MFA re-auth if signing in from a non-trusted (on-prem) location catch this type of sign-in and force a new MFA prompt?
WhatDaBleepDoWeKnow - 1 year ago
No, there is no sign-in.
Using stolen session tokens basically says to the server, "I'm already signed in on a trusted device". That's how the server trusts the device, by giving them a unique token to store.
howettworks - 1 year ago
In this case I agree with the MS response, the device would have to be fundamentally comprised for an attacker to take advantage of this. Not to sweep it away, from those with Win Pro/Enterprise you can use controlled folder access to ensure only defined apps can access that directory (stopping malware getting into it). In the case of a stolen token, conditional access should help here. One would hope you wouldn't allow full rich client access on unmanaged devices (as this allows the caching of data on devices out of the organisations control) so you have continuous access evaluation and the requirement for hybrid or compliant devices will help here, as it will stop the authentication from an unmanaged device. In this case as well, having MFA as the only requirement in the CA policy will not be enough as it will be seen as an MFA sign in.
In short, this is fun to see your own sign in token if you want to see it, but you will have much bigger problems if an attacker can exploit this (i.e., they have full access to the device as it is)
BH0 - 1 year ago
"Not to sweep it away, from those with Win Pro/Enterprise you can use controlled folder access to ensure only defined apps can access that directory (stopping malware getting into it)."
Nobody will do that, the effort is not worth it. Especially when the token wont work from a different device. But usually Microsoft behaves as a savior, its interesting to see different approach.
My bet is, that similar tokens to the Microsoft Account are stored somewhere. Let the hunt begin! :D
WhatDaBleepDoWeKnow - 1 year ago
"Especially when the token wont work from a different device"
This is incorrect. The whole point of cookies and tokens like this... is that they tell the server that it's the same device that has an active session.
Session tokens can be stolen, moved to an attacker's system, and they can be logged in without going through the normal authentication process that would prompt for MFA. If an attacker would steal only passwords, then they could be blocked by MFA since the server would not know if its a different device.
WhatDaBleepDoWeKnow - 1 year ago
"controlled folder access to ensure only defined apps can access that directory"
This is incorrect. This is an anti-ransomware feature by microsoft. It cannot block read access, it only alerts and blocks attempts to modify or delete (things that ransomware does). So it won't work for protecting against data leakage.
BH0 - 1 year ago
Thank you for information. If one token is enough to steal our account, I conside those MFA poorly designed and useless.
I mean lot of FAs complicates login, but stealing is easy still. You know what I mean.
WhatDaBleepDoWeKnow - 1 year ago
"If one token is enough to steal our account, I conside those MFA poorly designed and useless."
Then MFA doesn't mean what you think it means. MFA isn't everything. MFA is a subset of Identity and Access Management (IAM). And IAM has a LOT of other functions. Authentication (whether multifactor or single factor), is only a small part of the security posture. Session management is something different.
You can blame the convenience that people demand of collaboration tools like Teams. Convenience takes priority over security of the session. Bank websites may have strict session control, logging you out every 5 minutes, with Captchas to prevent automation, forcing MFA since session tokens expire quickly... but would anyone use Teams if it did that?
If you really want to blame something, blame the lack of security on the endpoint that allows an attacker local filesystem access. Microsoft is correct. This is a "post-exploitation" issue, where the real vulnerability has already been exploited long before Teams was even targeted.
BH0 - 1 year ago
Maybe I do not understand MFA, as you stated. But same as the 99% of people using computer, I understand that it makes login more complicated, so the attacker cannot login, if he stole your password. For me, that is puprose of the MFA - not to be able to login with password only.
On one machine, if token is stored, the MFA is bypassed. The security should be done on the local device. And the "cloud" service should register, form which device the token came. If same token came from different device, then its hijacking - how easy logic is that.
WhatDaBleepDoWeKnow - 1 year ago
Tokens are a representation of "same device". The server won't know the difference between someone stealing a token file, and someone stealing your whole laptop.
BH0 - 1 year ago
I still do not understand, whats the problem in implementing simple device check together with the token. And more about Microsoft here - if it comes to other parts of their SW, they do so much about UI, Startmenu and other cosmetical things, that I do not understand this lousy security approach, while their marketing is brainwashing us, how safe their system is - the reality is different.
Andretti227 - 1 year ago
Hi,
I want to build an M365 advanced hunting query to monitor this. Does anyone know the correct combinations?
Many thanks in advanced!
BH0 - 1 year ago
I think you can start with URL parsing, it also contains tokens ;)
Andretti227 - 1 year ago
Thanks for the headsup. But what i mean is the build in Advanced hunting query builder in the Microsoft 365 defender (security) panel.
kakamayka - 1 year ago
I think that something like that. give or take
DeviceFileEvents
| where FolderPath contains "\\Microsoft\\Teams\\Cookies" or FolderPath contains "\\Microsoft\\Teams\\Local Storage\\leveldb"
| where InitiatingProcessFileName != "Teams.exe"
| where InitiatingProcessFileName <> ""
cougar99t - 1 year ago
Overblown article. MS is correct, Not a vulnerability. These tokens are the equivalent of session cookies, which have the exact same privileges and ability to be stolen and replayed. In fact, the recommended mitigation will not protect you, the browser also stores JWTs and refresh tokens, which can be pulled out using the inspect feature in chrome or any number of tools...additionally, the browser has session cookies that can easily stolen. MFA does NOT protect internal access...meaning it only works against remote logins, once you move to internal MFA offers zero protect as all logins, whether they be web, windows, SSO, etc., are converted into some sort of token which has to be accessible to the user and/or machine and therefore are subject to compromise/reuse. This is only a vulnerability if there was a way to remotely extract these creds, otherwise this is how creds are protected in all operating systems, not just windows.
BH0 - 1 year ago
I think its good to tell about security downsides too!
Recent years we all have been pushed into cloud solutions, "one-size-fits-all" accounts and other techniques, that are dependent on the internet. We all heard aanouncements like: "Cloud is safe.", "Dont be affraid, our account is protected by MFA.", ... etc. marketing, marketing, marketing..
While these announcements are partly true, all was not said! Negative voices were silenced, marked as conspirational, or overly negative. At the same time, this file described in article may not be "vulnerability" (the token wont work on a different user/device pair), it clearly shows some problems that do exist. Microsoft reaction is acceptable, they dont have time to fix that, they have to change Windows UI once again, introduce brand new calculator - lot of work has to be done before another feature update pack is released :D
cougar99t - 1 year ago
Cloud has nothing to do with this "issue," it's a product of single sign on, or not having to enter your password every time you do anything, send an email, send a message, login to a website, open a file, etc. It's ages old!!! It way outdates cloud. The machine has to store your credentials somehow so it can be reused for you. There's been some advances such as using TPMs to store them, but even those are not perfect. Solve this decades old problem and you'll easily become a multi-millionaire.
BH0 - 1 year ago
I dont think you are 100% correct. This has something to do with cloud, since SSO tokens validates accessing your cloud services.
I think humans already found the way for secure ciphering, its called asymetric type of ciphering. Alice and Bob can communicate securely, but the key distribution is the problem ;)
More about this topic in awesome Simon Singh's book - The Code Book. Really recommend this book.
WhatDaBleepDoWeKnow - 1 year ago
Yes, the article is overblown. Unfortunately some people are scared because they didn't fully understand the level of access this requires. Local filesystem access is nothing to sneeze at, and will likely compromise any browser session tokens too.
MFA has nothing to do with this. Authentication controls are not relevant since stealing an active session bypasses any and all authentication.