I repository pubblici di source code, da Sourceforge a GitHub, da Linux Kernel Archives a ReactOS.org, da PHP Packagist a Python Package Index (meglio noto come PyPI) sono una fonte straordinaria (scusate l’aggettivo!) di sistemi operativi, applicazioni, librerie di programmazione e toolkit per sviluppatori gratuiti che hanno comportato grandi benefici all’informatica e all’ingegneria del software.
La maggior parte dei progetti software ha bisogno di codice “ausiliario” che non è parte sostanziale del problema che il progetto stesso sta cercando di risolvere, come ad esempio le funzioni di utilità per scrivere nel log di sistema, produrre output colorati, caricare rapporti di stato su un servizio web, creare archivi di backup di vecchi dati e così via.
In casi come questo si può risparmiare tempo (e beneficiare gratuitamente dell’esperienza di altre persone) cercando un pacchetto già esistente in uno dei tanti repository disponibili e agganciandolo al proprio albero di source code.
D’altra parte, nel caso stiate lavorando a un vostro progetto che include alcune utility che non riuscite a trovare da nessun’altra parte, potreste sentirvi inclini a offrire qualcosa in cambio alla comunità impacchettando il vostro codice e rendendolo disponibile gratuitamente a tutti gli altri.
Il costo della gratuità
Come sicuramente saprete, tuttavia, i repository di source code della comunità comportano una serie di sfide per la cybersecurity:
- Pacchetti popolari che scompaiono improvvisamente. A volte i pacchetti che un programmatore benintenzionato ha donato alla comunità diventano così popolari da costituire una parte fondamentale di migliaia o addirittura centinaia di migliaia di progetti più grandi che li danno per scontati. Ma se il programmatore originale decidesse di ritirarsi dalla comunità e di cancellare i suoi progetti (cosa che ha tutto il diritto di fare se non ha obblighi contrattuali formali nei confronti di chi ha scelto di affidarsi a lui), gli effetti collaterali potranno essere temporaneamente disastrosi, in quanto i progetti di altre persone si “aggiornerebbero” improvvisamente e verrebbe a mancare una parte fondamentale del loro codice.
- Progetti che vengono attivamente sfruttati a fini malvagi. I criminali informatici che scoprono, rubano o comprano le password dei progetti altrui possono iniettare malware nel codice, e chi già si fida del pacchetto un tempo innocuo nel caso scaricasse automaticamente “l’update” disonesto infetterà involontariamente sé stesso (e forse anche i propri clienti) con il malware. I truffatori possono anche impossessarsi di vecchi progetti utilizzando trucchi di ingegneria sociale, entrando a far parte del progetto e mostrandosi molto disponibili per un po’ di tempo finché il manutentore originale deciderà di fidarsi di loro fornendo l’accesso all’upload.
- Pacchetti illegali che si fingono innocui. I truffatori caricano regolarmente pacchetti con nomi sufficientemente simili a progetti noti, in modo tale che altri utenti li scarichino e li usino per errore, in un attacco scherzosamente noto come typosquatting (lo stesso trucco funziona per i siti web, sperando che un utente che sbaglia a digitare un URL finisca invece su un sito fasullo). I truffatori in genere clonano prima il pacchetto autentico, in modo che quest’ultimo continui a svolgere tutte le funzioni dell’originale, ma con alcuni comportamenti dannosi aggiuntivi nascosti in profondità nel codice.
- Comportamento petulante dei cosiddetti “ricercatori”. Purtroppo abbiamo dovuto scrivere più volte di questo tipo di comportamento probabilmente legale, ma eticamente scorretto. Tra gli esempi citiamo uno studente di dottorato statunitense ed il suo supervisore che hanno deliberatamente caricato false patch al kernel di Linux come parte di un esperimento non autorizzato che il team principale del sistema operativo è stato costretto a risolvere, e ricordiamo un “esperto” che si è auto-assolto fornendo l’upload di un falso progetto con trappola esplosiva sul repository PyPI per rievocare il rischio dei cosiddetti attacchi alla supply chain. SC Risks ha poi fatto seguire al suo pacchetto di “ricerca” proof-of-concept altri 3.950 pacchetti, lasciando al team PyPI il compito di trovarli ed eliminarli tutti.
Uploader disonesti
Sfortunatamente, durante lo scorso fine settimana PyPI sembra essere stato colpito da un gruppo di upload automatizzati e illegali.
Il team, forse comprensibilmente, non ha ancora fornito alcun dettaglio su come sia stato condotto l’attacco, ma il sito ha temporaneamente bloccato l’iscrizione di nuovi utenti e ha inoltre impedito agli utenti esistenti di creare nuovi progetti:
La registrazione di nuovi utenti e nomi di progetti su PyPI è temporaneamente sospesa. Il volume di utenti malintenzionati e di progetti dannosi creati su PyPI nell’ultima settimana ha superato la nostra capacità di rispondere in modo tempestivo, soprattutto in considerazione dei numerosi amministratori di questo sito in congedo.
Mentre ci riorganizziamo durante il fine settimana, la registrazione di nuovi utenti e nuovi progetti è temporaneamente sospesa [2023-05-20T16:02:00Z].
Immaginiamo che gli aggressori stessero usando strumenti automatizzati per riempire il sito di pacchetti illegali, presumibilmente sperando che alcuni dei contenuti dannosi sfuggissero all’attenzione dei difensori e rimanessero anche dopo gli sforzi di bonifica del sito, completando così quello che si potrebbe chiamare un Attacco di Bypass della Sicurezza…
… o forse che gli amministratori del sito si sarebbero sentiti costretti a mettere offline l’intero sito per risolvere il problema, causando così un attacco Denial of Service o DoS.
La buona notizia è che in poco più di 24 ore il team ha risolto il problema ed è stato in grado di annunciare: “La sospensione è stata revocata”.
In altre parole, anche se PyPI non ha funzionato al 100% durante il fine settimana, non c’è stato un vero e proprio denial of service contro il sito o i suoi milioni di utenti.
Cosa fare?
- Non scegliete un pacchetto di repository solo perché il nome sembra corretto. Verificate che si stia davvero scaricando il modulo giusto dall’editore corretto. Anche i moduli legittimi a volte hanno nomi che stridono, sono in contraddizione o creano confusione.
- Non scaricate alla cieca gli update dei pacchetti nei vostri sistemi di sviluppo o di compilazione. Testate ed esaminate tutto ciò che scaricate prima di decidere se utilizzarlo o meno. Ricordate che i pacchetti di solito includono script di update-time che vengono eseguiti quando si procede all’aggiornamento. Di conseguenza le infezioni da malware potrebbero essere trasmesse attraverso il processo di upgrade stesso e non come una parte del codice sorgente del pacchetto che viene successivamente dimenticata.
- Non rendete facile agli aggressori entrare nei vostri sistemi. Scegliete password adeguate, usate la 2FA ogni volta che potete e non fidatevi ciecamente dei nuovi arrivati nel vostro gruppo, per quanto siate desiderosi di passare le redini a qualcun altro, quando iniziano a chiedere l’accesso come manutentori.
- Non fate i saputelli. Come ci ricorda questa storia, i volontari della comunità open source hanno già abbastanza problemi con i criminali informatici veri e propri, senza anche dover avere a che fare con “ricercatori” che conducono attacchi proof-of-concept a proprio vantaggio, sia per scopi accademici che per farsene vanto (o entrambi i casi).
