Praktiˇcno bomo predstavili eden najbolj znanih napadov v raˇcunalniˇskih komunikacijah – napad z vrivanjem ali napad s posrednikom (angl. man in the middle – MITM). Pri tem bomo videli dodatni pomen dodatnega zavarovanja na transportni plasti, saj bomo napad uspeˇsno izvedli na MQTT omreˇzju, ki zahteva tako avtentikacijo kot avtorizacijo. Normalno delovanje testnega omreˇzja vidimo na sliki 6.10, posledice napada z vrivanjem pa na sliki 6.11. Tokrat bomo primer uporabe kanˇcek spremenili – uporabili bomo senzorje mobilnega telefona in lokalno omreˇzje namesto mobilnih podatkov.
6.4.1 Arhitektura omreˇ zja
Naˇse testno omreˇzje vsebuje 6 naprav, in sicer:
1. Usmerjevalnik ASUS (192.168.22.1) – veˇze ostale naprave z zunanjim svetom, toda njegova naloga v tem preizkusu je samo posredovanje sporoˇcil MQTT v lokalnem omreˇzju.
2. Mobilni telefon Xiaomi Mi A2 (192.168.22.214) – igra vlogo poˇsiljatelja.
S senzorji bere podatke iz zunanjega sveta (pospeˇskometer, ˇziroskop, GPS itd.). Te podatke potem objavlja posredniku na podtemah niza /avtomobili/uporabnik1/lokacija/#.
3. Namizni raˇcunalnik (192.168.22.169) – ne igra pomembno vlogo. Na njemu je zgolj zagnan prvi navidezni raˇcunalnik Kali (napadalec).
4. Navidezni raˇcunalnik Kali 1 (192.168.22.61) - igra vlogo napadalca.
Izvede napad z vrivanjem in prepriˇca poˇsiljatelja, da se pogovarja s posrednikom in obratno.
5. Prenosnik Lenovo T550 (192.168.22.81) – igra vlogo posrednika. Od poˇsiljatelja in naroˇcnika zahteva uporabniˇsko ime in geslo. Prenaˇsa sporoˇcila MQTT od poˇsiljatelja do naroˇcnika.
6. Navidezni raˇcunalnik Kali 2 (192.168.22.112) – igra vlogo naroˇcnika in je naroˇcen na podteme niza/avtomobili/uporabnik1/lokacija/#.
Slika 6.10: Arhitektura omreˇzja (normalno delovanje).
Slika 6.11: Arhitektura omreˇzja (napad z vrivanjem).
6.4.2 Potek napada
Za zaˇcetek namestimo program Mosquitto na napadalcu, posredniku in naroˇ cni-ku. Poˇsiljatelj (mobilni telefon) uporablja aplikacijo Sensor Node Free, ki omogoˇca branje podatkov s senzorji in njihovo poˇsiljanje preko protokola MQTT.
Posrednik podobno kot prej zaˇzene Mosquitto posrednik z ukazom mosquitto -v -c /etc/mosquitto/mosquitto.conf.
Nanj se poveˇzeve naroˇcnik z ukazom
mosquitto_sub -h 192.168.22.112 -u uporabnik1 -P geslo1 -t
"/avtomobili/uporabnik1/lokacija/#".
Napadalec vklopi orodje Ettercap, ki je privzeto vsebovano v distribuciji Kali. Potem vnese dvojˇcek naslovov IP, kot prvi poˇsiljateljev (192.168.22.214), kot drugi posrednikov (192.168.22.112).
Izbere opcijo ponarejanja paketov ARP (angl. ARP spoofing) in zaˇzene napad (6.12). Potem lahko nemoteno prisluˇskuje, saj posrednik misli da govori s poˇsiljateljem, obratno misli tudi poˇsiljatelj.
Slika 6.12: Ponarejanje paketov ARP v programu Ettercap.
S tem je zaupnost podatkov naruˇsena v celoti . Slednje dokaˇzemo z zajemanjem prometa v orodju Wireshark (slika 6.13).
Slika 6.13: Posnetek paketov od strani napadalca.
Ko zaˇcne poˇsiljatelj poˇsiljati tok podatkov proti posredniku, bo vse teklo preko napadalca in bo zato vidno tudi v programu Wireshark. Naroˇcnik bo sicer prejel vse pakete poˇsiljatelja, a ne bo vedel, da je povezava kompromi-tirana. Kot vidimo na sliki 6.14, komunikacija za njega poteka normalno.
Slika 6.14: Naroˇcnik uspeˇsno prejema pakete, posrednik uspeˇsno posreduje pakete
6.4.3 Moˇ zne posledice
Posledice takˇsnega napada za naˇs primer uporabe so ˇstevilne. Celovitost sporoˇcil je vpraˇsljiva, saj lahko napadalec z enostavno logiko vsako
priha-jajoˇce sporoˇcilo poljubno spremeni in posreduje ponoru. ˇCe ˇzeli, ga lahko celo ”odstrani”, zadrˇzi zase in ga ne posreduje. Prav tako trpi zasebnost, saj vsa sporoˇcila potujejo preko tretje entitete, brez vednosti akterjev.
Konkretno je za naˇs primer najbolj problematiˇcno, ˇce bi napadalec za-molˇcal opozorila. Odjemalec misli, da je sporoˇcilo uspeˇsno poslal pravemu posredniku, a so njegovi klici na pomoˇc zgolj shranjeni pri neznani, tretji entiteti. Lahko bi tudi spremenili telo sporoˇcila. Npr. namesto sporoˇcila, ki opozarja na nesreˇco uporabnika 1, bi lahko posredovali sporoˇcilo, ki opozarja na nesreˇco uporabnika 2. ˇCe bi ob sporoˇcilu poˇsiljali tudi lokacijo, bi jo lahko popolnoma spremenili in tako prelisiˇcili skrbnika sistema.
6.4.4 Prepreˇ cevanje napada
Slika 6.15: Primerjava zajete komunikacije z in brez SSL-a.
Enostavna in sploˇsna reˇsitev za takˇsen napad je uporaba protokola SSL. ˇCe moˇcno poenostavimo: akterji svojo identiteto dokaˇzejo s certifikati, ki jih do-deli certifikatna agencija (angl. certificate authority. Potem se dogovorijo za ˇsifrirni algoritem, varno izpeljejo kljuˇce in nato poˇsiljajo ˇsifrirana sporoˇcila.
Z uporabo SSL-a smo izboljˇsali avtentikacijski mehanizem ter ˇsifrirali komu-nikacijo.
Na kratko bomo opisali poenostavljeno implementacijo s programom OpenSSL, vendar zgolj za namizne naprave (saj SSL ˇzal ni podprt v aplikaciji SensorTag).
1. Ustvarimo mapo certs in v njej tri podmape ca, broker in client.
2. V podmapi ca generiramo kljuˇc certifikatne agencije:
openssl req -new -x509 -days 365 -extensions v3_ca -keyout ca.key -out ca.crt.
3. V podmapi broker generiramo kljuˇc posrednika openssl genrsa -out broker.key 2048.
4. Ustvarimo zahtevo za certifikat in jo posredujemo naˇsi agenciji, ki nam ustvari digitalni certifikat posrednika:
openssl req -out broker.csr -key broker.key -new
openssl x509 -req -in broker.csr -CA ../ca/ca.crt -CAkey ../ca/ca.key -CAcreateserial -out broker.crt -days 100.
5. V podmapi client generiramo kljuˇc odjemalca openssl genrsa -out client.key 2048.
6. Ustvarimo zahtevo za certifikat in jo posredujemo naˇsi agenciji, ki nam ustvari digitalni certifikat odjemalca:
openssl req -out client.csr -key client.key -new
openssl x509 -req -in client.csr -CA ../ca/ca.crt -CAkey ../ca/ca.key -CAcreateserial -out client.crt -days 100.
7. Konfiguracijsko datoteko posrednika spremenimo tako da referenciramo certifikat in kljuˇc posrednika ter kljuˇc agencije, nastavimo vrata za ˇsifrirana MQTT sporoˇcila 8883 ter izrecno zahtevamo uporabo SSL-a.
Dodamo vrstice:
port 8883
cafile /home/kali/diplomska/certs/ca/ca.crt
certfile /home/kali/diplomska/certs/broker/broker.crt keyfile /home/kali/diplomska/certs/broker/broker.key require_certificate true
Poslediˇcno bo vsa komunikacija s posrednikom ˇsifrirana, vsaka neˇsifrirana MQTT zahteva pa zavrnjena. Razliko med komunikacijama z in brez SSL-a vidimo tudi na sliki 6.15; s SSL-om so sporoˇcila ˇsifrirana, sicer pa niso.