Aggiornamento di Windows - Intercettazione

Question

Aggiornamento di Windows - Intercettazione

Naviga le tue risposte

#1 da (2 voti)
#2 da (1 voti)

3

Sto provando a monitorare le richieste / risposte HTTP fatte durante l'esecuzione di un aggiornamento di Windows.

Ho una macchina Windows 8 configurata con un proxy in IE. Ho anche importato tramite netsh per winhttp:

netsh winhttp import proxy source = ie

Il proxy è in esecuzione su un'altra macchina sulla porta 8080 ed è configurato per intercettare SSL.

Ho provato entrambi con il proxy Burp o con un normale proxy Squid (usando ssl_bump). I certificati CA radice sono installati sul computer Windows 8, nell'archivio Computer locale, nelle CA radice affidabili. Se sfoglio da IE o Chrome, posso accedere ai siti https senza un avviso (poiché il certificato del server presentato è firmato dalla CA proxy).

Tuttavia, se provo a utilizzare Windows Update, ricevo un errore:

"Si è verificato un problema durante il controllo degli aggiornamenti"

Si tratta di un problema noto, Bluecoat consiglia di aggiungere un'eccezione per l'intercettazione SSL per Windows Update:

link

Microsoft fa lo stesso consiglio per TMG:

link

Quindi sembra che il servizio Windows Update non controlli solo il certificato nel modo consueto, in realtà verifichino un elenco CA differente, o richiede specificamente un determinato certificato server dal sito Windows Update.

La domanda è, come posso aggirare questo, in modo che possa vedere le richieste HTTP fatte da Windows Update?

windows proxy tls updates

posta user61451 03.03.2013 - 12:33

fonte

2 risposte

Leggi altre domande sui tag windows proxy tls updates

Codifica del contenuto dell'email HTML Processi di certificazione del server

score 2 · Answer 1

Questo problema mi ha sfidato per un po ', ma ha trovato una soluzione. In genere si manifesta come errore di aggiornamento di Windows 80245006 o 803D000A

Ho scritto uno strumento chiamato SuperPhishers DetermineSubCAIdentity.py nel marzo 2015 che ti permetterà di ignorare le finestre interne per verificare che i certificati siano realmente di Microsoft. Il nome è un gioco sulla polemica SuperFish Lenovo alla volta.

La parte facile è che il tuo proxy SSL generi qualcosa di moderno: come RSA > = 2048 e SHA256RSA, ecc. Ho usato sslsplit e l'ho modificato per generare digesti SHA256. Windows richiede SHA256 sul suo aggiornamento e memorizza i certificati o fallisce con 0x803D000

La parte difficile è ignorare Windows controlla che CA Cert sia Microsoft:

Fondamentalmente ci sono due funzioni che implementano un controllo che il certificato CA è valido. Entrambi sono chiamati DetermineSubCAIdentity in wuaueng.dll e storewuauth.dll Usando Nektra Deviare2, la funzione DetermineSubCAIdentity è stata agganciata in modo che fosse sempre completata lasciando EAX = 3. Ciò consente al controllo Microsoft di passare e la funzione di aggiornamento o di archiviazione continua normalmente.

Se si patch questa funzione in entrambe le DLL, consente l'intercettazione del traffico di Windows Store. Controlla il tuo traffico intercettato o esegui ICAP per riscrivere il divertimento.

Ho realizzato un video qui: link

Il codice e la documentazione tecnica sono disponibili qui: link

Thomas Pornin ha ragione nel senso che devi modificare dll - Quando ho modificato la DLL su disco, SFC li ha sostituiti con quelli buoni. Comunque facendolo in memoria con Deviare2 iniettato in un processo di SISTEMA, a Windows 8.1 non sembra importare.

Spero che questo aiuti ed è stato divertente vedere il traffico di Windows Update in chiaro per la prima volta.

score 1 · Answer 2

Tra i possibili aggiornamenti ci sono gli aggiornamenti dei contenuti predefiniti dell'archivio di fiducia stesso. Se Windows utilizzava il trust store predefinito, qualsiasi CA in quel negozio poteva modificare un aggiornamento contraffatto che avrebbe sottratto i suoi concorrenti. Potrebbe anche alterare qualsiasi parte del sistema operativo. Per un SO, il percorso per gli aggiornamenti è molto sensibile . Sarebbe abbastanza rischioso dare la potenza degli aggiornamenti a un centinaio di CA, non tutti i quali possono essere veramente attendibili per svolgere correttamente il loro lavoro (sono accaduti contrattempi, non spesso, ma ancora ...).

Quello che potresti provare è aggiungere il tuo certificato falso per il server SSL di Windows Update in " editori attendibili " negozio (quello per il" computer locale "). Includere il certificato falso del server stesso, non la CA controllata da Burp che rilascia al volo certificati falsi (non so se Burp possa utilizzare uno specifico certificato falso non dinamico per un dato server). Questo negozio normalmente serve per convalidare le firme sui driver, non per i server SSL, ma dato il modo in cui Microsoft gestisce i certificati, questo potrebbe funzionare e fare ciò che vuoi (non ho una macchina Windows a portata di mano per provarlo adesso).

Se il codice di Windows non utilizza un trust store di facile accesso, ma invece codifica l'elenco dei certificati accettabili per il server Windows Update, dovrai ricorrere alle modifiche DLL, come fanno le scritture di malware per vivere . Il sistema operativo proverà a difenderti attivamente contro questo.