Hackers stalen in april wachtwoordhashes en mailadressen van 100.000 npm-users

Criminelen stalen bij de npm-aanval in april gebruikersnamen, gehashte wachtwoorden en e-mailadressen van ongeveer 100.000 npm-gebruikers. De aanvallers gebruikten daarvoor OAuth-tokens die ze van twee externe diensten hadden gestolen.

Met de OAuth-token wisten de aanvallers toegang te krijgen tot npm-repo's, schrijft npm's moederbedrijf GitHub. Daar wisten ze toegang te krijgen tot AWS-accesskeys. Binnen de AWS-infrastructuur van npm wisten de aanvallers oudere back-ups van het JavaScript-ontwikkelaarsplatform npm te downloaden, met metadata en package manifests voor alle publieke en privépackages tot april 2021. Het gaat daarbij om readme-bestanden, package-versiegeschiedenissen, maintainer-e-mailadressen en package-installeerscripts. De package artifacts zelf zaten hier niet in.

In deze back-up zat ook een archief met npm-gebruikersinfo uit 2015. Hierin was login-informatie van ongeveer 100.000 npm-gebruikers te vinden. Het gaat hierbij om gebruikersnamen, e-mailadressen en gehashte wachtwoorden. Die wachtwoorden waren met PBKDF2 gehasht of met een salted SHA1-algoritme. GitHub zegt dat deze zwakke hashingalgoritmes sinds 2017 niet meer worden gebruikt, toen npm overstapte naar bcrypt.

Npm heeft de wachtwoorden van deze 100.000 gebruikers gereset en ze worden per mail ingelicht over het datalek. Sinds maart dit jaar is mailverificatie verplicht bij accounts zonder tweefactorauthenticatie. GitHub zegt geen bewijs te hebben dat de aanvallers packages hebben aangepast of nieuwe versies van bestaande packages hebben gepubliceerd.

GitHub schreef begin april voor het eerst over het OAuth-beveiligingsincident, waarbij hackers OAuth-tokens gebruikten van Heroku en Travic-CI. Hiermee downloadden ze data uit privérepo's op GitHub. Heroku ontdekte dat wachtwoorden van gebruikers zijn gestolen en resette daarna alle gebruikersaccounts.

Los van het OAuth-onderzoek ontdekte GitHub dat bepaalde inloggegevens in plaintext werden opgeslagen bij een intern loggingsysteem voor npm-diensten. Het gaat hierbij om een 'klein aantal' wachtwoorden. GitHub benadrukt dat er geen bewijs is dat aanvallers toegang hadden tot deze data en dat deze alleen ingezien kon worden door GitHub-werknemers. GitHub gaat de getroffenen informeren, heeft de data verwijderd en zegt zijn proces voor het opruimen van loggingdata te hebben verbeterd.

Reacties (48)

[Jace / TBL]

Die wachtwoorden waren met PBKDF2 gehasht of met een salted SHA1-algoritme. GitHub zegt dat deze zwakke hashingalgoritmes sinds 2017 niet meer worden gebruikt,

Sinds wanneer is PBKDF2 ook al 'zwak'?

Ligt bovendien aan de onderliggende hash die daarbij gebruikt wordt, PBKDF2 met hmac-sha256 of 512 lijkt me toch alleszins prima.

[Zebby]

Is het ook, maar jaarlijks moet je de iteraties min of meer verdubbelen. Mogelijk refereren ze dus naar de verouderde hashing. Zie ook:
https://cheatsheetseries...._Storage_Cheat_Sheet.html
Wat me niet duidelijk wordt is waarom de volgorde Argon2id -> Bcrypt -> PBKDF2 is, terwijl PBKDF2 de enige is die benoemd staat voor bepaalde certificeringen en een benoeming voor verbruik vanuit de NIST?

Wij zijn zelf over van PBKDF2 naar Argon2i in ieder geval.

[Bulkzooi]

@Zebby Die certificeringen betreft FIPS en gaat over de internal hash function van HMAC-SHA-256 en het verloop over tijd van ISA extensions zoals AES, en bijbehorende hardware zoals AMD Platform Security Processor (PSP) en Arm TrustZone.

Het onderscheid dat NIST maakt (en daarmee bigtech en buggov) is aardig definitief t.o.v. die andere industrie standaarden. Een kwestie van hardware vs. software en omvat de beveiligingsmarkt en ook de status aparte van America in relatie tot het internet.

Frontend libraries zoals OpenSSL lopen in het algemeen ook netjes mee in de onwikkelingen.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[jdh009]

Denk dat het vooral aan de manier van hoe het toegepast is ligt:

Een zwak punt van PBKDF2 is dat, hoewel het aantal iteraties kan worden aangepast om een willekeurig grote hoeveelheid rekentijd te vergen, het kan worden geïmplementeerd met een kleine schakeling en zeer weinig RAM, waardoor brute-force aanvallen met behulp van toepassingsspecifieke geïntegreerde schakelingen of grafische verwerkingseenheden relatief goedkoop zijn.

[Alfa1970]

Als je de wachtwoorden in plain text in je logging laat staan dan is SHA1024 nog zwak.

[Bulkzooi]

@Jace / TBL Het is meer de classificering van Microsoft over "beveiliging in het algemeen" die opvalt. En die negatieve classificering van bepaalde algo's en methods is per 6 april 2017, het overstapmoment naar bcrypt. Microsoft/Github volgde "gewoon" de industry good practices met SHA1 salting en qua PBKDF2 hashing neigt Microsoft "natuurlijk", gezien de beursnotering aldaar, naar het NIST FIPS programma.

Dat Github de log/database met userinfo van Javascript developpers (sudo NPM gebruikers van de laatste 5 jaar!) niet bewaakt als haar regalia is erg genoeg, de Europese politiek zit al jááren achter Bigtech aan (tegenwoordig is de vraag waar de data fysiek wordt opgeslagen), maar dat er zo'n NPM service in plain text logt is véél erger, gezien m2m 5G Smart IoT Cities.

Deze data hoeft dan niet rechtstreeks gebruikt te zijn om op NPM te publishen, het kan wel gebruikt worden in off-premise analytics. Hetgeen ook het geval geweest lijkt te zijn, gezien de architecture en impact van de hack, waar 3rd party integrators bij betrokken zijn die ook nog eens fungeren als industry defaults in hun niches binnen het Javascript ecosysteem.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[DutchieSmokah]

Ik schrik hiervan. Vanwege security redenen draaien wij op kantoor al jaren een eigen GIT server. Echter kost dit behoorlijk wat beheer/effort en missen wij hierdoor ook enkele fancy functies in onze deployment pipeline (kunnen we toevoegen maar kost waardevolle development resources die we het liefst enkel aan core business willen wijden).

Om deze reden was ik van plan volgende week te checken wat de kosten en risico's zijn om naar GitLab of GitHub te migreren. Dankzij dit soort nieuws wil ik eigenlijk GitHub al helemaal niet meer overwegen; of is dit te kort door de bocht? Wat is jullie mening?

Anderzijds dwingen dit soort beveiligings-incidenten bedrijven nog een keer extra goed na te denken over hun beveiliging..en zal in dit geval moederbedrijf Microsoft dan wel hun klanten bepaalde eisen stellen en audits initiëren.

[Reactie gewijzigd door DutchieSmokah op 23 juli 2024 13:53]

[Bulkzooi]

@DutchieSmokah Heb je lokaal al de Gitlab Community Edition geprobeerd? Het voegt wel veel toe tov enkel GIT.
klik >> https://about.gitlab.com/install/

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[DutchieSmokah]

Ziet er goed uit @Bulkzooi , kende ik nog niet. Zal het sowieso gaan checken, thanks!

[R4gnax]

Om deze reden was ik van plan volgende week te checken wat de kosten en risico's zijn om naar GitLab of GitHub te migreren. Dankzij dit soort nieuws wil ik eigenlijk GitHub al helemaal niet meer overwegen; of is dit te kort door de bocht? Wat is jullie mening?

Dit voorval bij NPM stamt van bedrijfsvoering nog voor NPM door GitHub overgenomen was; en nog voor GitHub door Microsoft overgenomen was. Totaal ongerelateerd aan hoe de huidige zaken geregeld worden.

Sterker nog; het spreekt zelfs voor Microsoft, dat ze in navolging van de NPM hack, verder zijn gaan kijken in de beveiligingsopzet en gerelateerde zaken en daarbij ook het probleem met het niet wegfilteren van authenticatie-gegevens uit logging geidentificeerd hebben.

[DutchieSmokah]

Helder thanks @R4gnax voor de toelichting! Dit was inderdaad ook het idee wat ik kreeg, dat de overname ervoor gezorgd heeft dat er extra audits dan wel checks hebben plaatsgevonden waardoor dit soort flaters ontdekt worden.

[Viper1995]

Ik snap je gedachtegang, al vind ik het zelf altijd een beetje een lastig verhaal. Aan de ene kant kan je zeggen dat wanneer je dit soort cloud oplossing gebruikt (wat ik zelf al jaren doe zowel werk als privé) je altijd een kans maakt dat het bij die partij mis gaat. Of het nou om Github, Atlassian, Azure DevOps gaat of noem ze maar op. Nu zijn er wachtwoorden gelekt, niet goed uiteraard. Maar ik hoop wel dat mensen onderhand toch doorhebben dat het hebben van MFA wel echt helpt in dit soort situaties.

Daarnaast is het zomaar mogelijk dat morgen iemand een probleem vind in GitLab (of welk pakket je ook gebruikt(, en hier ook goed misbruik van gemaakt kan worden (en ook even er vanuit gaan dat de GitLab vanaf buiten te bereiken is). Dan kan ook zomaar opeens dat er dingen op straat liggen waarvan je het liever niet hebt. Ook moet je zelf de instantie onderhouden om hem veilig te doen, dus je moet actief bezig blijven met je software.

Uiteindelijk is er denk ik geen eentje echt beter, en is het meer iets wat een afweging van meerdere factoren wat het beste is om te gebruiken.

[Bender]

Vanwege security redenen draaien wij op kantoor al jaren een eigen GIT server.

Ik ken uiteraard je team niet, maar ik kan me voorstellen dat de Git gebruikers geen hardcore server beheerders zijn (maar developers).
Hoe goed zijn die developers ten opzichte van een team dat zijn hele werkleven gewijd heeft aan het beheer van een Git omgeving?

Dus hoewel ik je angst begrijpt, is het wellicht juist die angst die meer risico met zich meebrengt.
Aanvullend is het natuurlijk ook een business beslissing, juost omdat je aangeeft dat het kostbare resources kost is het uitbesteden in veel gevallen ook beter.
De vraag is alleen... aan wie (zelf hebben we op alle nieuwe plekken gekozen voor GitLab, legacy keuzes zijn Bitbucket).

[choogen]

Misschien aardig om ergens in de tekst uit te leggen wat npm is...

[OttoRocketman]

Los van het OAuth-onderzoek ontdekte GitHub dat bepaalde inloggegevens in plaintext werden opgeslagen bij een intern loggingsysteem voor npm-diensten. Het gaat hierbij om een 'klein aantal' wachtwoorden.

Ik blijf het verbazingwekkend vinden dat plaintext wachtwoorden gelogd worden. Ik snap ook niet in wat voor use-case je dat zou willen doen.

[kuurtjes]

Ze hebben gezegd dat dit een fout was toch?

GitHub recently discovered that a subset of npm service logs stored in our internal logging system contained data that was not properly sanitized to remove credentials received in requests to npm services.

https://github.blog/2022-...rity-update-oauth-tokens/

[Reactie gewijzigd door kuurtjes op 23 juli 2024 13:53]

[kodak]

Maar het legt niet uit hoe het mogelijk was en legt niet uit waarom ze dat niet eerder door hadden. Fouten kunnen gemaakt worden, maar dan moet wel duidelijk zijn wat de keuzes waren dat de mogelijkheid en gebrek aan controle kon bestaan. Anders is het te makkelijk om te beweren dat het fouten waren. Het valt namelijk niet zomaar een fout te noemen als er eerder keuzes gemaakt zijn dat het mogelijk was, dat er geen of onvoldoende controle op was en dat dat kennelijk kon bestaan tot het mis ging.

[R4gnax]

Maar het legt niet uit hoe het mogelijk was en legt niet uit waarom ze dat niet eerder door hadden.

Triviaal voorbeeld is dat je aan request/response logging doet en de scrubbing logica niet alle cases afdekt voor het wegfilteren van authenticatie-gegevens. Als je nagaat dat er miljoenen zo niet miljarden requests op een dag richting NPM gaan, wordt het ondoenlijk om die allemaal met de hand te gaan controleren.
En als je dan één of twee randgevallen niet schoon schrobt, heb je op een maand tijd toch een aanzienlijk aantal van zulke 'oopsies' in je logs zitten, zonder dat je het ooit wezenlijk door zult hebben als je er niet specifiek naar op zoek gaat in een audit.

De les hier zal dus ook waarschijnlijk wel zijn om vaker doelbewust een bisectie van een dag of 3~4 uit de logs te pakken en daar in diepte doorheen te gaan kammen om dit soort gevallen tijdig op te sporen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:53]

[kodak]

Het lijkt me dan ook redelijk dat github eens uitleg geeft hoe het mogelijk was dat die wachtwoorden zo opgeslagen werden. Want of ze leken het prima te vinden, of het was niet de bedoeling terwijl er zowel te veel mogelijk was als dat er te weinig controle was om te voorkomen of te stoppen.

[Zebby]

Dat wil je dus nog steeds niet doen. Ik heb dit wachtwoord probleem geinig genoeg gehad bij XS4ALL. Een mismatch tussen acceptatie op front-end en daadwerkelijke opslag back-end, waardoor er een stuk werd afgehakt. Ik werk met wachtwoord managers, dus verkeerd intypen zat er niet in.

Wat je als verantwoordelijke ontwikkelaar doet is sowieso zorgen dat je voor dit soort zaken testcases inbouwt die dit soort zaken blijvend controleren bij iedere build. Ook kun je prima zelf op een dev/test omgeving dit soort zaken nabootsen, en op een dev omgeving logging aanzetten is natuurlijk een iets ander verhaal dan op productie.

Als er bedrijven zijn die aangeven plaintext wachtwoorden te tonen op een productie omgeving mag je die direct naar de AP sturen voor een forse boete wat mij betreft, dat is gewoon onverantwoord prutswerk.

[comecme]

Enkel en alleen het loggen van een wachtwoord (zonder een id van de user mee te loggen) lijkt mij niet verboden onder de AVG. Het is namelijk niet herleidbaar tot een persoon.

Natuurlijk is het wel een bijzonder slecht idee om wachtwoorden te loggen.

[Zebby]

Over het algemeen log je wel meer zaken, zoals login (pogingen) inclusief IP, waardoor er toch met enige aannames data herleid kan worden. Zie een potentieel data lek nooit als een los gegeven, maar als iets dat gekoppeld gaat worden aan de grotere databases om zo een geheel te vormen.

En of het nou mag of niet, ik zet er grote vraagtekens bij of het verstandig is.

[YGDRASSIL]

Als je het tijdstip van de loginpoging meelogt kun je met andere info zoals providertraffic misschien al weer snel een link leggen wie het was.

En als je 1 wachtwoord hebt en ergens anders een lijst met accounts kan krijgen hoef je voor elk account maar 1 poging te doen en ben je ook binnen bij het account van dat wachtwoord.

Dus ook wachtwoorden loggen zonder accounts is een bijzonder slecht idee.

[Bor]

Interessant leesvoer voor je: Is een (gehasht) wachtwoord een persoonsgegeven?

[comecme]

Interessant artikel. Leuk dat het van voor de AVG is. Het stelt dus dat juist het wachtwoord een persoonsgegeven is en de hash niet.

Ik zou juist denken dat de hash een persoonsgegeven is, aangezien je de hash kunt opzoeken in een database waar vervolgens staat welke gebruiker het betreft.

Aan de andere kant kun je adhv het wachtwoord de hash opnieuw berekenen en daarmee dus de gebruiker vinden in de database.
Met een salt erbij wordt het natuurlijk anders, dan kun je met alleen het wachtwoord niet de hash bepalen en dus niet de gebruiker opzoeken.
Bezit je de gesalte hash, dan kun je wel weer zoeken.

Blijft dus moeilijk te zeggen wat in deze een persoonsgegeven is. Maar hoe dan ook is het geen goed idee om een wachtwoord (of de hash) te loggen.

[Reactie gewijzigd door comecme op 23 juli 2024 13:53]

[Puddi Puddin]

Support horen de wachtwoorden niet in te kunnen zien evenmin als de ontwikkelaars.

[Reactie gewijzigd door Puddi Puddin op 23 juli 2024 13:53]

[Bulkzooi]

@Verwijderd Wellicht zijn er company policies die uitzonderingssituatie's beschrijven, bv. door een gerechtelijk bevel. Of vanuit de marketing afdeling. En dan kan zoiets zomaar een onvoorzien implementatie "artefact" opleveren.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[Puddi Puddin]

Tja dan stemmen ze er dus in mee dat bij een datalek ook wachtwoord gelekt kunnen worden.

[Bulkzooi]

klopt, maar enkel in sommige gevallen kwamen de plain-text gegevens in de NPM-log terecht. Dus een Microsoft account die de logging-facility inricht met een specifiek doel voor ogen.

De details zullen later wel naar buiten komen, maar toch merkwaardig dat Microsoft een separaat probleem mee communiceert in een NPM-hack. Alsof ze zichzelf vrijpleitten van implementatie- en gebruikersfouten terwijl het probleem van plain-text wachtwoorden opslaan én exposen zo oud is als Methusalem.

Opslaan, het loggen zelf, is niet hetzelfde als lekken; dan is er meer fout.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[wica]

Dat vind ik geen goede reden om wachtwoorden in plain tekst op te slaan in je logs (überhaupt nergens).

De enigste reden, dat ik kan bedenken, is dat iemand vergeten is een debug optie uit te zetten.

[Potter]

Dan nog zou je denken dat er tenminste een iemand in de database heeft gekeken tussen 2017 en nu? Ze zeggen dat PBKDF2 sinds 2017 niet meer wordt gebruikt dus neem aan dat ze toen bezig waren geweest in de database.

[Bulkzooi]

@wica De horror van plain-text wachtwoorden opslaan is zo oud als Methusalem, maar tegenwoordig moet je er inderdaad werk in stoppen om het te vernaggelen. De SAML en PAM authenticatie modules gebruikt met oAuth hebben zwaktes en afhankelijkheden, die ook allemaal hun problemen hebben. Eén van de redenen waarom doas snel aan populariteit won t.o.v. sudo en fundering van de suckless philosophy, hetgeen een minimalistiche verfijning is van de Unix filosofie om alles te outsourcen.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[xiphoid]

Dat is natuurlijk gewoon vragen om problemen. Er is 100% geen rede voor iemand om de wachtwoorden in te zien. Support is tevens niet verantwoordelijk voor het niet kunnen gebruiken van een password manager of intypen van iets in het toetsenbord. Support moet niet verder gaan dan helpen met resetten, zodat de persoon van de account zelf de volgende stap kan nemen.

[Bender]

Ik heb met alle manieren proberen te bedenken op wat voor wijze het loggen van wachtwoorden in plain-text handig zou kunnen zijn.. tot het vinden van software bugs aan toe.
Maar ik kan geen enkel praktisch nut of voordeel bedenken om dit überhaupt te doen.

[Sando]

In deze back-up zat ook een archief met npm-gebruikersinfo uit 2015.

En zo kan bijna geen enkel bedrijf redelijkerwijs voldoen aan artikel 17 van de AVG: Het recht om vergeten te worden.

[Bender]

Daar kan ook geen enkel bedrijf aan voldoen, gezien je van de belastingdienst een bewaarplicht hebt van 7 jaar.
Dat recht om te vergeten bestaat daardoor simpelweg niet.

[Groningerkoek]

Wat een bedrijf van je moet houden volgens de bewaarplicht is doorgaans veel minder dan wat ze van je hebben.

[Bender]

Nee hoor.
Veel bedrijven waar jij iets van koopt hebben alleen je factuur informatie en die bewaren ze .

Waar je naar verwijst zijn platforms zoals Facebook, maar de meeste bedrijven zijn niet zo ver gevorderd met hun data.

[Groningerkoek]

Een winkel heeft geen bewaarplicht voor NAW gegevens, die worden verzameld om een product af te leveren en kunnen mits kenbaar gemaakt daarna worden bewaard voor bijvoorbeeld een nieuwsbrief maar van de wet hoef je NAW niet te bewaren.

[Bender]

Daar denkt de belastingdienst helaas toch echt anders over.
https://www.belastingdien...maken/uw_facturen_bewaren

Als jij in de supermarkt een pak appelsap koopt heb je gelijk.
Als je in een webshop iets koopt,waar verzendgegevens gevraagd worden en je een factuur krijgt moet de webshop dit dus 7 jaar bewaren.

[Groningerkoek]

Als ik als privé-persoon iets bestel krijg ik bijna nooit een factuur, ik betaal vooruit en krijg een lever- of bestelbon, er is ook geen factuurplicht bij dergelijke transacties.

[Bender]

Hoewel ik nog niet eerder een webshop gezien heb die geen facturen geeft, wil ik je die in het voordeel van de twijfel geven.

Echter vallen pakbonnen ook onder de basisgegevens en dienen deze dus ook bewaard te worden. Daar staat je adres op want anders kan het immers niet naar je toe gestuurd worden.

[Reactie gewijzigd door Bender op 23 juli 2024 13:53]

[Groningerkoek]

Om gelijk maar de grootste te benoemen. Bol.com bijvoorbeeld geeft geen facturen tenzij je daar zelf actief om verzoekt.

[Bender]

Ook al maakt Bol.com in sommige gevallen geen facturen, het maakt pakbonnen en financiële transacties (jouw betaling) en deze moeten ze 7 jaar bewaren.

[comecme]

Een bedrijf waar ik alleen een online account heb waar ik niet voor betaal hoeft m.i. niets van mijn gegevens te bewaren voor de belastingdienst.

[Bulkzooi]

Apart, double or parallel logging, hetgeen zéér resource intensief is.

Los van het OAuth-onderzoek ontdekte GitHub dat bepaalde inloggegevens in plaintext werden opgeslagen bij een intern loggingsysteem voor npm-diensten

Uit de blogpost;

Unrelated to the OAuth token attack, we also recently internally discovered the storage of plaintext credentials in GitHub’s internal logging system for npm services. We mitigated this issue and purged the logs containing the plaintext credentials prior to this attack on npm. Our initial and current investigation has concluded that only internal GitHub employees had access to this data at the time of exposure.

Nog aparter is dat in sommige gevallen de gegevens in de NPM log terecht kwamen als plain text, buiten oAuth om. Lijkt er op dat een Microsoft account de logging facility als malware endpoint, passwordstealer, gebruikte of zoiets.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 13:53]

[analog_]

Uit interesse; NIST certificeert niet zelf; https://www.nist.gov/stan...rity-validation-program#1 Daarom denk ik dat je minder snel OSS certified setups ziet en (denk ik) omdat OSS het danig modulair maakt dat zonder commerciële rendable appliance vorm het niet verder komt dan compliant oplossingen.