Hackers who broke into Equifax exploited a flaw in open-source server software • Hacker News Board

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#81

Post by bodz » Sat, Sep 09, 2017, 6:35 PM UTC

bluejekyll wrote: post #63

bodz wrote: post #7

Earlier quoted context omitted.

Why do you hope that? Do you want them to be liable? If it was a zero-day then they legitimately may not be at fault.

Forget about the zero-day for a minute. They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext. If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way. The prevalence a…

There's no evidence so far (that I've seen) that points to Equifax storing SSNs in plaintext. The initial reports so far indicate that the exploit scraped the SSNs while it was in use by other systems, and not at rest in a database. Encryption (whether they do it or not) wouldn't have saved the day here.

> The prevalence and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.

I completely agree.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#82

Post by runeks » Sat, Sep 09, 2017, 7:08 PM UTC

needusername wrote: post #70

technion wrote: post #68

Earlier quoted context omitted.

I had shock and awe when I learnt how to exploit PHP's unserialize() vulnerabilities, shock when I learnt Python had the same thing with unpickle, and then somewhat lost the plot reading about a previous Rails vulnerability which looks very much like this struts vulnerability. It's unsurprising someone, somehow, built the same thing for Java, but I wish we'd move from "don't unserialize unless it's safe" to "this lan…

Well, the intended goal of the plugin in question is to enable Rails-like functionality [1]. So if they took inspiration from there it's not that surprising if they end up with the same vulnerabilities. [1] http://struts.apache.org/docs/rest-plugin.html

In my humble opinion, when a remote code execution vulnerability appears in an application written in a memory safe language, you know you’ve chosen the wrong way to model a problem.

The art of writing code is defining the problem space, which is avoided completely when you allow the consumer of your interface to execute arbitrary code. The whole point of interfaces is to restrict the possible actions of a consumer of it — i.e. the inverse of arbitrary remote code execution — which is the hard part of software design.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#83

Post by BrandoElFollito » Sun, Sep 10, 2017, 7:23 AM UTC

technion wrote: post #68

runeks wrote: post #46

Regarding CVE-2017-9805, I’m genuinely in awe over how remote code execution in Java is even possible. Why should it even be possible to deserialize data on the wire into executable code? Also, can someone shed light on the technical side of this? E.g., how does the JVM compile Java code it receives on the wire into Java byte code? Does the JVM runtime have a built-in Java compiler that outputs Java byte code that it…

I had shock and awe when I learnt how to exploit PHP's unserialize() vulnerabilities, shock when I learnt Python had the same thing with unpickle, and then somewhat lost the plot reading about a previous Rails vulnerability which looks very much like this struts vulnerability. It's unsurprising someone, somehow, built the same thing for Java, but I wish we'd move from "don't unserialize unless it's safe" to "this lan…

I am not sure what you mean with Python and pickle. You get a binary blob with data (dict, list,...) as an input and bring these data in memory.

This is the same as reading a file in, getting data though a http call, through user input...

Of course you must marshall what you get before using it further - but that does not depend on the source once it is not secure /trusted

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#84

Post by evilDagmar » Tue, Sep 12, 2017, 1:31 PM UTC

bodz wrote: post #7

phkahler wrote: post #6

Earlier quoted context omitted.

I just hope the EFX breach used an older exploit and not a zero-day. That may have some influence on their perceived liability.

Why do you hope that? Do you want them to be liable? If it was a zero-day then they legitimately may not be at fault.

No, they'll still be at fault because if you have a massive pile of highly sensitive data online, and all it takes is one vulnerability to get at it all, then your security model was awful.

Was this database typically accessed with broad-sweeping queries that could snarf large amounts of it at once, or was it the sort of thing where a few specific keys were used to identify a single client record? My thinking is that it was probably the latter, and if that's the case then another layer of security should have been in place there. Stored procedures can be used to require very specific queries to access very specific records--this falls under the "prevention" category. Next, monitors should be deployed so that someone gets notified right away if some session makes a large number of successive queries to get around the restriction--this goes under the heading of "detection". These two things would have been able to prevent attackers getting the goods with just one exploit.

...yet companies regularly fail to take these kinds of simple and rational steps seriously, and then act like it was all just too hard for anyone to possibly defend against.