Comment by bsuvc
5 days ago
It sounds like there were two separate problems:
The first was that 123456 was the credentials for the admin panel.
The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.
> It sounds like there were two separate problems:
> The first was that 123456 was the credentials for the admin panel.
No. 123456 was the credentials for the test setup, which contained nothing. But you could use the IDOR to access data from the test setup.
If 123456 had been the credentials to the admin panel, there would have been no point in exploiting an IDOR - as an admin, you can just look at whatever you want.
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.
Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.
Defense in depth is a thing, so even if you make a mistake in one place, and the attacker gets complete access - as what happened with the McApplicaton here - they won't be able to download your entire db within minutes. Even with zero authentication, non-guessable identifiers will slow down the exfiltration by several factors from dozens/hundreds of records per second to one record per $MANY_DAYS, with lots of 404s for the defenders to look at.
> That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs)
The additional friction of acquiring the UUIDs from a different channel is beneficial to defenders, compared to decrementing or incrementing IDs, which is trivial to do, and doesn't need RCE. It's the difference between "All users' data was exfiltrated" and "Only a couple/handful of accounts were affected", and this can make or break the breached company.
I think I disagree with "totally fine"... Even if that were true though, this case is definitely a point where you wouldn't want to give away information with a numeric ID. Giving away # of applications/growth of that over time is definitely business information that arguably should not be discernible.
The point is not that UUIDs are magically secure, it's that they mean nothing to whoever gains access except a single job app. The assumption is that they will get out (they're in a public URL), and that they will have no meaning when they do.
It's a defense-in-depth thing IMO -- cargo-culting this approach defends you even when you don't do the other things right. It's simple -- with a non-zero probability that the actual access control is faulty, do you want a default that protects you or doesn't. What's the intentional trade we're going for? More DB perf? Easier to type URLs? There are other ways to deal with those
> Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
Yes :(
Yes it makes very little difference if I can see all your public published blog posts on a WordPress site by iterating the number.
1 reply →
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
You could also "just" have an internal-use only numeric ID, or use a UUIDv7.
6 replies →
Not impossible, just more difficult to guess.
"Security through obscurity" isn't really good enough.
Yes and…
UUIDs aren’t “just more difficult to guess.” They are inconceivably harder to guess.
> Put another way, one would need to generate 1 billion v4 UUIDs per second for 85 years to have a 50% chance of a single collision.
11 replies →
Yes, you are technically right -- I should have said "functionally impossible". It's not actually impossible, but close enough for the average random onlooker.
123456 was both the username & password, they were hit by CWE-1392 because someone failed to change the default credentials.
The writeup never claimed that 123456:123456 were default credentials?
I've read more than just this particular writeup. See also: https://ian.sh/mcdonalds
> During a cursory security review of a few hours, we identified two serious issues: the McHire administration interface for restaurant owners accepted the default credentials 123456:123456, and an insecure direct object reference (IDOR) on an internal API allowed us to access any contacts and chats we wanted. Together they allowed us and anyone else with a McHire account and access to any inbox to retrieve the personal data of more than 64 million applicants.