La OpenSSF (Open Source Security Foundation), creata sotto gli auspici della Linux Foundation per migliorare la sicurezza del software open source, ha messo in guardia la comunità dall'identificazione di attività legate a tentativi di ottenere il controllo su popolari progetti open source, ricordando nel suo stile delle azioni degli aggressori nel processo di preparazione all'installazione di una backdoor nel progetto xz. Analogamente all'attacco a xz, individui dubbiosi che in precedenza non erano stati profondamente coinvolti nello sviluppo hanno cercato di utilizzare metodi di ingegneria sociale per raggiungere i propri obiettivi.
Gli aggressori sono entrati in corrispondenza con i membri del consiglio direttivo della OpenJS Foundation, che funge da piattaforma neutrale per lo sviluppo congiunto di progetti JavaScript aperti come Node.js, jQuery, Appium, Dojo, PEP, Mocha e webpack. La corrispondenza, che includeva diversi sviluppatori di terze parti con dubbie storie di sviluppo open source, tentava di convincere il management della necessità di aggiornare uno dei popolari progetti JavaScript curati dall'organizzazione OpenJS.
Il motivo dell'aggiornamento è stato dichiarato essere la necessità di aggiungere "protezione contro eventuali vulnerabilità critiche". Tuttavia, non sono stati forniti dettagli sull’essenza delle vulnerabilità. Per implementare le modifiche, lo sviluppatore sospettoso si è offerto di includerlo tra i manutentori del progetto, al cui sviluppo aveva precedentemente preso solo una piccola parte. Inoltre, scenari sospetti simili per l'imposizione del loro codice sono stati identificati in due progetti JavaScript più popolari non associati all'organizzazione OpenJS. Si presuppone che i casi non siano isolati e che i manutentori dei progetti open source debbano rimanere vigili quando accettano codice e approvano nuovi sviluppatori.
I segnali che possono indicare un'attività dannosa includono sforzi ben intenzionati, ma allo stesso tempo aggressivi e persistenti, da parte di membri della comunità poco conosciuti di avvicinarsi ai manutentori o ai project manager con l'idea di promuovere il loro codice o garantire lo status di manutentore. Si dovrebbe prestare attenzione anche alla nascita di un gruppo di sostegno attorno alle idee promosse, formato da individui fittizi che non hanno precedentemente partecipato allo sviluppo o che si sono recentemente uniti alla comunità.
Quando accetti le modifiche, dovresti considerare come segni di attività potenzialmente dannosa i tentativi di includere dati binari nelle richieste di unione (ad esempio, in xz, è stata inviata una backdoor negli archivi per testare l'unpacker) o il codice che è confuso o difficile da comprendere. Dovrebbero essere presi in considerazione tentativi di tentativi di modifiche minori che compromettono la sicurezza presentati per valutare la risposta della comunità e per vedere se ci sono persone che tengono traccia delle modifiche (ad esempio xz ha sostituito la funzione Safe_fprintf con fprintf). Dovrebbero destare sospetti anche i cambiamenti atipici nei metodi di compilazione, assemblaggio e implementazione del progetto, l'uso di artefatti di terze parti e l'escalation del sentimento della necessità di adottare urgentemente cambiamenti.
Fonte: opennet.ru