Reverse Engineering IoT zariadenia
IoT (Internet of Things) zariadenia sa čoraz viac stávajú neoddeliteľnou súčasťou každodenného života a to nie len v prostredí domácností ale aj vo firmách, zdravotných zariadeniach či väčších spoločnostiach. V tomto článku sa pozrieme na bezpečnosť jedného IoT zariadenia, ktoré kvôli svojmu účelu môžeme nájsť naozaj kdekoľvek.
Zariadenie ktorého bezpečnosť budeme analyzovať patrí do skupiny "chytrých" zásuviek (Smart Plugs).
O bezpečnosti tohto zariadenia hovorí celá rada certifikátov a silných slov ako Military-grade encryption, GDPR a pod.
Toto IoT zariadenie umožňuje po zapojení do elektrickej zásuvky a spárovaní s mobilnou aplikáciou vzdialene zapínať/vypínať pripojené el. zariadenia, a to dokonca kdekoľvek zo sveta. Vďaka tomuto zariadeniu teda skončili časy kedy ste odišli z domu na víkend lyžovať, na svahu ste si spomenuli, že ste nechali zapnutú žehličku a váš celý výlet bol pokazený strachom, že vám zhorí byt – stačí jeden klik v mobilnej aplikácii, žehlička je na diaľku vypnutá a vy sa môžete pokojne oddávať radostiam z výletu.
S veľkou mocou ale prichádza veľká zodpovednosť a preto sa pozrieme na celý proces od konfigurácie zásuvky po spôsob akým prebieha komunikácia a taktiež sa pozrieme na fyzickú bezpečnosť.
Konfigurácia
Ako prvé zapojíme zásuvku do zdroja elektrickej energie a nakonfigurujeme pomocou mobilnej aplikácie.
Mobilná aplikácia je zdieľaná s ďalšími zariadeniami, pri konfigurácii teda vyberieme naše konkrétne zariadenie a v ďalšom kroku potvrdíme, že zariadenie je pripravené ku konfigurácii. Zariadenie ponúka 2 spôsoby konfigurácie. V rámci konfigurácie mobilná aplikácia predá informácie IoT zariadeniu, k akej WiFi sieti sa má po konfigurácii pripájať – teda jedná sa o napr. domácu WiFi sieť.
Prvá možnosť predstavuje spôsob kedy IoT zariadenie vytvorí vlastný WiFi prístupový bod a mobilná aplikácia vyzve užívateľa aby sa pripojil k tejto sieti. Užívateľ následne zadá konfiguráciu jeho domácej WiFi siete (názov a zdieľané heslo), ku ktorému sa zariadenie má pripájať. Pri analýze tohto spôsobu sme zistili, že vytvorená WiFi sieť IoT zariadením je otvorená (nevyžaduje sa heslo, pakety sú nešifrované).
A čo viac, samotné údaje predávané pri konfigurácii sú taktiež nešifrované a teda, ktokoľvek v dosahu schopný odchytávania paketov môže získať názov a heslo domácej WiFi siete užívateľa, ku ktorej sa následne môže bez problémov prihlásiť.
Druhým spôsobom akým je možno nakonfigurovať IoT zariadenie je tzv. SmartConfig protokol. Jedná sa o spôsob akým mobilná aplikácia predá informácie o užívateľovej domácej WiFi sieti IoT zariadeniu bez nutnosti vytvárať ďalšiu WiFi sieť. Technicky sa jedná o zložitý proces, ktorý nie je až tak dôležitý pre účely tohto článku, v jednoduchosti sa ale deje nasledovné:
- IoT zariadenie prepne svoj WiFi adaptér do monitorovacieho režimu
- IoT zariadenie začne odchytávať všetky WiFi pakety
- Užívateľ v mobilnej aplikácii špecifikuje názov a heslo k jeho domácej WiFi sieti
- Mobilná aplikácie zadané informácie zakóduje do dĺžky UDP paketov, ktoré začne následne posielať
- IoT zariadenie po prečítaní dĺžky týchto paketov sa snaží spätne dekódovať názov WiFi siete a heslo pre pripojenie
- IoT sa po úspešnom dekódovaní pripojí do WiFi siete užívateľa
V rámci šifrovanej WiFi siete do ktorej je zapojené mobilné zariadenie, môžu pakety odoslané mobilnou aplikáciou vyzerať nasledovne.
Pre IoT zariadenie, ktoré sa nachádza mimo túto sieť, sú tieto pakety zašifrované ale ich dĺžka koreluje s pôvodnou dĺžkou.
Inými slovami, ide o exfiltráciu citlivých údajov (prístupových údajov k domácej WiFi sieti) skrz veľkosť UDP paketov, ktorú dokáže odchytiť aj niekto, kto sa nachádza mimo túto sieť ale v dosahu vysielača.
Jak teda je vidieť oba spôsoby konfigurácie IoT zariadenia sú náchylné na únik informácii, kedy útočník môže jednoducho získať prístupové údaje k WiFi sieti a následne sa k nej pripojiť.
Komunikácia so svetom
Následne sa skúsme pozrieť na komunikáciu IoT zariadenia s okolitým svetom. Dolu uvedený graf znázorňuje priebeh komunikácie v čase s rôznymi stranami, pričom červene sú vyznačené tie kanály, ktoré nie sú šifrované. Jak je možné vidieť, celý proces začína tým, že mobilná aplikácia zažiada server o akýsi prístupový token. Tento token je unikátny pre každé IoT a generuje sa v dobe, kedy prišiel dotaz na tento token. Následne prebehne konfigurácia IoT zariadenia, popísaná vyššie, po ktorej začne zariadenie samo komunikovať so servermi poskytovateľa.
Z grafu je teda jasné, že k tomu aby bolo možné ovládanie našej "Smart" zásuvky, umožňujeme poskytovateľovi nielen prístup k samotnému IoT zariadeniu a možnosti ho vzdialene ovládať bez nášho vedomia, ale taktiež prístup do našej lokálnej siete – keďže zásuvka je neustále pripojené k našej WiFi.
Ďalej sa bližšie pozrieme na jednotlivé komunikačné kanály a ako sú (ne)chránené pred bežnými útokmi ako je odposluch, či MitM útokmi.
Ako prvá nastáva komunikácia IoT zariadenia a HTTP servera, v ktorej sa zariadenia inicializuje, získa doménové mená dôležitých serverov a ďalšie nastavenia. Jeden z prvých paketov, ktoré IoT odosiela je práve na získanie dodatočných nastavení a mimo iné aj šifrovacích kľúčov, nižšie uvedené secKey a localKey.
Celá táto komunikácia prebieha nešifrovane a teda ktokoľvek schopný odchytiť danú komunikáciu je schopný získať uvedené nastavenia a šifrovacie kľúče.
Následne sa vytvorí spojenie s MQTT serverom. Toto spojenie je tiež nešifrované, ale jeho obsah šifrovaný je. Pre pripojenie k MQTT serveru je nutné sa autentizovať, čo sa deje zaslaním hodnôt User Name a Password. User Name je hodnota pravdepodobne unikátna pre naše IoT zariadenie, ale Password je hodnota, ktorá pred malou chvíľkou bola prenesená skrz nešifrovaný protokol HTTP. Ide o hodnotu secKey, z ktorej sa spočíta MD5 hash a následne sa oreže špecifickým spôsobom.
Prihlasovacie údaje je teda možné buď priamo odchytiť, alebo ak nemáme pôvodný paket s prihlasovacími údajmi, je možné ich dopočítať z predošlých údajov.
Po autentizácii voči MQTT serveru je možné začať posielať dáta. Keďže samotný MQTT protokol nie je šifrovaný môžeme vidieť podobu dát, ale samotné dáta sú šifrované.
Našťastie, vďaka nešifrovanej HTTP komunikácii máme kľúč k rozšifrovaniu týchto dát. Na dešifrovanie dát nám bude stačiť jednoduchý Python skript, schopný dešifrovať AES v ECB (Electronic CodeBook) režime. Kľúč k rozšifrovaniu bol v predošlej HTTP komunikácii označený ako localKey. Samotné dáta sa ale skladajú z niekoľkých častí, pričom nás ale zaujíma len vyznačená časť, zvyšok je pravdepodobne verzia protokolu a akýsi kontrolný súčet:
2.184b7d7203221c6fd
V5l6nk8ee5cLjLSQ6xE2E6HPYndUzZ0yRv5vb1KSrPf8oUWTisoUZ8ah0vWpLby2ZUeGQ0WpO9x0rHl/SqKPhrc808S8ODamcHdsJMovRcS1gso3vMUEWFMrXUJ06IU6
Po rozšifrovaní dát môžeme vidieť, že sa jedná o akúsi správu obsahujúcu status zariadenia, kde:
"dps":{"1": false}
Určuje stav zásuvky, v tomto prípade stav vypnutá. Zmenou tohto stavu na hodnotu true sa zásuvka zapne.
Ako sme ukázali, komunikácia IoT zariadenia s okolitým svetom nie je nijak špeciálne zabezpečená. V niektorých prípadoch sa šifrujú dáta alebo sa vyžaduje autentizácia, no problémom je, že kľúče k šifrovaniu/prihlasovacie údaje sa posielajú v predchádzajúcej komunikácii nešifrovane - čím celé šifrovanie stráca zmysel .
Ďalším problémom samotného IoT zariadenia je, že v rámci lokálnej siete je možné so zariadením komunikovať na priamo a teda je možné vypínať/zapínať toto zariadenie. Naviac, po konfiguračnej fázy a teda počas celej doby fungovania, zariadenie stále prijíma "konfiguračný" paket, ktorým je veľmi jednoduché zariadenia prekonfigurovať útočníkom nachádzajúcim sa v lokálnej sieti. Týmto je buď možné vykonať DoS (Denial of Service) útok alebo zariadenie ovládnuť a získať pod svoju správu.
Zariadenie šifruje dáta taktiež v rámci HTTP komunikácie ale len pre odosielané POST parametre. Tieto dáta ale idú rozšifrovať rovnako ľahko ako MQTT správy, s tým rozdielom, že na dešifrovanie použijeme kľuč secKey a nie localKey. Toto platí pre všetky správy okrem správ, ktoré predchádzajú inicializácii (zariadenie ešte neobdržalo hodnoty secKey a localKey). Pre tieto prvé správy, zariadenie používa špeciálny kľuč, ktorý vznikne kombináciou reg_key (získaný z mobilnej aplikácie, ktorá ho získala od HTTP serveru) a pravdepodobne statickou hodnotou auz_key (táto hodnota sa neprenášala pri inicializácii a jak klient tak server ju musia poznať na šifrovanie/dešifrovanie komunikácie). reg_key teda útočník ľahko získa pri odchytávaní komunikácie. Získať auz_key môže predstavovať problém, keďže sa neprenáša v komunikácii a je ho možné extrahovať iba z flash pamäte zariadenia. Vzhľadom ale na povahu tejto hodnoty, je možné, že je rovnaká na rôznych zariadeniach a teda ju stačí extrahovať iba raz.
Mimo uvedené nedostatky, je v jednom z uvedených výpisov možné vidieť aj dotaz zariadenia na HTTP server s parametrom tuya.device.upgrade.silent.get. Tento dotaz pravdepodobne slúži na aktualizáciu firmware zariadenia a útočník, ktorý je v postavení MitM môže za určitých okolností zariadeniu podhodiť škodlivý firmware a tým zariadenie ovládnuť.
Fyzická bezpečnosť
Ako posledné sme sa pozreli na samotnú fyzickú bezpečnosť. Keďže IoT zariadenia často môžu predstavovať malé ľahko ukradnuteľné veci (ako napr. zásuvka), je určite namieste analyzovať možné riziká spojené s ukradnutím zariadenia. Mimo iné o tom svedčí aj nasledujúci komentár jedného z používateľov takéhoto zariadenia.
V prípade takéhoto použitia, nie je pre útočníka nič jednoduchšie, ako si takúto zásuvku pohodenú vonku nachvíľku "požičať" a skúsiť z nej získať užitočné informácie. Zásuvku je možné jednoducho rozobrať odskrutkovaním 4 skrutiek.
Po rozobratí našu pozornosť hneď zaujme modul TYWE3S. Chvíľka pátrania po internete a zistíme, že vlastne ide o nasledujúce 😊:
Našťastie nemusíme ísť študovať čínštinu, kľúčové slová sú TYWE3S a ESP8266. Nakoniec nám pomôže ešte rozloženie pinov.
Vďaka verejne dostupným informáciám a nástrojom ako je esptool, môžeme nielen prečítať obsah flash pamäte ale aj zapisovať. V rámci nášho článku si ale vystačíme len s čítaním. Náš ďalší krok je teda zapojenie USB-UART prevodníka na správne piny podľa uvedenej schémy.
Ďalší krok je už len jednoduché zapojenie prevodníka do USB a spustenie príkazu.
Súbor flash_contents.bin teraz obsahuje dump flash pamäte, ktorý môže analyzovať klasickým spôsobom – hex editor, extrakcia reťazcov pomocou programu strings, extrakcia súborov pomocou programu binwalk a pod. Ako ukážka nám bude stačiť pár extrahovaných reťazcov.
Z týchto reťazcov získame nielen servery na ktoré sa zariadenie pripája, ale aj verziu, šifrovacie kľúče, registračné kľúče a mimo ďalšie citlivé informácie aj názov a heslo k WiFi sieti kam sa zariadenie pripája. Po takto jednoduchej analýze náš pomyselný útočník môže vrátiť zariadenie na pôvodné miesto, pričom naviac získa prístup k WiFi sieti obete. V inom prípade môže útočník prepísať firmware svojím vlastným trojanizovaným firmwarom a tak získať trvalí prístup k sieti obete i po zmene WiFi siete alebo dokonca zmene bydliska (keďže zásuvka dokáže a zo svojej podstaty aj musí komunikovať skrz internet).
Zhrnutie
Ako sme ukázali v tomto článku, IoT zariadenia stále majú čo doháňať v oblasti bezpečnosti a to aj v prípade keď ich výrobca/distribútor tvrdí aké sú bezpečné. Odhliadnuc od toho, že užívateľ vkladá nesmierne veľkú dôveru do rúk poskytovateľa tým že mu sprístupňuje svoju vlastnú lokálnu sieť (pekne zabalený backdoor), má testované zariadenie kopu ďalších nedostatkov. Analyzované zariadenie už počas svojej konfigurácie hlási celému okoliu prístupové údaje k užívateľovej WiFi sieti, komunikuje s viacerými servermi pomocou otvorených protokolov do ktorých každý poslucháč na sieti vidí a kvôli absencii overovania identity taktiež umožňuje radu MitM útokov. Naviac, čo sa týka fyzickej bezpečnosti, zariadenie je len tak bezpečné, ako miesto kde je uložené. Pri krádeži ho útočník môže bez väčšej námahy vypitvať a extrahovať citlivé údaje pomocou ktorých následne môže získať prístup k WiFi sieti obete alebo vykonať radu ďalších útokov.