11 ms·

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

219 points by uptown 9y ago

valbaca 9y ago
To give nuance to the clickbait: "The vulnerability in Struts was just recently discovered by security researchers, who announced it earlier this week on Sept. 4. According to the researchers, the bug has existed since 2008."
- cpncrunch 9y ago
  Equifax discovered the hack on July 29, more than a month before this vulnerability was discovered.
  - ihattendorf 9y ago
    A month before this vulnerability was discovered by these specific security researchers.
    - AdamJacobMuller 9y ago
      A month before it was _disclosed_ by these researchers. Given the magnitude of this hack, it is entirely possible they embargoed it for a while.
  - lawnchair_larry 9y ago
    No, the vulnerability was reported to the Struts project on July 17. https://lgtm.com/blog/apache_struts_CVE-2017-9805 https://lgtm.com/blog/apache_struts_CVE-2017-9805
    - cpncrunch 9y ago
      I meant a month before it was reported.
  - imron 9y ago
    So little to no chance then that those executives who sold stock the other day didn't know about it then.
- dabber 9y ago
  There is now a correction at the beginning of the article: > Correction: An earlier version of this article said the vulnerability exploited by the hackers who broke into Equifax was the one disclosed on Sep. 4. It’s possible that the vulnerability that was targeted was one disclosed in March. We will update this post when we’ve confirmed which vulnerability it was.
IronWolve 9y ago
Humm, just got an apache struts security update from Redhat, and confluence doesn't have an update for it. Interesting...
- spydum 9y ago
  I believe the more recent vulnerability doesn't apply to the atlassian tools (I'd love to know if I was mislead). My understanding was the latest struts vuln requires you to be using a specific REST plugin.
- mimg 9y ago
  It was my understanding Atlassian tools like Jira and Confluence do not use Struts. Is this correct?
ekimekim 9y ago
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 patch. [1] https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c1-88e55503ecb0.pdf https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c...
- phkahler 9y ago
  I just hope the EFX breach used an older exploit and not a zero-day. That may have some influence on their perceived liability.
  - bodz 9y ago
    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.
    - mistercow 9y ago
      If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.
      - bodz 9y ago
        > points away from a world where a hundred million people's private information is unavoidably vulnerable Regardless of this specific situation, we already live in this world. We all just need to get used to it.
        deleted 9y ago
        [deleted]
fencepost 9y ago
This is based on a report from Baird Equity Research. Some key items from that report: * "Our understanding is data retained by EFX primarily generated through consumer interactions was breached via the Apache Struts flaw (i.e., core databases not believed to have been breached)." * "Key EFX databases are not known to have been breached as part of the incident, including the consumer credit file, TWN, NCTUE, IXI, or its commercial credit database. Our understanding is that data entered (and retained) through consumer portals/interactions (consumers inquiring about their credit reports, disputes, etc.) and data around it was breached via the Apache Struts flaw." * "the breach is believed to have occurred from mid-May through July" and was discovered on July 29. It's not clear whether this is referring to the Struts problem just announced or if it's the Struts problem earlier in the year, but if it's the just-announced one then it means that someone was actively exploiting it in the wild since at least May of this year. The timeframe would fit better for the early-2017 vulnerability [1] which was apparently also being exploited in the wild in March. Obviously if they had enough access to the system it would be possible to connect through to the databases being accessed, but if this was all scraping of data passing through rather than at-rest then it may also indicate a lot more sophistication in the attack - unless there's a small number of points where the attackers could copy out data, this likely required a fair amount of analysis of Equifax's code to shim things in and grab data without breaking things. The other interesting question is more along the lines of "If you haven't interacted with Equifax and haven't applied for anything involving credit, does that lessen the risk that you're impacted?" [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 (Apache Struts Jakarta Multipart Parser file upload vulnerability for RCE)
- spo81rty 9y ago
  I would guess that you have any sort of credit history or digital financial trail, companies are sending it to Equifax. Could be something as simple as a cell phone service.
- marksellers 9y ago
  I find it curious how one can implant code like this into existing codebases. It takes us a while to code review and deploy, and when we deploy we overwrite what's already on production
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
unquietcode 9y ago
TIL people are still using Struts in their crazy old enterprise applications. Jesus...
Nomentatus 9y ago
(Also posted in the discussion for an article re the lawsuits being filed vs Equifax for the leak) Credit card companies could provide other businesses such as Equifax distinct mere-reference numbers which the customer doesn't see and which can't be used for purchases - just to absolutely identify which card, for all parties. These could be added to the magnetic stripe or chip in the card, for example. (It might be gilding the Lilly, but many such reference numbers could be used for a given card, re privacy issues or otherwise. But then those numbers couldn't be usefully passed between companies for all purposes.) There's no need for anyone but the customer and Credit Card company itself to retain the actual credit-obtaining-number (other than to allow future purchases with permission, which is the rarer case, often needs to be prevented not facilitated, and doesn't excuse Equifax having more than a reference number.) Yet the credit card companies don't do this. Why not? 'Cause humans are idiots, all of us, that's why. PS - run to the patent office and you might be able to make a ton of money patenting this, since patents are now given to whoever shows up at the patent office with the appropriate fees first. Precedence doesn't matter. You would be implying that you thought the idea up independently, of course, but you're smart, right? That's totally the sort of thing you could think of independently. Then when you're rich, you too can help choose what the patent laws look like, and whether rich people should pay taxes.
lngnmn 9y ago
Wrong emphasis. It must be read "flaw in open source Java software. The problem is Java, not Open Source.
- ajarmst 9y ago
  I'd leave it out of the title altogether as irrelevant. The fact that Struts is distributed with a particular license is no more important in this case than the fact that the foundation that distributes it is incorporated in Delaware.
- ajanuary 9y ago
  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/master/struts-pwn.py https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma... [1] https://blog.nelhage.com/2011/03/exploiting-pickle/ https://blog.nelhage.com/2011/03/exploiting-pickle/
ajarmst 9y ago
I find the title irritating, as it seems to impugn open source software as a category. Why is the licensing model even relevant? A better phrasing would be something like "...flaw in a popular web framework" or "...flaw in Apache Struts."
- znpy 9y ago
  > Why is the licensing model even relevant? Licensing model directly affects the availability of source code, and this technically facilitates exploit discovery.
  - throwawaykf09 9y ago
    Also, many open source proponents claim that open source software is more secure because the “many eyes” theory will lead to bugs and vulnerabilities being discovered sooner. This and other high profile exploits like heartbleed show how well this theory applies in practice is questionable.
    - lillesvin 9y ago
      I find that conclusion presumptuous. Unless you can say how many bugs would have been discovered had the source been closed, then it doesn't make sense to claim the opposite. Also, do we know that e.g. this and Heartbleed were discovered by reading the source? If they weren't then the availability of the source code is inconsequential IMO.
  - ajarmst 9y ago
    That's a very dubious claim, as it depends on the largely debunked idea of "security through obscurity." Bruce Schneier: https://www.schneier.com/crypto-gram/archives/2002/0515.html#1 https://www.schneier.com/crypto-gram/archives/2002/0515.html...
    - znpy 9y ago
      I am not saying that closed-source software is more secure. I am saying finding exploits when the source code is available is definitely easier.
runeks 9y ago
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 itself can execute? https://lgtm.com/blog/apache_struts_CVE-2017-9805 https://lgtm.com/blog/apache_struts_CVE-2017-9805
- Kubuxu 9y ago
  I am not sure about this exploit but what can be done is you can send a Class type over the wire. It contains Java bytecode and when de-serialized it will use some ClassLoader to construct the Class instance. While doing that the static intializer of that class will be executed. This probably is not what is going on here but is a possibility.
- yc-kraln 9y ago
  the JVM lets you modify stuff at runtime with reflection
- ajanuary 9y ago
  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/master/struts-pwn.py https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma...
- technion 9y ago
  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".
  - 9y ago
norikki 9y ago
> a popular plugin called REST Why cant tech 'journalists' get someone who knows what they're talking about to proofread their articles?
- godzillabrennus 9y ago
  Remember this the next time you read anything in the news about an industry you don't understand.
  - sundarurfriend 9y ago
    The Gell Mann amnesia effect - https://seekerblog.com/2006/01/31/the-murray-gell-mann-amnesia-effect/ https://seekerblog.com/2006/01/31/the-murray-gell-mann-amnes...
  - nl 9y ago
    The irony here is that the plugin is actually called REST plugin http://struts.apache.org/docs/rest-plugin.html http://struts.apache.org/docs/rest-plugin.html
- deleted 9y ago
  [deleted]
- vfu6 9y ago
  There is actually a plugin called REST: http://struts.apache.org/docs/rest-plugin.html http://struts.apache.org/docs/rest-plugin.html
  - _fizz_buzz_ 9y ago
    If that's the plugin that was affected, then I think the author did nothing wrong. What would be the point to explain what REST - as a concept - is, in a non technical article.
campuscodi 9y ago
On what proof?
aewnjfksd 9y ago
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.

219 points by uptown 9y ago

To give nuance to the clickbait: "The vulnerability in Struts was just recently discovered by security researchers, who announced it earlier this week on Sept. 4. According to the researchers, the bug has existed since 2008."

cpncrunch 9y ago
Equifax discovered the hack on July 29, more than a month before this vulnerability was discovered.
- ihattendorf 9y ago
  A month before this vulnerability was discovered by these specific security researchers.
  - AdamJacobMuller 9y ago
    A month before it was _disclosed_ by these researchers. Given the magnitude of this hack, it is entirely possible they embargoed it for a while.
- lawnchair_larry 9y ago
  No, the vulnerability was reported to the Struts project on July 17. https://lgtm.com/blog/apache_struts_CVE-2017-9805 https://lgtm.com/blog/apache_struts_CVE-2017-9805
  - cpncrunch 9y ago
    I meant a month before it was reported.
- imron 9y ago
  So little to no chance then that those executives who sold stock the other day didn't know about it then.
dabber 9y ago
There is now a correction at the beginning of the article: > Correction: An earlier version of this article said the vulnerability exploited by the hackers who broke into Equifax was the one disclosed on Sep. 4. It’s possible that the vulnerability that was targeted was one disclosed in March. We will update this post when we’ve confirmed which vulnerability it was.

IronWolve 9y ago

Humm, just got an apache struts security update from Redhat, and confluence doesn't have an update for it. Interesting...

spydum 9y ago
I believe the more recent vulnerability doesn't apply to the atlassian tools (I'd love to know if I was mislead). My understanding was the latest struts vuln requires you to be using a specific REST plugin.
mimg 9y ago
It was my understanding Atlassian tools like Jira and Confluence do not use Struts. Is this correct?

ekimekim 9y ago

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 patch. [1] https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c1-88e55503ecb0.pdf https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c...

phkahler 9y ago
I just hope the EFX breach used an older exploit and not a zero-day. That may have some influence on their perceived liability.
- bodz 9y ago
  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.
  - mistercow 9y ago
    If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.
    - bodz 9y ago
      > points away from a world where a hundred million people's private information is unavoidably vulnerable Regardless of this specific situation, we already live in this world. We all just need to get used to it.
      - deleted 9y ago
        [deleted]

fencepost 9y ago

This is based on a report from Baird Equity Research. Some key items from that report: * "Our understanding is data retained by EFX primarily generated through consumer interactions was breached via the Apache Struts flaw (i.e., core databases not believed to have been breached)." * "Key EFX databases are not known to have been breached as part of the incident, including the consumer credit file, TWN, NCTUE, IXI, or its commercial credit database. Our understanding is that data entered (and retained) through consumer portals/interactions (consumers inquiring about their credit reports, disputes, etc.) and data around it was breached via the Apache Struts flaw." * "the breach is believed to have occurred from mid-May through July" and was discovered on July 29. It's not clear whether this is referring to the Struts problem just announced or if it's the Struts problem earlier in the year, but if it's the just-announced one then it means that someone was actively exploiting it in the wild since at least May of this year. The timeframe would fit better for the early-2017 vulnerability [1] which was apparently also being exploited in the wild in March. Obviously if they had enough access to the system it would be possible to connect through to the databases being accessed, but if this was all scraping of data passing through rather than at-rest then it may also indicate a lot more sophistication in the attack - unless there's a small number of points where the attackers could copy out data, this likely required a fair amount of analysis of Equifax's code to shim things in and grab data without breaking things. The other interesting question is more along the lines of "If you haven't interacted with Equifax and haven't applied for anything involving credit, does that lessen the risk that you're impacted?" [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638 (Apache Struts Jakarta Multipart Parser file upload vulnerability for RCE)

spo81rty 9y ago
I would guess that you have any sort of credit history or digital financial trail, companies are sending it to Equifax. Could be something as simple as a cell phone service.
marksellers 9y ago
I find it curious how one can implant code like this into existing codebases. It takes us a while to code review and deploy, and when we deploy we overwrite what's already on production

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

unquietcode 9y ago

TIL people are still using Struts in their crazy old enterprise applications. Jesus...

Nomentatus 9y ago

(Also posted in the discussion for an article re the lawsuits being filed vs Equifax for the leak) Credit card companies could provide other businesses such as Equifax distinct mere-reference numbers which the customer doesn't see and which can't be used for purchases - just to absolutely identify which card, for all parties. These could be added to the magnetic stripe or chip in the card, for example. (It might be gilding the Lilly, but many such reference numbers could be used for a given card, re privacy issues or otherwise. But then those numbers couldn't be usefully passed between companies for all purposes.) There's no need for anyone but the customer and Credit Card company itself to retain the actual credit-obtaining-number (other than to allow future purchases with permission, which is the rarer case, often needs to be prevented not facilitated, and doesn't excuse Equifax having more than a reference number.) Yet the credit card companies don't do this. Why not? 'Cause humans are idiots, all of us, that's why. PS - run to the patent office and you might be able to make a ton of money patenting this, since patents are now given to whoever shows up at the patent office with the appropriate fees first. Precedence doesn't matter. You would be implying that you thought the idea up independently, of course, but you're smart, right? That's totally the sort of thing you could think of independently. Then when you're rich, you too can help choose what the patent laws look like, and whether rich people should pay taxes.

lngnmn 9y ago

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

ajarmst 9y ago
I'd leave it out of the title altogether as irrelevant. The fact that Struts is distributed with a particular license is no more important in this case than the fact that the foundation that distributes it is incorporated in Delaware.
ajanuary 9y ago
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/master/struts-pwn.py https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma... [1] https://blog.nelhage.com/2011/03/exploiting-pickle/ https://blog.nelhage.com/2011/03/exploiting-pickle/

ajarmst 9y ago

I find the title irritating, as it seems to impugn open source software as a category. Why is the licensing model even relevant? A better phrasing would be something like "...flaw in a popular web framework" or "...flaw in Apache Struts."

znpy 9y ago
> Why is the licensing model even relevant? Licensing model directly affects the availability of source code, and this technically facilitates exploit discovery.
- throwawaykf09 9y ago
  Also, many open source proponents claim that open source software is more secure because the “many eyes” theory will lead to bugs and vulnerabilities being discovered sooner. This and other high profile exploits like heartbleed show how well this theory applies in practice is questionable.
  - lillesvin 9y ago
    I find that conclusion presumptuous. Unless you can say how many bugs would have been discovered had the source been closed, then it doesn't make sense to claim the opposite. Also, do we know that e.g. this and Heartbleed were discovered by reading the source? If they weren't then the availability of the source code is inconsequential IMO.
- ajarmst 9y ago
  That's a very dubious claim, as it depends on the largely debunked idea of "security through obscurity." Bruce Schneier: https://www.schneier.com/crypto-gram/archives/2002/0515.html#1 https://www.schneier.com/crypto-gram/archives/2002/0515.html...
  - znpy 9y ago
    I am not saying that closed-source software is more secure. I am saying finding exploits when the source code is available is definitely easier.

runeks 9y ago

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 itself can execute? https://lgtm.com/blog/apache_struts_CVE-2017-9805 https://lgtm.com/blog/apache_struts_CVE-2017-9805

Kubuxu 9y ago
I am not sure about this exploit but what can be done is you can send a Class type over the wire. It contains Java bytecode and when de-serialized it will use some ClassLoader to construct the Class instance. While doing that the static intializer of that class will be executed. This probably is not what is going on here but is a possibility.
yc-kraln 9y ago
the JVM lets you modify stuff at runtime with reflection
ajanuary 9y ago
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/master/struts-pwn.py https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma...
technion 9y ago
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".
- 9y ago

norikki 9y ago

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

godzillabrennus 9y ago
Remember this the next time you read anything in the news about an industry you don't understand.
- sundarurfriend 9y ago
  The Gell Mann amnesia effect - https://seekerblog.com/2006/01/31/the-murray-gell-mann-amnesia-effect/ https://seekerblog.com/2006/01/31/the-murray-gell-mann-amnes...
- nl 9y ago
  The irony here is that the plugin is actually called REST plugin http://struts.apache.org/docs/rest-plugin.html http://struts.apache.org/docs/rest-plugin.html
deleted 9y ago
[deleted]
vfu6 9y ago
There is actually a plugin called REST: http://struts.apache.org/docs/rest-plugin.html http://struts.apache.org/docs/rest-plugin.html
- _fizz_buzz_ 9y ago
  If that's the plugin that was affected, then I think the author did nothing wrong. What would be the point to explain what REST - as a concept - is, in a non technical article.

campuscodi 9y ago

On what proof?

aewnjfksd 9y ago

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.