By-pass di intercettazione suite Burp

Naviga le tue risposte
3

Sto cercando di intercettare il traffico a livello di applicazione utilizzando attacchi a livello di rete. In particolare, mi sono imbattuto in questo interessante articolo qui.

Link

In breve, utilizza l'avvelenamento ARP per rendere mitmatico la macchina dell'attaccante e usa iptables per inoltrare il traffico http e SSL per ruttare sulla macchina dell'attaccante.

La mia configurazione:

  1. OnePlus X con hotspot come router
  2. Windows 10 32 bit PC come vittima (vari browser in esecuzione)
  3. Kali Linux 2018 64 bit PC come attaccante (Wireshark, burp suite e Esecuzione spoof ARP)

Tutto funziona bene e bene, l'avvelenamento ARP fa il suo lavoro e posso vedere i pacchetti in Wireshark. Tutte le richieste DNS effettuate e tutti i dati HTTP non crittografati sono visibili in Wireshark. Inoltre, burp è configurato bene e intercetta il traffico, anche il traffico HTTPS. Ad esempio, ho provato link e ho potuto vederlo in Burp.

Poi ho testato bing.com e ho potuto vederlo anche in Burp. Ma quando ho provato a connettermi a Facebook o Google dalla macchina della vittima, non vedo alcun traffico nel rutto. Non c'è nessun singolo segno di traffico verso Facebook o Google nel rutto. Nemmeno messaggi di errore. Tuttavia, posso vedere le richieste DNS fatte su Facebook e Google su Wireshark. E poi segue lo scambio di stream TCP, che ovviamente deve essere la risposta alla richiesta da questi due siti. Questo significa che il traffico passa attraverso la mia macchina Kali Linux. Allora perché non riesco a intercettare il traffico nel rutto?

Ho testato questo problema su entrambi i browser Chrome 66 e Opera (entrambi aggiornati) sulla mia macchina vittima. Entrambi hanno lo stesso comportamento.

Potrei vedere gli errori specifici di hsts prima di importare la CA di burp nella root attendibile delle mie vittime. Dopo l'importazione, quando riesco a intercettare il traffico su bing.com, perché non posso intercettare il traffico su Facebook o Google? Che magia è al lavoro che mi impedisce di vederlo nel rutto?

Qualsiasi vantaggio sarebbe apprezzato. Grazie.

    
posta user148898 11.05.2018 - 14:21
fonte

1 risposta

1

Nevermind. Quei siti Web utilizzavano IPv6 su IPv4 e quindi a causa della crittografia di IPv6 non riuscivo a vedere il traffico. Risulta che Windows ha una preferenza di IPv6 su IPv4 quando la scheda di rete ha alcuni tipi di indirizzi, tipici di quelli assegnati dagli hotspot mobili. (Forse per sicurezza?)

Ho visto in Wireshark che le richieste DNS per Facebook e Google stavano ricevendo indirizzi IPv4 e IPv6. Ma quelli di Bing e barracuda non lo erano. E a causa della preferenza di IPv6 su IPv4, è stato utilizzato IPv6. Costretto il supporto IPv6 disabilitato su Windows tramite l'adattatore in questione e, come previsto, le cose sono tornate alla normalità.

E si scopre che gli scambi TCP che ho citato sono probabilmente qualcos'altro e non le risposte richieste da Google o Facebook. Mi sono reso conto di ciò semplicemente eseguendo Wireshark sulla mia macchina Windows, e successivamente ho fatto alcune ricerche e ho avuto modo di conoscere da qualche parte il supporto Microsoft sulla preferenza di IPv6 su IPv4.

Spero che questo aiuti qualche pentitore da qualche parte.

    
risposta data 11.05.2018 - 19:34
fonte

Leggi altre domande sui tag

"Targeted" Brute-Force una password dell'app locale Nessun attributo nella richiesta di certificato