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

#61

Post by jaclaz » Sat, Sep 09, 2017, 9:35 AM UTC

sillysaurus3 wrote: post #27

hossbeast wrote: post #26

Earlier quoted context omitted.

Sure, if you don't have physical security, you have no security. Goes without saying.

Unfortunately ~nobody does. The effectiveness of red teams was one of the most surprising aspects of working in security. The most common way to break into someplace was to pose as a construction worker: http://i.imgur.com/ZjnGmZ5.png If you're dressed as one of them, you can go wherever you want and people rarely ask questions. Another approach is to pose as an interviewee. That's how you get into the building, but…

>People generally don't care when someone is walking around the halls dressed up in a suit.

Particularly if they behave accordingly.

A classic (just to show that there is nothing new under the sun):

https://en.wikisource.org/wiki/The_Innocence_of_Father_Brown...

>If you meet a member of that select club, "The Twelve True Fishermen," entering the Vernon Hotel for the annual club dinner, you will observe, as he takes off his overcoat, that his evening coat is green and not black. If (supposing that you have the star-defying audacity to address such a being) you ask him why, he will probably answer that he does it to avoid being mistaken for a waiter. You will then retire crushed. But you will leave behind you a mystery as yet unsolved and a tale worth telling. ...

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

#62

Post by aewnjfksd » Sat, Sep 09, 2017, 9:50 AM UTC

Hah! Surely a memory-safe language cannot have security vulnerabilities. /s

I find it telling that in this case it was NOT a C program being responsible for the hack, even though the affected machine was likely running many orders of magnitude more C than Java code.

I've always said it and I will repeat it here again; higher level languages fail in ways that are much more surprising, complicated and hidden than your typical "insecure" C program.

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

#63

Post by bluejekyll » Sat, Sep 09, 2017, 10:04 AM 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.

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 and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.

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

#64

Post by ajanuary » Sat, Sep 09, 2017, 10:06 AM UTC

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…

It can deserialise into arbitrary classes. You could deserialise a process builder to execute an arbitrary shell command [0].

[0] https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma...

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

#65

Post by ajanuary » Sat, Sep 09, 2017, 10:11 AM UTC

lngnmn wrote: post #41

Wrong emphasis. It must be read "flaw in open source Java software. The problem is Java, not Open Source.

And Ruby [0] and Python [1] and...

Nothing about Java or it's community makes it any more prone than most other languages to exposing deserialisation into arbitrary objects.

[0] https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma... [1] https://blog.nelhage.com/2011/03/exploiting-pickle/

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

#66

Post by phkahler » Sat, Sep 09, 2017, 11:31 AM UTC

kelnos wrote: post #28

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.

I despise the existence of the credit reporting bureaus and would love to see one of them caught with their pants down for a breach that was entirely preventable (well, at least through the vector that was used). If they failed to patch a known vulnerability, and that caused the breach, likely they'll be on the hook for a larger payout once settlement time comes.

This is exactly what I meant. These companies compile large amounts of personal financial data without peoples consent. They use SSNs for non-tac purposes, which I think is/was illegal. This ultimate cause of the breach has nothing to do with the exploit used, but rather the fact that this company and its practices exist at all. They put peoples info on a computer connected to the internet for no reason other than efficiency - profit.

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

#67

Post by sschueller » Sat, Sep 09, 2017, 12:41 PM UTC

phkahler wrote: post #6

ekimekim wrote: post #4

Take this with a grain of salt: They claim that the Struts vulnerability in question is specifically CVE-2017-9805, and cite a William Baird & Co. report [1]. However, the report in question says nothing about a specific CVE, only that it was "the Apache Struts flaw". Struts has had multiple vulnerabilities recently, such as one back in February (CVE-2017-5638). It's possible it was one of these that they failed to p…

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

I hope it is a zero day but part of vault 7 which would put the blame back at the CIA for keeping it to them selves.

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

#68

Post by technion » Sat, Sep 09, 2017, 12:41 PM UTC

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 language should not have this feature".

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

#69

Post by nl » Sat, Sep 09, 2017, 1:11 PM UTC

godzillabrennus wrote: post #50

norikki wrote: post #48

> a popular plugin called REST Why cant tech 'journalists' get someone who knows what they're talking about to proofread their articles?

Remember this the next time you read anything in the news about an industry you don't understand.

The irony here is that the plugin is actually called REST plugin

http://struts.apache.org/docs/rest-plugin.html

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

#70

Post by needusername » Sat, Sep 09, 2017, 2:06 PM 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…

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