Quali sono i rischi e le possibilità o gli scenari in cui qualcuno imposta le maschere di repository e/o ip stream per fornire copie di libreria mascherate dell'originale ma iniettate con codice dannoso o dannoso.Quanto è sicuro l'utilizzo di Maven?
Quali sono i passaggi e le pratiche per prevenire tali rischi e possibilità?
suppongo un attaccante dedicato e pieno di risorse potrebbe eseguire un attacco MITM e intercettare tutte le richieste di repository Maven pubblici, con attenzione iniettando dannoso bytecode negli artefatti JAR, quindi ricalcolo e fornendo gli hash SHA1.
Al client, apparirebbe come un artefatto legittimo: il file JAR binario e lo SHA1 corrispondono e saranno uguali anche se controllano i mirror alternativi.
Suppongo che l'unica vera soluzione sia richiedere ai repository centrali di supportare HTTPS (e fidarsi che TLS stesso non sia stato danneggiato).
In alternativa, un approccio pratico potrebbe essere quello di impostare un proxy Maven (Artifactory o Nexus) servito su HTTPS ai client interni. Questo riduce la superficie di attacco e significa che dovrai solo proteggere le linee di comunicazione da quel server al mondo esterno. Periodicamente verificherei che i JAR e gli hash del proxy corrispondano a quelli dei mirror pubblici utilizzando una rete totalmente indipendente e affidabile.
Se davvero, davvero vuole essere sicuro che non sarebbe confidando binari-, invece, si sarebbe scaricando tutti codice sorgente e la revisione li a mano prima di compilare da soli, ma che si presuppone risorse sufficienti e tempo sufficiente per condurre le revisioni e fidati della tua intera catena di strumenti di creazione.
Bene, sicurezza a strati come dicono sempre.
Oppure è possibile utilizzare un approccio di lista bianca –
Non è necessario intercettare tutte le richieste, quanto basta per iniettare un JAR errato. E se lavori su un laptop usando la connessione wifi, non ci vuole un attaccante intraprendente, anche con WPA. – aij
L'attacco MITM non funziona in centrale poiché utilizza le firme PGP per gli artefatti. –
Se si utilizzano repository noti (repository maven centrale, repository jboss) è molto bassa la possibilità di iniettare codice dannoso. Il virus informatico, l'ISP o l'ISP del proprio ISP devono fare confusione nei server DNS o modificare i percorsi di routing per alcune destinazioni. Penso che sia piuttosto improbabile - lo stesso non riguarda solo i repository di Maven ma tutti i servizi Internet (email, http, voip e così via). Lo stesso rischio è lo stesso con il download di JAR direttamente dai siti di progetto.
In ogni caso, se si vuole avere un controllo totale è possibile impostare il proprio repository Maven (http://nexus.sonatype.org/)
Ogni file disponibili nel repository dovrebbe avere MD5 o SHA checksum generato - in questo modo puoi verificare se ciò che hai scaricato è davvero quello che volevi. Ma - se l'attaccante (virus) è abbastanza intelligente da intercettare il trasferimento dei dati e fare casino nei file JAR, sarà anche abbastanza intelligente da intercettare i checksum md5/sha. La difesa contro di esso è di fornire firme PGP sia per checksum che artefatti: gli elementi di rilascio caricati su repository centrale sono obbligati a farlo (file .asc)
L'idea migliore è usare Nexus Professional - si sarebbe in grado di configurare suite di approvvigionamento per controllare la firma PGP su un server a chiave pubblica ogni volta che viene scaricata la risorsa. Maggiori informazioni sulle firme PGP con Maven può essere trovato qui:
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
Posso pensare a diversi scenari, anche se il primo non è specifico per Maven.
cache DNS poisoning
I dati DNS si utilizza per raggiungere i repository standard potrebbero essere avvelenati, causando Maven per scaricare gli artefatti da un repository diverso. Vedi the wikipedia article on DNS cache poisoning.
repository non standard
Qualsiasi repository si aggiunge alla configurazione di Maven potrebbe fornire manufatti contenenti codice dannoso. Previeni questo usando solo quei repository di terze parti di cui ti fidi.
avvelenamento Repository
Sulla base Guide to uploading artifacts to the Central Repository di Maven, sembra che il repository centrale Maven pubblica artefatti da host del repository approvati, quindi la sicurezza di manufatti dipende dal host. Non conosco le specifiche sul processo di diventare un host di repository approvato, ma con così pochi elenchi è probabilmente oneroso.
Inoltre, il repository centrale richiede firme PGP per tutte le distribuzioni, quindi, a meno che un utente malintenzionato non acceda alla chiave privata per un progetto, non penso sia possibile.
Manufatto modifica durante la trasmissione (uomo nel mezzo)
Maven fa verifica automatica di controllo per tutti gli artefatti, quindi l'utente malintenzionato deve modificare il manufatto ed i checksum accompagnamento per iniettare codice dannoso. Non so se riuscirai a impedirlo completamente, ma per assicurarti di prestare attenzione ai checksum, assicurati che la tua politica di checksum non venga ignorata. Vedi lo settings doc.
Come altri commentatori hanno detto, un buon modo per evitare che codice maligno di entrare nel vostro distribuzione di produzione è di utilizzare solo un repository Maven interna per la versione di produzione si basa. Limitando l'accesso all'aggiunta di dipendenze a quel repository, puoi assicurarti che siano tutti verificati a qualsiasi livello tu scelga, ad es. checksum doppio controllo, scansione di origine.
Correlati: http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/ –
Ho scritto una regola del plugin Enforcer per scopi generali per risolvere questo problema: https://github.com/gary-rowe/BitcoinjEnforcerRules –
@GaryRowe Sembra che il tuo plug-in prevenga download successivi che non corrispondono ai checksum registrati da cuocendo i checksum nella build (che riduce la superficie di attacco, che è buona), ma questo non sembra proteggere nel momento in cui la build viene prima creata e la lista di checksum è scritta (o generata). Fondamentalmente, previ che la build avveleni * qualcun altro * giusto? È una corretta comprensione del tuo plugin? – Gus