PyPI laat nieuwe projecten weer toe na onhoudbare hoeveelheid malware-uploads

PyPI staat nieuwe gebruikers en projecten weer toe nadat die dit weekend tijdelijk stop werden gezet. De Python Package Index zette zaterdag alle nieuwe gebruikersregistraties stil omdat er grote hoeveelheden malware in Python-projecten werden verspreid.

De Python Package Index schrijft op een statuspagina dat de tijdelijke stop sinds middernacht Nederlandse tijd is opgeheven. Die stop begon op zaterdagmiddag. Toen besloot PyPI om de registratie van nieuwe gebruikers en van nieuwe projecten tijdelijk op te schorten. "Het aantal malafide gebruikers en malafide projecten die de afgelopen week in de index zijn aangemaakt, gaat harder dan onze mogelijkheid om daar tijdig op te reageren", schrijven de ontwikkelaars. Dat heeft onder andere te maken met het feit dat verschillende beheerders tijdelijk op vakantie zijn. PyPI verwachtte al dat het probleem na het weekend zou zijn opgelost.

PyPI, de officiële Python-repository, geeft geen details over de exacte betekenis van malicious projects of om hoeveel projecten of gebruikers het dan gaat. Waarschijnlijk gaat het om malware die via de index wordt verspreid. PyPI heeft de laatste maanden steeds vaker last van zulke malware. Soms wordt die dan via dependency confusions verspreid, waarbij een geïnfecteerde Python-library kan worden geüpload naar PyPI. Dat gebeurde in januari van dit jaar nog, al is de dependencyconfusionmethode nog steeds relatief zeldzaam. In de afgelopen weken zijn er ook al remoteaccesstools en reverseshellmalware verspreid via PyPI, al ging het in dat geval om andere soorten aanvallen.

Reacties (30)

[grrfield]

Ik vraag mij af hoe dat werkt dan. Als ik een package nodig heb, ga ik op zoek naar een package die beantwoordt aan mijn specs. Ik lees wat reviews, kijk voor alternatieven en weeg af wat ik het beste gebruik. Ik installeer dus enkel maar packages die 'bekend' zijn. Wie installeert er nu zomaar een 'random' package met in totaal 2 downloads. Ik begrijp het niet.

[GertMenkel]

Veel van dit soort pakketten worden door middel van typo's binnengehaald. In theorie valt er ook nog wat te behalen qua malwareverspreiding met bitflips, al is dat sinds HTTPS minder snel een probleem.

Qua downloads kun je natuurlijk altijd de statistieken faken. Een miljoen keer zelf een pakket van PyPi halen is niet zo moeilijk. Huur een klein botnet om je downloads te verspreiden en je hebt zo je statistieken opgekrikt. Doe dit met een hele boom van kwaadaardige projecten en je hebt ook nog dependents/dependencies als een echt project.

Jij hoeft overigens zelf niet een verkeerd package te installeren wil je getroffen worden hierdoor. Als een dependency van jou dependency een dependency heeft die gehackt is, ben je de sigaar.

Er zijn de nodige audit tools (moet je hopen dat wat hier genoemd is niet van een Chatgpt-bot komt ) maar directe, menselijke verificatie van iedere dependency en de inhoud daarvan lijkt me eigenlijk de enige oplossing. Dat maakt sommige pakketten onbruikbaar omdat ze simpelweg veel te veel dependencies binnenhalen om zelf te controleren; veel machine learning-projecten hebben hier last van.

Slim nadenken over wie je wanneer vertrouwt is hier echt de enige oplossing voor ben ik bang. Iedere automatische tool kan automatisch worden omzeild. Zo min mogelijk dependencies downloaden helpt enorm.

Ook kun je zoveel mogelijk werken binnen containers om de impact ietwat te beperken, al maakt dit dingen als debuggen soms wel nodeloos ingewikkeld en zul je alsnog je API-keys kwijt zijn als een kwaadwillende auteur die met zo'n pakket wil ontfutselen. Hier kun je nog weer een stapje bovenop doen door de code die je uitvoert geen netwerkverkeer toe te staan en iedere netwerkcall te loggen en te analyseren, want vaak hoeven je dependencies geen netwerkverkeer te genereren. Dit moet je dan natuurlijk zowel lokaal als in productie doen, anders helpt dat niet. Eigenlijk kun je zeggen dat de meeste geautomatiseerde oplossingen voor de meeste bedrijven niet praktisch zijn.

Nu moet ik zeggen dat de dependency trees die ik bij Python zie een stuk kleiner zijn dan bijvoorbeeld die van NodeJS en Rust. Ik ga ook niet ontkennen dat ik zelf niet te lui ben voor een hobbyproject de hele dependency tree te verifiëren ondanks dat ik weet dat ik dat zelf wel zou moeten doen. Vroeg of laat zal het vast een keer misgaan, maar voor nu werkt "vertrouw de pakketten die iedereen gebruikt enigszins" me nog gered te hebben.

[nst6ldr]

[...] reviews [...] in totaal 2 downloads.

Ik lees alleen maar eigenschappen die behoorlijk maakbaar zijn. Een volume aan reviews kan je letterlijk kopen en downloads kan je zelfstandig nog fabriceren.

[grrfield]

Je begrijpt me verkeerd. Ik bekijk wie er wat over schrijft op sites zoals stackexchange. ik zoek op het python discord channel en vraag of iemand ervaring heeft met een bepaald pakket. Ik kijk rond in mijn eigen kennissenkring.... Ik baseer me dus niet alleen op wat er op de officiële repository staat. De uitleg en documentatie bij sommige packages op de officiële repo is vaak zodanig karig, dat ik al geen goesting meer heb om uit te zoeken hoe ze werken.

[nst6ldr]

Als ik deze reactie in de context van je eerste vraag plaats ("Wie installeert er nu zomaar een 'random' package met in totaal 2 downloads?") dan kan ik het wel uitleggen: jouw werkwijze is niet die men op de MBO's en hogescholen krijgt aangeleerd. Daar komt het letterlijk neer op 'download and repurpose if you must', wat ook niet mijn voorkeur heeft overigens.

De commerciële sector richt zich op snelheid van deployment, beveiliging is bijzaak.

[Osiummaster]

Sterker nog de meeste packages hebben weer hun eigen sub-package requirements. Als je OpenCV installeert krijg je een hele lijst aan ander spul meegeleverd. Zelfde met vele andere packages. Log4J iemand?

Iedereen die hier doet alsof ze alles volledig nakijken op veiligheid voordat ze het downloaden liegen of tegen ons of tegen zichzelf.

[nst6ldr]

Iedereen die hier doet alsof ze alles volledig nakijken op veiligheid voordat ze het downloaden liegen of tegen ons of tegen zichzelf.

Dat valt reuze mee, het ligt er maar net aan welke dependency je download. Waar ik werk doen we deze controles dus wel, in het slechtste geval bouwen we de componenten zelf - waar ik overigens niet compileren mee bedoel want dat doen we altijd.

Een groot deel is ook te ondervangen met de open source community overigens.

[Osiummaster]

Een groot deel is ook te ondervangen met de open source community overigens.

Dit is zeker waar. Dat is ook 100% waar ik zelf mijn controle neerleg. Meeste grote packages krijgen wel een grondige check van een enthousiaste contributor. Soms kan ik dat zelf zijn maar meestal niet.

Individuele checks doen op elke gebruikte packagezou waarschijnlijk een full-time baan vereisen. En zelfs dan is er geen zekerheid.

Als een package meer dan 500 sterren op Github heeft en er niet heel verdacht uitziet dan druk ik samen met alle andere devs van wereld gewoon blindelings op download. Niemand op deze wereld heeft de tijd om voor elke package alle code na te lezen. Dan zou ik ook de Linux kernel en Ubuntu volledig moeten doorpluizen. Simpelweg onmogelijk.

[Reactie gewijzigd door Osiummaster op 31 juli 2024 10:51]

[starfight]

Je vergeet dat het ook om name confusion gaat waar ze gebruik maken van simpelgemaakte typo's.
Bijvoorbeeld iemand maakt het project requets, jij wil in je project requests importeren maar maakt een typfout. Zo haal je onbedoeld het geinfecteerde project binnen, en omdat deze waarschijnlijk doet wat je wil (+ een malwarelading) is de kans kleiner dat je dit gaat ontdekken.

[Alfa1970]

Ik snap wat je zegt,
Maar, wat doe je als er geen kennis is binnen je kennissenkring?
Dan gebruik je Google? Stackoverflow?
En dat zijn nu met name de bronnen waardoor je in problemen kan komen.
Google is met stellige zekerheid een probleem, door een klein beetje geld er tegenaan te gooien kun je er zorg voor dragen dat jouw oplossing bovenaan komt te staan voor een bepaalde zoekterm.
Dat kan al voor een kleine 50 euro, gratis als je een van de vouchers gebruikt die vrijwel elke maand in diverse magazines zitten.
Stack overflow is op dezelfde manier te beïnvloeden waarop PyPi te beïnvloeden is, door gewoon een random fake probleem te posten, en met een ander account zogenaamd een oplossing aan te bieden met een linkje naar je malicious bibliotheek.
ChatGPT is een perfecte tool om dergelijke onzin te produceren.

En ChatGPT zelf zou ook een bron van een dergelijk probleem kunnen worden.
Want wat garandeert jou dat de oplossing die wordt aangeboden door ChatGPT niet malicious van aard is?
En for that matter, Copilot?
Heeft iemand eraan gedacht dat er niet makkelijk zichtbare defecten kunnen worden gecreëerd door gebruik te maken van dit soort tools die at random stukjes code aan elkaar plakken die uit een of meerdere online projecten worden gevist.
Er zit zeker malicious code in Github. Denk maar aan proof of concepts.

Alleen als je zelf heel goed weet waar je mee bezig bent kun je zien dat de code die een dergelijke tool aanbied gaten maakt in je beveiliging.
Maar de meeste gebruikers van deze tools zullen juist die ontwikkelaars zijn die nog niet zo goed zijn...

[ddofborg]

Voor mij de vraag: hoe je zelf als developer ervoor zou kunnen zorgen om de kans op het downloaden van een malicious project nihil te maken? Zijn er tools voor? Ik kan mij voorstellen dat iemand gewoon op pypi vanuit Google komt en gewoon een pakketje download om te gebruiken.

[Morrar]

Er zijn een aantal tools die daarbij kunnen helpen inderdaad, bijvoorbeeld packages als `pip-audit` en `safety` die je omgeving kunnen scannen op kwetsbaarheden. Deze tools werken ook op een `requirements.txt`, zodat je kunt checken voordat je installeert.

Probleem is wel dat deze scanners werken met *bekende* kwetsbaarheden; niet ontdekte / gemelde kwetsbaarheden staan niet in hun database en worden dus *niet* gedetecteert. Als men dus net nieuwe malware in PyPI heeft gezet, dan is de kans dat zo'n scanner deze oppakt eigenlijk nul...

Verder kun je ook nog steeds een kwetsbaar package handmatige installeren natuurlijk via `pip install`... Om dat te voorkomen moet je eigenlijk zelf een mirror opzetten met een whitelist / blacklist. Dit kan met package als `devpi` of `bandersnatch`, maar vergt wel wat extra onderhoud.

Ook belangrijk om dan `pip` goed te configureren zodat 'ie je eigen mirror gebruikt en niet (terugvalt op) de standaard PyPI index. Dit doe je door het index-url naar je eigen mirror om te zetten in de configuratie.

P.S.-je nog: Om je eigen code te scannen kun je nog kijken naar bijvoorbeeld `bandit`; dit scant je code op veel voorkomende "oepsies". Wel zijn de checks vrij eenvoudig te omzijlen, dus kwaadwillende programmeurs ga je er niet mee stoppen.

[Reactie gewijzigd door Morrar op 31 juli 2024 10:51]

[MiesvanderLippe]

Aanvullend daarop is dat sites als Github dit nu aanbieden voor open-source en betaalde projecten.

[nst6ldr]

Gewoon voorzichtig zijn en desnoods zelf statische code analyse doen? In omgevingen als de MIC, overheden en andere combinaties van high profile/high confidentiality/high availability is dit niet ongebruikelijk ofzo.

Vroeger was het al niet verstandig om op kaaza/limewire zomaar van alles naar binnen te hengelen en op te starten, dat is een periode waar we lachend naar terugkijken - maar als het om libraries gaat doen ontwikkelaars in de commerciële sector precies hetzelfde?

[Dan91]

Precies. Naar mijn mening is een vertrouwde en goed gereguleerde library marketplace dan ook een goede oplossing.

[Rouwette]

Of de stroom malware accounts is constant, de medewerkers die ze oplossen en verwijderen niet.

Het kleinere team kreeg het niet bijgebeend.

[Blorgg]

Apart hoe de discussie lijkt te gaan over het personeel dat op vakantie gaat en niet de klootzakken die de malware verspreiden. Laten we de schuld wel even op de juiste plaats neerleggen en de mensen die werken aan PyPI vooral hun vakantie gunnen.

[GertMenkel]

PyPi de schuld geven is lekker makkelijk en goedkoop. Het probleem ligt bij de hele ontwikkelindustrie, dependencies en updates daarvan controleren krijgt amper tijd dus wanneer het weer een keer misgaat is het natuurlijk de schuld van de rest van de wereld dat jij gehackt bent.

Het hele systeem is slecht ontworpen maar de alternatieven kosten meer tijd, geld, en moeite, dus dan is het makkelijk om een zondebok te kiezen. PyPi maakt hier de verandering dus dan is het makkelijk hen de schuld te geven.

[GeeBee]

Tijd voor een overleg over wie wanneer vakantie neemt…
Want is zou toch wel raar en opvallend zijn dat er net op het moment dat er veel beheerders op vakantie zijn, er opeens extra veel nieuwe gebruikers en projecten binnenkomen.
Oftewel: de drukte kun je toch aan zien komen als je met te weinig mensen bent?

[vinkjb]

Er zullen er vast wel paar achter gebleven zijn toch?
Als jij op vakantie gaat sluit de tent ook niet neem ik aan.

[GeeBee]

Jawel, want ik ben docent

[StackMySwitchUp]

Of malware verspreiders wachten tot de bezetting minimaal is om zo'n groot mogelijke impact te hebben.
Het is een bekend fenomeen in de infosec wereld dat aanvallers wachten tot momenten waar veel mensen vrij nemen, de enige manier om je ertegen te wapenen zou zijn om die mensen dan maar geen vrij te geven. Dat is ook niet altijd eerlijk.

[GertMenkel]

Ik zou zeggen: sla de SLA die je hebt afgenomen bij het bedrijf erop na wat hun procedures zijn omtrent dit soort situaties.

Heb je die niet, dan moet je voorbereid zijn op totale downtime. Dit soort kleine probleempjes zijn daar niets bij.

[raro007]

Maar hoe weten ze dat de meeste op vakantie zijn?
Of ze zetten allemaal op Facebook dat ze vakantie gaan of mededeling op te site of 1 ontwikkelaar speelt die informatie door aan malware schrijvers.

[The Zep Man]

Maar hoe weten ze dat de meeste [sic] op vakantie zijn?

Die informatie is redelijk publiekelijk bekend.

Je kan ervan uitgaan dat in het algemeen de meeste mensen op vakantie gaan tijdens vakantieperiodes. Hetzelfde als dat je weet dat rond 12:00 lunchtijd is in veel culturen.

[Reactie gewijzigd door The Zep Man op 31 juli 2024 10:51]

[raro007]

Maar dat betekent niet dat iedereen op vakantie gaat.
Elk wel denkend bedrijf weet je gaat niet met zijn allen op vakantie gaat. En dus criminelen gaan daar van ook uit.

[Reactie gewijzigd door raro007 op 31 juli 2024 10:51]

[The Zep Man]

Maar dat betekent niet dat iedereen op vakantie gaat.

Niet iedereen hoeft met vakantie te gaan. Zolang het merendeel maar op vakantie is heb je mogelijk al ruimte voor een kwetsbaarheid. Als het beperkte team bezig is met aanval A, zien zij wellicht aanval B over het hoofd.

[Reactie gewijzigd door The Zep Man op 31 juli 2024 10:51]

[bwerg]

Bestaat dit team alleen uit Nederlandse ontwikkelaars dan?

[The Zep Man]

Bestaat dit team alleen uit Nederlandse ontwikkelaars dan?

Via openbrononderzoek is het mogelijk om te weten waar de meeste beheerders zich globaal bevinden. Ik durf met redelijke zekerheid te zeggen dat vakanties in andere landen ook publiekelijk bekend zijn.

[Alfa1970]

Niet alleen Nederland kent een feestdag tijdens Hemelvaart.
De Duitse buren hadden ook een dagje vrij, en zo zijn er wel meer landen.
Dus als antwoord op je vraag: niet noodzakelijk.