An Analysis of CVE-2017-5638 – how Equifax was hacked | Hacker News Reader

An Analysis of CVE-2017-5638 – how Equifax was hacked

blog.gdssecurity.com

132 pointsnotverysecure18 comments

Wow, article is from March 2017.

Summary: Attacker sends a malformed Content-Type header on file upload, which throws an exception due to the Content-Type being unknown. But, in the exception text is the direct, unsanitized user input from the header.

There is not a specific text localization handler for struts.messages.upload.error.InvalidContentTypeException, so a generic exception handler ends up being used to process the exception. This generic handler turns out to parse the unsanitized user input as OGNL markup, running the attacker code when processing the exception text.

Some effort is made to blacklist loading other Java libraries in the text rendering context, however it was easily defeated by emptying the blacklist in the attacking code before calling the blacklisted modules.

Beautiful summary.

Thank you.

Agreed - great write up, but can you expand on this a bit more please?

Ah, I probably should have used a TL;DR tag - my original comment is just a really condensed summary of the awesome but super detailed article, which even shows and explains the Struts code in question, example requests and responses, stack traces from the exception, and the exception logs. Even in the comments are some logs that look like evidence of an actual in-the-wild RCE attempt!

So maybe check there for more explanation... all credit for the research and investigation goes to the article's author. It was really a good 'deep dive' into the internals of Struts to see how such a subtle bug could be turned into RCE.

This generic handler turns out to parse the unsanitized user input as OGNL markup

The article is pretty dense and I don't understand this point. I can maybe understand why you'd want to parse the output of an exception message, but why would you ever want to be executing what you parse?

I don't know either, so I googled [OGNL] and the instant answer snippet was

> OGNL stands for Object-Graph Navigation Language; it is an expression language for getting and setting properties of Java objects, plus other extras such as list projection and selection and lambda expressions. You use the same expression for both getting and setting the value of a property.

Which makes it pretty clear.

I still don't get it. Why would you want to execute that kind of markup in an error handler?

Rendering the exception message into an output template for display perhaps.

To substitute variables in a localized error message template.

Does generating that substitute value imply launching a shell command?

No. But template expression language used in Struts is quite expressive. :) There's some defensive system to prevent access to arbitrary classes, but the attacker managed to overcome it in a clever way.

So basically they called eval() on an error message, to put it bluntly? Nice reminder that no matter how safe the language, people will do nutty stuff with it.

I have yet to see any credible source pinpointing the CVE used to compromise the Equifax data (we all know it's in Struts, but which one was it?). Has something changed, or is this title clickbait?

>The attack vector used in this incident occurred through a vulnerability in Apache Struts (CVE-2017-5638), an open-source application framework that supports the Equifax online dispute portal web application.

https://www.equifaxsecurity2017.com

^ the official site, despite looking like a phish

There might be more to it, but this vulnerability was definitely used.

This isn't the official site by the way.

https://news.ycombinator.com/item?id=15295146

Nope. https://securityequifax2017.com/ is the site referenced in your linked article https://www.equifaxsecurity2017.com/ is the official site

Note that the linked article isn't clickbait. It's an InfoSec description of how they dealt with the same vuln that hit Equifax. The article was written ~6 weeks before Equifax's stated timeline of attack.

To clarify your comment, Equifax did recently reveal[1] the specific vuln (CVE-2017-5638) in Apache Struts that was used during the ~May-July attack that caused the most headlines.

[1] https://investor.equifax.com/news-and-events/news/2017/09-15...

Oh, yes, I understand that the linked article isn't clickbait - I was calling out the title specifically for that reason, because if Equifax hadn't confirmed the CVE, I think it would qualify as a clickbait title ;)

Thanks for the link, though, I somehow managed to miss that announcement.

Reply on news.ycombinator.com