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

41–50 of 171 posts

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

#41

Post by bloopernova »

client4 wrote: post #12

I did a penetration test for $NATIONALINSURER and they had an FTP site with weak credentials where all the remote offices uploaded claims. Millions of records and scans of SSNs, home addresses, bank information, etc. Their mitigating controls were: we put it behind a firewall. Then again I didn't expect much, their MSSQL in prod had SA/SA credentials active.

I'm currently fighting against management dragging their feet on using 2FA.

On HIPAA PHI.

(I know HIPAA doesn't actually mandate 2FA, but it's recommended by many best practices and guides.)

Apparently some tech folks don't like the inconvenience of 2FA.

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

#42

Post by stochastic_monk »

mediocrejoker wrote: post #28
munk-a wrote: post #16

Earlier quoted context omitted.

While everyone here says "Oh that's terrible!" the market says "Oh that's terr-SQUIRREL" and then forgets it ever happened. Additionally, no appropriate fines have been levied nor jail time handed out for this sort of thing - right now the sane approach (money wise) is just occasionally have a breech and offer up an apology.

That's what everyone (including myself) said after Equifax but just this week their credit rating was downgraded by Moody's: https://www.darkreading.com/attacks-breaches/moodys-downgrad...

The market shouldn’t be the only entity responsible for punishing this kind of massive damage.

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

#43

Post by CyanLite2 »

PatrolX wrote: post #25
raesene9 wrote: post #10

Earlier quoted context omitted.

I don't think there will be, we're well into "breach fatigue" territory now, and here there's not even currently any evidence of malicious use. Unless/until this breach results in a large financial hit to the company (possibly via a class action suit) I doubt it'll have any impact and I'm not even sure a class action suit could show damages without evidence of misuse.

Equifax's costs as a result of their breach have exceeded $1 billion now, and Moody's downgraded them a couple of days ago. I suspect this is going to hit First American pretty hard.

Doubt it. There's no evidence yet that FA's leak was used by malicious hackers. The breach was discovered by some random other person who typed in a different parameter to a URL. Very likely that no one else would've known about it.

Whereas the Equifax situation was intentionally breached by attackers and it can be assumed that the breach was used to capture information for later sale.

I suspect that First American knew about this earlier this week and intentionally did a garbage dump on a Friday evening on Memorial Day Weekend. Maybe trade down a few tenths of a percent on Tuesday and their CISO will probably get axed. Nothing to see here, move along.

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

#44

Post by mattmanser »

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 rebuilding them, etc.

For almost everything, sequential int IDs are fine. It's the things you expose to the users that you need to be careful with, and then don't use the primary key to access them, add another unique key to them, but keep the id in there for the db to use and for your own use.

My lesson was to go back to always using int ids, and on a few objects have a separate unique key column to expose to users for sensitive stuff.

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

#45

Post by r00fus »

mediocrejoker wrote: post #28
munk-a wrote: post #16

Earlier quoted context omitted.

While everyone here says "Oh that's terrible!" the market says "Oh that's terr-SQUIRREL" and then forgets it ever happened. Additionally, no appropriate fines have been levied nor jail time handed out for this sort of thing - right now the sane approach (money wise) is just occasionally have a breech and offer up an apology.

That's what everyone (including myself) said after Equifax but just this week their credit rating was downgraded by Moody's: https://www.darkreading.com/attacks-breaches/moodys-downgrad...

Equifax should have been fined billions not just had a credit downgrade.

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

#46

Post by kitotik »

stochastic_monk wrote: post #42
mediocrejoker wrote: post #28

Earlier quoted context omitted.

That's what everyone (including myself) said after Equifax but just this week their credit rating was downgraded by Moody's: https://www.darkreading.com/attacks-breaches/moodys-downgrad...

The market shouldn’t be the only entity responsible for punishing this kind of massive damage.

It shouldn’t, but currently is and I have seen 0 signs of any change in direction.

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

#47

Post by tptacek »

bryant wrote: post #37
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…

(It's apparent that my initial reply didn't resonate, so I've made substantial edits to my reply for clarity's sake. If you've read it once, give it another read; it's from the angle of an organization with much in the way of legacy impairment.) > Yet another security vulnerability caused by... I mean, yes, but these are also some of the easiest vulnerabilities to miss even with out-of-the-box static analysis (code s…

There are no effective static source code security analyzers. Static analyzers aren't a bad thing to add to a CI pipeline, because why not, but anyone depending on static analysis is playing to lose.

This is absolutely not the kind of vulnerability that pentests tend to miss; rather, they're the first thing pentesters check for. You can miss bugs like this when they're in obscure backend features and your client or team didn't document the project adequately --- though you still shouldn't, and that's part of the point of getting an assessment, to find stuff like that --- but you generally don't miss them in an assessment where the bug is literally "edit a number in a URL".

Web scanning tools will miss findings like this. But, regarding web scanners: see static source code security analyzers.

As for code review: a competently constructed application shouldn't be relying on developers to catch every possible instance where numeric ids are used individually. In modern web frameworks, it should be obvious when you're looking an ID up without doing an authorization check; for instance, in a Rails or Django app, you can simply regex for lookups coming off the ORM class rather than the appropriate association instance.

In sum: I dispute much of this analysis.

People do miss things, even when they're things they shouldn't miss. Put 3 different test teams on the same application and you will get 3 overlapping but distinctive sets of vulnerabilities back. But this is not an instance of the kind of vulnerability that is hard to catch.

see below

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

#48

Post by dvlsg »

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…

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.

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

#49

Post by scarface74 »

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…

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 session and won’t even route to the request if the user isn’t validated.

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

#50

Post by eganist »

tptacek wrote: post #47
bryant wrote: post #37

Earlier quoted context omitted.

(It's apparent that my initial reply didn't resonate, so I've made substantial edits to my reply for clarity's sake. If you've read it once, give it another read; it's from the angle of an organization with much in the way of legacy impairment.) > Yet another security vulnerability caused by... I mean, yes, but these are also some of the easiest vulnerabilities to miss even with out-of-the-box static analysis (code s…

There are no effective static source code security analyzers. Static analyzers aren't a bad thing to add to a CI pipeline, because why not, but anyone depending on static analysis is playing to lose. This is absolutely not the kind of vulnerability that pentests tend to miss; rather, they're the first thing pentesters check for. You can miss bugs like this when they're in obscure backend features and your client or t…

> This is absolutely not the kind of vulnerability that pentests tend to miss

You're right; they don't. Which is why I called out automated dynamic analysis. I.e. the web scanning tools which you subsequently mentioned:

> Web scanning tools will miss findings like this.

---

> As for code review: a competently constructed application shouldn't be relying on developers to catch every possible instance where numeric ids are used individually. In modern web frameworks, it should be obvious when you're looking an ID up without doing an authorization check; for instance, in a Rails or Django app, you can simply regex for lookups coming off the ORM class rather than the appropriate association instance.

Right, which I also stated:

> As for best-case prevention: accomplished generally architecturally, e.g. language/framework decisions that enforce secure coding practices by design, or implementing certain patterns in development which whisks away some of the more risky coding decisions from engineers who may not be qualified to be making them, such as mandating authn/z and limiting exceptions only to roles and change processes qualified to make them. Checks including linting for specific privacy defects (direct object referencing using sensitive data or iterative identifiers as opposed to hashes/guids/etc) can help with catching them during development, and as you might've guessed, such checks tend to be custom for a given environment rather than out of the box.

Post reply on HN