PyPI arkiv med öppen källkod hanterar manisk malström med skadlig programvara

PyPI arkiv med öppen källkod hanterar manisk malström med skadlig programvara

Tidsstämpel: 23 maj 2023 2:45
Källnod: 2674842
by

Offentliga källkodsförråd, från Source till GitHub, från Linux kärnarkiv till ReactOS.org, från PHP Packagist till Python-paketindex, Mer känd som PyPI, är en fantastisk källa (förlåt!) till gratis operativsystem, applikationer, programmeringsbibliotek och utvecklares verktygssatser som har gjort datavetenskap och programvaruteknik till en värld av gott.

De flesta programvaruprojekt behöver "hjälpar"-kod som inte är en grundläggande del av problemet som projektet i sig försöker lösa, såsom verktygsfunktioner för att skriva till systemloggen, producera färgglada utdata, ladda upp statusrapporter till en webbtjänst, skapa backup-arkiv av gamla data och så vidare.

I sådana fall kan du spara tid (och dra gratis nytta av andras expertis) genom att söka efter ett paket som redan finns i ett av de många tillgängliga förråden och koppla in det externa paketet i ditt eget källkodsträd.

I andra riktningen, om du arbetar med ett eget projekt som innehåller några användbara verktyg som du inte kunde hitta någon annanstans, kanske du känner dig benägen att erbjuda något till samhället i gengäld genom att packa ihop din kod och göra den tillgänglig gratis för alla andra.

Kostnaden för gratis

Som du utan tvekan är medveten om, har communityns källkodsförråd med sig ett antal cybersäkerhetsutmaningar:

  • Populära paket som plötsligt försvinner. Ibland blir paket som en välmenande programmerare har donerat till samhället så populära att de blir en kritisk del av tusentals eller till och med hundratusentals större projekt som tar dem för givna. Men om den ursprungliga programmeraren bestämmer sig för att dra sig ur communityn och ta bort sina projekt (vilket de har all rätt att göra om de inte har några formella avtalsförpliktelser mot någon som har valt att förlita sig på dem), kan biverkningarna vara tillfälligt katastrofala, eftersom andras projekt plötsligt "uppdateras" till ett tillstånd där en nödvändig del av deras kod saknas.
  • Projekt som aktivt blir kapade för ondska. Cyberkriminella som gissar, stjäl eller köper lösenord till andras projekt kan injicera skadlig kod i koden, och alla som redan litar på det en gång oskyldiga paketet kommer omedvetet att infektera sig själva (och kanske sina egna kunder) med skadlig programvara om de laddar ner den oseriösa "uppdateringen" automatiskt. Crooks kan till och med ta över gamla projekt med hjälp av social ingenjörskonst, genom att gå med i projektet och vara riktigt hjälpsam ett tag, tills den ursprungliga underhållaren bestämmer sig för att lita på dem med uppladdningsåtkomst.
  • Oskyldiga paket som utger sig som oskyldiga. Skurkar laddar regelbundet upp paket som har namn som är tillräckligt nära välkända projekt som andra användare laddar ner och använder dem av misstag, i en attack skämtsamt känd som typskattning. (Samma knep fungerar för webbplatser, i hopp om att en användare som skriver fel en URL till och med lite kommer att hamna på en falsk look-alike-webbplats istället.) Skurkarna klonar vanligtvis det äkta paketet först, så det utför fortfarande alla funktionerna i originalet , men med ytterligare skadligt beteende begravt djupt i koden.
  • Petulant beteende av så kallade "forskare". Vi har tyvärr varit tvungna att skriva om den här sortens förmodligen-lagliga-men-etiskt-tveksamma beteende flera gånger. Exempel är en amerikansk doktorand och deras handledare som medvetet laddade upp falska patchar till Linux-kärnan som en del av ett obehörigt experiment som Linux-kärnteamet fick reda ut, och en självbetjänande "expert" med smeknamnet Supply Chain Risker som laddade upp ett booby-fällt falskt projekt till PyPI-förvaret som en påminnelse om risken för så kallade supply chain-attacker. SC Risks följde sedan upp sitt proof-of-concept "research"-paket med en ytterligare 3950 paket, och lämnar PyPI-teamet för att hitta och ta bort dem alla.

Rogue uppladdare

Tyvärr verkar PyPI ha hamrats av ett gäng oseriösa, automatiserade uppladdningar under den senaste helgen.

Teamet har, kanske förståeligt nog, ännu inte gett några detaljer om hur attacken genomfördes, men platsen tillfälligt blockerad alla nya från att gå med och blockerade befintliga användare från att skapa nya projekt:

Registrering av ny användare och nytt projektnamn på PyPI är tillfälligt avstängd. Mängden skadliga användare och skadliga projekt som skapats på indexet under den senaste veckan har överträffat vår förmåga att svara på det i tid, särskilt med flera PyPI-administratörer på ledighet.

Medan vi grupperar om under helgen är registreringen av nya användare och nya projekt tillfälligt avstängd. [2023-05-20T16:02:00Z]

Vi gissar att angriparna använde automatiserade verktyg för att översvämma webbplatsen med oseriösa paket, förmodligen i hopp om att om de försökte tillräckligt hårt skulle en del av det skadliga innehållet undvikas och lämnas kvar även efter sajtens saneringsförsök, och därmed slutföra vad du kan ringa en Säkerhet Bypass Attack.

…eller kanske att webbplatsens administratörer skulle känna sig tvungna att ta hela webbplatsen offline för att reda ut det, vilket skulle orsaka en Denial of Service Attack, eller DoS.

Den goda nyheten är att teamet på drygt 24 timmar kom över problemet och kunde meddela, "Avstängningen har hävts."

Med andra ord, även om PyPI inte fungerade till 100 % under helgen, fanns det ingen verklig överbelastning mot webbplatsen eller dess miljontals användare.

Vad göra?

  • Välj inte ett förvarspaket bara för att namnet ser rätt ut. Kontrollera att du verkligen laddar ner rätt modul från rätt utgivare. Även legitima moduler har ibland namn som krockar, konkurrerar eller förvirrar.
  • Ladda inte blint ner paketuppdateringar till dina egna utvecklings- eller byggsystem. Testa och granska allt du laddar ner innan du godkänner det för användning. Kom ihåg att paket vanligtvis innehåller skript för uppdateringstid som körs när du gör uppdateringen, så skadlig programvara kan levereras via själva uppdateringsprocessen, inte som en del av paketets källkod som blir kvar efteråt.
  • Gör det inte lätt för angripare att komma in i dina egna paket. Välj rätt lösenord, använd 2FA när du kan, och lita inte blint på nykomlingar till ditt projekt så fort de börjar meta för att få åtkomst till underhållare, oavsett hur angelägen du är att lämna över tyglarna till någon annan.
  • Var inte en du-vet-vad. Som den här historien påminner oss alla har volontärer i open source-gemenskapen tillräckligt med problem med äkta cyberbrottslingar utan att behöva ta itu med "forskare" som utför proof-of-concept-attacker för egen vinning, vare sig det är i akademiska syften eller för att skryta (eller både).

Tidsstämpel:

Mer från Naken säkerhet