Qualunque precedente storico per le librerie Open-Source come vettore di attacco?

5

Sono curioso di sapere se ci sono storicamente casi degni di nota di persone che hanno deliberatamente piazzato exploit in librerie di codice open-source usate da altri, o qualcosa di relativamente ovvio con la speranza che nessuno controllerà, o con qualcosa di subdolo facilmente sfruttabile come una back-door?

Mi sembra che l'aumento dei tipi di sviluppatori che incollano ciecamente le librerie insieme porterebbe a un mondo in cui questo è molto più comune, ma ho difficoltà a identificare eventuali casi reali in cui si verificano.

Mi sembra che l'iniezione di codice arbitrario non reclamato da terze parti non fidate sia uno sforzo ad alto rischio che le startup stanno gettando in giro con abbandono sconsiderato, quindi mi chiedo solo perché non sono ancora a conoscenza di alcuna catastrofe.

    
posta Kevin Dolan 13.07.2016 - 05:59
fonte

1 risposta

1

Hai ragione, l'iniezione deliberata non è comune nel mondo open source, in parte perché il processo lo rende costoso, ma soprattutto perché non è necessario.

La maggior parte dei progetti open source che ottengono la trazione hanno utenti che esercitano molti casi d'uso e necessitano di custodi attenti che rispondono ai problemi e conoscono i loro committer, quindi le richieste arbitrarie dei nuovi sviluppatori passano attraverso un processo di verifica e per ottenere i loro inserire i codici, i partecipanti devono essere investiti nella crescita della reputazione e nella costruzione della fiducia. Tutto ciò rende difficile l'iniezione deliberata di vulnerabilità.

E non è necessario perché il software è vulnerabile per impostazione predefinita. Dal punto di vista di un aggressore, non vi è alcun motivo per passare attraverso una farsa di fiducia per iniettare vulnerabilità, perché ci saranno già alcuni in qualsiasi base di codice, è sufficiente cercarli. E poiché il codice è aperto, puoi cercarli senza che nessuno sappia che li stai cercando.

Nel mondo closed source / commerciale, l'iniezione è molto più comune, ad esempio:

link

Per quegli aggressori di tale scala è logico costruire e poi sacrificare la fiducia, anche se questo è un esercizio molto costoso. Il famigerato caso di Dual_EC_DRBG è istruttivo, perché si trattava di un'iniezione in un mondo che somigliava all'open source in termini di dinamica, con il risultato che un attore precedentemente affidabile (NSA) che lavorava in un processo aperto senza errori (NIST) ha sacrificato per sempre il proprio proprio e la credibilità del processo. Controlla wikipedia per i dettagli.

Il modello che suggerisci - terze parti che utilizzano un processo che non richiede la fiducia per iniettare attacchi o vulnerabilità - descrive con precisione il modello di consegna per il malware web.

Code di codice arbitrari, non riconoscibili e mirati di terze parti di javascript, flash e così via che forniscono annunci, acquisiscono metriche, forniscono pulsanti di condivisione e fanno tonnellate di altre cose - vengono caricati nel browser per conto del primo dominio di terze parti che l'utente sta visitando, in genere con poca o nessuna consapevolezza dalla prima parte o dall'utente. È molto rischioso per gli utenti e, naturalmente, le catastrofi accadono continuamente:

link

    
risposta data 04.08.2016 - 06:52
fonte

Leggi altre domande sui tag