Duizenden npm-packages dankzij verlopen domeinnamen over te nemen
Duizenden npm-packages zijn dankzij verlopen domeinnamen over te nemen, zo hebben onderzoekers ontdekt. Npm is de standaard package manager voor de JavaScript-omgeving Node.js en naar eigen zeggen het grootste softwarearchief ter wereld. Npm-packages worden beheerd door maintainers.
Onderzoekers van NC State University en Microsoft analyseerde de metadata van 1,63 miljoen npm-packages. Ze vonden ruim 2800 e-mailadressen van maintainers die aan verlopen domeinnamen waren gekoppeld. Via deze verlopen domeinnamen is het mogelijk om 8500 npm-packages over te nemen.
Een aanvaller zou de verlopen domeinnamen kunnen registreren. Vervolgens een wachtwoordreset voor het maintainer-account uitvoeren en zo het npm-package in handen kunnen krijgen als de maintainer geen tweefactorauthenticatie (2FA) heeft ingesteld. In 2020 bleek dat meer dan negentig procent van npm-ontwikkelaars geen 2FA gebruikte om het eigen account te beveiligen.
Npm-packages kunnen weer door allerlei andere software worden gebruikt, waardoor een gekaapt npm-package grote gevolgen kan hebben. De onderzoekers hebben een overzicht van alle maintainer-accounts waarvan het domein is verlopen en te koop wordt aangeboden gedeeld met het npm-securityteam, zodat de accounts kunnen worden geblokkeerd.
Het probleem met verlopen domeinnamen is niet het enige probleem voor de veiligheid van npm-packages. Zo werden tienduizenden packages gevonden die van installatiescripts gebruikmaken die voor het uitvoeren van malafide commando's zijn te gebruiken, wat in strijd is met best practices. Verder hebben sommige maintainers controle over een groot aantal packages en worden sommige packages weer door veel personen beheerd, wat tot kwetsbaarheden of opzettelijk toegevoegde malafide code kan leiden.
Er is altijd al "whois" geweest maar dit is niet bruikbaar omdat je niet duizenden whois queries per dag kunt doen zonder
geblokkeerd te worden.
En een DNS lookup doen zegt in feite ook niks.
Maar er zijn wel van die domeinkapers die binnen een paar minuten weten dat een domein verlopen is om het snel
te kunnen overnemen en tekoop zetten. Dus voor de incrowd is dit kennelijk wel mogelijk.
Als men bij NPM ook zo'n feed had zou men alle mail adressen waarvan het domein verlopen is meteen kunnen verwijderen
of in ieder geval markeren als niet meer geldig voor een wachtwoordreset.
En dat geldt ook wel voor andere situaties.
Er is altijd al "whois" geweest maar dit is niet bruikbaar omdat je niet duizenden whois queries per dag kunt doen zonder
geblokkeerd te worden.
En een DNS lookup doen zegt in feite ook niks.
Maar er zijn wel van die domeinkapers die binnen een paar minuten weten dat een domein verlopen is om het snel
te kunnen overnemen en tekoop zetten. Dus voor de incrowd is dit kennelijk wel mogelijk.
Als men bij NPM ook zo'n feed had zou men alle mail adressen waarvan het domein verlopen is meteen kunnen verwijderen
of in ieder geval markeren als niet meer geldig voor een wachtwoordreset.
En dat geldt ook wel voor andere situaties.
Wauw, dat is wel ernstig.
JavaScript, dus scriptkiddies. Maar dan nog is het ernstig want die vormen tegenwoordig de hoofdmoot van de beschikbare resources en als je die de vrije teugel geeft dan krijg je dit soort toestanden. :-(
security.nl mail is handled by 10 mx1.certifiedsecure.com.
$ host -t MX invalid.domain
Host invalid.domain not found: 3(NXDOMAIN)
Door MX-records op te vragen richt je je specifiek op email-domeinen (MX=Mail eXchange, geloof ik). Het eerste commando (domein gevonden) geeft exitcode 0 af, het tweede (domein niet gevonden) exitcode 1.
Het is niet moeilijk om een script te maken dat op basis hiervan controleert of de domeinen in een lijst met e-mailadressen wel bestaan.
gederegistreerd worden. Zo moeten die domeinkapers dat ook doen, het is ondoenlijk om alle domeinen te pollen om
te zien of ze vrijgekomen zijn. En zelfs in Nederland wordt ieder vrijgekomen domein meteen geregistreerd, ondanks
dat SIDN zegt dat ze deze informatie niet aan derden verkopen.
Door MX-records op te vragen richt je je specifiek op email-domeinen (MX=Mail eXchange, geloof ik). Het eerste commando (domein gevonden) geeft exitcode 0 af, het tweede (domein niet gevonden) exitcode 1.
Hoewel het niet gebruikelijk is ben je hiermee niet compleet; een domein hoeft geen MX record te hebben om mail te kunnen ontvangen. Er is juist een specifieke MX record die aangeeft dat het domein *geen* mail ontvangt (met "0 ." als waarde).
Daarnaast geeft de aanwezigheid van specifieke records niet aan of de domeinnaam zelf geregistreerd is, en wanneer. Daar kun je beter whois voor gebruiken.
Maar dan nog weet je niet of een domeinnaam verlopen is *geweest*, en dat is het probleem hier. Zulke informatie is achter niet echt goed op te halen. Eigenlijk komt het erop neer dat als je een domeinnaam in gegevens van een package gebruikt je deze domeinnaam voor altijd moet laten bestaan. Tenzij er in de package ecosystemen ooit iets gaat komen om die wereldwijd 'terug' te trekken, maar op de lijst van problemen in package ecosystemen is er heel wat laaghangender fruit voorlopig.
Er is altijd al "whois" geweest maar dit is niet bruikbaar omdat je niet duizenden whois queries per dag kunt doen zonder
geblokkeerd te worden.
En een DNS lookup doen zegt in feite ook niks.
Maar er zijn wel van die domeinkapers die binnen een paar minuten weten dat een domein verlopen is om het snel
te kunnen overnemen en tekoop zetten. Dus voor de incrowd is dit kennelijk wel mogelijk.
Als men bij NPM ook zo'n feed had zou men alle mail adressen waarvan het domein verlopen is meteen kunnen verwijderen
of in ieder geval markeren als niet meer geldig voor een wachtwoordreset.
En dat geldt ook wel voor andere situaties.
PHP heeft niks met NodeJS te maken...
Het zijn pakketten van NodeJS die gehijacked kunnen worden door verlopen domein namen.
Dat is iets heel anders dan bijv. bij een PHP Composer repository, waar alles in Github zit.
gederegistreerd worden. Zo moeten die domeinkapers dat ook doen, het is ondoenlijk om alle domeinen te pollen om
te zien of ze vrijgekomen zijn. En zelfs in Nederland wordt ieder vrijgekomen domein meteen geregistreerd, ondanks
dat SIDN zegt dat ze deze informatie niet aan derden verkopen.
WHOIS informatie bevat de expiration date. Op basis daarvan kun je een script aftrappen dat dat domein probeert te registreren. Faalt het: dan is het domein verlengd. Loopt het door: dan is het domein nu van de cybersquatter.
GoDaddy (een van de grootste domain registrars) heeft hier zelfs een API voor: https://developer.godaddy.com/doc/endpoint/domains
Leuker kunnen ze het niet maken. En gemakkelijker ook al niet.
gederegistreerd worden. Zo moeten die domeinkapers dat ook doen, het is ondoenlijk om alle domeinen te pollen om
te zien of ze vrijgekomen zijn. En zelfs in Nederland wordt ieder vrijgekomen domein meteen geregistreerd, ondanks
dat SIDN zegt dat ze deze informatie niet aan derden verkopen.
WHOIS informatie bevat de expiration date.
Ja maar dat zegt niks! Het kan voor die tijd opgezegd worden.
Bovendien je wilt geen whois doen van alle domeinen waarop je mail adressen hebt, zeker niet in een bestaand systeem.
Na een stuk of 20 queries ben je gebanned door de whois server.
Is het ook een idee om domeinnamen niet opnieuw uit te geven? Zoals het eigenlijk ook met e-mail adressen van mail providers zou moeten? Zodat ze niet door iemand anders gekaapt kunnen worden?
En telefoonnummers ook maar meteen? Zodat je niet met de troep van de vorige eigenaar opgescheept zit?
Is het ook een idee om domeinnamen niet opnieuw uit te geven? Zoals het eigenlijk ook met e-mail adressen van mail providers zou moeten? Zodat ze niet door iemand anders gekaapt kunnen worden?
En telefoonnummers ook maar meteen? Zodat je niet met de troep van de vorige eigenaar opgescheept zit?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
