Attacco denial-of-service persistente basato su HPKP su siti Web

Question

Attacco denial-of-service persistente basato su HPKP su siti Web

#1 da (1 voti)

4

HTTP Public Key Pinning (HPKP) è uno standard che consente a un sito Web HTTPS di specificare quali certificati si fida e indica al browser di non consentire alcuna connessione a quel sito che è protetto da qualsiasi altro certificato.

Può essere usato per facilitare un attacco denial-of-service persistente su un sito web? Supponiamo che un utente malintenzionato comprometta un sito Web come cnn.com (per esempio). Sembra che l'avversario possa configurare il server web per abilitare HSTS e HPKP, con una politica di blocco che specifica un certificato controllato dal attaccante. L'attacco potrebbe essere scoperto e gli amministratori legittimi riprenderanno il controllo, ma tutti coloro che visitano cnn.com nel frattempo riceveranno una politica HSTS e HPKP e il loro browser la memorizzerà nella cache. Di conseguenza, il browser non consentirà alcuna connessione HTTP a cnn.com (a causa del criterio HSTS) e consentirà solo le connessioni HTTPS se il server utilizza il certificato aggiunto e la chiave pubblica. Tuttavia, poiché l'autore dell'attacco ha specificato il certificato, potrebbe utilizzare una chiave privata controllata dall'hacker e non nota a cnn.com. Di conseguenza, dopo che l'utente malintenzionato è stato avviato, cnn.com non ha modo di terminare una sessione SSL utilizzando la chiave privata scelta dall'attentatore. Quindi, tutte le future connessioni da quei browser a cnn.com falliranno.

Lo standard HPKP suggerisce che i browser devono impostare un'età massima per queste norme, ma anche suggerimenti imposta l'età massima a 60 giorni. Quindi, se sto capendo correttamente questo, significa che se un utente malintenzionato compromette temporaneamente un sito Web, l'utente malintenzionato può garantire che il sito Web sarà assolutamente irraggiungibile per i prossimi 60 giorni per tutti gli utenti che visitano il sito Web durante il breve periodo in cui il sito Web è compromesso. In sostanza, qualsiasi utente che visita il sito Web in un momento in cui è controllato dall'attaccante viene "avvelenato" per i successivi 60 giorni e il sito Web appare semplicemente irraggiungibile.

Poiché le violazioni del sito Web non sono inaudite, sembra che sarebbe un risultato piuttosto grave. Questo è un tipo piuttosto inusuale di attacco denial-of-service: consente il vandalismo irreversibile di un sito che non c'è nulla in cui gli amministratori del sito web possano fare qualcosa, tranne aspettare. Sembra anche che questo attacco possa essere sfruttato contro qualsiasi sito Web, anche uno che attualmente non usa HPKP, HSTS o persino HTTPS.

L'ho capito correttamente? Ci sono delle attenuazioni che un sito Web può intraprendere per impedire a se stesso di comportarsi in questo modo? C'è un argomento secondo cui HPKP non introduce alcun nuovo rischio DoS più grave di quello che esisteva già prima di HPKP? Questo tipo di attacco DoS persistente è mai stato osservato in natura?

Ho letto RFC 7469, lo standard che descrive HPKP, e non sembra avere alcuna mitigazione. Sembra che l'attacco che ho descritto si qualifichi come un'istanza di 'ostile pinning' , ma lo standard non lo fa Sembra che menzioni qualsiasi mitigazione utile per il blocco ostile (a parte l'età massima).

denial-of-service tls certificate-pinning hsts

posta D.W. 06.07.2015 - 07:26

fonte

1 risposta

Leggi altre domande sui tag denial-of-service tls certificate-pinning hsts

Come inviare frame di gestione Wi-Fi da macOS? Autorizza la comunicazione transitiva tra le applicazioni per conto dell'utente

score 1 · Answer 1

Leggendo il questo memo , viene fornito un link al pin draft di Perrin qui . Vedo due contromisure contro lo scenario che descrivi in questo progetto:

Iniziamo con il primo, che può essere interpretato in diversi modi:

Whenever a client performing "pin activation" sees a hostname and TSK combination not represented in the "pin activation" pin store, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.

Secondo la mia interpretazione, l'implementazione del paragrafo precedente significherebbe che un utente malintenzionato può attivare solo nuovi pin per un intervallo temporale molto limitato. Tuttavia, sembra che l'attaccante possa ancora revocare pin più vecchi. Pertanto, passiamo alla seconda contromisura descritta:

Nonrevokable tacks: A tack with generation 255 cannot be revoked. Such tacks MAY be used to minimize the risk that a compromised TSK private key could be used to affect site availability.

Quindi, un server che ha emesso una virata non revocabile, potrebbe infatti continuare a utilizzare questa virata per sempre. Come ho letto è che un server poteva creare una coppia di chiavi che NON usa, ma per la quale crea una virata non revocabile. (Nell'implementazione di Perrin, questo diventerebbe uno dei due PIN massimi che non possono essere cancellati). Nel caso in cui il server sia compromesso, questa chiave può essere recuperata e utilizzata per annullare le modifiche dell'utente malintenzionato.

Se questo è implementato o meno nei browser attuali, non lo so.

Modifica : Come @StackzOfZtuff ha evidenziato in uno dei commenti, esiste in realtà una trascrizione di una conversazione via email tra IETF: WEBSEC e Perrin, sottolineando di implementare un meccanismo simile a TACK per HSTS.