L'hashing di un file da un sito Web non firmato fornisce un falso senso di sicurezza?

So, if you're downloading a file from what is effectively an unauthenticated source, and validating it with a hash from the same source (or even another unauthenticated source), what is the real value of hashing the file?

L'hash fornito ti consente di ricontrollare che il file scaricato non è stato danneggiato accidentalmente durante il transito o che il file scaricato da un'altra fonte (un mirror più veloce) è lo stesso del file disponibile per il download su questo sito.

Tuttavia, non c'è davvero molta sicurezza aggiuntiva. Un cracker sufficientemente esperto può sostituire il file con una versione mal intenzionalmente modificata e l'hash con uno che corrisponde al file modificato; oppure può MITM le richieste sulla rete e sostituire sia il file richiesto con il proprio che l'hash con il proprio.

Il vantaggio è davvero limitato. Come hai sottolineato, se puoi sostituire una cosa su un sito, puoi probabilmente sostituirla entrambe.

Questo, tuttavia, ha alcuni vantaggi:

• Consente ad altri siti di ospitare file di grandi dimensioni con integrità verificata. Con ciò posso prendere il file da una terza parte casuale a cui non ho motivo di fidarmi e verificare ancora che si tratti di un buon file basato sul sito di origine (che potrebbe avere una larghezza di banda limitata).
• Se il tuo sito è abbastanza popolare, è probabile che ci siano abbastanza copie del vecchio hash per confermare rapidamente un compromesso per il pubblico, anche tramite archive.org e varie cache del motore di ricerca.

Anche se si ottiene maggiore sicurezza con la firma di file con una coppia di chiavi pubblica / privata, il vantaggio pratico per la maggior parte delle applicazioni non è maggiore con una chiave che senza. Se inserisco la mia chiave sul sito Web e firmo tutto invece di postare l'hash, un utente malintenzionato può ottenere lo stesso effetto sostituendo la chiave come è stato fatto sostituendo l'hash. Progetti veramente grandi che hanno una distribuzione indipendente hanno bisogno di questo strato extra (mi viene in mente Debian), ma penso che pochi ne trarrebbero beneficio.

Affinché l'hash abbia un valore relativo alla sicurezza, le due seguenti condizioni devono essere soddisfatte entrambe :

• il valore hash deve essere distribuito attraverso un protocollo che garantisce l'integrità (ad esempio HTTPS);
• il file scaricato deve non essere distribuito attraverso un protocollo che garantisca l'integrità;

perché, se il file viene servito anche con HTTPS, l'hash tende a essere inutile: SSL garantisce già l'integrità durante il trasferimento.

L'hash non protegge da un utente malintenzionato che prende il controllo del server, in quanto potrebbe modificare l'hash proprio come potrebbe modificare il file.

Un esempio dell'utilità dell'hash pubblicato è quando scarichi il file ad una certa data, e poi vuoi controllare in seguito che la copia che hai sia corretta, perché non ti fidi necessariamente l'integrità della tua memoria locale (ad esempio era su una chiave USB che avrebbe potuto essere temporaneamente rubata da una persona malintenzionata). Un altro esempio è quando il download stesso proviene da una rete p2p, perché tali sono molto efficienti per distribuire il software di massa a molti client (questo è ciò che fa Blizzard Downloader): usa p2p per ottenere il file, poi ottieni il piccolo valore di hash dal sito HTTPS principale. Un terzo esempio (che io incontro professionalmente) è quando si costruisce un sistema affidabile in condizioni di audit pesanti (ad esempio, creando una nuova CA radice): si desidera che l'auditor sia in grado di verificare che il software utilizzato sia autentico . Se un file hash è distribuito (tramite HTTPS), l'auditor deve semplicemente controllarlo con un archivio locale; in caso contrario, l'auditor deve essere testimone dell'intero download. Date le tariffe orarie dei revisori, è preferibile l'hash.

Hai ragione che avere un hash crudo è di beneficio limitato, dal momento che devi anche distribuire in modo sicuro l'hash e la maggior parte delle persone non sa come controllarlo correttamente o navigare tra i molti possibili problemi.

Il modo giusto per ottenere una buona sicurezza è utilizzare la tecnologia a chiave pubblica per firmare gli hash e integrarli perfettamente nell'intero schema di distribuzione del software. È ancora necessario distribuire in modo sicuro la chiave pubblica, ma ciò può essere fatto una sola volta, ad es. quando il sistema operativo è installato. Presumo che sia essenzialmente ciò che viene fatto con Windows e MacOS per gli aggiornamenti del sistema operativo e alcuni pacchetti importanti come Office.

La cosa migliore è che quasi tutto il software necessario è coperto dalle stesse chiavi standard. Questo è essenzialmente ciò che accade con la maggior parte delle distribuzioni di software open source, come Debian, Ubuntu, Red Hat, Suse, ecc. Distribuiscono in modo sicuro letteralmente decine di migliaia di pacchetti, tutti automaticamente firmati con chiavi gestite come parte della distribuzione, e quindi altamente sicuro. E succede soprattutto senza che nessuno debba fare alcun controllo manuale.

So, if you're downloading a file from what is effectively an unauthenticated source, and validating it with a hash from the same source (or even another unauthenticated source), what is the real value of hashing the file?

In questa situazione, dove un hash si trova immediatamente accanto a un collegamento al file, il valore è principalmente per garantire che il file non sia danneggiato o danneggiato durante il transito.

Da un punto di vista della sicurezza, hai ragione; questo ha pochissimo valore per dimostrare che il file non è stato manomesso, perché chiunque potrebbe entrare e caricare un file compromesso (o cambiare il link per puntare a una copia compromessa) potrebbe anche sostituire l'hash seduto accanto a esso. Ecco perché non viene quasi mai fatto in questo modo quando l'obiettivo è la sicurezza.

In genere, quando viene offerto un hash digest, viene fornito direttamente dal produttore del software. Offrono software per il download, ma non sono disposti a ospitare direttamente il software sui propri server; sono una società di software, non una società di hosting, e non hanno la larghezza di banda dentro e fuori dai propri server per consentire migliaia di download simultanei a banda larga. Quindi, noleggiano spazio e larghezza di banda da un provider cloud per fornire lo stesso servizio.

Ora, non controllano questa nuvola; è un sistema diverso gestito da una società diversa, "casa mia, le mie regole". Il fornitore di software è preoccupato dell'hacking e del suo buon nome offuscato da un compromesso della società di hosting, e per una buona ragione; questo è un metodo comune di attacco, ed è il nome della società software sul software che ha permesso a un utente malintenzionato di entrare nella rete di un utente aziendale e causare il caos.

La soluzione è che il produttore di software hash i file che vengono offerti per il download sul sito di hosting e presenta l'hash dai propri sistemi sotto il suo controllo. Ora, tu, l'utente finale, puoi scaricare il software dal grande sito di hosting e verificare che quello che hai ottenuto è ciò che la società di software ha messo lì andando al sito della società di software e confrontando l'hash dei file elencati con quello che calcoli da il file scaricato. Ciò richiede molto meno larghezza di banda per la società di software rispetto all'hosting del file effettivo per il download. Ora, non c'è più un singolo punto di vulnerabilità; un utente malintenzionato deve hackerare sia il che il sito del produttore del software cloud per mettere un file sul posto che passerà il controllo hash. Possono rovinare le persone che non si preoccupano di controllare gli hash (che sono un sacco di persone) semplicemente hackerando il sito di hosting e sostituendo il file, oppure possono rovinare le persone che fanno controllano gli hash hackerando il sito del fornitore di software e cambiando gli hash in modo che l'hash del file reale non corrisponda più, ma possono solo mascherare veramente un file compromesso come quello della società di software eseguendo entrambi, il che è molto più difficile.

In generale, sì - un hash da un sito http fornisce la sicurezza minima o nulla che i dati provengano da una fonte attendibile.

Ma dipende dalla tua definizione di sicurezza, ovvero il tuo modello di minaccia. Un aspetto della sicurezza è l'integrità dei dati, e il controllo di un hash ti aiuterà spesso a evitare perdite di tempo su un CDROM o su un download danneggiato.

È molto meglio ottenere software da un sistema di pacchetti che fornisce una buona autenticazione dal programmatore, attraverso il controllo della versione, fino al packaging e alla distribuzione.

Per il tuo utente di casa è solitamente "sufficiente" il comfort che il file sia corretto (e con ciò intendo - il download ha funzionato e non c'è corruzione) - sebbene da un punto di vista della sicurezza un utente malintenzionato potrebbe altrettanto facilmente sostituire il file hash come file se volessero, se sono memorizzati nella stessa posizione.

per una persona della sicurezza aziendale o per qualcosa di un po 'più sensibile, vorresti veramente convalidare l'hash, probabilmente con un meccanismo fuori banda.

Nella situazione che hai descritto, l'unico uso per una firma è solo per assicurarsi che il file non sia corrotto.

Ci sono alcuni casi in cui il controllo dell'hash di un file può essere un vantaggio per la sicurezza, anche se l'hash non è stato scaricato tramite una connessione sicura:

• Se viene manomessa solo la tua connessione, puoi visitare la pagina web che contiene l'hash usando un'altra connessione (ad esempio una VPN sicura). Se la pagina, se visualizzata attraverso quell'altra connessione, visualizza lo stesso hash, è molto meno probabile che sia stata manomessa.
  Ovviamente, è possibile ottenere lo stesso risultato scaricando lo stesso file due volte attraverso diverse connessioni, ma questo è molto più veloce.
• Se l'utente malintenzionato, sia esso umano o software, non si è preoccupato di calcolare l'hash del file dannoso e sostituire l'hash originale con esso. Fai attenzione però, fare affidamento sul fatto che gli aggressori siano pigri non è la migliore difesa.
• Se il file viene scaricato da un sito diverso dal sito hash e quel è stato compromesso, ma il sito che ha fornito l'hash era non . Ad esempio, il file può essere distribuito attraverso un mirror o CDN .
• Se l'hash fornito è firmato digitalmente con una chiave fidata. Ad esempio hash firmati con una firma PGP attendibile.

Tuttavia, quando si forniscono hash tramite una connessione non protetta, il vantaggio principale è che è possibile verificare che il file trasmesso non sia corrotto durante il transito. Al giorno d'oggi ciò non accade molto spesso, ma si verifica. La masterizzazione di una ISO Linux corrotta può darti un'installazione corrotta che potresti notare solo quando è già troppo tardi. Lampeggiare il tuo BIOS con un download danneggiato potrebbe essere anche peggio.

Un'altra cosa da considerare è che, pur fornendo hash può effettivamente dare un falso senso di sicurezza, è molto probabile che la persona che sta scaricando il file lo abbia scaricato comunque, anche se non sono presenti hash. In tal caso, il piccolo vantaggio di sicurezza fornito dagli hash potrebbe superare di gran lunga nulla.

@Iszi ecco una breve storia ... (ok, forse non "breve" ... mi dispiace per questo: P)

supponiamo che tu desideri scaricare VLC . Per Windows Versione più recente (versione 1.1.5). Ok?

Il tuo primo posto dove andare sarebbe link ( sito ufficiale ). Ma puoi trovare e ottenere lo stesso "prog" da 5.780.000 siti. Giusto? (google "vlc download 1.1.5").

Il sito ufficiale afferma che MD5 del file è "988bc05f43e0790c6c0fd67118821d42" (vedi link). E puoi ottenere questo prog (versione 1.1.5) sia da server WEB di videolan.org ( NO HTTPS ). Oppure fai clic sul link, reindirizza a Sourceforge e prendilo. E ancora con NO HTTPS . Ma Sourceforge è un nome grande . Trustworthy. Destra? E indovina cosa. Tuo zio che ha VLC, ti manda un link rapidshare via e-mail, per scaricarlo. E anche il tuo amico dal lavoro.

Quindi lo scarichi da queste " fonti affidabili ".

Amici, siti, versioni, zii. Ti fidi di tutti loro. Destra ? Io non la penso così Almeno non dovresti.

C'è un solo modo per controllare che quello che hai, è il file originale . Inalterato, non modificato. Intatto. E questo è per confrontare l'hash di esso. Ma con cosa? Con l'hash dalla fonte ufficiale.

Nessun HTTP (S), nessuna firma digitale, nessun server "Sicuro" o "Sicuro". Niente. Non hai bisogno di nessuno di questi. L'integrità dei dati è tua amica.

È lo stesso con PGP / GnuPG. È possibile rilevare se un messaggio è stato modificato da quando è stato completato.

@Justice ha detto che

A sufficiently skilled cracker can replace the file with a maliciously modified version and the hash with one that matches the modified file

Certo, è stato trovato che Collisioni MD5 esistono. Esistono anche collisioni SHA-1 . Ma per citare Wikipedia :

Cryptographic hash functions in general use today are designed to be collision resistant, but only very few of them are absolutely so. MD5 and SHA-1 in particular both have published techniques more efficient than brute force for finding collisions. However, some compression functions have a proof that finding collision is at least as difficult as some hard mathematical problem (such as integer factorization or discrete logarithm). Those functions are called provably secure.

E non penso che un "cracker sufficientemente abile" possa trovare una "versione cattiva" o creare un file / binario / qualunque sia l' originale che vuoi e rendere ha lo stesso MD5 / SHA-1 come originale. E fallo sembrare lo stesso (foto). O con la stessa dimensione del file o persino eseguirlo o avere senso (testo). Neanche vicino. Può farlo inosservato per l'antivirus (se dannoso). Questa è una storia diversa. Ma ci sono segnalati alcuni casi veramente brutti per le collisioni .

Quindi, scarica da QUALSIASI (buona) fonte che ti piace, ma confronta l'hash dalla fonte originale . E c'è sempre una fonte originale .

Se ci pensavi davvero, avere più siti per ospitare il tuo contenuto scaricabile, insieme alle chiavi di hash, fermerebbe la maggior parte degli attacchi di sostituzione del mulino. Ancora una volta l'ipotesi è il modello di minaccia in cui l'attaccante dovrebbe sostituire in situ anziché in transito. Anche con una singola fonte, le copie impedirebbero a chiunque di sostituire sia il file che l'hash.

E, le fonti di file possono essere danneggiate durante il download.