Hack bij kredietbeoordelaar kwam door bekend lek in Apache Struts

De hack bij de Amerikaanse kredietbeoordelaar Equifax kwam door een lek in Apache Struts dat sinds maart bekend was. Dat heeft Equifax zelf meegedeeld. Inloggen op een pagina met Argentijnse medewerkers van de kredietbeoordelaar blijkt ook kinderspel te zijn geweest.

Equifax heeft een update op de eigen site gezet met uitleg over het lek. Een beveiligingsbedrijf waarschuwde in maart voor aanvallen via het lek in Apache Struts. De kredietbeoordelaar had kennelijk zijn software niet bijgewerkt om zich te wapenen tegen deze aanval. Een of meer hackers hadden tussen mei en juli toegang tot databases van Equifax met daarin gegevens van 143 miljoen vooral Amerikaanse klanten van het bedrijf.

Het lek, met kenmerk CVE-2017-5638, maakt het mogelijk om op afstand code uit te voeren via een bestandsupload met de Jakarta Multipart-parser. Volgens beveiligingsbedrijf Qualys is het op die manier mogelijk om een compleet systeem over te nemen. Talos merkt op dat aanvallen van verschillende niveaus plaatsvinden. Zo zijn er varianten die alleen controleren of een systeem kwetsbaar is en andere varianten die firewalls uitschakelen en vervolgens malware op het systeem binnenhalen.

De Argentijnse tak van Equifax had een portal met gegevens van medewerkers openbaar online staan. De vereiste login was gebruikersnaam 'admin' met wachtwoord 'admin', meldt KrebsOnSecurity. Vervolgens bleek het mogelijk om de wachtwoorden van medewerkers op te zoeken door in de html-broncode van de pagina te kijken. Equifax had 111 medewerkers in het systeem staan. Het bedrijf heeft de pagina inmiddels offline gehaald.

Equifax kondigde vorige week aan te zijn gehackt. De criminelen kwamen binnen via een niet nader genoemde exploit van een applicatie op een Amerikaanse website van het bedrijf, waardoor ze toegang kregen tot de database. Ze hadden toegang van medio mei tot juli, toen het bedrijf de hack ontdekte.

Reacties (41)

[Keypunchie]

admin/admin

Professioneel beheer, dames en heren. Welkom2017!

Dit is systemisch falen. Als een systeem met bekende vulnerabilities an het internet hangt met dit wachtwoord, dan is er op elk niveau te weinig aandacht voor informatiebeveiliging.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 06:43]

[mmjjb]

En volgens mij heb je het bericht niet goed gelezen, net zoals vele anderen

Als een systeem met bekende vulnerabilities an het internet hangt met dit wachtwoord

En daar sla je de plank mis, de vulnerabilities hebben niks en ook maar niks te maken met dit wachtwoord.

1. Equifax is 'gehackt' doorzat ze Apache Struts niet gepatched hadden
2. Haar krediet klachten portaal in Argentinië had het standaard wachtwoord en zijn er gegevens gelekt.

Nu maakt KrebsOnSecurity er een heel mooi verhaal van, maar alle data's die zichtbaar zijn in de afbeeldingen, zijn allemaal uit 2015. Waarop ik de conclusie baseer dat het waarschijnlijk om verouderde rommel gaat, dat niet meer gebruikt wordt, alleen om af en toe nog te raadplegen.

Maarja, "oud portaal had standaard wachtwoord" klinkt natuurlijk minder interessant. Desondanks bevatte dit 'oude' portaal nog wel 14,000 records.

[Reactie gewijzigd door mmjjb op 24 juli 2024 06:43]

[WhatsappHack]

Apache lijkt er iets skeptischer over te zijn, maar benadrukt iig dat ALS het al zo is dat zij dan (een van) de eersten geweest moeten zijn.
https://blogs.apache.org/...ruts-statement-on-equifax

[Verwijderd]

Of dit recenter statement
https://blogs.apache.org/foundation/entry/media-alert-the-apache-software

[WhatsappHack]

Yup:
“In conclusion, the Equifax data compromise was due to their failure to install the security updates provided in a timely manner.”

‘Nuff said.

[0xygen500]

Admin admin, gvd de gemiddelde huisrouter heeft zelfs het standaardwachtwoord aangepast. Bedrijf aanklagen voor het openbaarstellen van je gegevens.

[Reactie gewijzigd door 0xygen500 op 24 juli 2024 06:43]

[SaiKoTiK]

Op die pagina "bleek het mogelijk om de wachtwoorden van medewerkers op te zoeken door in de html-broncode van de pagina te kijken", wat an sich al erg genoeg is, maar dit was dus niet de bron van de gelekte klantgegevens, zoals in het artikel staat uitgelegd was dat middels een exploit op een andere website van het bedrijf.

[Aial0n]

Is het mogelijk om een bedrijf aan te klagen omdat ze onvoorzichtig met je gegevens zijn omgesprongen? Dat dit niet toevallig is, maar ze hun beveiliging niet fatsoenlijk geregeld hebben kan je makkelijk bewijzen adhv dit medewerkersportaal

[F_J_K]

In NL zou hier inderdaad door de Autoriteit Persoonsgegevens een boete van max. 820.000 opgelegd kunnen worden wegens als ik het zo zie ernstig verwijtbare nalatigheid. (https://autoriteitpersoon...n/onderzoek-en-handhaving)

Of dat in de VS ook zo is, en daar gaat het nu om, weet ik niet zeker. Al heb je daar veel meer een sue cultuur waar hoge schadevergoedingen kunnen worden geëist.

[sumac]

820k is natuurlijk peanuts. Dat kunnen die heren nog makkelijk uit hun bonus betalen. Die kan dan het volgend jaar verhoogd worden met dit bedrag (als beloning vanwege de voortvarende aanpak van deze hele zaak), zodat ze er de volgende jaren van kunnen blijven genieten.

[The Lord]

De boete kan per overtreding worden opgelegd. Het is dus goed mogelijk dat dit lek bestaat uit meerdere overtredingen en er zodoende meerdere bestuurlijke boetes (al dan niet elk voor €820k) worden opgelegd.

Toevoeging: Mocht het aan wanbestuur te wijten zijn dan zijn er mogelijkheden om e.e.a. ook strafrechtelijk aan te pakken. Zo kan een bonus ook verdwijnen.

[Reactie gewijzigd door The Lord op 24 juli 2024 06:43]

[oef!]

Vanaf mei 2018 wordt dat overigens 20 miljoen of 4% van de jaaromzet waarbij het grootste geldt. De Wet Bescherming Persoonsgegevens wordt dan vervangen door de Europese GDPR.

[Zer0]

Tja, dan vertrekt het hoger management, met een gouden handdruk, en blijft er een failliet gaand bedrijf over. De enigen die dat treft zijn de doorsnee werknemers.

[The Lord]

Nou, dat neigt erg naar wanbestuur. :-)

Los daarvan is er ook de mogelijkheid dat de AP persoonlijke boetes oplegt en werknemers civielrechtelijk stappen ondernemen al dan niet in de vorm van een 'class action suit'.

[cracking cloud]

wtf welke developer dacht dat het een goed idee was om wachtwoorden in de html mee te sturen? (ik vermoed als hidden input)

[Rannasha]

Door de wachtwoorden me te sturen kun je lekker clientside de authenticatie afhandelen. Dan hoef je niet zo ingewikkeld te doen met servers en databases enzo.

[RGAT]

Die wachtwoorden moeten alsnog door een server uit een database gehaald worden om mee te sturen
Security clientside zou levenslang voor moeten staan.

[supersnathan94]

Database? Nee joh. Gewoon plaintext opslaan in een tsv bestand. Dan kun je het gewoon handmatig opzoeken als het nodig is en via de mail opsturen als het wachtwoord kwijt is.

[Troepje]

Mwah dan heb je het wachtwoord niet nodig dan zeg je met je client: ja hoor het wachtwoord was goed

[sumac]

Het was een pagina achter de admin-login. Dus die moest je wel eerst "kraken". De wachtwoorden stonden in de broncode, dus waren niet direct zichtbaar. Maar dit is natuurlijk nog net wat erger dan een sheet in google docs.

Het zal overigens niet de developer zijn die dit zo bedenkt, maar een manager die dit afdwingt. Ik ken ze persoonlijk, de mensen die dit soort dingen doen.

[Reactie gewijzigd door sumac op 24 juli 2024 06:43]

[ATS]

Zelfs dan doe je dat niet als developer wat mij betreft.

[sumac]

Het ligt er maar aan waar je in de rangorde zit, en wat je belangrijker vindt, hoezeer je afhankelijk bent van je salaris etc. Verder beloftes als: we werken dat later netjes af.

Je kunt natuurlijk principieel weigeren, en dat zou hier in NL best wel eens kans kunnen maken. Maar de kans dat je problemen krijgt als het management het echt wil is behoorlijk groot. Makkelijker gezegd dan gedaan.

[supersnathan94]

Nou ik kan me niet voorstellen dat het management moeilijk gaat doen als je het wachtwoord wijzigt van admin naar het spaanse equivalent van "fuckjullieallemaalmetjeadminalspassword".

Daarnaast is een klein beetje security in de vorm van standaard sha256 hashing al beter dan helemaal niets en het is echt supersimpel om te doen in bijvoorbeeld spring-boot. Kan me niet voorstellen dat je dat er niet door krijgt. Het is maximaal 15minuten extra werk.

[sumac]

In Argentinië werkt de wereld echt anders met hiërarchie - je doet wat je gezegd wordt en ertegenin gaan - vergeet het maar. NL is echt een uitzondering op dit gebied.

[supersnathan94]

Dan nog. Een wachtwoord wijzigen is iets wat je gewoon verplicht bent te doen als admin. Hier zou een internationale schorsing voor moeten komen te staan. Ongeldig verklaren van certificaten na strafrechtelijk onderzoek wegens grove nalatigheid.

Het is bijvoorbeeld het eerste wat ik doe als ik een verse sql database ergens neerzet. Al is het maar een standaard lokale docker test versie. Eerst in notpad random op je toetsenbord meppen met twee handen en dat dan kopieren. Kost letterlijk 10 tellen en voorkomt zoveel mogelijke ellende later

[Stoelpoot]

Nou ja, dat was de bron van de aanval die kan worden geidentificeerd. Als je gewoon wachtwoorden van medewerkers kon uitlezen, kan je maar lastig zien dat er opeens een vreemde data uitleest. Immers is het geen vreemde, maar gewoon een medewerker.

[Verwijderd]

Nee, de bron was 'admin', 'admin'. Dan ben je mijn inziens wel heel erg nalatig en aansprakelijk.

"De Argentijnse tak van Equifax had een portal met gegevens van medewerkers openbaar online staan. De vereiste login was gebruikersnaam 'admin' met wachtwoord 'admin', meldt KrebsOnSecurity. Vervolgens bleek het mogelijk om de wachtwoorden van medewerkers op te zoeken door in de html-broncode van de pagina te kijken."

En dan daarna nog de fout om 111 medewerkers in een HTML-bestand te zetten? OMG...

Wat de Apple Struts er dan mee te maken had, uit de titel "Hack bij kredietbeoordelaar kwam door bekend lek in Apache Struts" is me dan weer niet helemaal duidelijk. Bovenstaande is een lossstaand iets, lijkt me.

[supersnathan94]

Klopt. Beide incidenten zijn niet aan elkaar gelieerd anders dan dat het apache incident reden was voor onderzoekers om de rest van de software eens onder de loep te nemen.

[Zer0]

Bedrijf aanklagen voor het openbaarstellen van je gegevens.

Ik zie liever dat ze de werkelijke oorzaak aanpakken, namelijk de ontwikkelaar die het gebruik van een standaard wachtwoord in de software heeft gezet, zonder er voor te zorgen dat het bij eerste gebruik gewijzigd moet worden

Apparatuur en software zou gewoon niet bruikbaar mogen zijn met een standaard wachtwoord

[Reactie gewijzigd door Zer0 op 24 juli 2024 06:43]

[kakanox]

De ontwikkelaar of de opdrachtgever?

[Tukk]

Klaag jij ook een autofabrikant aan omdat je 180 kan rijden in een 30-zone?

[FrankoNL]

Enigszins kromme vergelijking. En met enigszins bedoel ik volledig.

[Zer0]

Nee, maar ik klaag hem wel aan als ik er 180 mee kan rijden en het remsysteem niet naar behoeven functioneerd.

[RGAT]

Zou de fabrikant zeker aanklagen als die een slot op je auto zet wat de deur wagenwijd open laat staan elke keer ja.

[dakathefox]

De vereiste login was gebruikersnaam 'admin' met wachtwoord 'admin'

De desbetreffende ontwikkelaar zou je toch met een mattenklopper even flink moeten afranselen. Op z'n minst lijkt me. En als je toch bezig bent, dan ook even de medewerkers die met admin/admin inloggen. Welke nitwit heeft dit in vredesnaam bedacht?!

[Reactie gewijzigd door dakathefox op 24 juli 2024 06:43]

[Verwijderd]

Ik begrijp de min op je reactie niet. Dit is wel heel erg 'punt 1' wat goed en veilig moet werken voor iets als een inloggedeelte. En dat nog wel voor een kredietbeoordelaar waar de miljoenen waarschijnlijk om de oren vliegen.

[dakathefox]

Ik snap het ook niet helemaal. Wij werken met vertrouwelijke klantinformatie en krijgen op jaarbasis de records binnen van naar schatting 2,5 miljoen Nederlanders. Vanzelfsprekend kun je bij onze hoofdapplicatie niet inloggen met admin/admin, maar ook op het intranet kun je niet op die manier inloggen, ondanks dat het uitsluitend binnen het lokale netwerk geopend kan worden.

Zo hoort het volgens mij ook gewoon. Zou één van mijn ontwikkelaars een applicatie met admin/admin beveiligen, dan was hij nog niet jarig. En reken maar dat die mattenklopper dan nog te lief is.

[Dorank]

Ik begrijp het wel: je stelt minimaal lijfstraffen voor (geen idee wat je bedoelt met een zwaardere vorm van straf). En dat ook nog eens voor wellicht een persoon die niet verantwoordelijk is voor het te implementeren ontwerp.

[supersnathan94]

Het ontwerp kan de ontwikkelaar misschien niets aan doen, maar het instellen van het wachtwoord als "admin" is wel heel erg karig.

[jimshatt]

Linkje in 2e alinea ('mogelijk') is dood. Sorry dat ik het in de main thread gooi.
Edit: moet zijn: https://threatprotect.qua...-execution-vulnerability/

[Reactie gewijzigd door jimshatt op 23 juli 2024 11:25]

[Verwijderd]

Mijn vermoeden is dat Equifax niet lang meer bestaat. De aandeelhouders zullen alles van waarde verkopen en daarna de boel laten ploffen, omdat het aantal rechtszaken het bedrijf boven het hoofd zal groeien.