API-02 Broken Authentication

Broken Authentication can refer to a number of vulnerabilities, while they may seem different at first the thread that ties these flaws together is their target – an APIs authentication mechanism. These attacks, fundamentally, allow an attacker to login to a victims account, the how can be quite different though!

APIs are a common target for authentication attacks because they often use a stripped down login system when compared to traditional web applications. With many having a single API key or JWT to identify a user. Even those with traditional username/password authentication mechanisms may be a victim to a credential stuffing attack or brute force attempts.

If you missed the last blog post Suzy’s Social is a new micro-blogging platform, users can write short-medium length posts, these posts can have comments or be shared with other users. 

A user on Suzy’s Social, our victim Viv has been a victim of an attack on another website. Unfortunately Viv isn’t good at remembering passwords and isn’t familiar with password managers, she knows she should have a unique password for every website so instead she adds a number on the end. Suzy’s Social grew quickly though and they haven’t added abuse mechanisms like captchas or rate limiting. Within a few minutes our attacker Adam sets up a brute forcing attack with Viv’s password from the other breach and then every number starting from 1. Adam notices the API returns false if the username or password is wrong, but returns a token if it is correct, it only takes a few seconds for him to try 1,000s of passwords automatically before finding hers and gaining access to her account. 

After he gains access he notices that the token starts with `eyJ` and he realises that this is a JWT. He tries editing the final part of the JWT, the signature, this ensures that only someone who knows the secret (the developers) can generate new tokens. However, after some testing he realises that the web application isn’t checking this signature and he is able to edit the parameter username in the payload. After editing this he is no longer logged into Viv’s account but another user! After exploring the API he realises he could also change an email to his own without confirming the change with a password, permanently taking over an account so the victim can never use that account again.

Due to the complexity of APIs and the fact they often use different authentication mechanisms it’s important to fully understand the login flow, and consider how an attacker could achieve an account takeover or privilege escalation during development. While APIs may not be public and intended for third party developer use, you should consider any API requests and responses public.

There are lots of different flaws this vulnerability covers, so it’s important to be aware of the authentication standards in use, instead of trying to build your own from scratch. When investigating standards ensure that you enable any security mechanisms such as verifying JWTs signatures, account lockouts for repeated unsuccessful login attempts, password rules to help users set a strong password. 

Harold Bell

Harold Bell is the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.

All Harold Bell posts All of Harold Bell's posts