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

71–80 of 171 posts

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

#71

Post by eganist »

tptacek wrote: post #68
eganist wrote: post #56

Earlier quoted context omitted.

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

> I read what you wrote differently than you appear to have intended.

I really appreciate this as this at least concludes that a miscommunication took place, thank you. I'll accept that there's likely a bit too much flourish to what I write for the sake of targeting nuanced clarity.

> If you think scanners suck too, we might just not have anything worth arguing about.

Largely yes, but I do think they have their place. I view them more as platforms to build upon or add to (e.g. custom data rules or enforcing the use of specific best practices) than generalized security salves, but as you'd pointed out, many of those objectives can also be achieved through much simpler means, e.g. just grep the code for things as a commit test.

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

#72

Post by OrgNet »

snovv_crash wrote: post #13

At some point people will realise that holding large quantities of sensitive information is a liability, not an asset. Mindsets are slowly changing in this direction already. The chickens will continue to come home to roost until people treat digital security as seriously as physical security.

do you think digital security will ever be possible?

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

#73

Post by throwawaymath »

jeromegv wrote: post #40
throwawaymath wrote: post #23

Earlier quoted context omitted.

Depending on how weak those credentials were, this sounds like something you should report to Krebs as well.

I mean the whole point of that company hiring someone to do a penetration test is to be sure this doesn't end up on Krebs. You pretty much lose your reputation if the company thinks you will go around and leak what you found out through that private investigation.

Good point, I jumped the gun a bit there. I misread the comment and thought they meant the firm didn't do anything about a pentest result, not that they found it themselves.

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

#74

Post by dmix »

> He said anyone who knew the URL for a valid document at the Web site could view other documents just by modifying a single digit in the link.

Good thing he didn't post this bug online after getting no response. I remember reading about someone who did that on an AT&T website a while back and was sent to jail for simply incrementing an id number in the URL and talked about it on Twitter.

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

#75

Post by edoceo »

throwawaymath wrote: post #69
tptacek wrote: post #61

Earlier quoted context omitted.

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.

One reason I I couldn't say it better myself when I'm speaking to management that makes these kinds of decisions. Now I can quote throwawaymath verbatim to drive the detailed point home.

Thanks!

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

#76

Post by asher »

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…

One path is to use sequential ints internally and encrypt them externally with something like idgen:

https://pypi.org/project/idgen/

That provides IDs that are both opaque and, if you want, user-friendly.

(disclaimer: I wrote it.)

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

#77

Post by throwawaymath »

sverhagen wrote: post #70
tptacek wrote: post #63

Earlier quoted context omitted.

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 i…

That's not what people usually mean by "security by obscurity" when they critique the concept. Unfortunately the term is overloaded so it's lost its way over time.

To illustrate this for you, let me turn it around a bit. Is it security by obscurity if the only thing stopping someone from logging into your account is knowing your password?

Security by obscurity is when you (for example) roll your own cryptosystem and rely (in whole or part) on the secrecy of your new-fangled algorithm to save you. That is unsafe. But if you're saying high-entropy strings shouldn't be the only barrier to authentication, you're throwing out half a century of complexity theoretic cryptography.

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

#78

Post by tptacek »

throwawaymath wrote: post #77
sverhagen wrote: post #70

Earlier quoted context omitted.

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 i…

That's not what people usually mean by "security by obscurity" when they critique the concept. Unfortunately the term is overloaded so it's lost its way over time. To illustrate this for you, let me turn it around a bit. Is it security by obscurity if the only thing stopping someone from logging into your account is knowing your password? Security by obscurity is when you (for example) roll your own cryptosystem and…

Another pretty direct comparison would be to 128-bit secret bearer tokens, on which a huge portion of the industry relies.

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

#79

Post by PatrolX »

throwawaymath wrote: post #69
tptacek wrote: post #61

Earlier quoted context omitted.

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.

> I agree with you. Let me emphasize this explicitly: the real failure here is the utter lack of authn and authz.

Bingo.

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

#80

Post by pointytrees »

scarface74 wrote: post #59
birken wrote: post #54

Earlier quoted context omitted.

Maybe not "wrong", but there are some very obvious downsides to exposing sequential IDs vs a randomized token: - It exposes the count you have of a particular item - It exposes your growth rate of those items - If a developer accidentally breaks your authentication (or somebody hacks it), it becomes trivially easy to download all your items very quickly And it isn't like using a randomized token is hard. In the most…

In that simple scenario. What are some ways that a hacker could break your front end API to allow it to serve requests for multiple users without having access to multiple account logins? I understand that they could possibly get access to your database but that’s a different threat. If they could somehow change your code, all hope is already lost. But I do agree with it does allow someone to determine rate of growth…

In my experience, many tables don't have a userid on the table that would be associated with the user. It would be a table join or two or three away.

So the developer may think it is safe to say select value from stock positions left join account on account.id = stock position.id left join user_accounts on user_accounts.accountid == account.id left join users on user_accounts.userid == user.id where user.id == session.userid.

Safe right? We checked userid. But then clicking on the position to drill in on the position data, they just select * from stock_position where stock_position.id = params.stock_id... there's no "and stock_position.userid" on that table, and the developer might be too lazy to spin up the entire join again especially if you don't need account data for this view. Whoops, suddenly a vulnerable page query.

I imagine there are other ways to screw up. Like insecure cookies, and just checking cookie.userid, ah yes, you're the right user. Whoops, didn't realize cookies could be spoofed.

Post reply on HN