Verschillende openbare en populaire bibliotheken die verlaten zijn maar nog steeds worden gebruikt in Java- en Android-applicaties zijn vatbaar gebleken voor een nieuwe aanvalsmethode voor de softwaretoevoerketen, genaamd MavenGate.
“Toegang tot projecten kan worden gekaapt door het kopen van domeinnamen en aangezien de meeste standaard buildconfiguraties kwetsbaar zijn, zou het moeilijk of zelfs onmogelijk zijn om te weten of er een aanval werd uitgevoerd”, zei Oversecured in een analyse die vorige week werd gepubliceerd.
Succesvol misbruik van deze tekortkomingen zou ervoor kunnen zorgen dat snode actoren artefacten in afhankelijkheden kunnen kapen en kwaadaardige code in de applicatie kunnen injecteren, en erger nog, zelfs het bouwproces in gevaar kunnen brengen via een kwaadaardige plug-in.
Het mobiele beveiligingsbedrijf voegde eraan toe dat alle op Maven gebaseerde technologieën, inclusief Gradle, kwetsbaar zijn voor de aanval en dat het rapporten naar meer dan 200 bedrijven heeft gestuurd, waaronder Google, Facebook, Signal, Amazon en anderen.
Apache Maven wordt voornamelijk gebruikt voor het bouwen en beheren van op Java gebaseerde projecten, waardoor gebruikers afhankelijkheden (die uniek worden geïdentificeerd door hun groupIds) kunnen downloaden en beheren, documentatie kunnen creëren en releasebeheer kunnen uitvoeren.
Hoewel opslagplaatsen die dergelijke afhankelijkheden hosten privé of openbaar kunnen zijn, kan een aanvaller zich op laatstgenoemde richten om supply chain-vergiftigingsaanvallen uit te voeren door gebruik te maken van verlaten bibliotheken die zijn toegevoegd aan bekende opslagplaatsen.
Concreet gaat het om het kopen van het verlopen omgekeerde domein dat wordt beheerd door de eigenaar van de afhankelijkheid en het verkrijgen van toegang tot de groupId.
“Een aanvaller kan toegang krijgen tot een kwetsbare groupId door zijn rechten daarop te laten gelden via een DNS TXT-record in een repository waar geen account bestaat dat de kwetsbare groupId beheert”, aldus het bedrijf.
“Als een groupId al bij de repository is geregistreerd, kan een aanvaller proberen toegang te krijgen tot die groupId door contact op te nemen met het ondersteuningsteam van de repository.”
Om het aanvalsscenario te testen, heeft Oversecured zijn eigen test-Android-bibliotheek (groupId: “com.oversecured”), die het toastbericht “Hello World!” weergeeft, geüpload naar Maven Central (versie 1.0), terwijl er ook twee versies worden geüpload naar JitPack , waarbij versie 1.0 een replica is van dezelfde bibliotheek gepubliceerd op Maven Central.
Maar versie 1.1 is een bewerkte “niet-vertrouwde” kopie die ook dezelfde groupId heeft, maar verwijst naar een GitHub-repository onder hun controle en wordt geclaimd door een DNS TXT-record toe te voegen om te verwijzen naar de GitHub-gebruikersnaam om bewijs van eigendom vast te stellen.
De aanval werkt vervolgens door zowel Maven Central als JitPack toe te voegen aan de lijst met afhankelijkheidsrepository’s in het Gradle-buildscript. Het is in dit stadium de moeite waard om op te merken dat de volgorde van declaratie bepaalt hoe Gradle tijdens runtime controleert op afhankelijkheden.
“Toen we de JitPack-repository boven mavenCentral verplaatsten, werd versie 1.0 gedownload van JitPack”, aldus de onderzoekers. “Het wijzigen van de bibliotheekversie naar 1.1 resulteerde in het gebruik van de JitPack-versie, ongeacht de positie van JitPack in de repositorylijst.”
Als gevolg hiervan kan een tegenstander die de softwareleveringsketen wil corrumperen, zich richten op bestaande versies van een bibliotheek door een hogere versie te publiceren, of tegen nieuwe versies door een versie te pushen die lager is dan die van zijn legitieme tegenhanger.
Dit is een andere vorm van een afhankelijkheidsverwarringsaanval waarbij een aanvaller een frauduleus pakket publiceert naar een openbare pakketopslagplaats met dezelfde naam als een pakket binnen de beoogde privéopslagplaats.
“De meeste applicaties controleren de digitale handtekening van afhankelijkheden niet, en veel bibliotheken publiceren deze niet eens”, voegde de onderzoekers eraan toe. “Als de aanvaller zo lang mogelijk onopgemerkt wil blijven, is het zinvol om een nieuwe versie van de bibliotheek uit te brengen waarin de kwaadaardige code is ingebed, en te wachten tot de ontwikkelaar ernaar upgradet.”
Van de in totaal 33.938 geanalyseerde domeinen bleken er 6.170 (18,18%) kwetsbaar te zijn voor MavenGate, waardoor bedreigingsactoren de afhankelijkheden konden kapen en hun eigen code konden injecteren.
Sonatype, eigenaar van Maven Central, zei dat de geschetste aanvalsstrategie “niet haalbaar is vanwege de bestaande automatisering”, maar merkte op dat het “alle accounts geassocieerd met verlopen domeinen en GitHub-projecten heeft uitgeschakeld” als veiligheidsmaatregel.
Het zei verder dat het een “regressie in het validatieproces van de openbare sleutel” aanpakte dat het mogelijk maakte om artefacten naar de repository te uploaden met een niet-openbaar gedeelde sleutel. Het heeft ook plannen aangekondigd om samen te werken met SigStore om de componenten digitaal te ondertekenen.
“De eindontwikkelaar is niet alleen verantwoordelijk voor de beveiliging van directe afhankelijkheden, maar ook voor transitieve afhankelijkheden”, aldus Oversecured.
“Bibliotheekontwikkelaars moeten verantwoordelijk zijn voor de afhankelijkheden die zij declareren en ook publieke sleutel-hashes schrijven voor hun afhankelijkheden, terwijl de eindontwikkelaar alleen verantwoordelijk zou moeten zijn voor hun directe afhankelijkheden.”
