Dit is de vierde aflevering in de serie reeks berichten over kwaadaardige componenten, waar we de Xygeni aanpak voor het omgaan met deze dreiging, als onderdeel van onze dekking voor Open Source Security.
We zagen dat overmatig vertrouwen in open source-componenten van onzekere oorsprong door kwaaddoeners van allerlei aard wordt misbruikt om onverwacht gedrag te leveren dat op de machines van ontwikkelaars kan worden uitgevoerd, CI/CD systemen, of ingebed in de software van de slachtofferorganisatie, zodat het wordt doorgegeven aan de klanten van de organisatie. We hebben ontleed in aflevering 2 de aanvallen waarbij gebruik wordt gemaakt van openbare registers om malware af te leveren en wat we hebben geleerd nadat we hebben gezien hoe de slechte actoren te werk gaan, en in het voorgaande aflevering 3 de controles die werken (en de controles die falen) tegen deze dreiging werden onderzocht.
Nu is het tijd om te kijken naar onze aanpak van het probleem. In deze aflevering presenteren we de strategie die we bij Xygeni volgen voor onze doeleinden Vroegtijdige waarschuwing voor malware (MEW)-systeem. Hoe dit uit meerdere fasen bestaande systeem in realtime werkt wanneer een nieuwe pakketversie wordt uitgebracht, hoe bewijsmateriaal uit verschillende bronnen wordt verzameld, hoe triage wordt uitgevoerd, welke classificatiecriteria we volgen en waarom er nog enige handmatige analyse nodig is om de aard ervan te bevestigen van een kwaadaardig pakketkandidaat. We zullen ook uitleggen hoe we NPM, GitHub, PyPI en andere belangrijke infrastructuren in de open-source-ecosystemen helpen de verblijftijd van malware te verkorten.
Het pipeline
Xygeni Malware Early Warning (MEW) verwerkt continu componenten, hetzij pakket-tarballs voor bibliotheken en frameworks voor ondersteunde programmeerecosystemen zoals JavaScript/Node of Python, Docker/OCI-containerimages, of extensies en plug-ins voor tools zoals IDE's of CI/CD systemen. Dergelijke componenten worden gepubliceerd in openbare registers met verschillende niveaus van gebruikerscontrole.
Hieronder ziet u een schematische weergave van de werking van het systeem:
Het ontdekker proces krijgt de feed van publicatiegebeurtenissen. Een publicatiegebeurtenis is de creatie van een nieuwe versie van een nieuwe of bestaande component. Omdat de populaire registers geen pub-sub-mechanisme bieden voor geïnteresseerde consumenten, wordt dit vaak gedaan door bij het register te peilen naar recente gebeurtenissen. Een uitstekend project van de OSSF, pakketfeeds, Support populaire registers zoals PyPI of Maven Central, en bieden een uniforme, op feeds gebaseerde interface. In MEW hebben we enkele specifieke implementaties toegevoegd die de wachttijd verkorten, bijvoorbeeld met een replica van de CouchDB-database die door NPM wordt gebruikt en die gesynchroniseerd is met de openbare registerdatabase.
Bij Xygeni hebben we een inventaris[1] van alle componenten (direct of indirect) die door de software van onze klanten worden gebruikt. Componentcoördinaten van klanten worden regelmatig aan MEW doorgegeven om de analyses te prioriteren: componenten die door onze klanten worden gebruikt, worden eerder verwerkt. Prioriteit is ook gebaseerd op de reputatie van de uitgever en de kriticiteit van de component, dus componenten afkomstig van uitgevers met een lage reputatie krijgen ook prioriteit.
Het analysers gebruik vervolgens de componenten die in behandeling zijn in de prioriteitswachtrij. Wanneer een componentversie wordt geselecteerd voor analyse, wordt de tarball ervan gedownload uit het register. Houd er rekening mee dat de verpakte, binaire component wordt geanalyseerd: de meeste open source-componenten komen doorgaans uit een open source-repository, vaak op github.com, die alleen voor context wordt gebruikt, en de malware wordt altijd gezocht in de component tarball omdat bedreigingsactoren systematisch liegen over de bronnen die ze beweren te hebben gebruikt om de component-tarball te bouwen die ze vrijgeven.
Vanuit het perspectief van de gebruiker
Ik hoor je denken: hoe kan ik profiteren van het vroegtijdig op de hoogte zijn van een kwaadaardige pakketversie? In de aflevering “Anatomie van kwaadaardige pakketten: wat zijn de trends?” we zagen dat de totale verblijftijd in het bereik van dagen ligt, terwijl de eerste melding van MEW aan klanten die het getroffen onderdeel gebruiken in het bereik van minuten ligt. Met eenvoudige leuning[2] u kunt de build blokkeren (er zijn twee waarschuwingsniveaus, één volledig geautomatiseerd wanneer de engine concludeert dat er potentiële malware is en een latere melding wanneer ons beveiligingsteam door handmatige inspectie de aanwezigheid van malware bevestigt). Wachten tot het register de malware bevestigt en uit het register verwijdert, is doorgaans te laat vanwege de lange blootstellingsperiode.
De organisatie kan een vangrail gebruiken die controleert of er een component is met potentiële malware (op een van de twee waarschuwingsniveaus) of, via API, snel weten of een van de directe of indirecte afhankelijkheden in een softwareproject een kwaadaardige component gebruikt.
Hoe MEW werkt: inside-details
De kern: Malwaredetectie-engine
De analysator gebruikt verschillende detectoren om bewijs van wangedrag vast te leggen. Detectoren combineren statische analyse, mogelijkhedenanalyse en contextanalyse[3], zoals beschreven in het vorige bericht van deze serie.
Bij Xygeni hebben we een technisch team met een lange ervaring in statische analyse, en dit is het belangrijkste verschil met andere antimalwareoplossingen. Merk op dat voor sommige ecosystemen de verpakte tarball broncode bevat (bijvoorbeeld JavaScript- of TypeScript-code voor NPM-pakketten, Python-bronnen voor PyPI-pakketten), of gecompileerde code die dicht genoeg bij de broncode ligt voor statische analyse (bijvoorbeeld bytecode in JAR-bestanden voor Maven) . Voor anderen, zoals containerimages, zijn binaire uitvoerbare bestanden gebruikelijk, dus het infereren van capaciteiten is de gebruikte techniek, samen met conventionele malwaredetectie op basis van YARA-regels en malwarehandtekeningen.
Houd er rekening mee dat eenvoudige technologieën zoals reguliere expressies of handtekeningen niet geschikt zijn voor het detecteren van kwaadaardig gedrag. Stel je voor dat je een dropper of downloader detecteert: een code of binair bestand bevindt zich in het pakket of is gedownload van een extern domein, niet gerelateerd aan de component (kan er één zijn van een grote lijst met domeinen die door de bedreigingsacteur zijn gekocht[4]Of een legitiem domein om detectie te omzeilen). Die code wordt vervolgens uitgevoerd met behulp van een van de functies daarvoor. De code kan worden getransformeerd om de download-URL of de functie die wordt gebruikt voor het uitvoeren van de gedownloade code te verbergen. Om dit te detecteren is een volledige gegevensstroomanalyse nodig, waarbij gebruik wordt gemaakt van de volledige machinerie van statische analyse, of een sandbox-uitvoering (als daadwerkelijk aan de voorwaarden voor het uitvoeren van kwaadaardig gedrag wordt voldaan) dit in het algemeen zou kunnen detecteren.
Bedreigingsactoren volgen dezelfde technieken en er zijn detectoren voor hen ontworpen en geïmplementeerd. Er zijn ook enkele voorbewerkingsstappen, bijvoorbeeld voor het verwijderen van verduistering, die vaak nodig zijn om het verborgen gedrag bloot te leggen.
Context toevoegen
Sommige detectoren gebruiken contextinformatie. Een mismatch tussen de versie in het componentenregister en de tag/release in de bijbehorende GitHub-repository vormt bijvoorbeeld een sterk bewijs dat een slechte actor wellicht publicatiereferenties voor het register heeft verkregen, maar niet voor de GitHub-repository. Aanvallen zoals die welke de verkoper van crypto-portemonnees treffen Grootboek Deze mismatch zou gemakkelijk kunnen worden opgespoord.
A kwaadwilligheidsscore (MS) wordt berekend op basis van de bevindingen van de uitgevoerde detectoren, gebaseerd op de sterkte van het vastgelegde bewijsmateriaal. Niet alle bevindingen zijn hetzelfde en de volgorde van uitvoering is relevant.
Reputatie van gebruikers en componenten
Niet alle open-sourceontwikkelaars zijn gelijk geschapen!
Het kan zijn dat bij een gerenommeerde ontwikkelaar zijn/haar NPM-account wordt gekaapt (dit gebeurt zelfs bij beveiligingsbewuste mensen) en dat er malware wordt gepubliceerd met behulp van dat account. Het is duidelijk dat de reputatie abrupt moet dalen en pas in vergane glorie moet herstellen als het gekaapte account is hersteld en de ontwikkelaar de omstandigheden heeft opgelost die tot de accountovername hebben geleid. Reputatie is moeilijk te verdienen, maar kan in een oogwenk verloren gaan.
Bij MEW hebben we een uitgebreid reputatiemanagementsysteem geïmplementeerd om positief gedrag te belonen en verdachte activiteiten te bestraffen. Dit systeem begint met nieuwe gebruikers in een neutrale houding en past hun reputatie aan op basis van hun lopende activiteiten.
De reputatie van een gebruiker verbetert door positieve acties zoals het onderhouden van actieve sociale media-accounts, het mogelijk maken van multi-factor authenticatie, het regelmatig bijdragen aan projecten en het ondertekenen commits met verifieerbare sleutels. Omgekeerd verslechtert de reputatie als gevolg van vijandige acties zoals het publiceren van malware, het gebruik van wegwerp-e-mailadressen en het niet ondertekenen commits, of ongebruikelijke patronen in bijdragen vertonen.
Het primaire doel van ons systeem is het garanderen van een veilige en betrouwbare omgeving. Dit wordt bereikt door de reputatie van gebruikers dynamisch aan te passen op basis van verschillende factoren, terwijl ook privacykwesties en de beperkingen van verschillende registers worden gerespecteerd.
Er wordt een interne reputatiescore berekend voor de gebruiker (die indien mogelijk lid wordt van het register en het github-account), samen met de kwaadwilligheidsscore die wordt gebruikt tijdens de classificatie van de component die wordt geanalyseerd, en om beter te kunnen kwalificeren wie onder de componentpublicatie valt.
Er is bewijs gevonden voor kwaadaardig gedrag. Dus? Het handmatige beoordelingsproces
De huidige classificatie stelt de geanalyseerde componentversie in in een van de categorieën 'bevestigd kwaadaardig', 'waarschijnlijk kwaadaardig', 'hoog risico', 'laag risico' of 'niet-kwaadwillig' op basis van drempelwaarden voor de scores die de bevindingen en de reputatie van de gebruiker/component samenvatten. Een classificatie in de categorieën ‘hoog risico’ of ‘waarschijnlijk kwaadaardig’ activeert de handmatige beoordeling en eerste melding. De categorie “bevestigd kwaadaardig” wordt ingesteld na handmatige beoordeling of wanneer het bewijsmateriaal overeenkomt met hetzelfde bewijsmateriaal voor een eerdere versie waarvan is bevestigd dat het kwaadaardig is.
Wanneer er voldoende bewijs is voor potentieel kwaadaardig gedrag, wordt een eerste waarschuwing (quarantainewaarschuwing) verzonden naar de getroffen organisaties. Zoals eerder vermeld, kan dit de installatie of build van software blokkeren die afhankelijk is van het in quarantaine geplaatste onderdeel.
Dat creëert een probleem in de interne MEW dashboard zodat beveiligingsanalisten het handmatige beoordelingsproces voor de component kunnen starten. Het team beschikt over gespecialiseerde tools (sandbox, deobfuscators, distributie voor malwareonderzoek, rapportage van malwaretools) om snel de aard van de onderzochte componentversie te beoordelen. Het merendeel van de malware (“de ansjovis” of ongecompliceerde kwaadaardige componenten) wordt beoordeeld
Het resultaat van de beoordeling eindigt in een van beide veilig, dus de automatische analyse-engine heeft een vals-positief gevonden dat wordt gebruikt als feedback voor de machine learning-classificator om het patroon te leren; of kwaadaardig bevestigd, zodat het onderdeel op verantwoorde wijze als schadelijk wordt bekendgemaakt aan het openbare register, na het rapportageproces. Er wordt een tweede melding verzonden naar de betrokken organisaties, die op hun beurt mogelijk de quarantaine van het onderdeel ongedaan maken, of het definitief blokkeren voor hun versie-upgradeproces of de componentfirewall die in hun interne register wordt gebruikt.
Met deze instelling kunnen we dagelijks tienduizenden nieuwe versies analyseren en de tientallen identificeren die waarschijnlijk kwaadaardig zijn, die we vervolgens handmatig beoordelen. Onthoud uit de vorige aflevering dat één op de tienduizend het aantal kwaadaardige componenten is dat we momenteel in het wild zien.
Rapporteren aan het Register
We ontdekten dat de meeste openbare registers, een van de ruggengraat van de open source-infrastructuur, vrij beperkte mechanismen bieden voor het melden van beveiligingsproblemen, en met name kwaadaardige componenten. Wij hebben moeite met het verbeteren van de onderliggende organisatie van het rapportageproces. Normaal gesproken ontvangen we hoogstens een feedback-e-mail van het beveiligingsteam in het register waarin wordt bevestigd dat het onderdeel uit het register is verwijderd.
Soms wordt het register misbruikt, waardoor de gebruiksvoorwaarden worden overtreden, maar er geen kwaadaardig gedrag in de geleverde software wordt veroorzaakt. Dit wordt ook gemeld aan de registratie, maar niet aan organisaties om de geluidsoverlast te beperken.
Toekomstwerk
Er staan momenteel veel verbeteringen op de roadmap. Eerst en vooral, een openbare portal voor de gezondheid van besturingssysteemcomponenten, met name met betrekking tot het gevonden bewijsmateriaal voor mogelijke kwaadwilligheid, is momenteel in ontwikkeling. Dit is bedoeld als een bescheiden bijdrage aan de open-sourcegemeenschap. Blijf kijken.
Een andere voortdurende ontwikkeling is een verbeterde classificatie voor machinaal leren. MEW zal leren van eerdere classificaties. De vector van bevindingen van motordetectoren, plus de afgeleide kwaadaardigheidsscore en reputatiescore voor zowel het onderdeel als de uitgever ("het gevonden bewijs") wordt gebruikt als input voor een machine learning-systeem dat het classificatiemodel bijwerkt. De uitvoervariabele is simpelweg of het register bevestigde of het onderdeel kwaadaardig was. Dit heeft de codenaam "de Oracle" en zal helpen met een meer precisDe kwalificatie is zo ontworpen dat deze betrouwbaar is (hoge recall, d.w.z. geen schadelijke componenten mist), maar met minder foutpositieve resultaten (veilige componenten niet als schadelijk rapporteren).
A kriticiteitsscore zal worden toegevoegd voor prioriteitscriteria, naast het behoren tot de reeks afhankelijkheden van klanten en de lage reputatie van de uitgever. Het is duidelijk dat projecten met meer invloed en belang eerder in aanmerking moeten worden genomen voor analyse. We zullen hier niet het wiel opnieuw uitvinden en het volgende volgen Open source projectkriticiteitsscore.
Ondersteuning voor aanvullende ecosystemen is in ontwikkeling. Wijdverbreide technologieën en tools zoals PHP- of Jenkins-plug-ins staan op de roadmap.
We onderzoeken ook of het handmatige beoordelingsproces kan worden geholpen met AI om de analyse van de paar meer geavanceerde kwaadaardige componenten te stroomlijnen.
In de volgende en laatste aflevering van deze serie, “Open source exploiteren: wat u van de slechteriken kunt verwachten”, zullen we ons concentreren op de nieuwste manieren die de tegenstanders gebruiken om de aanvallen heimelijker, moeilijker te detecteren, gerichter op specifieke industrieën en winstgevender te maken. Zullen ransomware-aanvallen met dit voertuig worden uitgevoerd? Hoe maken de slechteriken gebruik van AI-tools om meer geavanceerde malware te leveren? Zijn populaire topprojecten in gevaar? Dit is om de lezers een idee te geven van deze wapenwedloop en wat ze kunnen verwachten op de korte termijn (tweede helft van 2024) en de middellange termijn (2025).
We sluiten af met enkele gedachten over welke kleine stapjes de gemeenschap zou kunnen zetten zonder de openheid van de open-sourcewereld al te veel te veranderen. Een efficiënter mechanisme voor het melden van malware aan openbare registers en het delen van bewijs van potentieel kwaadaardige componenten met de registers en de gemeenschap zou bijvoorbeeld een kleine stap in de goede richting zijn in de richting van het doel om de deuren te sluiten voor bedreigingsactoren.
Malware in open-sourcecomponenten mag de enorme voordelen die de open-sourcegemeenschap onze samenleving heeft gebracht niet verstoren.
- [1] Onze scanner detecteert open-sourcecomponenten waarnaar wordt verwezen door de geanalyseerde softwareprojecten, zodat de volledige up-to-date afhankelijkheidsgrafiek bekend is, tenminste voor projecten die regelmatig worden gescand. De Xygeni OSS onthult een API die klanten ook kunnen gebruiken tijdens het op de witte lijst zetten van een interessant onderdeel, inclusief informatie over kwetsbaarheden en kwaadaardig bewijsmateriaal.
- [2] Een vangrail kan de constructie verbreken als een toestand wordt gedetecteerd die overeenkomt met beveiligingsproblemen. Beveiligingsbevindingen zoals een kritieke en bereikbare kwetsbaarheid of het gebruik van een in quarantaine geplaatst onderdeel kunnen ernstig genoeg worden geacht om de build van de getroffen software te verbreken.
- [3]Onze beveiligingsanalisten voeren de component of de bijbehorende installatiescripts indien nodig uit in een sandbox-omgeving. MEW voert echter geen dynamische analyses uit, voornamelijk omdat het kwaadaardige gedrag niet altijd wordt uitgevoerd bij gerichte aanvallen en vanwege de ontwijkingslogica die bedreigingsactoren gebruiken om dynamische analyses te omzeilen.
- [4] Deze techniek kreeg een naam, Registered Domain Generation Algorithms of RDGA, en nieuwe dreigingsactoren zoals de zogenaamde Revolver Konijn investeerde maar liefst 1 miljoen dollar in 500 domeinen, wat aantoont hoe winstgevend de cybercriminaliteitsindustrie is.
