Twee Python-libraries zijn offline voor het stelen van ssh- en gpg-sleutels

Twee Python-libraries zijn offline gehaald nadat gebleken is dat zij phishingmalware bevatten. Volgens het beveiligingsteam achter de software gaat het om libraries die misbruik maakten van typosquatting.

De libraries werden dit weekend ontdekt door een beveiligingsonderzoeker. Het team achter Python heeft de libraries daarna offline gehaald, schrijven zij op GitHub. Het ging om een namaakversie van jellyfish waarbij de eerste l als een i werd geschreven, en python3-dateutil, een gekloonde versie van de standaard dateutil-library, die erg populair is. De python3-dateutil-code bevatte zelf geen malware, maar laadde wel jellyfish in die op zijn beurt wel malware bevatte.

In de libraries zat een bestand genaamd hashsum dat werd ontsleuteld naar een bruikbare Python-executable, schrijft ZDnet, dat de malware liet analyseren. De executable probeerde ssh- en gpg-sleutels van een systeem te verzamelen en naar een command-and-control-server te sturen. Buiten de malware werkten de libraries precies zoals de software die zij kloonden.

De python3-dateutil-library stond pas twee dagen online. Voor jeIlyfish was dat wel anders: die was al meer dan een jaar actief. Hoe vaak de malware is gedownload, is niet bekend. Inmiddels zijn beide packages offline gehaald.

Reacties (52)

Lijkt mij dat de effectiviteit typosquatting van Jellifish wat onwaarschijnlijk is, zelfs met autocomplete lijkt het mij dat je de eerste L wel typt dus jel en niet zo heel snel jei. Ook zie ik niet zo heel snel dat je per ongeluk I in plaats van L tikt qua keyboard layout.

Die python3 prefix is dan wel weer slim. Misschien dat het ook gewoon de bedoeling was om die te gebruiken en de andere gewoon proberen onopvallend te houden zo dat het niet zo snel op valt dat je een library mee trekt die niet te vertrouwen is.

Lijkt mij dat de effectiviteit typosquatting van Jellifish wat onwaarschijnlijk is, zelfs met autocomplete lijkt het mij dat je de eerste L wel typt dus jel en niet zo heel snel jei. Ook zie ik niet zo heel snel dat je per ongeluk I in plaats van L tikt qua keyboard layout.

De bedoeling zal wel zijn om nog een andere python-module te uploaden die gebruikt maakt van de foute versie van Jellifish. Als je die andere applicatie onderzoekt is er niks mis mee (anders dan een "typo" in een dependency) en zit er zelfs wat nuttige functionaliteit in zodat mensen die module willen installeren.

Ik denk zeker dat dat de manier is. Het deed mij gelijk denken aan:
https://medium.com/hacker...e-here-s-how-9a8cb347c5b5

I’ve now made several hundred PRs ... to various frontend packages and their dependencies. “Hey, I’ve fixed issue x and also added some logging.”
...
There are a lot of sensible people out there that tell me they don’t want a new dependency, but that was to be expected, it’s a numbers game.
Overall, the campaign has been a big success and my colourful console code is now directly depended on by 23 packages. One of those packages is itself depended upon by a pretty widely used package — my cash cow.

Die laatste zin is cruciaal. Als iemand een dependency toevoegt, kijk je misschien nog in de source daarvan, maar je gaat niet al zíjn dependencies ook nog doorscannen, hoogstens kijk je in het lijstje van dependencies, maar dan valt zo'n typo niet snel op.

(In die blogpost trouwens zie je ook uitstekend dat naar de source kijken ook niet alles zegt )

Veel beginners zullen de libraries installeren nadat ze op een website gelezen hebben hoe dat te doen of als ze bij een probleem op een website lezen dat ze die library moeten herinstalleren.

Als er vervolgens de commando's bij staan om dat te doen en je die commando's kunt kopiëren en plakken in je eigen terminalvenster, zullen er aardig wat zijn die niet doorhebben dat er een hoofdletter i tussen staat i.p.v. een l.

Het enige wat je dus hoeft te doen is op stackoverflow een vraag over een probleem met python te beantwoorden waarbij jellyfish opnieuw geïnstalleerd moet worden, en je hebt aardig wat mensen te pakken.

Ik kopieer stiekem best vaak een code rechtstreeks in m'n terminal ipv dat ik em overtyp. Vermoed dat dat vaker gebeurt dan je denkt.

Same, vooral taken die je eens in de never uitvoert.. bijv. python lib installeren.. vaak zit alles Python al helemaal ingebakken dus je moet maar net een situatie hebben waarbij jellyfish noodzakelijk is.

Het kan toch moeilijk mis gaan als je een font gebruikt waarbij de kleine letter L en hoofdletter i duidelijk verschillend van elkaar weergeven wordt?

Dan moet je wel een verwachting hebben van wat er moet staan. Misschien dat iemand opvat dat jel1yfisch niet goed is, maar hoeveel leken zien het verschil tussen "libi18n-dev", "libl10n-dev" en "libk14n-dev"? (Twee van de drie bestaan echt).

True, een leek gaat dat verschil uitsluitend zien als er letterlijk op internet mee gezocht wordt of show/info-achtige commando's van package managers.

Maar IMO de naamgevingen van de libaries die je noemt zijn al bedroevend.

i18n is zo'n afkorting dat uit een tijd stamt toen schermen 4:3 waren en regels code maximaal 80 tekens lang mochten zijn, zodat internationalisatie een onhandig lang woord is. En dan hoor je tegewoordig op de werkvloer dingen als ie-achttien-en of ie-één-acht-en of eye-one-eight-en. Zucht.

Het is een hele verre gedachten, maar Python is een van de meest gebruikte talen voor AI. Moet je eens voorstellen dat belangrijke AI modellen waar op basis van hele belangrijke beslissingen genomen worden. Denk bijvoorbeeld eens aan Ecologische modellen waarop overheden besluiten nemen beïnvloed worden door hackers, die via Python libraries proberen deze systemen binnen te dringen. Wat dat betreft is Python zelf inmiddels een hele belangrijke target. Lijkt mij dat Python hier wel een strenger review process moet gaan hanteren in de toekomst.

[Reactie gewijzigd door ro8in op 4 december 2019 10:52]

npm (JavaScript), bundler (ruby), ze hebben last van soortgelijke problemen. Over het algemeen valt het met het aantal downloads wel mee. Het is uiteindelijk aan de gebruiker van dit soort libraries om goed op te letten dat ze zorgvuldig externe packages gebruiken. Aangezien de gebruiker in het geval van professionele toepassingen een professional is mag dit ook wel van deze gebruiker verwacht worden dat ze hierin de juiste overweging maakt (in tegenstelling tot een willekeurige gebruiker van een app store). Veel organisaties hebben daarboven nog iets in een CI systeem staan welke dagelijks controleerd of er geen verkeerde packages zijn gebruikt.

[Reactie gewijzigd door :murb: op 4 december 2019 11:26]

Ik denk dat je hier overmatig positief in staat, helaas. In mijn ervaring reviewt vrijwel niemand hun dependencies, ongeacht de taal, ongeacht of het een hobbyproject of een werkproject is, ongeacht hoeveel ervaring iemand heeft met softwareontwikkeling, en ongeacht hoeveel ze betaald worden.

Er is dan ook vrijwel geen tooling voor om dit efficiënt te doen, en het is geen standaard onderdeel van het proces in de meeste organisaties. Dit is echt een cultuuromslag die gemaakt zal moeten worden, willen we dit probleem effectief aan kunnen pakken.

Edit: En om het gebruikelijke argument maar even voor te zijn: nee, het vermijden van dependencies is hiervoor geen oplossing. Het aantal bugs (zowel security bugs als anderszins) dat je voorkomt door gebruik te maken van libraries waarin meerdere gebruikers problemen hebben gevonden en gefixt, is echt aanzienlijk.

Bovendien zal het reviewen van de code in die dependencies nog altijd minder tijd kosten dan het zelf heruitvinden van een wiel, als je het vervolgens moeten fixen van alle bugs meerekent. In de gevallen waar dependencies zo slecht geschreven zijn dat dat niet het geval is, heb je dus ook gelijk je antwoord: dan wil je die specifieke dependency dus niet gebruiken.

Dit is dus echt gewoon een geval van "dependency review moet een gewoonte worden binnen organisaties". Oftewel, een cultuurprobleem, geen technisch probleem.

Dat is overigens geen reactie op jou direct, maar ik heb deze discussie al heel vaak gevoerd, en dit is steevast het argument waar een of andere willekeurige meelezer vervolgens mee aanhaakt

[Reactie gewijzigd door svenslootweg op 4 december 2019 15:28]

Gewoon White source bolt in je build pipeline aan spreken

Jammer dat het geen standalone applicatie is die je lokaal kan draaien, maar een 3rd party service voor je GitHub repo's.

Voor organisaties die liever alles in eigen beheer houden met bijvoorbeeld een self-hosted GitLab, is dat dus geen optie.

Binnen menig bedrijf mag je niet zomaar iedere library binnen halen om onder andere deze reden. Een fatsoenlijke standard library is wat dat betreft nogal belangrijk om je attack surface klein te houden. Ik vraag me echter af of dit soort reviews ook gedaan worden voor talen waar het normaal is om bakken libraries binnen te halen zoals Javascript en Python.

Maar precies dat. Als hacker ben je altijd op zoek naar de zwakste schakel. In Python based systemen zou dat zomaar eens Python zelf kunnen zijn.

Maar je moet dus de typo zowel maken in je pip commando als in de code waarin je het importeert. Lijkt me heel onwaarschijnlijk om beiden verkeerd te doen en daarom ga ik er vanuit dat dit niet heel vaak gebeurd is.

Er zijn genoeg ontwikkelaars die gewoon de cmds vanaf een tutorial/website kopiëren voor gebruikersgemak. Veel makkelijker om mensen dan het verkeerde package te laten downloaden. Met bepaalde fonts valt het niet op op de website, en daarna is het ctrl+v, enter.

"ontwikkelaars" - Fixed.

Ben jij een ontwikkelaar dan? Ik kopieer namelijk nog vaak zat wat dingetjes van stackoverflow oid. En zeker een lijst met commands die ik moet uitvoeren.

In dit geval ja, maar Python libraries aansich kunnen wel intressant zijn om te targeten dus.

Het probleem is NIET python.
Wel de "codeur" (beslist geen programmeur)/hobbyist die blind knippen en plakken toepast.
Van een programmeur/ontwikkelaar mag je verwachten dat er enige controle op het proces en de gebruikte middelen is.

Whitesource bolt....

nice to know....

De python3-dateutil-library stond pas twee dagen online.

Is er geen review proces?

Nee, i.t.t. bv een Appstore, zijn uploads direct beschikbaar op PyPi. Dit is denk ik ook een beetje inherent aan opensource. Misschien dat een heel basale malware/virus scan gedaan wordt op de uploads, maar geen handmatige review. Een review process zou de ontwikkelsnelheid behoorlijk blokkeren, ook gezien het een tijdrovende klus is om elke change in elke package te controleren en evalueren en open source vaak van vrijwilligers afhankelijk is.
Daarnaast moet je niet alleen bij het maken, maar bij elke update van iedere package een review doen omdat het anders nog niet veilig is. Je kan denk ik beter inzetten op analyse achteraf en snel ingrijpen hierop ipv blokkeren aan de voordeur. Een review vooraf maakt het ook makkelijker om het kat-en-muis spel wat je dan gaat krijgen te automatiseren als aanvallen omdat je altijd feedback krijgt.

Het feit dat iets open source is heeft niets te maken met de afwezigheid van een reviewproces.

Klopt, bij grote open-source projecten wordt nieuwe code altijd gereviewed door project medewerkers en hobbyisten.

Bij niet zo populaire 3rd party packages van onderandere Node.js NPM, .NET NuGet, Cargo) en hele kleinere frameworks dan moet de developer het echt zelf gaan uitzoeken of alles wel in orde zit. Helemaal als er niet eens documentatie bij zit...

Klopt, veel open source heeft betere review processen dan closed source en vaak geautomatiseerd en publiek.

Waar ik daarmee op doelde is dat omdat het open source is deze 'marktplaats' meer een bazaar is dan een gecureerde winkel (zoals je bij meer commerciële App stores hebt). Iedereen kan zonder veel moeite zijn werk (hoe groot of insignificant ook) erop zetten en publiek maken. Dit bevorderd open source samenwerking en zorgt dat iedereen kan aansluiten.
Een uitgebreid review proces hindert deze vrijheid. Ook omdat de capaciteit er moet zijn om deze reviews te doen. Iets wat met open source projecten vaak een probleem is omdat je financieel beperkt bent en vaak afhankelijk van vrijwilligers.

Het feit dat iets open source is heeft niets te maken met de afwezigheid van een reviewproces.

Maar de kans is veel groter dat deze niet grondig is omdat mensen die het controleren niet financieel gecompenseerd worden. Waarom denk je dat er in Nederland zoveel vrijwilligers worden gevraagd? Omdat er niet genoeg mensen zijn die iets willen doen voor 'nop', zo werkt dit ook bij OS projecten. En nu kan je zeggen, geen goed review proces, geen release, dergelijke verantwoordelijkheid hebben verschillende mensen, maar zeer zeker niet iedereen. En van buiten is het zeer moeilijk om het verschil te zien...

Maar de kans is veel groter dat deze niet grondig is omdat mensen die het controleren niet financieel gecompenseerd worden

Softwareontwikkelingsbedrijven worden óók niet 'gecompenseerd' voor het reviewen van code. Ze verdienen geld met:

• Het toevoegen van nuttige features
• Het vermijden en/of verwijderen van bugs waar mensen last van hebben
• Het vermijden en/of verwijderen van gerapporteerde (CVE) kwetsbaarheden (alhoewel het hier meer om beperken van imago- of financiële schade gaat, maar dat levert dus ook geld op)

Voor zover code-review een nuttige en rendabele manier is om een van die doelen te bereiken, zullen ze dat dus doen, maar niet méér dan dat. Uiteindelijk moet er wel geld verdiend worden, en dat lukt niet met 'nutteloze' reviews" dwz reviews waarvan het nut niet aangetoond kan worden

[Reactie gewijzigd door RJG-223 op 4 december 2019 17:26]

Als een bedrijf en software bekend wordt als onveilig of voorzien van malware, zorgt dat voor schade. Zeker in bv. het bankwezen kan dat voor enorme schade zorgen, dus, ja hier wordt op gecontroleerd. En hoewel het bedrijf niet direct geld ervoor krijgt, krijgen ze het wel indirect, de mensen die het controleren worden er wel voor betaald en DAT is het grote verschil.

Als een bedrijf en software bekend wordt als onveilig of voorzien van malware, zorgt dat voor schade. Zeker in bv. het bankwezen kan dat voor enorme schade zorgen, dus, ja hier wordt op gecontroleerd.

Wees toch realistisch. Er zijn (tien?/honderd?)duizenden softwarebedrijven/ontwikkelaars die commerciëel software ontwikkelen. En jij wil beweren dat al die code goed gereviewd wordt ? Dream on. Goed reviewen van een niet-triviaal softwareprojekt kán niet eens. Er zijn talloze manieren waarop zaken in een groot complex systeem elkaar beïnvloeden, en dus talloze manieren waarom het mis kan gaan. Om nog maar niet te spreken van ingekochte libraries, zeker als die closed-source zijn. Reviewen is een arbeidsintensief projekt, en wel iets meer dan 'controleren'. Je moet dan goed kosten en opbrengsten tegen elkaar afwegen, en accepteren dat er bugs, ook security-bugs, achterblijven.

En een hack zorgt voor schade, maar het komt inmiddels zo vaak voor, dat die schade beperkt is, zeker als er adequaat op gereageerd wordt, en voor één bedrijf niet te vaak gebeurt. En als er een bank gehackt wordt, dan zijn het vooral de aandeelhouders die de pijn voelen. Niet de klanten.

Als je wilt weten wat er gebeurt als een bedrijf herhaaldelijk kwetsbaarheden in z'n produkt heeft, dan moet je maar eens kijken naar Intel, en hoezeer ze afgestraft worden voor al die veiligheidsproblemen in hun processors die steeds weer naar boven komen. Amper dus. Hun grootste probleem is enkel dat ze technologisch zwaar achter lopen, en zelfs dan gaan hun produkten nog steeds als warme broodjes over de toonbank.

En natuurlijk zijn er voldoende voorbeelden te noemen van commerciële software die gereviewd wordt. En zo is er ook heel veel open source die gereviewd wordt - door betaalde mensen. De meeste mensen hebben nog steeds geen geldboom in de achtertuin, terwijl ze wel dagelijks willen eten, een auto willen rijden, en met de kinderen op vakantie willen. Dus ze werken bij bedrijven die hen betalen om open source mee te ontwikkelen. Of om het te reviewen, te testen, etc.

En hoewel het bedrijf niet direct geld ervoor krijgt, krijgen ze het wel indirect, de mensen die het controleren worden er wel voor betaald en DAT is het grote verschil.

Er zijn inderdaad mensen die betaald worden om te reviewen. Dat gebeurt voor zowel commerciële software als open source. Tot zover is er dus geen verschil. Maar in alle gevallen geldt ook dat de meeste mensen niet betaald worden om te reviewen, maar om nieuwe features te ontwikkelen. Het idee dat open source software ontwikkelen onbetaald gebeurt, door vrijwilligers, is een sprookje. Ja, het komt voor, en ik doe het ook af en toe, maar de meeste software, ook open source, wordt ontwikkeld door mensen die er door een of ander bedrijf gewoon voor worden betaald om dat te doen. Nogmaals: dat heeft iets met brood en plank te maken...

Dit is waarom ik standaard alles wat ik met pip installeer sandbox met Firejail. Mocht zo'n programma toch kwaadaardige bedoelingen hebben, is de schade nihil. Ik heb toch net iets meer vertrouwen in packages die uit de officiele repos van mijn linux distributie komen.

Wat hebben ze aan ssh keys als het van een gewone user is die (maybe) toegevoegd is aan sudo? Dan hebben ze alsnog een password nodig om eventueel iets met het systeem te kunnen toch?

Er vanuit gaande dat men root heeft disabled in sshd en een sudo user hebben aangemaakt.

Local attacks zijn al een stuk makkelijker dan remote attacks. Er is dus na verkrijgen van credentials om op het systeem te komen een belangrijke barriere geslecht. Daarnaast kan het systeem dat aangevallen moet worden voor een privilege escalatie grondig bestudeerd worden.

Waarom staat deze comment onder dit artikel?

Met vragen of klachten over advertenties kan je altijd terecht in het forum, waar zoiets meer op zijn plaats is. En de advertentie die jij ziet is door Google bepaald aan de hand van een aantal factoren zoals de inhoud van de pagina en jouw persoonlijk advertentieprofiel.

Waarom is er niet gewoon een knopje bij de reclame om het te melden. IPV naar het forum te moeten.

Ik irriteer me er eigenlijk aan dat als er terechte kritiek is op een artikel of nu reclame, mensen altijd -1 krijgen en naar het forum verwezen worden. Terwijl de reactie box de enige direct beschikbare mogelijkheid is om dit te melden.

Het zou tweakers sieren als je ze een mogelijk geven om dit soort dingen bij het artikel zelf te melden, dan hoeft het niet tussen de reacties te staan.

Inderdaad, dit zou erg fijn zijn als je met een druk op de knop nep nieuws advertentie's kan rapporteren aan Tweakers.
Al kan ik terecht op het forum moet ik nog steeds uitzoeken waar ik precies moet zijn. Erg onhandig en ik snap dat mensen snel opgeven met het doorgeven van dit soort rare advertenties.
Tweakers moet dit gewoon niet willen.

@ro8in Ik denk dat ik helemaal nergens last van heb

@GENETX heeft dit netjes op het forum gemeld en meerdere gebruikers hebben hier last van.
Hij wordt wel degelijk door google gepresenteerd. Daarnaast werk ik niet op een Windows machine die gevoeliger zijn voor malware en virussen.
Je weet niet waar ik op werk en waar ik allemaal wel of niet gebruik van maak. Dus je verhaal over addons is al kul omdat ik die niet gebruik,

- Doubleclick (google) redirect naar currest.com (screenshot genomen op een ubuntu-server installatie)
- Google host zelf de foto van Jort Kelder die voor deze ad gebruikt wordt
- currest.com redirect (via javascript) naar de neppe NOS pagina met een bitcoin scam. Geverifiëerd op meerdere apparaten. Dit is niet via curl te zien omdat het via javascript gebeurt, en ook niet 100% van de pogingen voorkomt.

Dit soort advertenties komen continu door de facebook filters heen. Waarom zou dit nooit voorkomen bij Google?

Ik zie soortgelijke advertenties ook wel eens op andere sites die zaken doen met Google en ik meen zelfs op Youtube (of anders inderdaad op Facebook), dus hij komt duidelijk wel door de Googlereviews. Misschien totdat erover geklaagd wordt, maar toch.

[Reactie gewijzigd door mae-t.net op 4 december 2019 20:23]

Shit happens, daarvoor is dit topic:
Rare of twijfelachtige reclames: geef ze hier door

Assumptions, the mother of all f*ckups. Nee dus, dit probleem zit hem gewoon in de filters voor eht selecteren van advertenties.Doordat iedereen dit netjes meldt zie je dat er meerdere tweakers dezelfde reclame krijgen (zie de link in mijn vorige post maar). Gewoon melden dus!

[Reactie gewijzigd door GENETX op 4 december 2019 11:02]

Tsja, zo'n filter werkt nooit 100%. Ik snap ook nog steeds niet waarom Tweakers zijn gebruikers uitverkoopt terwijl er zo'n mooie traditie was van eigen advertentieselectie (iets dat door de overname door VNU alleen nog maar makkelijker zou moeten zijn geworden; een mediabedrijf is goed in adverteren). Ik draag graag bij door advertenties te bekijken, maar de kans op malware is relatief groot en ik word liever niet door Google getrackt.

[Reactie gewijzigd door mae-t.net op 4 december 2019 20:21]

Gelukkig doet niet iedereen dit, en wordt het verder wel gewoon netjes gemeld, zodat er wat aan gedaan kan worden. Beter een melding waarbij het wel om malware gaat dan geen melding wanneer het niet aan malware ligt.
Het is goed om je plugins te checken, maar als je niet alles installeert wat los en vast zit of shady websites bezoekt, zullen de plugins het probleem niet zijn.

Ik denk dat Google dan last heeft van malware. Nee deze ad zal gewoon door de filters heen geslipt zijn.