Issue 81: Vulnerabilities in Microsoft Teams 👥, Auth0, smart home hubs

Researchers from CyberArk found a serious vulnerability in Microsoft Teams that the vendor promptly fixed.

The attack vector was how Teams handled authentication to image resources and then allowed expansion to full API access. Here’s how the scenario went in a nutshell:

1. Researches were able to take over two abandoned subdomains of teams.microsoft.com.
2. The researchers used the subdomains to host a simple GIF file that they could then send to a target user. Just the victim seeing the GIF was enough to return an authentication cookie to the attackers.
3. The researches then made an API call to exchange that cookie to an authentication token for the Teams APIs.
4. With full API access, the researchers could scrape the victim’s chat history for messages and information. They could also use the APIs to spread the attack with messages to the victim’s colleagues.

Now, since this attack did not require any interaction from the user, it could be scaled up easily without it being in anyway obvious. A co-worker suddenly spamming a GIF to everyone could raise suspicions quickly. However, a single GIF sent to a Teams group would provide the attacker authentication tokens of several users with no one batting an eye.

This is a brilliant illustration of the dangers of wildcards in URLs, token exchange, and the power that APIs can give to attackers once they get past authentication.

JSON Web Tokens (JWT) is the prevalent format of authentication tokens in modern APIs. One of the common attack vectors on JWT is forging a token and then setting the signature algorithm in the token header to alg:none. This makes poor JWT implementations blindly trust such a token and do not verify its signature. For more details on the JWT standard and JWT attack vectors, see this AppSec California session recording.

Modern tools and frameworks typically include out-of-the-box protection against this attack. However, Ben Knight found a flaw in how this protection was implemented in Auth0.

Auth0’s check for alg:none was case-sensitive. Thus attackers could go around it simply by sending alg:nonE instead. This tiny change was enough to get the check to pass and disable the signature verification, in turn allowing attackers to forge tokens.

Luckily, Auth0 has since fixed the issue. Lessons learned:

• Case-sensitive checks are dangerous
• Blacklisting (when you test for what should not happen) is more error-prone than whitelisting (when you only let through what is expecting)

Researchers from ESET have disclosed API (and other) flaws in Fibaro Home Center Lite, Homematic Central Control Unit (CCU2), and eLAN-RF-003 smart home hubs that they found.

The list of vulnerabilities includes such classics as:

• Unencrypted HTTP calls
• Unsecured APIs
• Injections in URL parameters

These cases are not exactly new: they were found and reported to vendors 2 years ago. However, the details were responsibly only published now to protect the users of unpatched models.

More opportunities to learn new things online: Curity has published a free online course, “Getting Started with OAuth and OpenID Connect“.

The course topics include:

1. Introduction to OAuth
2. OAuth vs OpenID Connect
3. Tokens and APIs
4. Server to Server Communication with OAuth
5. Design tokens for your APIs
6. Dynamic Clients and Metadata
7. OAuth for Mobile Applications
8. OAuth for Single Page Applications

Each lesson takes about 30 minutes, so they do not make a huge dent to your day, and you can slot them in when it bests suits you.