Mi chiedevo se il seguente scenario fosse realisticamente realizzabile.
Abbiamo una rete con un computer che viene utilizzata da Bob. È una persona attenta alla sicurezza e utilizza un gestore di password. Il suo computer è connesso a Internet tramite un router che Bob ha ricevuto dal proprio ISP. L'ISP e il produttore del router non hanno implementato aggiornamenti per le vulnerabilità critiche del suo router.
Poi c'è Trudy che vuole davvero conoscere le password di Bobs. Lei ottiene pieno accesso al suo router attraverso un exploit. Ci sono un paio di siti web a cui è interessata, quindi manipola le voci DNS per puntare a un server web sotto il suo controllo. Poiché Trudy ha molto tempo, si presume che la cache DNS del computer di Bob verrà eventualmente aggiornata per contenere le voci manipolate.
Bob si connette a un sito web a cui Trudy è interessato. Pensa di stabilire una connessione con https://www.safewebsite.com , ma in realtà si connette al server web di Trudy. Il server Web esegue il downgrade della connessione a HTTP semplice, solo per stabilire la connessione. Quindi il server web esegue un reindirizzamento all'URL effettivo di se stesso, ad es. https://safewebsite.evil.com per cui Trudy ha un certificato SSL valido (semplice). Supponendo che Bob non guardi troppo da vicino non vede la differenza nella barra degli indirizzi.
In alternativa, Trudy induce Bob a visitare il suo server web in modo da non attivare un'eccezione di certificato non valida.
Quello che Trudy deve fare, per estrarre la password di Bobs, è incorporare il sito web valido che Bob ha voluto visitare. Trudy ha anche meno lavoro in quanto non vuole codificare un sito Web di phishing, ma vuole ingannare il gestore di password di Bob. Quando Bob visitava il sito Web malevolo di Trudy, il gestore password immette le sue credenziali nel sito Web incorporato, poiché ritiene che questa sia una connessione valida. Quindi uno script del sito Web di Trudy cattura il contenuto del campo della password e il nome utente, inviando entrambi al server web.
Ora Trudy ha una cosa con cui sta lottando, molti siti web hanno l'opzione x-frame impostata per negare. Questo sventa il tentativo di Trudy in molti casi. Ha l'idea di lasciare che il Router annusi i pacchetti contenenti l'opzione x-frame. Sarebbe quindi modificato o rimosso. Quindi, se Bob visita il sito Web dannoso di Trudy, richiede il sito Web reale incorporato e il router esegue un MITM attivo. Ciò significa che il router si connette a https://www.safewebsite.com e solo a mani tocca la versione http. Bob vedrebbe ancora il https://safewebsite.evil.com , senza indicare una modifica visiva rispetto alla versione precedente dell'attacco. La domanda è se il router sarebbe in grado di rimuovere o modificare l'opzione x-frame in un modo che non influisce sull'esperienza di navigazione di Bob.
Speriamo che l'idea sia chiara. Se noti qualcosa di non realistico, lascia un commento. Forse hai un'idea ancora più semplice di come ottenere questo.
Questo è uno scenario di attacco contro uno specifico gestore di password (che non verrà nominato qui) che vorrei usare in una presentazione per un corso universitario, ma solo se è plausibile.
Aggiorna
Anche se lo sapevo e lo avevo pensato diverse volte, l'idea scritta qui sopra ha un difetto cruciale, www.safewebsite.com dovrebbe essere caricato come https altrimenti il gestore di password non riempirebbe i dati. Lavorerò sullo scenario e pubblicherò una versione aggiornata.
Aggiornamento 2
Sembra che il gestore di password abbia un problema di sicurezza che riempie le credenziali negli iframe. Lo scenario è però imperfetto e le risposte fornite sono corrette per la domanda originale. Se il nuovo scenario funziona, dovrò prima contattare gli sviluppatori e in seguito rilasciare ulteriori informazioni sul problema.