6 ms·

Microsoft Teams stores auth tokens as cleartext in Windows, Linux, Macs

62 points by DemiGuru 4y ago

hkgjjgjfjfjfjf 4y ago
yrro 4y ago
> 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. Big deal? They can also read all sorts of stuff out of ~/.config, or my Kerberos tickets out of $KRB5CCNAME, or my tokens out of ~/.kube/config, or my MS Graph/Azure access tokens out of ~/.azure/accessTokens.json! I guess Microsoft agrees: > 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. > 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. Hold on, can't the same attacker now read my access tokens out of ~/.mozilla/firefox or ~/.config/chromium? > 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. While I wholeheartedly agree with anyone advising people to ditch the awful Microsoft Teams... why not just switch to the browser version, as already advised? This is what MS are advising users to do anyway... [additional] I'm still dreaming of a world where Flatpak runs every app as a separate UID and SELinux domain, to prevent the above attacks.
- azalemeth 4y ago
  Exactly. I think the only time this matters if you have read permissions on a machine you shouldn't have and want to get access to other SSO-related network resources.
- kevingadd 4y ago
  While that's true, they could be placed in secure credential storage instead. The Ripcord chat client for Discord and Slack uses Windows's secure credential storage, for example, so I can't easily extract its saved credentials and to clear them I go to the Credential Manager under Control Panel. Mozilla VPN and my GitHub credentials are both in Credential Manager instead of a dotfile as well. The recommendation that a browser is safer seems pretty silly though. As far as I can tell no web browser uses secure credential storage.
  - deleted 4y ago
    [deleted]
  - tux3 4y ago
    This seems like a fundamental problem, if you store a secret locally, you can read it locally. I was skeptical/curious how Windows's Credential Manager could have gotten around that, but Stackexchange says this (https://security.stackexchange.com/a/120001/76848 https://security.stackexchange.com/a/120001/76848): > The Windows Credential Manager is anything but secure. It's "secure" at the user account level, which means that any process that the user ever runs and the user themselves must necessarily be trusted in order to call this system "secure" with a straight face. So this should be about as secure as Chrome or Firefox's storage. A small layer of obfuscation to deter the least motivated script kiddies, but nothing that changes the nature of the problem. If you store secrets under your user account, then programs running under your user account can also read them back.
    - yrro 4y ago
      B-b-but the Windows Credential Manager asks me to authenticate before it shows me the value of any saved passwords! It must be secure, right?
    - Xylakant 4y ago
      It’s true that protecting against processes running under the users account is hard, but exploiting that would require code execution Accessing a secret in a file does not necessarily. It could be stored on a network share, included in a backup or archive or an attacker could confuse a program into handing them the file. Especially that used to be a very common attack against browsers.
- zinekeller 4y ago
  I think that the solution is to make it a non-issue: fingerprint the machine and make sure that the auth tokens are only usable on that specific machine... but this solution is both a privacy nightmare and a flimsy deterrent (especially on Linux, somewhat on Windows, might actually work on Macs though). I agree with Microsoft that it's a non-issue: there's no concept of a separate user-inaccessible data compartment unlike with Android and iOS, so the best they could do is to store it in system-provided keychain (but usually it is often unlocked during log-in, defeating its purpose).
  - gw99 4y ago
    Actually there is Credential Guard which in concept does this. But Microsoft only use this for Kerberos/Domain stuff and it's only supported in Enterprise Edition. They only don't support this because Windows is market segmented and Microsoft have fuck all product management and direction that isn't run by an army of crack smoking monkeys.
  - zhengyi13 4y ago
    > there's no concept of a separate user-inaccessible data compartment Would a TPM serve here, in some hypothetical world where folk were willing to put in the work to do this? Or I guess I'm asking, naively, what are the functional differences between the TPMs on our desktop/laptop machines, and what smartphones have in them?
    - zinekeller 4y ago
      It could work but in Windows you generally need administrator privileges to touch TPM. > Or I guess I'm asking, naively, what are the functional differences between the TPMs on our desktop/laptop machines, and what smartphones have in them? A security processor on mobile devices are usually actually like TPM and Intel SGX combined together. I won't say it's better than PC TPMs, but have a very different design.
    - yrro 4y ago
      At some point Teams has to ask the TPM to unseal its encrypted copy of the access token. At that point an attacker can read the communication between Teams and the TPM, or it can read the token straight out of Teams' memory space.
- Genbox 4y ago
  > Hold on, can't the same attacker now read my access tokens out of ~/.mozilla/firefox or ~/.config/chromium? You are correct. There is no such thing as "multiple OS-level controls". In Google Chrome on Windows, the cookies in question are stored in an SQLite database at '%localappdata%\Google\Chrome\User Data\Default\Network\Cookies'. The cookie is named TSAUTHCOOKIE and contains an authentication token. There is the same level of protection on this file, as there is on the Microsoft Teams Cookies database. Source: I build forensics investigation tools for a living.
- Macha 4y ago
  Since on most systems the only two users are root/admin and the user's personal account, they could also just read it out of the process as well
- insane_dreamer 4y ago
  the AWS CLI similarly stores your access credentials in ~/.aws/credentials. If you have logged-in local system access to a user's computer, there's a lot more you can get than their Teams token
  - outworlder 4y ago
    Which is why one should avoid handing off AWS keys and secrets to people. Add SSO, then you will only have ephemeral keys.
    - CoolCold 4y ago
      Any good articles to start with?
- arjvik 4y ago
  Looks like you're using Kerberos in a corporate setting? Purely out of curiosity, what does that look like? Is the entire company's authentication infrastructure based on Kerberos? Is it used only for access to development infrastructure? Do you make use of the more "advanced" features of Kerberos like forwarding tickets for something like deployment/CI? Until now, I genuinely thought Kerberos was used mostly only by MIT.
  - AndrewDucker 4y ago
    Windows has used Kerberos as its authentication mechanism since Windows 2000.
  - yrro 4y ago
    Active Directory uses Kerberos for authentication, it's safe to say it's pretty widely used outside of MIT. :) Our user accounts live in an AD DS. We use FreeIPA (actually Red Hat Identity Management) to manage a second domain for Linux stuff. There is a trust between the domains so that users can log into systems with their AD credentials. It all works pretty well; most of my frustrations with the system are because of AD's limitations (chiefly, lack of built-in MFA; awful documentation; lack of decent tooling for creating keytabs & configuring resource-based constrained delegation, seriously, I can't believe how bad the AD admin tools are) and flaws in how we have configured AD (obsolete protocols and ciphers still in use; the trust is one-way so users on Windows machines can't authenticate to services in the FreeIPA domain). This is for logging on to end user devices & accessing servers. Web apps we don't configure (any more) to use LDAP for authentication, rather OpenID Connect (against Azure AD, the confusingly similarly named service from MS, that syncs user accounts from AD DS). Where web apps want access to Kerberos-protected resources, we have some... interesting... setups to allow web apps to use constrained delegation to impersonate the users who have logged in (and this is another thing about AD DS that surprises me... it's incredibly easy to create a service principal that can impersonate any user when authenticating to a resource, including highly privileged users... there's nothing anywhere near as flexible as FreeIPA's Service Constrained Delegation mechanism, that can say "this service can impersonate anyone in group A to resource B") CI/CD is a bit too advanced of a concept for our AD audience :), we just keep an eye on the platforms and products that our users use & make sure they're doing the right thing with respect to token handling, etc.
Genbox 4y ago
The files in question[1] are only readable by the current user. That is the default for files stored in the user's folder. I just checked my own installation and the files does have the correct permissions. Having tokens in clear text is not a serious security issue as long as the files cannot be accessed by anyone else. The best way of storing credentials today is to either: A. Use asymmetric cryptography and store the private keys in a non-exportable format like the Trusted Platform Module. B. Use an API like the Data Protection API in Windows and store the secrets under "User scope". This encrypts the secrets with the user's logon password. Only solution A above protects against malware running as the current user, however, the solution is also not very portable and technically difficult to maintain across platforms. There is no way Microsoft (or any other software vendor on the market today) can truly protect against credential stealing if malware is running in the context of the user. The exception is solution A above, but even then the attacker would have brief access to the remote systems as long as the user is concurrently using those systems. [1] https://www.vectra.ai/blogpost/undermining-microsoft-teams-security-by-mining-tokens https://www.vectra.ai/blogpost/undermining-microsoft-teams-s...
- JohnFen 4y ago
  > Having tokens in clear text is not a serious security issue as long as the files cannot be accessed by anyone else. Conceptually true. However, you cannot guarantee that the files can't be accessed by anyone else. I think that storing any critical data in cleartext is a Bad Thing because it eliminates a layer in a layered defense stance, and layered security is always desirable.
icy 4y ago
Doesn't Docker also do something similar at ~/.docker? This isn't all too egregious as long as the permissions are set to allow only the current user to rw it.
ComputerGuru 4y ago
felixrieseberg 4y ago
> Electron does not support encryption or protected file locations by default Jesus, this article is wrong on so many levels. Electron is fundamentally a way to build cross-platform apps with C, C++, and web technologies. It supports anything the operating system supports. I like 1Password's secure starter kit: https://github.com/1Password/electron-secure-defaults https://github.com/1Password/electron-secure-defaults
grnmamba 4y ago
"It rather involved being on the other side of this airtight hatchway", as one Microsoft blogger would say.
psanford 4y ago
Chrome has an entry in their FAQ about why this type of attack is specifically excluded from its thread model: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- https://chromium.googlesource.com/chromium/src/+/master/docs...
pornel 4y ago
macOS sets the bar higher than leaving stuff readable by anything run by the current user. Applications are supposed to store secrets in the Keychain, which will give them back only to the same application with code signed by the same developer. macOS applications can't steal each others' secrets willy-nilly.
smcleod 4y ago
Why was this flagged? It's interesting and a serious security risk.
- josephcsible 4y ago
  Because it's not a serious security risk, and the article is deceptively making it sound like it is to get more clicks. Consider this: while you're at home asleep, do you keep your car keys locked in a safe, or do you leave them sitting on a table/dresser/nightstand? Most people do the latter, and it's not a serious security risk since the door into your house is locked.
  - smcleod 4y ago
    I could be wrong but disagreeing with an article isn't really a reason to flag the submission. That analogy doesn't hold up, getting access to a network is usually something done remotely - not by forced entry, with the amount of things running on a network it's only a matter of time until something gets owned, phones home and next thing you know you have someone with a shell on your network. Electron has _serious_ security problems and as it's footprint grows so does the risk profile.
    - josephcsible 4y ago
      A shell that's just on your network isn't good enough to exploit this. The attacker would need a shell on your computer, either running as you or as an administrative user. And given that, your data isn't safe anyway even if it weren't in cleartext.
      - DemiGuru 4y ago
        What I think you're missing is the possibility of using these tokens as an attack vector in this case - social engineering. Impersonating a senior manager or a C level entity. So while on the surface you can say that the risk is minimal this can be damaging to a business provided you impersonate the "right" person.

62 points by DemiGuru 4y ago

yrro 4y ago

> 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. Big deal? They can also read all sorts of stuff out of ~/.config, or my Kerberos tickets out of $KRB5CCNAME, or my tokens out of ~/.kube/config, or my MS Graph/Azure access tokens out of ~/.azure/accessTokens.json! I guess Microsoft agrees: > 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. > 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. Hold on, can't the same attacker now read my access tokens out of ~/.mozilla/firefox or ~/.config/chromium? > 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. While I wholeheartedly agree with anyone advising people to ditch the awful Microsoft Teams... why not just switch to the browser version, as already advised? This is what MS are advising users to do anyway... [additional] I'm still dreaming of a world where Flatpak runs every app as a separate UID and SELinux domain, to prevent the above attacks.

azalemeth 4y ago
Exactly. I think the only time this matters if you have read permissions on a machine you shouldn't have and want to get access to other SSO-related network resources.
kevingadd 4y ago
While that's true, they could be placed in secure credential storage instead. The Ripcord chat client for Discord and Slack uses Windows's secure credential storage, for example, so I can't easily extract its saved credentials and to clear them I go to the Credential Manager under Control Panel. Mozilla VPN and my GitHub credentials are both in Credential Manager instead of a dotfile as well. The recommendation that a browser is safer seems pretty silly though. As far as I can tell no web browser uses secure credential storage.
- deleted 4y ago
  [deleted]
- tux3 4y ago
  This seems like a fundamental problem, if you store a secret locally, you can read it locally. I was skeptical/curious how Windows's Credential Manager could have gotten around that, but Stackexchange says this (https://security.stackexchange.com/a/120001/76848 https://security.stackexchange.com/a/120001/76848): > The Windows Credential Manager is anything but secure. It's "secure" at the user account level, which means that any process that the user ever runs and the user themselves must necessarily be trusted in order to call this system "secure" with a straight face. So this should be about as secure as Chrome or Firefox's storage. A small layer of obfuscation to deter the least motivated script kiddies, but nothing that changes the nature of the problem. If you store secrets under your user account, then programs running under your user account can also read them back.
  - yrro 4y ago
    B-b-but the Windows Credential Manager asks me to authenticate before it shows me the value of any saved passwords! It must be secure, right?
  - Xylakant 4y ago
    It’s true that protecting against processes running under the users account is hard, but exploiting that would require code execution Accessing a secret in a file does not necessarily. It could be stored on a network share, included in a backup or archive or an attacker could confuse a program into handing them the file. Especially that used to be a very common attack against browsers.
zinekeller 4y ago
I think that the solution is to make it a non-issue: fingerprint the machine and make sure that the auth tokens are only usable on that specific machine... but this solution is both a privacy nightmare and a flimsy deterrent (especially on Linux, somewhat on Windows, might actually work on Macs though). I agree with Microsoft that it's a non-issue: there's no concept of a separate user-inaccessible data compartment unlike with Android and iOS, so the best they could do is to store it in system-provided keychain (but usually it is often unlocked during log-in, defeating its purpose).
- gw99 4y ago
  Actually there is Credential Guard which in concept does this. But Microsoft only use this for Kerberos/Domain stuff and it's only supported in Enterprise Edition. They only don't support this because Windows is market segmented and Microsoft have fuck all product management and direction that isn't run by an army of crack smoking monkeys.
- zhengyi13 4y ago
  > there's no concept of a separate user-inaccessible data compartment Would a TPM serve here, in some hypothetical world where folk were willing to put in the work to do this? Or I guess I'm asking, naively, what are the functional differences between the TPMs on our desktop/laptop machines, and what smartphones have in them?
  - zinekeller 4y ago
    It could work but in Windows you generally need administrator privileges to touch TPM. > Or I guess I'm asking, naively, what are the functional differences between the TPMs on our desktop/laptop machines, and what smartphones have in them? A security processor on mobile devices are usually actually like TPM and Intel SGX combined together. I won't say it's better than PC TPMs, but have a very different design.
  - yrro 4y ago
    At some point Teams has to ask the TPM to unseal its encrypted copy of the access token. At that point an attacker can read the communication between Teams and the TPM, or it can read the token straight out of Teams' memory space.
Genbox 4y ago
> Hold on, can't the same attacker now read my access tokens out of ~/.mozilla/firefox or ~/.config/chromium? You are correct. There is no such thing as "multiple OS-level controls". In Google Chrome on Windows, the cookies in question are stored in an SQLite database at '%localappdata%\Google\Chrome\User Data\Default\Network\Cookies'. The cookie is named TSAUTHCOOKIE and contains an authentication token. There is the same level of protection on this file, as there is on the Microsoft Teams Cookies database. Source: I build forensics investigation tools for a living.
Macha 4y ago
Since on most systems the only two users are root/admin and the user's personal account, they could also just read it out of the process as well
insane_dreamer 4y ago
the AWS CLI similarly stores your access credentials in ~/.aws/credentials. If you have logged-in local system access to a user's computer, there's a lot more you can get than their Teams token
- outworlder 4y ago
  Which is why one should avoid handing off AWS keys and secrets to people. Add SSO, then you will only have ephemeral keys.
  - CoolCold 4y ago
    Any good articles to start with?
arjvik 4y ago
Looks like you're using Kerberos in a corporate setting? Purely out of curiosity, what does that look like? Is the entire company's authentication infrastructure based on Kerberos? Is it used only for access to development infrastructure? Do you make use of the more "advanced" features of Kerberos like forwarding tickets for something like deployment/CI? Until now, I genuinely thought Kerberos was used mostly only by MIT.
- AndrewDucker 4y ago
  Windows has used Kerberos as its authentication mechanism since Windows 2000.
- yrro 4y ago
  Active Directory uses Kerberos for authentication, it's safe to say it's pretty widely used outside of MIT. :) Our user accounts live in an AD DS. We use FreeIPA (actually Red Hat Identity Management) to manage a second domain for Linux stuff. There is a trust between the domains so that users can log into systems with their AD credentials. It all works pretty well; most of my frustrations with the system are because of AD's limitations (chiefly, lack of built-in MFA; awful documentation; lack of decent tooling for creating keytabs & configuring resource-based constrained delegation, seriously, I can't believe how bad the AD admin tools are) and flaws in how we have configured AD (obsolete protocols and ciphers still in use; the trust is one-way so users on Windows machines can't authenticate to services in the FreeIPA domain). This is for logging on to end user devices & accessing servers. Web apps we don't configure (any more) to use LDAP for authentication, rather OpenID Connect (against Azure AD, the confusingly similarly named service from MS, that syncs user accounts from AD DS). Where web apps want access to Kerberos-protected resources, we have some... interesting... setups to allow web apps to use constrained delegation to impersonate the users who have logged in (and this is another thing about AD DS that surprises me... it's incredibly easy to create a service principal that can impersonate any user when authenticating to a resource, including highly privileged users... there's nothing anywhere near as flexible as FreeIPA's Service Constrained Delegation mechanism, that can say "this service can impersonate anyone in group A to resource B") CI/CD is a bit too advanced of a concept for our AD audience :), we just keep an eye on the platforms and products that our users use & make sure they're doing the right thing with respect to token handling, etc.

Genbox 4y ago

The files in question[1] are only readable by the current user. That is the default for files stored in the user's folder. I just checked my own installation and the files does have the correct permissions. Having tokens in clear text is not a serious security issue as long as the files cannot be accessed by anyone else. The best way of storing credentials today is to either: A. Use asymmetric cryptography and store the private keys in a non-exportable format like the Trusted Platform Module. B. Use an API like the Data Protection API in Windows and store the secrets under "User scope". This encrypts the secrets with the user's logon password. Only solution A above protects against malware running as the current user, however, the solution is also not very portable and technically difficult to maintain across platforms. There is no way Microsoft (or any other software vendor on the market today) can truly protect against credential stealing if malware is running in the context of the user. The exception is solution A above, but even then the attacker would have brief access to the remote systems as long as the user is concurrently using those systems. [1] https://www.vectra.ai/blogpost/undermining-microsoft-teams-security-by-mining-tokens https://www.vectra.ai/blogpost/undermining-microsoft-teams-s...

JohnFen 4y ago
> Having tokens in clear text is not a serious security issue as long as the files cannot be accessed by anyone else. Conceptually true. However, you cannot guarantee that the files can't be accessed by anyone else. I think that storing any critical data in cleartext is a Bad Thing because it eliminates a layer in a layered defense stance, and layered security is always desirable.

icy 4y ago

Doesn't Docker also do something similar at ~/.docker? This isn't all too egregious as long as the permissions are set to allow only the current user to rw it.

ComputerGuru 4y ago

felixrieseberg 4y ago

> Electron does not support encryption or protected file locations by default Jesus, this article is wrong on so many levels. Electron is fundamentally a way to build cross-platform apps with C, C++, and web technologies. It supports anything the operating system supports. I like 1Password's secure starter kit: https://github.com/1Password/electron-secure-defaults https://github.com/1Password/electron-secure-defaults

grnmamba 4y ago

"It rather involved being on the other side of this airtight hatchway", as one Microsoft blogger would say.

psanford 4y ago

Chrome has an entry in their FAQ about why this type of attack is specifically excluded from its thread model: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- https://chromium.googlesource.com/chromium/src/+/master/docs...

pornel 4y ago

macOS sets the bar higher than leaving stuff readable by anything run by the current user. Applications are supposed to store secrets in the Keychain, which will give them back only to the same application with code signed by the same developer. macOS applications can't steal each others' secrets willy-nilly.

smcleod 4y ago

Why was this flagged? It's interesting and a serious security risk.

josephcsible 4y ago
Because it's not a serious security risk, and the article is deceptively making it sound like it is to get more clicks. Consider this: while you're at home asleep, do you keep your car keys locked in a safe, or do you leave them sitting on a table/dresser/nightstand? Most people do the latter, and it's not a serious security risk since the door into your house is locked.
- smcleod 4y ago
  I could be wrong but disagreeing with an article isn't really a reason to flag the submission. That analogy doesn't hold up, getting access to a network is usually something done remotely - not by forced entry, with the amount of things running on a network it's only a matter of time until something gets owned, phones home and next thing you know you have someone with a shell on your network. Electron has _serious_ security problems and as it's footprint grows so does the risk profile.
  - josephcsible 4y ago
    A shell that's just on your network isn't good enough to exploit this. The attacker would need a shell on your computer, either running as you or as an administrative user. And given that, your data isn't safe anyway even if it weren't in cleartext.
    - DemiGuru 4y ago
      What I think you're missing is the possibility of using these tokens as an attack vector in this case - social engineering. Impersonating a senior manager or a C level entity. So while on the surface you can say that the risk is minimal this can be damaging to a business provided you impersonate the "right" person.