Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

krebsonsecurity.com

Post reply on HN
Print view View original

61–70 of 171 posts

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#61

Post by tptacek »

throwawaymath wrote: post #60
scarface74 wrote: post #49

Earlier quoted context omitted.

There is nothing wrong with using sequential ids in and of themselves. The typical web app has the concept of a validated user session per request. How hard is it really to Select ... From Documents where documentid = ? and userid = ? So even if the user does a GET /Document/{id+1} No documents would be returned. Every web framework that I am aware of let’s you add one piece of middleware that validates a user sessio…

No, nothing wrong with it intrinsically. But if UUIDs were used instead, the lack of authentication or authorization checks wouldn't be as catastrophic. That would be somewhat comparable to having a reset password token which doesn't expire. Still bad, but not as bad. The other commenter's point about leaking information is also correct. In the finance industry one of the basic tricks to obtaining alternative data is…

Having done a few assessments in the last year where I was forced to downgrade sev:hi findings because nobody is realistically going to guess a 128 bit random number, I have to grudgingly acknowledge that UUID object keys are a meaningful security improvement. Which I hate to admit, because I'm generally of the opinion that "defense in depth" is a design cop-out, and here's a pretty potent counterexample.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#62

Post by PatrolX »

jeromegv wrote: post #39
ownagefool wrote: post #18

Earlier quoted context omitted.

I've seen Retail stores with revenues in the 10s of billions using Telnet for the POS clients in 2019. They also used FTP glaore and were worried about the security of cloud. :)

Wonder how many retailers there are that make 10s of billions

Around 20-25 I believe.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#63

Post by tptacek »

sverhagen wrote: post #58
mattmanser wrote: post #44

Earlier quoted context omitted.

I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…

I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…

A securely generated 128 bit UUID isn't security-by-obscurity, but rather security-by-cryptography. It's still bad not to have authorization checks, because UUIDs can "leak" into logs, browser histories, emails, and things like that. But the security benefit of using crypto-random IDs is neither cosmetic nor superficial.

Most applications don't use UUIDs and many of them are fine and I definitely wouldn't ding an app for using monotonic IDs, but I'm increasingly thinking that it's worth praising UUIDs more.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#64

Post by tptacek »

dvlsg wrote: post #48
mattmanser wrote: post #44

Earlier quoted context omitted.

I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…

You can generate uuids that play nicer with database storage / indexing. NEWSEQUENTIALID() in MSSQL, for example. The keys will be easier to guess again, but if all you have to do is guess a primary key to get access to the underlying data, something else isn't right anyways.

Is MSSQL's NEWSEQUENTIALID secure? I didn't think it was.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#65

Post by throwawaymath »

mattmanser wrote: post #44
throwawaymath wrote: post #22

Yet another security vulnerability caused by: 1. Using sequentially incremented integer sequences as object IDs, and 2. Failing to protect sensitive data using some kind of authentication and authorization check. This is becoming a trend with data breaches. Several of Krebs' other reports on behalf of security researchers were originally identified by (trivially) walking across object IDs on public URLs. My cynical t…

I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…

Sure, that's fine. The context of my point about IDs is for user-facing APIs. Note that user-facing really means "publicly accessible", even in the case of private APIs. As I mentioned elsewhere, market research groups will be happy to extrapolate as many metrics as they can from your APIs integer object IDs.

That being said I'm a little surprised to hear about the complexity. Are you able to share which DB/stack you were using? This functionality should be natively supported at two distinct abstractions: your programming language and your database.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#66

Post by morpheuskafka »

sverhagen wrote: post #58
mattmanser wrote: post #44

Earlier quoted context omitted.

I once made an app not using sequential integers as object ids, as you suggest. It was an absolute nightmare. Maintenance was a nightmare, you're constantly having to generate or replicate these things that add an extra layer of complexity to everything, and almost always unnecessarily. It's also extremely bad for db performance, causes massive page fragmentation, indexes become useless almost straight after rebuildi…

I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…

I don't think it's really fair to call it security by obscurity. The UUIDs have far more entropy than 99.9% of user passwords protecting them.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#67

Post by angry_octet »

Whenever you are compelled to upload/send a photocopy of an ID document it is sensible to write the date and purpose / file reference on it. If it appears in a document dump at some later date you know the path and date of the leak.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#68

Post by tptacek »

eganist wrote: post #56
tptacek wrote: post #55

Earlier quoted context omitted.

Yeah, no, I think you got this wrong, but more than that I was motivated to comment by the implication you made that these were "easy to miss" vulnerabilities because bullshit security tools that don't work miss them. I don't so much care whether you're right or wrong, but I do want to take every opportunity I can get to disabuse people about the effectiveness of scanners.

> "easy to miss" vulnerabilities because bullshit security tools that don't work miss them > I do want to take every opportunity I can get to disabuse people about the effectiveness of scanners. This entire exchange is frustrating because it's exactly what I said in my root comment: > these are also some of the easiest vulnerabilities to miss even with out-of-the-box static analysis (code scanning and data analysis),…

You "stepped away from the keyboard", and then edited your comment. I read what you wrote differently than you appear to have intended. It is fine if we simply disagree about this. If you think scanners suck too, we might just not have anything worth arguing about.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#69

Post by throwawaymath »

tptacek wrote: post #61
throwawaymath wrote: post #60

Earlier quoted context omitted.

No, nothing wrong with it intrinsically. But if UUIDs were used instead, the lack of authentication or authorization checks wouldn't be as catastrophic. That would be somewhat comparable to having a reset password token which doesn't expire. Still bad, but not as bad. The other commenter's point about leaking information is also correct. In the finance industry one of the basic tricks to obtaining alternative data is…

Having done a few assessments in the last year where I was forced to downgrade sev:hi findings because nobody is realistically going to guess a 128 bit random number, I have to grudgingly acknowledge that UUID object keys are a meaningful security improvement. Which I hate to admit, because I'm generally of the opinion that "defense in depth" is a design cop-out, and here's a pretty potent counterexample.

I agree with you. Let me emphasize this explicitly: the real failure here is the utter lack of authn and authz. But it is meaningful that the integer IDs are being used.

Re: First American Financial Corp. Leaked Hundreds of Millions of Insurance Records

#70

Post by sverhagen »

tptacek wrote: post #63
sverhagen wrote: post #58

Earlier quoted context omitted.

I also don't think using UUIDs as a security (by obscurity) strategy is valid. But there are other reasons someone may choose to use UUIDs. For instance, it's convenient to generate identifiers in a decentralized manner. I want to counter your one bad experience with my (equally anecdotal) many-multiple good experiences. Databases do just fine with UUIDs. Though we may be working on different kinds of systems, and op…

A securely generated 128 bit UUID isn't security-by-obscurity, but rather security-by-cryptography. It's still bad not to have authorization checks, because UUIDs can "leak" into logs, browser histories, emails, and things like that. But the security benefit of using crypto-random IDs is neither cosmetic nor superficial. Most applications don't use UUIDs and many of them are fine and I definitely wouldn't ding an app…

If you know the (integer) identifier, and because the bad application isn't secured with authentication, you get access to something you're not supposed to. If you make the identifier a lot harder to know, and you still have no security, that smells like the obscurity part. I can absolutely see your point that the UUID identifiers are not just a lot harder to guess, they may be impossible to guess. But the security is still bad, and I don't think that the impossible to guess-property of the UUIDs should be a substitute for security. I don't think we really disagree, though.
Post reply on HN