Let it only be me who is (pen)testing my home network (Part I)
18.5.2017

V svojem prejšnjem članku sem prikazal nekaj specifičnih šibkih točk zloglasnega omrežnega protokola uPnP. V sklopu analize sem spoznal, da je ta protokol precej pogost v današnjih domačih omrežjih. Na srečo so v mojem domačem usmerjevalniku, ki sem ga poln zaupanja prejel od svojega ponudnika internetnih storitev (v nadaljevanju se bom izogibal uporabi imen ali znamk), vse možnosti zunanjega upravljanja privzeto onemogočene. Iskreno cenim skrb svojega ponudnika internetnih storitev, saj ta naprava deluje že precej dolgo in to brez mojega paranoičnega preskušanja njenih morebitnih varnostnih ranljivosti. Tako ni bila nikoli izpostavljena zunanjim napadom.

Nato pa me je prešinilo. Zakaj ne preverjati varnosti domačega usmerjevalnika iz notranjosti omrežja? Ali še pomembneje, kako varna je moja domača pisarna, predvsem pa njeni uporabniki in njihovi podatki. Morda se vam bo zdelo čudno, da bi nekdo iz svojega naslonjača poskušal vdreti v svoj domači usmerjevalnik? Morda malce »geeky«, vendar z argumenti. Suvereno lahko zatrdim, da najbolj dodelane grožnje pretijo prav končnim uporabnikom. Zakaj je temu tako? Prvič, to je lažje za napadalca. Drugič, skoraj vsi zaupajo članom domačega omrežja, mar ne? Naj vam podam nekaj primerov.

  1. uPnP je resda onemogočen ali ni na voljo na zunanjih vratih usmerjevalnika. Torej, zakaj ga ne bi izkoristili iz notranjosti; ko heker ali nepooblaščena koda pridobi dostop do notranjega vira, lahko od tam nadaljuje z nadaljnjimi poskusi zlorabe drugih naprav v omrežju. Ne pozabite, uPnP ne zahteva nobenega predhodnega overjanja na napravah, ki sodelujejo v procesu samodejnega nastavljanja.
  2. Skrbniški grafični uporabniški vmesnik usmerjevalnika je na voljo samo notranjim uporabnikom. Zakaj jih ne bi izkoristili za odpiranje stranskih vrat, prek katerih lahko kasneje zunanji uporabniki prosto vstopijo.

Oba scenarija sta realna samo ob določenih vnaprej izpolnjenih pogojih. Seveda mora zunanji uporabnik dobro opraviti svojo domačo nalogo in analizirati žrtve ter morebitne vektorje napadov. Ali poznavanje proizvajalca naprave CPE hekerju olajša delo? Zagotovo. Precej mogoče je, da je širši javnosti že znan način izkoriščanja določene ranljivosti. Kako dragoceno je za napadalca, če pozna zbirko naročnikov določenega ponudnika internetnih storitev? Neprecenljivo! Vsi ti imajo eno skupno točko – njihov ranljivi internetni domači prehod. Potem lahko napadalec enostavno »pogoogla« poišče e-poštne naslove svojih žrtev in jim dostavi primerno izkoriščevalsko kodo prek svoje priljubljene tehnike socialnega inženiringa.

Kar nekaj časa mi je vzelo iskanje znane CVE-je (Common Vulnerabilities and Exposures) ali javno objavljene ranljivosti. Vendar pa sem si bolj želel sam prepoznati morebitne šibke točke svojega domačega prehoda. Še posebej sem se osredotočil na tiste, ki bi jih bilo mogoče zlorabiti samo s prevaro nič hudega slutečih žrtev. Na primer z zavajanjem do klika spretno sestavljenega naslova URL ali z izvedbo zlonamerne kode, ki je vgrajena v Wordov dokument z omogočenimi makri.

Možnost XSS (Cross-site scripting) v skrbniškem vmesniku usmerjevalnika je bila dober kandidat za začetek. Takšna pomanjkljivost lahko napadalcu omogoča prevzem skrbniške seje (piškotek) po kliku zlonamerno sestavljenega naslova URL. Sprva sem odkril, da skrbniški vmesnik usmerjevalnika sicer upošteva piškotek skrbniške seje, vendar ta ne vsebuje splošno priporočenega atributa »HTTP-only«. Jackpot! Drugi predpogoj za uspešen prikaz ranljivosti XSS je šibka izvedba preverjanja veljavnosti uporabniških vnosov. Z uporabo proxy orodja za prestrezanje sem dobesedno preplavil najbolj interaktivne konfiguracijske menije usmerjevalnika in oprezal za morebitnimi sledmi vhodnih podatkov v izhodnih HTML izpisih. Na mojo žalost so vhodni podatki uporabnika ustrezno preverjani za vse znane zlonamerne meta-znake na obeh straneh, tako na odjemalcu (javascript) kot na strežniku (usmerjevalnik). Vseeno pa je bilo zanimivo opazovati informativne odgovore prehoda ob vsakem poskusu s prikazanimi znaki, ki so prekršili pravila veljavnih vhodnih podatkov. Koristne povratne informacije v obliki »Special characters such as &<>" ' / \ are not valid« (Posebni znaki, kot so &<>" ' / \, niso veljavni) pri poskusu izogibanja filtrom vhodnih podatkov v konfiguracijskih menijih WiFi SSID. Odlične informacije za (etičnega) hekerja!

To me je dovolj navdahnilo, da sem nadaljeval z naprednejšimi tehnikami vdiranja. Na vrhu mojega seznama je bila varnostna analiza možnih ranljivosti tipa CSRF (Client Side Request Forgery) (ponarejanje zahtevkov na strani odjemalca). Moj cilj je bil sestaviti takšen naslov URL, ki bi pomembno nastavitev usmerjevalnika spremenil v prid napadalca. Vse to že samo s klikom na tako pripravljen URL naslov.

Najbolj so me pritegnile nastavitve zunanjega upravljanja usmerjevalnika. Z uporabo prestreznega proxy-ja sem poustvaril izvorni zahtevek HTTP(S) POST, ki omogoča omejevanje oddaljenega upravljanja. Kmalu sem odkril zelo deskriptivne parametre HTTP(S) POST »remote management« (oddaljeno upravljanje) in »upnp enable« (omogoči upnp). Oba vsebujeta privzeto vrednost »disable« (onemogoči) pri vsakem pošiljanju obrazca.

Input 

V transakcijah HTTP(S) POST ni vdelane varovalke CSRF, ki bi posamezne zahteve povezal z ustreznim predvidenim in legitimnim skrbnikom. S spremembo teh informativnih vrednosti v »enable« (uveljavi) je mogoče, če ranljivost obstaja, spremeniti privzeto delovanje usmerjevalnika v izvajanje skritih funkcij oddaljenega upravljanja usmerjevalnika. Zmaga! Že samo s klikom posebej sestavljenega naslova URL, ki je podatke poslal z mojim, že izpolnjenim obrazcem CSRF HTML. Morda bo kdo trdil, da napadalec s tem ne pridobi nič posebnega. V nadaljevanju vdora bi še vedno moral uporabiti grobo silo za ugotovitev skrbniških poverilnic. Seveda, če te niso bile puščene na privzetih vrednostih, kot so »admin/admin« ali »admin/blank«. Vam je znano?

Neodvisno od prejšnjih testov sem se osredotočil na ožje področje, na tiste najpomembnejše nastavitve v konfiguracijskih menijih usmerjevalnika. Če niso primerno zasnovani, to lahko zunanjemu hekerju dovoli nadzor nad vsako zahtevo, ki prihaja iz notranjega omrežja žrtve. Samega sebe sem spodbujal h kreativnemu razmišljanju bližje pravemu napadalcu! Tako sem pomislil na DNS, zaledno storitev razreševanja domenskih imen, ki jo je mogoče v vseh usmerjevalnikih SOHO nastaviti ročno. Najbrž ni treba poudarjati, da je DNS lahko na voljo tudi kot zunanja storitev za domače uporabnike, npr. izvaja se lahko nekje v internetu. Storitev DNS lahko tudi, če je zlonamerna, razrešuje v lažna imena in poizvedbe odjemalcev tako preusmerja na klonirane ciljne strani. Vidite, kam ciljam?

S tem uspešnim prikazom sem sestavil še en naslov URL, tokrat za CSRF obrazec spremembe storitve DNS. Spodaj je izsek moje kode »samo en klik stran«, ki DNS mojega domačega prehoda spremeni v zlonamerno alternativo (gostovana na naslovu 1.2.3.4).

html 

Naslovitev mojega domačega prehoda s spremenjeno zahtevo HTTP ponastavi privzeto nastavitev DNS in napravo tudi ponovno zažene. Presenetljivo, vnovično overjanje povzročitelja takšne transakcije sploh ni zahtevano. Tukaj moram posebej poudariti, da so takšne zahteve učinkovite samo, če je žrtev že prijavljena. To pa ni tako malo verjetno po tem, ko žrtev prejme lažno e-pošto s prepričljivimi navodili (zato so običajno prevedena) vsiljivca.

Mail

Kot dokaz uporabnosti je moj zlonamerni strežnik DNS podajal samo en »DNS zapis«. Klonirano ciljno spletišče storitve Gmail, ki zahteva vnos Gmail gesla uporabnika v njegovem domačem omrežju. Samo pomislite, koliko drugih storitev imate povezanih s svojih računom Gmail. In če še vedno niste prepričani, si vzemite čas za ogled nagovora Mikka Hypponena. Seveda bi lahko šlo za poljuben shranjeni vir, npr. e-bančništvo ali naslov omrežja VPN vašega podjetja. Z uporabo HTTP ali varnega HTTPS, v obeh primerih je mogoč popoln prevzem s strani napadalca. To so samo moji najhujši strahovi, na kaj pa vi pomislite najprej?

Bralce mojih ugotovitev po opravljenih varnostnih testih spodbujam, naj ne pretiravajo z odklopom svojih domačih omrežnih naprav. Vse le ni tako črno-belo. Poleg tega morajo biti za izvedbo takšnega vdora izpolnjeni številni predpogoji. Od poglobljenega zbiranja informacij o ponudniku internetnih storitev in morebitnih ranljivostih njegovih naprav CPE do zavajanja baze naročnikov istega ponudnika v klik lažne povezave. Me pa vse skupaj sili v razmišljanje o varnostni problematiki interneta stvari (IoT) in varnostnih izzivih v orkestriranih okoljih IT. Na obeh področjih vidim veliko vzporednic, ki jih lahko projiciram na osnovi mojih preizkusov. Sem mar edini?