Pitanje:
Dešifriranje TLS paketa između aplikacija Windows 8 i Azure
Bill Sempf
2013-03-24 04:42:30 UTC
view on stackexchange narkive permalink

U razvoju aplikacije Windows Store za Windows 8 postoji klasa koja se naziva remoteSettings koja programeru omogućuje spremanje serija podataka tako da će im korisnik imati pristup na nekoliko računala, sve dok su prijavljeni s istim računom .

Priključio sam WireShark i otkrio da je paket pohranjen u Azureu i zaštićen je TLS-om. Htio bih se MITM-om tako da mogu dešifrirati paket i vidjeti jesu li podaci šifrirani na Azureu.

Očito nemam privatni ključ za Azure, pa bih želio znati je li bilo tko ima ideju kako izvršiti tu MITM analizu.

Pet odgovori:
#1
+11
Brendan Dolan-Gavitt
2013-03-27 20:52:26 UTC
view on stackexchange narkive permalink

Još jedna stvar koju biste mogli učiniti, a koja je možda pretjerana, ali korisna u drugim scenarijima, jest presretanje stvaranja glavne tajne TLS-a od 48 bajtova. Za mnoge Windows programe (uključujući IE), to se događa u lsass.exe u sljedećoj funkciji (preuzeto iz Win7 SP1 32-bit):

  Pozivač: ncrypt! _Tls1ComputeMasterKey @ 32 + 0x57 EIP: ncrypt! _PRF @ 40 + 0x11a  

Zatim možete dešifrirati zarobljene pakete nakon fakta u Wiresharku postavljanjem (Pre) -Master-Secret log datoteke u SSL preferencije u datoteku datoteku koja izgleda ovako:

  RSA sesije ID: 87492B3586DE289FAE1598B0A19CC7BCCB69371993F2C0DF32438034E06FE3FBMaster-Key: F58C0EFA2BF87602646B318400DFEB0C8CCDE59408C9F13C6D923F6208743BD34EA8BA17BCE02B9BD8DFED5A58036068  

sesije Ovdje se ID može naći u zaglavljima TLS-a (nešifrirani) za stream koji vas zanima. (RSA vas nemojte zavarati - ovo funkcionira za sve TLS veze bez obzira na šifru koja se koristi.)

Prednost ove metode je u tome što, budući da ne radite čovjeka u sredini, klijentska aplikacija ne mora vjerovati vašem CA-u, ​​što je posebno zgodan ako pokušavate poništiti neki zlonamjerni softver koji zapravo kripto radi ispravno.

Loša strana je ta što morate biti u mogućnosti otkloniti pogreške lsass.exe , što može biti lukav; postoje neke informacije o tome kako to učiniti ovdje.

#2
+10
Peter Andersson
2013-03-24 13:55:46 UTC
view on stackexchange narkive permalink

Ako se podaci prosljeđuju kao HTTPS, možete isprobati klasični pristup Fiddler čovjek-u-sredini. Nisam siguran poštuje li Windows trgovina poštuje li postavke proxyja ili ima prikvačeni certifikat. Ako poštuje postavke proxyja, što bi trebao, a nema prikvačenu potvrdu, trebali biste je trivijalno umjestiti u sredinu s Fiddlerom.

Ako podaci nisu ' t HTTPS i certifikat nije prikvačen, jedna od mogućnosti je proxy sigurne veze pomoću SSLNetcat. Ono što radite je da promijenite datoteku hostova tako da se izvršna datoteka Store poveže sa SSLNetcatom koji se izvodi lokalno, a zatim postavite SSLNetcat tako da koristi cerifikat za koji imate privatni ključ. Tada jednostavno SSLNetcat prosljeđuje podatke izravno u program po vašem izboru ili unosi privatne ključeve u Wireshark i koristi ih za njuškanje prometa.

Ako podaci nisu HTTPS, ako potvrda u binarni je prikvačen i nije pohranjen u datoteku, možete zakrpati izvršnu datoteku Windows trgovine i zamijeniti certifikat vlastitim za koji imate privatni ključ. OpenSSL bi trebao moći generirati zamjenski certifikat za vas. Tada se ovaj privatni ključ može unijeti u Wireshark koji će zatim dešifrirati promet.

Prilično ste blizu teritorija zaštite od kopiranja pa biste mogli naići na brojne komplikacije.

Da budem jasan - ovo radim u vlastitoj aplikaciji da vidim jesu li podaci u Azureu pohranjeni šifrirani ili ne. Ne razbijanje tuđe aplikacije. Pokušao sam Fiddler, ali možda sam to pogriješio, pa ću to istražiti. Nisam bio upoznat sa SSLNetcatom, pa hvala i na tome. Strašan odgovor.
Oh, pretpostavljao sam isto toliko. Samo sam mislio da biste mogli naići na probleme u kojima je komunikacija jako zaštićena zbog zaštite od kopiranja. To malo komplicira jer je vjerojatnije da ćete naići na prikvačene certifikate, samoprovjerljive izvršne datoteke, pa čak i provjere integriteta na razini jezgre. Nepoznat sam u Microsoftovoj trgovini pa ne mogu savjetovati više od uopćavanja.
Savjeti su vam doduše sjajni. Primit ću se posla kad završim s gledanjem košarke ovdje ...
#3
+5
ŹV -
2013-03-24 07:01:47 UTC
view on stackexchange narkive permalink

Postoje brojni pristupi kojima biste mogli izvaditi lokalni ključ koji koristi Windows Store i uvesti ga u Wireshark, međutim, mislim da je najbolje da ubrizgate DLL koji povezuje mrežne IO funkcije send () i recv () iz vašeg postupka.

Mogli biste i sami pokušati to učiniti na "niskoj razini", ali u interesu pragmatizma bilo bi pametno ispitati Microsoftove zaobilaznice kako biste ih pronašli, postoji toliko primjera koji to koriste - lako je dovoljno je sada da je jedini prototip funkcije jedini bitan zahtjev.

Nisam siguran da mogu doći do mrežnih IO funkcija u WinRT-u - možda uz neko hakiranje C ++-a jer ovo baš i ne prolazi certifikaciju. Još nisam čuo za Zaobilaznice - hvala na tome.
#4
+4
0xea
2013-03-27 16:38:37 UTC
view on stackexchange narkive permalink

Možete isprobati i oSpy koji u osnovi spaja odgovarajuće API pozive i omogućuje vam da vidite podatke prije i nakon što su šifrirani / dešifrirani.

oSpy je alat koji pomaže u softveru za obrnuti inženjering koji radi na Windows platformi. [...] kad se njuškanje vrši na razini API-ja, omogućuje puno precizniji prikaz onoga što se događa. [...] ako aplikacija koristi šifriranu komunikaciju, lako je presresti i ove pozive. oSpy već presreće jedan takav API i API je koji MSN Messenger, Google Talk itd. koriste za šifriranje / dešifriranje HTTPS podataka.

#5
+2
sw.
2014-06-10 17:44:58 UTC
view on stackexchange narkive permalink

Najvjerojatnije Windows 8 koristi WinINet za povezivanje s App Storeom. Ako je to slučaj, možete vidjeti da se nešifrirani potoci priključuju na wininet.dll umjesto da koriste proxy. HookME to radi, a predstavljen je prošle godine u BlackHatu.

Vjerojatno trebate unijeti neke manje izmjene da biste ga kompajlirali i koristili u sustavu Windows 8.



Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
Loading...