Secure Software Systems · sites-using-apache-struts/ “Hits” = Unique users attempting to exploit CVE-2017-5638 vulnerability. Commentary ì Q: Why did it take Equifax so long

ìSecure Software SystemsCYBR 200|Fall2017|UniversityofthePacific|JeffShafer

EquifaxFiasco

What is Equifax?

ì CreditReportingAgency

ì Vision:Havea“magicnumber”thattellswhetheryou(consumer)areagoodorbadcreditrisk

ì Consultthatdatabasewhenconsumerappliesforcreditinordertomakeadecisioninrealtime!

ì Usefulforbanks(mortgages,creditcards,…)butalsopotentiallyusefulforemployers,landlords,etc…ì Although“notpayingacontestedmedicalbill”≠“won’t

paytherent”or“lazythievingemployee”

Fall2017SecureSoftwareSystems

2

What is Equifax?

ì You(consumer)don’tdirectlydealwithconsumercreditreportingagencies: Equifax,Experian,TransUnion,Innovis,

ì Creditgrantingcompanies(e.g.banks)checkwithEquifax’sdatabasetodetermineyourcreditworthinessì Thesamecompaniessharetheirinformationabout

consumersbacktotheagencies(makingthedatabasemorecompleteandvaluable)


3


4September7th,2017viahttps://www.equifaxsecurity2017.com/


5


6

14344%

180.156%

USTotalPopulation(323.1Million)

Personw/StolenEquifaxRecordPersonw/noStolenRecord

Note:Only125millionUSresidentshaveacreditcard(2016)

Implications

ì Applyfornewcreditcards/loans/bankaccountsì Creditfreezeatmajorreportingagenciesmayblockthis

ì Submitfraudulenttaxreturns(w/largerefund)inyournameì Creditfreezewon’thelphere…

ì Heathinsurancefraudì Creditfreezewon’thelphere…

ì Othercreativetypesoffraud?


7

https://krebsonsecurity.com/2017/09/the-equifax-breach-what-you-should-know/http://www.npr.org/sections/thetwo-way/2017/09/07/549296359/hackers-accessed-the-personal-data-of-143-million-people-equifax-says

Whatcanathreat dowithName+DOB+SSN+Address+Driver’sLicense?(Attacks?Harm?)

Credit Freeze

ì Equifax(freeatthemoment)ì https://www.freeze.equifax.com

ì TransUnion($10)ì https://www.transunion.com/credit-freeze/place-credit-

freeze

ì Experian($10)ì https://www.experian.com/freeze/center.html

ì Innovis (free)ì https://www.innovis.com/personal/securityFreeze

ì ChexSystems


8

https://krebsonsecurity.com/2017/09/the-equifax-breach-what-you-should-know/

Late Breaking Update

ì Attackersalsogot200,000creditcardstoo….(newsas-ofSept142017)


9

https://krebsonsecurity.com/2017/09/equifax-hackers-stole-200k-credit-card-accounts-in-one-fell-swoop/

ìSecure Software Development


10


11

September13th,2017viahttps://www.equifaxsecurity2017.com/

CVE-2017-5638

ì ApacheStruts,CVE-2017-5638ì https://nvd.nist.gov/vuln/detail/CVE-2017-5638ì Released:3/10/2017ì Description:“TheJakartaMultipartparserinApache

Struts22.3.xbefore2.3.32and2.5.xbefore2.5.10.1mishandlesfileupload,whichallowsremoteattackerstoexecutearbitrarycommandsviaa#cmd=stringinacraftedContent-TypeHTTPheader,asexploitedinthewildinMarch2017.”

ì Otherlinksì https://threatprotect.qualys.com/2017/03/08/apache-struts-jakarta-

multipart-parser-remote-code-execution-vulnerability/ì https://github.com/rapid7/metasploit-framework/issues/8064


12

Timeline of Events


13

March72017Exploitsof“zero-day”vulnerabilityspottedinthewild(Couldhavebeenearlier,wasonlyaddedtodetectionsignaturesthisday)http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html

March72017ApachereleasesStruts2.3.32tofixvulnerabilityhttps://struts.apache.org/announce.html

March102017CVEpublished

Mid-May2017AttackerstargetEquifax(successfully)

July292017Equifaxdetectsattack

March22017ApacheStrutsdevs investigateS2-045securitybulletinandbeginworkonfixhttps://struts.apache.org/docs/s2-045.html


14


15

https://arstechnica.com/information-technology/2017/03/in-the-wild-exploits-ramp-up-against-high-impact-sites-using-apache-struts/

“Hits”=UniqueusersattemptingtoexploitCVE-2017-5638vulnerability

Commentary

ì Q:WhydidittakeEquifaxsolongtosecuretheirsystems?

ì A:ApacheStrutsflawwasharderthantypicalvulnerabilitytopatch


16

Commentary

ì Idealsoftwareupdateprocess?ì sudo apt-get update && sudo apt-get upgradeì WindowsUpdate:Click“Install”ì Somesystem-widelibrary(installedinone place)and

managedbypackagemanagerorOSì Rebootsystemorrestartdeamon andyou’refixed!J

ì Reasonablesoftwareupdateprocess?ì Programauto-updates(Chrome,Firefox,MSOffice,…)ì Manuallydownload“some-program.exe”fromvendor

andruninstallertooverwriteoldbinarywithnew

ì CanbedoneandverifiedeasilybyITdepartment


17

Commentary

ì Thisupdateismuchmuchworseì https://arstechnica.com/information-

technology/2017/03/critical-vulnerability-under-massive-attack-imperils-high-impact-sites/?comments=1&post=32957185

ì Well-writtenpost!ì PeterBright,TechnologyEditor,Ars Technicaì https://arstechnica.com/author/peter-bright/


18


19

Peter Bright Technology EditorREPLYMAR 9,20179:40AMARS STAFFPOPULARQuote:It's not clear why the vulnerability is being exploited so widely 48 hours after a patch was released.

The short answer is: 48 hours is utterly inadequate for this kind of update.

The long answer is:

Unlike, for example, a Windows flaw, or, say, an OpenSSL flaw, Struts is not a system library provided by an operating system or Linux distribution. With operating system libraries, maintenance is relatively straightforward: you hit Windows Update or run apt-get update, or whatever the case may be for your platform, and the fixed library is installed. A quick reboot to restart applications and you're good to go; all your software is now using the fixed version of the library and you can move on.

Rather, Struts is a library that is bundled with applications. Typically, every Struts-using Web app on a system will embed its own copy of the Struts JAR. Technically, this isn't absolutely necessary; you could in principle put your Struts JAR in a shared JBoss/Tomcat/Websphere/etc. location and have every deployed app use the shared JAR from the classpath, but this is rarely done because of the versioning headaches this causes. This means that updating Struts is outside the control of typical IT departments; sysadmins can't fix this. Instead, they have to get application developers involved.

An organization may have tens or hundreds of little Struts-using Web apps, all with their own Struts JAR embedded within them. Many of those apps may be essentially abandoned; the earliest affected version of Struts was released in October 2012, and I bet that there's plenty of apps developed since then that are "finished". They're still used and deployed, but they're not receiving ongoing maintenance; their developers have moved on to other projects, or even other companies.

Fixing those applications means getting the source code, updating the build scripts to change the Struts dependency to the latest version (2.3.32 or 2.5.10.1), and then rebuilding the application. For currently-developed code, that may be easy, but for a three year old app that hasn't been touched in a while? That's a little hairier. You might have to dig out older JDK versions to get it to build, find an old copy of an old internal JAR that's somehow gone missing, all the usual problems that happen when you try to rebuild an old application. That's assuming, of course, that you have the source code and build scripts, and that alone is far from guaranteed. I bet that there will be developers who find that the version in source control for some reason doesn't quite match the version that's deployed, or that they have no source at all, or that it doesn't build for whatever reason.

So, your developers have to update their Maven or gradle or (god forbid) Ant build scripts and bump the version number for the Struts dependency to grab the new version.

You then have to hope that nothing is broken. If you're using Struts 2.3.5 then in theory Struts 2.3.32 won't break anything. In theory it's just bug fixes and security updates, because the major.minor version is unchanged. In theory.

In practice, I think any developer going from 2.3.5 to 2.3.32 without a QA cycle is very brave, or very foolhardy, or some combination of the two. Sure, you'll have your unit tests (maybe), but you'll probably need to deploy into your QA environment and do some kind of integration testing too. That's assuming, of course, that you have a compatible QA environment within which you can deploy your old, possibly abandoned application.

Then you'll have to schedule an actual deployment of the updated application. If the app is world-facing, that may mean delaying until the weekend or night time or similar.

And all this is presuming that your developers even know about the problem. It's not (necessarily) super straightforward for IT to identify which apps are using which versions of Struts, so IT might well not know. And developers may very well not be tracking this stuff anyway. Struts was regarded as old-fashioned and backwards when I was writing Java just over a decade ago; I daresay it's even less sexy now. So your developers probably unsubscribed from the Struts mailing list, and probably aren't reading the release notes for each new Struts version. They've moved on to better, newer frameworks.

This kind of bug is a problem that IT will struggle to identify, and that IT can't fix themselves. Developers may well be unaware of the flaw, but developers and QA are going to be on the hook to fix it. There's no way a problem like this is getting any kind of widespread reaction within 48 hours. The wheels just don't turn that fast. This is a big hairy mess.

Q:Arethesepeoplestupidorlazy?A:Notreally….

Any Countermeasures?

ì Putproxyserverinfrontofstrutsapplication

ì Configureproxytobeveryrestrictiveand(especially!)blockanyContent-Type headersw/OGNL fromreachingthevulnerableapplication


20

Documents

Secure Software Systems · sites-using-apache-struts/ “Hits” = Unique users attempting to exploit CVE-2017-5638 vulnerability. Commentary ì Q: Why did it take Equifax so long