Perché i siti Web non forniscono un checksum dei loro file scaricabili?

Lo fanno! Molti eseguibili di Windows hanno un certificato integrato firmato da una CA attendibile da Microsoft. Il sistema operativo controlla questo certificato prima di eseguire il software. È possibile aggiungere ulteriori configurazioni a impedisce l'esecuzione del software non firmato , piuttosto che mostrare solo un avviso. Inoltre, è possibile creare ulteriori restrizioni che consentono solo l'esecuzione di eseguibili firmati da Microsoft, non solo gli eseguibili firmati da un editore affidabile di Microsoft.

Linux e i relativi sistemi operativi non lo supportano ancora (ELF, a differenza di PE32, non supporta i certificati incorporati), ma c'è ben poco da fare perché la maggior parte delle installazioni software viene eseguita usando il suo gestore di pacchetti nativo che di solito verifica il software. In questo caso, non vi è alcun certificato da una CA attendibile. Piuttosto, la firma viene fornita dai manutentori del repository software e verificata dal gestore pacchetti durante l'installazione.

Per i download sensibili alla sicurezza che non sono necessariamente forniti dai gestori di pacchetti e non possono avere firme incorporate, spesso vengono forniti hash firmati. Questo è il caso delle immagini ISO avviabili in particolare, sebbene alcune forniscano solo hash non firmati, non firmati. Sfortunatamente, ci sono ancora numerosi esempi di eseguibili forniti su connessioni non sicure non firmati semplicemente perché gli amministratori del sito Web non comprendono l'importanza dell'integrità e sottovalutano il rischio di compromissione.

Hai menzionato CCleaner, quindi è importante collegare a Una firma digitale avrebbe impedito il compromesso di CCleaner? La risposta breve è che non avrebbe impedito questo particolare compromesso .

Questo ci dà il nostro primo problema con la fornitura di hash: Chi confidiamo di firmare la build e cosa ci fidiamo di loro per controllare? La firma rappresenta semplicemente il server di build ufficiale, che potrebbe essere compromesso? O rappresenta un controllo di sicurezza effettivo da parte di una parte pre-attendibile?

Tuttavia, ci sono altri attacchi che un simile hash dovrebbe evitare - ad esempio, uno specchio compromesso o fraudolento che offre una build alterata. In questo caso, sarebbe sufficiente che la pagina del progetto principale pubblichi un hash, che potrebbe essere verificato rispetto al download offerto da qualsiasi mirror.

Tuttavia, questo ci porta al secondo problema, che è uno dei problemi più difficili della crittografia: distribuzione delle chiavi (o, in questo caso, distribuzione delle firme).

Per un hash senza firma, ti stai semplicemente fidando della pagina che mostra che hash non è stato manomesso. Un hash firmato a prima vista sembra migliore, ma devi comunque scaricare la chiave pubblica da qualche parte, quindi ti stai ancora fidando della fonte di quella chiave. Se un utente malintenzionato può indirizzare un utente a una pagina di download falsa, può aggiungere un collegamento a una chiave pubblica di sua scelta e l'utente otterrà un falso senso di sicurezza verificando l'hash di un download compromesso.

L'alternativa è avere un'autorità centrale di cui ti fidi per più applicazioni diverse: questo è il principio alla base della firma dei driver di Windows, dei gestori di pacchetti Linux e degli app delle app telefoniche (e anche dei certificati utilizzati per i siti Web HTTPS). Ora hai un nuovo problema: perché ti fidi di quelle autorità centrali? Stanno controllando direttamente il codice sorgente e costruendo processi dei file che stai scaricando? O stanno delegando la fiducia, tramite un certificato controfirmato, sulla base di una certa garanzia da parte del partito che produce effettivamente il software? Inoltre, è comunque necessario acquisire la chiave pubblica di root in qualche modo, presumibilmente è stata inclusa in alcuni supporti di installazione attendibili quando è stato installato OS / app store / package manager.

Alla fine, pubblicare un hash sarà molto utile per i progetti di grandi dimensioni, dove:

• è probabile che lo stesso utente scarichi e verifichi più versioni o diverse applicazioni con la stessa chiave pubblica;
• e, l'origine della chiave pubblica è probabilmente diversa dal server che offre il download (un server diverso o un supporto fisico)

Ma anche in quel caso, non è possibile correggere tutti gli exploit, come ha dimostrato CCleaner; e c'è un pericolo nel dare agli utenti un falso senso di sicurezza.

Perché la maggior parte degli utenti non controllerà comunque l'hash.

Ci vorrebbe un protocollo di download comune che automatizzi e imponga la verifica delle firme per fare in modo che la diffusione del malware si intacchi.

Ciò non sarebbe ancora perfetto: un server compromesso potrebbe anche pubblicare un hash diverso. La firma del software stesso, come con i driver di Windows, probabilmente ha più potenziale per avere un impatto. Entrambi potrebbero essere fatti anche.

Sto visualizzando più hash (comunemente md5) visualizzati sul sito correlati a linux . Principalmente, quando sono forniti iso .

Non vuoi installare un sistema operativo da un ISO corrotto, vero?

Troverete anche l'hash anche dell'ISO di Windows 10, nella pagina di download.

L'hash è usato qui solo per verificare l'integrità dei file scaricati.

Quando è necessario verificare che il file non sia stato manomesso, sito serio, fornire una firma chiave GPG che è necessario controllare con una chiave GPG. Ad esempio, tails.boum.org lo fa.

Perché è quasi inutile formare una prospettiva di sicurezza. Hash accanto ai download sono uno sportello unico per i compromessi; l'attaccante aggiorna l'hash nello stesso identico posto in cui è collegato il download. Il download non deve nemmeno essere sostituito, può essere collegato a un sito di terze parti poiché l'html rivolto all'utente è ciò che è sotto attacco.

È un po 'di conforto se un sito di terze parti ospita l'hash, ma è passato molto tempo da quando l'ho visto implementato e anche allora, significa solo che due siti devono essere compromessi invece di uno. Se l'hash si trova accanto al file in una cartella FTP, quanto è difficile sostituirli entrambi, considerando che hanno gli stessi permessi? A meno che uno non sia un target indurito fuori sede, cosa lo rende più sicuro della sola pagina / cartella di offerta di link?

L'idea di convalidare gli hash di download è buona, non è semplice ottenere l'hash all'utente in un modo più affidabile del collegamento stesso. Sono ancora buoni per l'integrità, non solo l'autenticazione su base singola autorità. Un'autorità centrale sarebbe carina, ma afaik, non ce n'è ancora uno.