Using a phone number for password reset seems like a terrible idea in general, especially if you have SMS-based 2FA. Phone numbers are way to easy to social engineer, and if your second factor can reset your first one, you don't have 2FA.
Also if I am reading it correctly, it sounds like the rate limiting was being done per-IP, which sounds strange. Why wouldn't Instagram just allow a fixed number of tries (some low limit, like 25) from any IP before invalidating the code? I don't really see a scenario where it makes sense to have per-IP rate limiting here. I guess they are probably just using the rate limiting features which are built in to whatever framework Instagram is using for their API.
> Also if I am reading it correctly, it sounds like the rate limiting was being done per-IP, which sounds strange.
Seems to me that the main mistake was not rate limiting per account right? If you get 200k password requests for a single user something is severely wrong.
Or maybe they did and it didn't work, he makes reference to a race condition in the original post but doesn't elaborate.
Also for people who don't have mobile phone signal at home (hello us), it's almost impossible to use these 2FA systems. There are a few systems including the UK government's own "Verify" scheme for submitting tax returns that I quite literally cannot use.
Not that mobile phone 2FA is actually secure. Fraudsters in the UK have discovered that it's possible to take over phone numbers rather easily because that relies on the phone companies' own systems which are (predictably) insecure.
> Why wouldn't Instagram just allow a fixed number of tries (some low limit, like 25) from any IP before invalidating the code?
This could makes it very easy to perform a DOS attack against a user. You could constantly send failed attempts and make it impossible for the user to type in the real code before you invalidate it.
I have turned off phone 2FA on all services that permit me to do so after getting hacked by someone using that exploit. Typically I use Google 2FA via Authy or Authy itself
I used to work at a cell phone company. One day I needed to change my SIM card so I call up the help desk :
"Hi I have a new SIM card, can you please activate it?
— Sure what's your number and IMSI?
— My number is ..., the IMSI is ...
— OK done"
And so, just like that, I took over someone else's phone number. Not on purpose, but the guy made a mistake punching in my number, didn't verify my identity, and ended up assigning someone else's phone number to my SIM card. I called the guy back after realizing that I wasn't getting calls and that the people I called thought I now had a new number.
Granted it was a while ago but the experience gave me a very low opinion of SMS for 2FA.
The first type of attack that should come to mind with SMS-based 2FA is SIM cloning. Identity question answers can be purchased off the dark web from previous leaks. Also, social engineering is notoriously effective against several of the top carriers, who lack effective identity validation. Lives have been ruined.
Is this reset mechanism conceptually flawed? Even with one attempt before invalidating the code, you have a 1:999,999 shot of stealing someone's account by lotto. Not bad odds for an automated process.
It's like every account on Instagram has an alternative six digit password.
You are right. Betting everything on a 6 digit code surely is a mistake. For example, try same code on a million different account, and you definitely get access to atleast 1 of them. (Considering they are using a good random generator)
Sony was using 8 characters of alphanumeric at one point. They reduced it to 6 digits. It turns out that the chance of guessing six digits successfully given one or two tries only is low enough to satisfy human beings when it comes to “annoyance versus protection”, especially when codes expire after a couple attempts.
I spot-checked some of those IPs in the video, and it appears all of them are on Amazon. So, what does the attacker's stack look like? Is it a bunch of servers running PHP and listening for a connection to run curl? Or Lambda functions configured to proxy the connection attempt to IG? Curious how much effort goes into setting up an attack like this. It's surprising (to me) that so many IPs can be used for so little money.
I've done scraping distributed over many IPs. I used luminati, bought X IPs, ran a bash script to download all IPs to a file, read the file in from python and spit out a new thread for each IP. Just used as a proxy, all activity was controlled by a single server.
Re Amazon, I've done that too and the way it works is you start up an EC2 instance that does the work and sends back info. In my case I sent the info to an S3 bucket and then pulled all the info from that bucket elsewhere once all the machines finished. Ultimately you pay for what you use, and if you only use an hour across a ton of machines and use the cheapest machine it's pretty cheap.
FYI: luminati will give you unlimited bandwidth for like $1/IP/month.
I quite recently learnt about “Residential proxies”, for a scraping idea I had. Seems like that can be useful for attacks like this.
It’s surprisingly cheap to get access to services which fan out your requests over millions of normal residential IPs, making them (I assume) hard to block.
Of course their use can be highly objectionable, as well as how they got the proxies installed in homes of people in the first place (semi-malware?)
Pretty interesting that distributed circumvention of rate limiting has to be considered its own class of vulnerability nowadays. I would think (of course) many other services are vulnerable. Rate limiting is hard.
Could someone explain how this person is allowed to do that type of testing (sending 200,000 requests)? How would Facebook know he is a white hat and not a black hat?
I would be interested in starting to try some of these programs, but a bit scared I'd be doing something illegal... Where is the line?
The actual "bug" is that Facebook did not have sufficient controls in place to even detect this type of brute-force attack, much less make it impossible to attempt in the first place. Facebook seems (IN THIS INSTANCE) to have appreciated the white-hat nature of this and awarded the bug bounty, but it very well might not have. And certainly other organizations don't take nearly as friendly stances. Generally, I wouldn't bet on most organizations seeing brute-force attacks as in-scope for bug bounties - this is by no means legal advice though.
They have a bug bounty program that gives you permission to do certain kinds of things and it not be illegal since you’re planning to report anything you find (and get paid for it)
So a bit of a strongly worded title. I'm going to nitpick for a second.
First you need the device-id, second you need the code that will be sent via text.
The code sent via text is 6 digits meaning 10^6 == 1MM permutations. He shows how he can enumerate these using 1K IP's ultimately bruteforcing the reset code.
The Device ID is still not captured although I'm guessing they allow handwaving via a malicious app or something of that nature.
Credit where credit is due, he cleverly enumerates them concurrently across 1K IP's and earned his bonus.
Interested how they fixed it...guessing adding a random session guid in the url and maybe increasing entropy && length of the secret.
Seems like a lot of improvements could have been made here. After you get the code wrong, it should reset and send you a different code. If you get more than 3 wrong in some pre-determined time, it should lock the person out for some other pre-determined time. You could even use exponential backoff time in both scenarios. Keeping the code the same after getting it wrong just seems really stupid.
Mathematically, does regenerating the code make a lot of difference?
You can simulate that by running a loop that generates a random 4-digit number in each iteration and randomly guessing it.
On average, you will guess the number after 10,000 iterations. It doesn't help that you regenerate the number each time. Your chance is still 1/10,000.
Nice find, but the original author has no idea what race condition means. This isn't race condition, it's just brute force combined with per ip rate limiting avoidance.
[+] [-] GhostVII|6 years ago|reply
Also if I am reading it correctly, it sounds like the rate limiting was being done per-IP, which sounds strange. Why wouldn't Instagram just allow a fixed number of tries (some low limit, like 25) from any IP before invalidating the code? I don't really see a scenario where it makes sense to have per-IP rate limiting here. I guess they are probably just using the rate limiting features which are built in to whatever framework Instagram is using for their API.
[+] [-] CPLX|6 years ago|reply
Seems to me that the main mistake was not rate limiting per account right? If you get 200k password requests for a single user something is severely wrong.
Or maybe they did and it didn't work, he makes reference to a race condition in the original post but doesn't elaborate.
[+] [-] rwmj|6 years ago|reply
Not that mobile phone 2FA is actually secure. Fraudsters in the UK have discovered that it's possible to take over phone numbers rather easily because that relies on the phone companies' own systems which are (predictably) insecure.
[+] [-] dahfizz|6 years ago|reply
This could makes it very easy to perform a DOS attack against a user. You could constantly send failed attempts and make it impossible for the user to type in the real code before you invalidate it.
[+] [-] pmarreck|6 years ago|reply
[+] [-] ridaj|6 years ago|reply
"Hi I have a new SIM card, can you please activate it?
— Sure what's your number and IMSI?
— My number is ..., the IMSI is ...
— OK done"
And so, just like that, I took over someone else's phone number. Not on purpose, but the guy made a mistake punching in my number, didn't verify my identity, and ended up assigning someone else's phone number to my SIM card. I called the guy back after realizing that I wasn't getting calls and that the people I called thought I now had a new number.
Granted it was a while ago but the experience gave me a very low opinion of SMS for 2FA.
[+] [-] mncolinlee|6 years ago|reply
[+] [-] gjs278|6 years ago|reply
[deleted]
[+] [-] someexgamedev|6 years ago|reply
It's like every account on Instagram has an alternative six digit password.
[+] [-] mkagenius|6 years ago|reply
[+] [-] floatingatoll|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] thefreeman|6 years ago|reply
[+] [-] degenerate|6 years ago|reply
[+] [-] ikeboy|6 years ago|reply
Re Amazon, I've done that too and the way it works is you start up an EC2 instance that does the work and sends back info. In my case I sent the info to an S3 bucket and then pulled all the info from that bucket elsewhere once all the machines finished. Ultimately you pay for what you use, and if you only use an hour across a ton of machines and use the cheapest machine it's pretty cheap.
FYI: luminati will give you unlimited bandwidth for like $1/IP/month.
[+] [-] hmate9|6 years ago|reply
I always find it weird that if I accidentally enter the wrong code, I get to try again instead of being sent a new one.
[+] [-] np_tedious|6 years ago|reply
Beyond that, definitely should regenerate / resend. This is to confirm you own that phone number. It's not hard to get another
[+] [-] filleokus|6 years ago|reply
It’s surprisingly cheap to get access to services which fan out your requests over millions of normal residential IPs, making them (I assume) hard to block.
Of course their use can be highly objectionable, as well as how they got the proxies installed in homes of people in the first place (semi-malware?)
E.g https://oxylabs.io/pricing/residential-proxy-pool
[+] [-] CPLX|6 years ago|reply
This is a euphemism right? Like what they're really saying is that this service would make it possible to fake ad traffic right?
[+] [-] sbarre|6 years ago|reply
They claim 30M residential IP addresses.. How would this be done otherwise?
There's no info on the site about "signing up" to be a proxy, just about using them..
[+] [-] deanclatworthy|6 years ago|reply
[+] [-] tuna-piano|6 years ago|reply
I would be interested in starting to try some of these programs, but a bit scared I'd be doing something illegal... Where is the line?
[+] [-] btown|6 years ago|reply
[+] [-] stibba|6 years ago|reply
[+] [-] jakecraige|6 years ago|reply
[+] [-] Swaglord333|6 years ago|reply
[+] [-] ryanlol|6 years ago|reply
[+] [-] paulpauper|6 years ago|reply
[+] [-] dane-pgp|6 years ago|reply
[+] [-] georgiecasey|6 years ago|reply
[+] [-] _57jb|6 years ago|reply
First you need the device-id, second you need the code that will be sent via text.
The code sent via text is 6 digits meaning 10^6 == 1MM permutations. He shows how he can enumerate these using 1K IP's ultimately bruteforcing the reset code.
The Device ID is still not captured although I'm guessing they allow handwaving via a malicious app or something of that nature.
Credit where credit is due, he cleverly enumerates them concurrently across 1K IP's and earned his bonus.
Interested how they fixed it...guessing adding a random session guid in the url and maybe increasing entropy && length of the secret.
[+] [-] T1glober|6 years ago|reply
A 0day RAT for android was hitting about 500 devs per second before getting fixed.
[+] [-] fortran77|6 years ago|reply
[+] [-] rdtwo|6 years ago|reply
[+] [-] jumbopapa|6 years ago|reply
[+] [-] herpderperator|6 years ago|reply
[+] [-] hkai|6 years ago|reply
You can simulate that by running a loop that generates a random 4-digit number in each iteration and randomly guessing it.
On average, you will guess the number after 10,000 iterations. It doesn't help that you regenerate the number each time. Your chance is still 1/10,000.
[+] [-] rwmj|6 years ago|reply
[+] [-] miyuru|6 years ago|reply
https://code.fb.com/production-engineering/legacy-support-on...
[+] [-] yardstick|6 years ago|reply
[+] [-] eitland|6 years ago|reply
[+] [-] odensc|6 years ago|reply
[+] [-] w8rbt|6 years ago|reply
[+] [-] Hitton|6 years ago|reply
[+] [-] thtthings|6 years ago|reply
The user will need to use a different way to authenticate if they can't enter the correct code in 5 tries
[+] [-] rileymat2|6 years ago|reply
[Obvisouly, there are ways just easy to screw up]
[+] [-] AgentME|6 years ago|reply
[+] [-] ape4|6 years ago|reply
[+] [-] mychael|6 years ago|reply
Facebook should know better.
[+] [-] bhandziuk|6 years ago|reply