HTTPS liikluse uurimine tcpdump, Wireshark ja mitmproxy abil
See artikkel räägib HTTPS liikluse analüüsimisest (HTTP päringute avatekstiks lahtivõtmise teel) kahes olukorras. Esiteks -- kui nii klient kui server on meie hallata ja me soovime testida, kas server saab just selliseid HTTP päringuid ja saadab selliseid vastuseid, nagu me eeldame. Teiseks -- kui serveriks on mõni avalik veebiteenus, millega suhtleme üle HTTPS protokolli, ja soovime teada, mida meie brauser serveriga räägib. Sisuliselt on siin tegemist olukorraga, kus me ei pruugi usaldada ei klienti (brauser jooksutab meie teadmata mingit kuritahtlikku skripti) ega ka serverit. Tegu võib olla ka mõne mobiilirakendusega, mille kohta soovime teada, mis andmeid ta meie telefoni kaudu edastab ja vastu võtab.
NB! Siin artiklis toodud juhised on mõeldud liikluse heatahtlikuks uurimiskes, mitte kolmandate osapoolte andmevahetusse sissemurdmiseks!
Autor: Marju Ignatjeva
Töövahendid ja keskkond
Kasutame töövahenditena tcpdump-i ja Wiresharki ning mitmproxy-t, HTTP kliendina ka curl-i.
Läbivalt on kasutusel serveri aadress 192.168.56.201.
Artikli lugejalt eeldan, et HTTPS üldine tööpõhimõte on selge ja et lugeja oskab Linuxi keskkonnas paigaldada tarkvara nii süsteemsest pakimajandusest kui ka Pythoni pakendussüsteemide (eeskätt pip) vahenditega, samuti saab hakkama käsureal. Töövahendite paigaldamise juhised on siiski ka artiklis olemas.
Artiklis toodud näited põhinevad katsetustel 64-bitise Kubuntu 12.10 operatsioonisüsteemi all.
Töövahendite paigaldamine
Kui tcpdump ei ole paigaldatud, tuleb see juurkasutajana paigaldada käsuga
apt-get install tcpdump
Wiresharki paigaldame käsuga
apt-get install wireshark
HTTP päringuid on käsurealt mugav teha curl nimelise tööriistaga, paigaldame ka selle.
apt-get install curl
Kuna erinevate Linuxi distributsioonide pakimajanduses ei pruugi alati olla Pythonis kirjutatud tarkvarast väga värskeid versioone, siis mitmproxy paigaldamiseks on mõistlik kasutada pip-i.
apt-get install python-pip pip install mitmproxy
tcpdump ja Wireshark
HTTPS liikluse püüdmiseks kasutame käsureavahendit tcpdump seetõttu, et servereid hallates ei ole meil tihtipeale ligipääsu graafilisele keskkonnale. Samas on Wireshark mugav ja kasutajasõbralik võrguliikluse uurimise töövahend ja tcpdump-i abil salvestatud liiklust saab Wiresharki abil hiljem suvalises teises masinas analüüsida.
Kuna veebiserver on meie hallata, siis on meil olemas tema privaatvõti. See on ainus vajalik sisend Wiresharkile, et ta oskaks kinnipüütud pakette lahti krüpteerida.
Pakettide püüdmine
Kõigepealt paneme tcpdump-i kuulama liiklust liidesel eth1 (antud juhul on see Virtualboxi host-only võrguliides), aadressil 192.168.56.201, pordil 443 (meil on sinna konfitud üks HTTPS toega virtualhost). Seda tuleb teha juurkasutaja õigustes, et meile antaks ligipääs võrguliidesele.
tcpdump -w https_dump.pcap -i eth1 host 192.168.56.201 and port 443
Teeme klientmasinast päringu (öeldes, et usaldame serveri enda poolt allkirjastatud sertifikaati):
curl --insecure https://192.168.56.201
Nüüd lõpetame Ctrl+C abil serveris tcpdumpi töö -- too ütleb lõpetades käsureale midagi sellist:
15 packets captured 15 packets received by filter 0 packets dropped by kernel
Püütud pakettide uurimine
Järgmiseks on vaja tcpdump-i väljundfail saada masinasse, kus meil on võimalik kasutada Wiresharki (kusjuures salvestatud faili uurimiseks ei ole juurkasutaja õiguseid vaja). Käivitame Wiresharki ja avame oma .pcap faili. Esialgu näitab Wireshark küll HTTPS-iga seotud andmevahetust, kuid HTTP päringuid avatekstina pole võimalik näha. Wireshark võimaldab seda krüpteeritud sisuga andmevoogu ka eraldi aknas uurida ("Follow TCP Stream" suvalise paketi kontekstimenüüst).
Järgmiseks hangime serverist tema privaatvõtme (NB! Erinevate virtualhostide olemasolul pead hankima just antud päringus kasutatud IP-le vastava võtme!)
Wiresharkis võtame menüüst "Edit"->"Preferences" avanevas aknas "Protocols" alt "SSL" ja lisame serveri võtme:
Kasulik on seadistada ka SSL debuglogi failitee, et probleemide korral saaks vigu otsida. Näiteks võib juhtuda, et brauseri või serveri krüpto vaikeseadistused on sellised, et Wireshark ei saa pakettide sisu lahti krüpteerida, kuigi serveri privaatvõti ja muud parameetrid on korrektsed (failitee seadistamine jääb lugejale väljauurimiseks).
Nimelt võib juhtuda, et peale võtmefaili määramist ja HTTPS suhtlusega seotud paketi kontekstimenüüs "Follow SSL Stream" valimist näidatakse tühjust.
Sellisel juhul võiks debuglogist otsida sääraseid ridu:
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt dissect_ssl3_handshake can't decrypt pre master secret
Nimelt Apache2 mod_ssl vaikimisi konfis on lubatud Diffie-Hellman võtmevahetuse protokolli kasutamine, mis aga muudab HTTPS liikluse Wireshark-i jaoks lahtivõetamatuks (erinevate krüptoprotokollide detailid on väljaspool selle artikli mahtu, kuid võtmefraasiks on siin perfect forward secrecy). Lähemalt loe näiteks: Wikipediast ja Stackexchange'ist.
Üks võimalikke lahendusi on Apache2 mod_ssl konfis (/etc/apache2/mods-available/ssl.conf) keelata Diffie-Hellman võtmevahetuse tugi, näiteks võtmesõna DH abil:
SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW
Vt. lähemalt: http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
Peale veebiserveri restarti tuleb teha uus paketipüüdmine. Kui kõik muu on korrektselt tehtud, võib Wiresharkis uue .pcap faili avamisel näha umbes sellist pilti ja HTTP päringut-vastust avatekstina uurida:
mitmproxy
Kliendi proxy seadistamine
Selleks, et mitmproxy abil HTTPS liikluse sisu uurida, tuleb ta kõigepealt HTTP kliendis (brauseris, curl-is vms) seadistada proxy-ks. Nimelt, kui mitmproxy käivitada, siis vaikimisi kuulab ta aadressil 0.0.0.0 pordil 8080. Seega curl-ile anname need parameetrid proxy jaoks ja teeme HTTPS päringu oma serveri pihta.
curl -x localhost:8080 --insecure https://192.168.56.201
See päring ja vastus kajastuvad nüüd mitmproxy interaktiivses aknas.
Päriselus kasutame vingemate veebirakenduste kasutamiseks siiski graafilist brauserit ja edasi läheme Chromiumi näitel, kus samuti on kõigepealt vaja seadistada proxy (ja brauser restartida). Seda siin ei kirjelda.
Teeseldud CA
Kui mitmproxy on seadistatud proxy-ks, siis HTTPS päringute korral pakub ta brauserile tegeliku serveri sertifikaadi asemel omaenda n-ö dummy sertifikaati (e. mängib CA-d) ja on seetõttu võimeline ka HTTPS liiklust "vahelt võtma", kuna HTTPS osapoolteks on klient ja mitmproxy, mitte enam server. Peale esimest käivitust tekivad kasutaja kodukataloogi alamkataloogi .mitmproxy selle dummy CA-ga seotud failid.
ls ~/.mitmproxy/ mitmproxy-ca-cert.cer mitmproxy-ca-cert.p12 mitmproxy-ca-cert.pem mitmproxy-ca.pem
Sellist dummy CA-d brauser vaikimisi ei usalda ja reageerib nagu tüüpiliselt ka iseallkirjastatud sertifikaatide puhul. Kui "harjumuspäraselt" vajutada "Proceed anyway", saame vaatlusalusele saidile tehtud HTTPS päringuid ja vastuseid üsna mugavalt uurida. Muidugi on mitmproxy CA võimalik lisada ka brauseri poolt usaldatavate CA-de hulka, aga seda siin ei kirjelda.
HTTPS päringute vaheltvõtmine
Edasi seadistame konkreetsele aadressile tehtavate päringute vaheltvõtmise. Selleks tuleb mitmproxy peaaknas vajutada "i" ja sisestada regulaaravaldis, mis meil on "192\.168\.56\.200".
Kui nüüd minna aadressile https://192.168.56.201, siis brauser jääb ootele ja mitmproxy aknasse tekib päringukirje, ning vaheltvõetud päringu edasisaatmiseks tuleb vajutada "a". Seda tuleb teha ka vastusega, kui me vastust muuta ei soovi, et brauser vastuse kätte saaks.
Päringuid ja vastuseid, mis veel ei ole "a" abil "aktsepteeritud", saame avatekstina uurida ja muuta! Lugejale jääb välja uurimiseks, mida mitmproxy peab silmas teatega "[decoded gzip] Couldn't parse: falling back to Raw" ja kas see takistab meil vastuse muutmist avatekstina.
Näide vaheltvõetud vastusest:
Põhjalikum mitmproxy kasutusjuhend kirjeldab nii päringute filtreerimist kui päringute ja vastuste redigeerimist ja palju muud.
Head eksperimenteerimist! ;-)
