Vlákno názorů k článku Virus v bezdrátových routerech - Skynet od M@v - Děkuji za více než užitečnou informaci - opět...
-
M@v (neregistrovaný)
Děkuji za více než užitečnou informaci - opět ukázka jedné hyper super klikací obezličky, který v téhle podobě podle mě nemá na žádném zařízení co dělat.
Nicméně zveřejněním postupu manuální instalace viru byla de-facto zveřejněna informace o zranitelné cestě přímo v článku. Nešlo napsat alespoň "najděte si cestu v archivu" nebo něco podobného? Docela mě děsí až si nějaké kiddie dá dvě a dvě dohromady a začne instalovat bez konzole :-(
Tomáš
-
Jenda (neregistrovaný)
Pokud vývojáři zmíněného SW o chybě už vědí, nevidím v tom, že se jede na full disclosure, problém.
Nicméně způsob odstraňování v článku je nešťastný, protože nectí zásadu „jednou rootem, navždy rootem“. Může se tedy stát, že útočník bude mít k systému přístup pořád. Pomohla by jen úplná reinstalace.
-
pixall (neregistrovaný)
UBNT zariadenia bezia na read-only filesysteme (neda sa remountovat na read/write). Virus sa uklada iba do oblasti kde je konfiguracia, do adresra ktory je urceny pre uzivatelske skripty. Reset konfiguracie na likvidaciu staci. Ak ovsem utocnik neflashne medzicasom do zaiadenia svoj zmeneny firmware. V kazdom pripade reflash firmware a vymazanie konfiguracie (aspon adresarov kde sa virus uklada) bude 100% v pohode. Do read-only filesystemu (squashfs) je principialne dost velky problem nieco zapisat.
Horsie je to ze diera je zverejnena a ze dostat sa do cudzieho zariadenia je trivialne.
K clanku by som opdotkol len tolko ze navrhovane opravy (doplnenie airos.deny) nie su ucinne (treba zakazat vsetky vynimky, potom ale uz nejde web rozhranie vobec). Bud si treba vypnut web rozhranie uplbne alebo neexistuje (bez rekompilacie firmware a modulu mod_airos) ziadna oprava alebo uprava ktora by to riesila.
-
Uváděná konfigurace /usr.../lighttpd.conf řeší všechny případy podvržení url,
akorát ji musíte dostat do squashfs (vlastní firmware), nemusíte pak řešit nahrání pomocných věcí v /etc/persistentJinou variantou je, nahrát lighttpd.conf do /etc/persistent a přinutit (konfigurace /etc/lighttpd.conf) lighttpd aby používalo konfigurační soubor v /etc/persistent.. Jenže to znamená úpravu rc.poststart a kill webserveru po startu. To mi přišlo velmi komplikované, tak jsem to do článku neuváděl a raději uvedl, že je to lepší dát do upraveného firmwaru.
-
pixall (neregistrovaný)
Kym je v airos.allow napisane "/login.cgi", je mozne pridanim tohto stringu do URL vyvolat zelane (chybove) spravanie. A v momente odstranenia "/login.cgi" z airos.allow (alebo po jeho pridani do airos.deny) uz sice chyba nie je pritomna, ale do weboveho rozhrania sa viac neda prihlasit.
Rekompilaciou sa da odstranit admin.cgi co moze trochu pomoct, ale fakt len trochu. Bez opravy mod_airos (parsovania URL) sa (imho) neda odstranit stav, ze bez hesla sa da citat (a menit) konfiguracia zariadenia.
Ste mi tym clankom pekne posrali vianoce, smradi. Co oci nevidia, to srdce neboli...
-
lukic (neregistrovaný)
skuste ale napr:
http://ip.ad.re.sa/admin.cgi/uplnachujovina/login.cgi
a toto uz otvori.. zabezpecenie bud treba doriesit dokompilovanim matchnutia na zaciatok a koniec stringu alebo vypnutim prepisu od UBNT.
-
MilanK (neregistrovaný)
Trochu jsem se na to podíval: musí se upravit lighttpd, přesněji modul mod_airos.c:
Ve funkci mod_airos_uri_handler() se sice správně testuje con->uri.path (přesněji se to testuje v uri_is_in_list()), jenže v době testování obsahuje uri.path ještě "path info".
To "path info" se detekuje/odstraňuje až později (response.c:699), takže uri.path bez něj vidí až mod_airos_subrequest_start(). Teprve v ní by měly být volány testy deny/allow. (Název deny/allow je trochu matoucí, protože "deny" znamená odmítnout úplně, kdežto "allow" znamená poslat bez autorizace - to, co není ani v "deny", ani v "allow" posílá jen autorizovaným uživatelům).
Ještě by se slušelo dát do uri_is_in_list() výjimku, že pokud testovaný vzorek začíná lomítkem, musí být shoda v celé délce.
Ubiquiti na tom prý pracuje, pravděpodobně dojdou k podobnému závěru, tak jsem línej přetahovat ty testy z mod_airos_uri_handler do mod_airos_subrequest_start, protože to stejně udělají za chvilku také... Proti zveřejněné verzi "skynet" stačí ochrana popsaná v článku, tak se snad dočkáme opravy z USA dříve, než přijde skynet2 ;-)
-
Ad „opět ukázka jedné hyper super klikací obezličky, který v téhle podobě podle mě nemá na žádném zařízení co dělat“
Více méně souhlas – problém je jednak v tom, že se nepoužívají standardní a vyzkoušené prostředky/frameworky, ale nějaký vlastní, evidentně nedostatečně otestovaný a zkontrolovaný bastl, a jednak v tom, že je to malé zařízení, je potřeba extrémně šetřit zdroji → je tu vyšší pravděpodobnost, že dojde k chybě.
Na druhou stranu, uživatelé těchto zařízení jsou často lamy a nějaké uživatelsky přívětivé rozhraní je pro ně nutnost – nejsou schopní psát něco do příkazové řádky, bohužel.
Napadají mne dvě možnosti, jak by se to dalo zlepšit:
1) Použít HTTP autentizaci – to je standardní a vyzkoušené řešení a v implementaci by neměly být takové trapné chyby, jako předvedli autoři té formulářové autentizace. Webová aplikace by pak mohla být i děravá, ale tolik by to nevadilo, protože přes HTTP autentizaci by se k ní dostal jen ten, kdo by znal jméno a heslo.
2) V zařízení mít jen to nejnutnější, žádný webový ksindl, jen SSH. A udělat nějakou pěknou a přívětivou aplikaci, která by běžela u uživatele na desktopu, připojovala se přes SSH a pouštěla na dálku příkazy.
-
Karel (neregistrovaný)
Ad 2 - to je cesta do pekla. Obyčejný uživatel by to vnímal tak, že musí do PC instalovat "ovladače pro tu krabičku". A bez nich že to ani nezkonfiguruje. Pak by se začala řešit kompatibilita s různými OS a po nějaké době by tu byli nešťastní uživatelé, kterým "ty ovladače" nějak nefungují a skupina IT profesionálů, kteří si budou ťukat na hlavu proč vůbec někoho napadlo dělat standardní konfiguraci !routeru! jako samostatnou aplikaci, navíc když je tu zažitý postup - konfigurace přes web. Za pár měsíců by si už málokdo vzpomněl, že to celé začalo jen tím, že autoři neuměli napsat bezpěčný webový interface.
Jinak já osobně webové rozhraní preferuji. Jsem na něj zvyklý u routerů, u HW print serverů, tiskáren, IP kamer, vlastně snad všech těch krabiček. Jsou jich tu kolem desítky (možná i lehce přes stovečku) a já se nemusím nazpaměť učit jak se která konfiguruje. Ověřit stav tiskárny nebo routeru zvládnu z jakéhokoliv PC s prohlížečem ať už na něm běží OS jaký chce. Jediné co musím vědět je IP adresa, zbytek je intuitivní nebo "až to uvidím, tak si vzpomenu".
