Hacker News Reader

Comment by MauranKilom | Hacker News Reader

I still don't understand what the author means with his exploits (also against Instagram[0]) involving a race condition.

A race condition means that something unexpected happens when you do something concurrently. Not "it gives the same result as when done one by one, but we're doing it faster" (which is what the author appears to be doing). It has to be different from the result any sequential operation could achieve.

They used a few thousand IPs to hammer an endpoint, staying below the per-IP rate limit. Did it matter that this was done during the same time from all the IPs? If yes, it's not clear from the blog post how/why it mattered. If no (i.e. the result is the same when first completing all requests from the first IP, then the second, etc.), then it is not a race condition - just concurrency.

[0]: https://thezerohack.com/hack-any-instagram

View on HN

From my understanding, there is a hard limit on how many attempts are allowed for entering the code for a specific account, regardless of the IP address. You can bypass that limit by sending all the attempts concurrently at once. The multiple IP addresses were used to bypass a different limit (a limit on concurrent connections).

A slightly more detailed answer than the other two you got:

It's likely a well-designed password (or similar) validation endpoint will both limit attempts per IP and per user, to avoid exactly the attack you describe.

This limit probably isn't permanent (though I think the design of Apple's HSM may be different here; too many attempts may lock or delete user data entirely?). Rather, it would be something like "allow 5 attempts per hour per user."

So, first, even if the attacker only exploits concurrency to speed things up--which implies the limits are only per IP--they can conduct attacks which are otherwise infeasible. (E.g. with 10k IPs at 5 attempts per hour per IP, they can brute force a six digit PIN in an average of an hour, as opposed to over a year.)

But second, what I think the attacker is describing is actually worse: he's saying that the quota "counter" is updated with a "read-modify-write pattern that's not safe for concurrent HTTP requests, so that you might have something like:

[request 0] read counter value = 0 [request 1] read counter value = 0 [request 0] set counter value = 1 [request 1] set counter value = 1

In this error, the counter is never incremented at all.

It's easy to imagine people making this mistake when they store the counter in something that does not support transactional updates.

> a well-designed password (or similar) validation endpoint will both limit attempts per IP and per user

I hope you‘ll never have to reset your password then as I‘ll happily send out those 5 requests every hour to lock you out ;-)

This is also a kind of attack.

The rate limit per IP cam be lower than per user to make this more difficult; you can also offer other options (captchas, less brute-forceable auth factors).

Not sure your point on “resetting” passwords, though. This applies to any validation flow, i.e. just logging in.

The race condition he was referring to might be that if you go fast enough at making requests, you can make more requests than the request limit.

Reply on news.ycombinator.com