Honíme botnet: od honeypotu k analýze routeru

Reakce na hlášení z našeho honeypotu

Takováto reakce na zprávu z našeho honeypotu pochopitelně zaujala moji pozornost. Požádal jsem tedy dotčeného ISP o pomoc a netrvalo dlouho a na stole jsem měl zapůjčené dva vzorky routeru Billion BiPAC 9800VNXL. Jeden přímo odhalený našimi honepoty a druhý čistý pro porovnání v případě, že by se jednalo o trvalou nákazu.

Po prvním „osahání“ přišlo trochu zklamání. Zařízení nemělo klasický shell, ale jenom jakousi příkazovou řádku na telnetu, která byla pro další analýzu naprosto neužitečná.

Když už jsem pomalu začal vzdávat svoji snahu a smiřoval se s tím, že nebudu schopen porovnat vzorky firmwaru z obou zařízení, zkusil jsem poslední možnost. Připojil jsem zařízení do internetu na veřejnou IP adresu. A vyplatilo se. Přibližně během do dvou hodin byl router plně kompromitovaný a stal se součásti botnetu. Hned jsem ho tedy odpojil od sítě a jal se analyzovat zachycená data.

Ukázalo se že router trpí zranitelností umožňující vzdálenému neautorizovanému útočníkovi spustit libovolný kód. Útok se skládá ze dvou HTTP/SOAP dotazů, přičemž ve druhém byl uschován řetězec:

Došlo tedy ke stažení a spuštění binárky a připojení infikovaného routeru k botnetu. Ze zvědavosti jsem binárku nahrál na Virustotal, ale jak se dalo očekávat, architektury jako například MIPS nejsou úplně zajímavé pro antivirové společnosti, jako podezřelý označil vzorek pouze jeden antivir z 55. Na základě posbíraných dat jsem si napsal krátký skript, který mi umožňoval do routeru posílat příkazy. Ty se nakonec zdrcly jen na vypnutí telnetového démona a jeho opětovné spuštění, ale tentokrát s parametrem -l /bin/sh, což mi udělalo velkou radost, protože jsem měl konečně přístup ke klasickému shellu.

Následně jsem již snadno z obou routerů vytáhl firmware a ověřil kryptografické otisky jednotlivých oddílů. Oddíl s kořenovým adresářem a linuxovým jádrem byly na chlup stejné. Lišily se pouze oddíly bootloaderu a oddíl s uloženou konfigurací. Rozdíl v konfiguracích byl nezajímavý a v bootloaderu se dle očekávání lišila pouze uložená MAC adresa. Porovnání oddílů tedy dopadlo dle očekávání, nebývá totiž časté, aby malware přepsal firmware. Částečně také proto, že oddíl s kořenovým adresářem používá jako systém souborů squashfs a při úpravě je zapotřebí, aby byl přepsán celý oddíl.

Porovnání kryptografických otisků jednotlivých oddílů

Po porovnání firmwarů jsem se vrátil k zpět k prošlému útoku a nalezené zranitelnosti. Samotný malware se choval celkem slušně. Upravil si iptables, tak aby sám sebe ochránil před případnou následnou nákazou zablokováním portů zranitelné služby. A hned na to se jal scanovat náhodné IP adresy za účelem dalšího šíření. Už jen chyběla hláška v telnetu o „zabezpečování zařízení“ a dalo se hádat, že se nejspíš jednalo o botnet Hajime. Ze zvědavosti jsem udělal ještě pár pokusů a nejkratší čas napadení čistého zařízení nepřekročil 10 minut.

Samotná zranitelnost tedy umožňuje vzdálené spuštění libovolného kódu (remote code execution) s maximální délkou řetězce 62 bajtů. Konkrétně se jedná o „vlastnost“ „NewNTPServer“ protokolu TR-064, který je určen pro konfiguraci po lokální síti, ale zřejmě následkem chybné implementace je dostupná i z Internetu v rámci protokolu TR-069. Zranitelnost byla objevena na portu 7547, ale v našem případě se týká i portu 5555, který obsluhuje stejný program ( /userfs/bin/tr69). První informace o této zranitelnosti u jiného routeru se objevila 7. listopadu loňského roku a jednalo se o Eir’s D1000. Zneužití této zranitelnosti je velice snadné a odkazovaná stránka obsahuje i modul do Metasploitu.

Na stránkách výrobce routeru nebyla o dostupnosti jiných verzí firmware ani zmínka, proto jsem jej kontaktoval s popisem nalezené zranitelnosti a dotazem, zda bude připravovat nějakou opravu. Při kontaktování výrobce routeru ohledně zranitelnosti však vyšlo najevo, že nová verze firmwaru již existuje a je přímo přeposílána cílovým zákazníkům (zřejmě ISP). Sami uživatelé pak bohužel nemají možnost zjistit ani existenci nové verze firmware či existenci a závažnost zranitelnosti, kterou jimi používaný produkt obsahuje.

Proto v tuto chvíli zvažujeme možnost vytvoření webových stránek, kde by si lidé mohli nechat automaticky otestovat svoje zařízení na tuto zranitelnost. Jednou z drobných překážek však bude nutnost požadovat od uživatele vypnutí a zapnutí zařízení, protože pokud by již router byl napadený podobným způsobem, zranitelnost by se díky blokovanému portu v iptables neprojevila.

Při hledání souvisejících CVE ID nebylo žádné nalezeno. Po komunikaci s Mitre došlo k přidělení nového CVE-2016–10372 pro zranitelnost dříve objevenou na modemu Eir a po dalším zkoumání pak bude pro BiPAC 9800VNXL přiděleno nové CVE ID a nebo pokud se prokáže, že se jedná o stejný software se stejnou chybou, tak se přidá na seznam zranitelných zařízení pod CVE-2016–10372.

I když se nejedná o zcela novou chybu a ani příliš rozšířená zařízení, jsem rád, že se nám podařilo projít celým řetězcem událostí, od detekování bezpečnostního incidentu vlastními prostředky, přes analýzu celé události až po komunikaci se zainteresovanými stranami.

Závěrem bych chtěl poděkovat Radku Jiroutovi z Dial Telecom za nahlášení vadného zařízení.

Odkazy:

• https://devicereversing.wor­dpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/ 
• https://isc.sans.edu/forum­s/diary/TR069+NewNTPServer+Ex­ploits+What+we+know+so+far/21­763/ 
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016–10372 
• https://www.broadband-forum.org/technical/download/TR-064.pdf 
• https://www.broadband-forum.org/technical/download/TR-069.pdf 

(Původně vyšlo na blogu CZ.NIC.)