Qual è lo scopo di fornire checksum dei file per la verifica dei download? [duplicare]
Molti progetti che offrono binari, offrono anche hash (ad esempio SHA256) di quei binari, appassiscono come .ASCfile o direttamente sulla pagina web vicino al binario. Questo non serve a proteggere dalla corruzione causata dalla rete, poiché è garantita dal protocollo TCP.
Dato che il file binario e l'hash vengono scaricati dallo stesso server (esempio da software molto sensibilebitcoin-core ), quali scenari di attacco impedisce questa tecnica?
Se un utente malintenzionato è riuscito a manomettere il binario, perché non sarebbe in grado di modificare il checksum nello stesso modo? Lo stesso vale per l'attaccante che esegue MITM e manomette il download in transito.
Si noti che non sto parlando della firma della chiave pubblica / privata, che è molto più sicura perché l'attaccante dovrebbe anche ottenere la chiave privata del firmatario. Sto solo parlando del punto di fornire checksum / hash insieme ai download. Questo è ancora più strano per bitcoin-core, che ha sia i meccanismi che il pubblico per firmare il file con una chiave privata.
Posso immaginare che un separato, segreto, il monitoraggio bot ospitato su un sistema completamente diverso, potrebbe scaricare il file di firma ogni minuto (dato le sue piccole dimensioni) e controllare che contro le manomissioni, ma non ho sentito parlare di questa operazione.
Risposte
Consente la distribuzione dei dati in blocco attraverso canali non attendibili.
Ad esempio, potresti darmi una chiavetta USB e chiedermi di scaricarla per te durante la notte usando la mia connessione DSL economica, mentre ottieni il checksum dalla pagina web (che hai tirato sul tuo laptop con una costosa connessione a contatore). Riconosco il nome del file, guardo nella mia cartella "file grandi che ho già scaricato", ed eccolo lì, quindi lo copio sulla tua chiavetta USB.
Ottieni il file immediatamente e non devi fidarti di me perché funzioni.
Se l'organizzazione che ospita il file scaricabile pubblica semplicemente il checksum del file insieme al file, allora hai ragione. Se un utente malintenzionato riesce a violare il server e sostituire il file scaricabile con un file dannoso, è banale per l'aggressore sostituire anche il checksum originale con il checksum del file dannoso.
Questo è il motivo per cui la maggior parte delle organizzazioni fa un ulteriore passo avanti e pubblica anche una firma digitale del checksum, in cui la firma digitale viene creata utilizzando una chiave di firma privata associata all'organizzazione e archiviata offline. Ad esempio, vedihttps://releases.ubuntu.com/focal/per le firme digitali delle immagini di Ubuntu realizzate utilizzando la chiave di firma privata di Ubuntu. In questo modo, anche se un utente malintenzionato riesce a violare il server e sostituisce il file scaricabile con un file dannoso, l'attaccante non sarebbe in grado di creare una firma valida per il file, perché la chiave di firma privata è (si spera) non memorizzata su il server.
Sollevi un punto valido riguardo al protocollo TCP assicurandoti che il file scaricato non sia danneggiato. Per quanto riguarda uno "scenario di attacco", e lo userò come una dichiarazione generale, la firma non può essere manomessa nel modo in cui hai proposto, né il file binario può essere manomesso e la firma essere la stessa quando il l'utente finale esegue l'hashing del file. Per esempio:
Un sito web mi dice che il loro programma di installazione ha un hash SHA256 di ABC(spesso me lo dicono proprio accanto al link per il download). Scarico quel file, ne generi l'hash SHA256 e mi dice che l'hash è 123. Ora so che il programma di installazione non corrisponde a ciò che il server mi stava offrendo, per qualsiasi motivo.
Sembra che tu capisca più dell'idea di base alla base di tutto questo, ma ti stai bloccando sull'idea di checksum / hash offerto e perché non può essere manomesso (a meno che non ti fraintenda). Ora, in teoria, se l '"attaccante" potesse compromettere anche il sito Web e modificare l'hash in modo che corrisponda all'hash del file manomesso ( 123nel nostro esempio), il loro attacco avrebbe successo. Ma a quel ritmo potrebbero anche smettere di manomettere il file in linea e ospitare semplicemente il proprio binario dannoso.
Tutto questo non tiene nemmeno conto dei binari firmati o delle controfirme spesso utilizzate nella distribuzione del software.
Sembra che tu stia assumendo che tutte le misure di sicurezza impediscano intrinsecamente qualche tipo di attacco.
Questo è un malinteso piuttosto comune. Tutte le misure di sicurezza aumentano la difficoltà di qualche tipo di attacco, ma solo poche rendono veramente impossibile un particolare tipo di attacco.
Questo è importante perché rendere un attacco più difficile riduce intrinsecamente la probabilità che accada effettivamente. Se l'attacco è troppo difficile o troppo costoso per l'attaccante rispetto al valore percepito del successo, semplicemente non tenterà l'attacco (o si arrenderà a metà strada).
In caso di fornitura di un hash per il download, si ottengono i seguenti vantaggi in termini di sicurezza:
- Gli attacchi MitM diventano solo un po 'più complicati. Devi intercettare e modificare due (o forse più) richieste invece di una sola affinché il tuo attacco non venga rilevato fino a quando non sarà troppo tardi.
- Se l'hashing non viene eseguito all'accesso, gli attacchi al server devono sostituire più di un file o potrebbe anche essere necessario sostituire le cose in due posizioni di rete completamente diverse (ho visto siti che memorizzano gli hash in una posizione separata da i file per questo motivo).
Ottieni anche i seguenti due vantaggi non legati alla sicurezza:
- L'utente può essere sicuro che il file che ha scaricato è quello che avrebbe dovuto ottenere nel caso in cui non ci fosse un attacco. IOW, li protegge dall'ottenere un file danneggiato a causa di cose come la corruzione dei dati inattivi sul server o una cattiva memoria sul server o sul loro sistema locale.
- Fornisce un ragionevole grado di fiducia che i protocolli intermedi non abbiano alterato i dati. Il tipo TCP protegge da questo (ma un checksum a 2 byte per potenzialmente 1k + byte sta per vedere molte potenziali collisioni), ma non tutto usa TCP e l'utente potrebbe non ricevere nemmeno il file dal server di origine (vedi Simon La risposta di Richter per un esempio di questo).
Quindi, nel complesso, ottieni un paio di vantaggi di sicurezza limitati e qualche assicurazione limitata contro un paio di problemi che potrebbero sorgere (se guardi i vecchi post di usenet e BB con i file, a volte vedrai i checksum forniti nel post per questi stessi motivi di non sicurezza). Al contrario, non costa essenzialmente nulla all'operatore del server e non crea nuovi problemi per l'utente, quindi anche se non aggiunge molta sicurezza, è abbastanza facile vedere come vale la pena farlo perché il sovraccarico è essenzialmente inesistente.