PL TP-Link WR840N v3 2 – 0day Os Command Injection

Początek

Jest to chyba jeden z najfajniejszych błędów, na które może się natknąć researcher podczas swoich badań. Tym bardziej, kiedy taki bug został zaprojektowany i wdrożony przez programistę w dosyć nieoczekiwanym miejscu (ku uciesze bezpiecznika, który go później wyłapuje oczywiście). Podchodząc jednak do tematu poważnie to podatność typu Os Command Injection stwarza atakującemu całkiem niezłe możliwości idące na równi z potencjalnymi zagrożeniami dla użytkownika końcowego, korzystającego z urządzenia na co dzień. Skutkiem ubocznym odkrycia takiej podatności jest jakaś “dzika satysfakcja” badaczy, którzy na taki błąd mogli się natknąć nierzadko po hektolitrach kawy, zażywania wiedzy swoich kolegów, psucia sprzętu czy wielu nieprzespanych nocy.

1. Dane diagnostyczne – w tym SSID innych sieci w obrębie routera.

W naszej aplikacji (panelu administratora) istnieje podstrona gdzie użytkownik ma możliwość wyszukania dostępnych sieci WIFI w obrębie działającego routera.

2. Opcja wyszukiwania sieci WIFI przez panel administratora. Widniejący na obrazku powyżej przycisk „Survey” rozpocznie wyszukiwanie dostępnych sieci. Po zakończonej operacji pisze wszystkie znalezione identyfikatory SSID na standardowe wyjście w aktywnej sesji shella co można zobaczyć na obrazku nr. 1.

Idąc tym tropem wpadłem na pomysł aby utworzyć sobie właśnie taką sieć WIFI podając w nazwie SSID spreparowany payload, który uda mi się wykonać na badanym routerze. Przyjąłem założenie, że kod, który jest odpowiedzialny za wypluwanie informacji na konsolę być może (lub nie, ale warto sprawdzić) wygląda mniej więcej tak:

exec(“echo $SSID”)

Zakładając, że serwer wykorzystuje powyższy kod to umieszczony pomiędzy dwoma znakami „`” („grave accent ) payload powinien się wykonać na systemie operacyjnym routera. Sprawdźmy, czy faktycznie tak się stanie.

3. Nazwa sieci jako payload, który listuje całą zawartość katalogu „/”.

Ustawiamy na telefonie WIFI, w routerze skanujemy sieć jeszcze raz (obrazek nr. 6).

4. Wynik wykonania payloadu na systemie operacyjnym routera.

Działa. Wszystkie pliki w bieżącym katalogu zostały wylistowane za pomocą programu „ls” – payload z SSID’a został wykonany prawidłowo co tylko potwierdza nam możliwość wykonywania dowolnych poleceń na systemie operacyjnym routera. Dla ambitnych pozostaje nie dowierzać autorowi na słowo i przeprowadzić analizę wsteczną funkcji odpowiedzialnej za obsługę powyższej omówionej operacji 😉 (o czym niedługo będę też pisał)

Podsumowanie

Ostatni zaprezentowany błąd typu „Os Command Injection” jest dość „kosztowny” do wykorzystania przez napastnika. Musi spełniać określone warunki takie jak uruchomiona sieć WIFI ze spreparowanym SSID’em w obrębie dziurawego routera oraz trzeba jakoś zmusić administratora do skanu sieci w pobliżu (albo zrobić to samemu na skompromitowanym sprzęcie).

Co dalej

Najpierw BONUS – znajdziemy sobie jeszcze jednego buga 😉 W panelu administratora użytkownik ma możliwość sprawdzania stanu połączenia z innymi urządzeniami za pomocą programu „ping” lub „traceroute”.

W formularzu znajduje się pole do podania adresu IP lub domeny. Co się stanie kiedy zamiast adresu IP podasz długi ciąg znaków? Pewnie już się domyślasz. Aplikacja przestanie funkcjonować prawidłowo ze względu na to, że pewne regiony pamięci zostaną przez nas nadpisane wysłanymi danymi. Wygląda na to, że jesteśmy w stanie przeprowadzić atak typu „Denial of Service” – odmowa usługi. Aplikacja webowa routera przestanie działać prawidłowo. DOS w tym przypadku to nie wszystko.

Spreparowane dane przesłane przez formularz nadpisują pewne rejestry – w tym rejestr $ra. Daje to nam możliwość przejęcia kontroli nad programem. Pytanie tylko czy ta informacja jest wystarczająca do tego aby stworzyć działającego eksploita 😉 Pozostawiam to jako “zadania domowe” do rozwiązania 😉

Cóż, dobrnęliśmy już do końca a na koniec pozostawiam dla Ciebie małą zachętę jeśli temat bezpieczeństwa IoT spodobał Ci się chociaż trochę. Jest to dość szeroki temat i każdy niezależnie od poziomu swojej wiedzy może znaleźć coś dla siebie.

Specjalizujesz się w bezpieczeństwie aplikacji webowych i chcesz przetestować różne web aplikacje związane z IoT? Będziesz miał co robić. Ze swojej strony mogę polecić Tobie kilka wybranych publikacji Michała na ten temat:

• PLNOG18 – Michał Sajdak – IoT hacking w praktyce
• TP-Link – root bez uwierzytelnienia
• Jednolinijkowe przejęcie kamery CCTV

A jeżeli kopiesz głębiej i interesujesz się błędami typu „Stack based Overflow” lubisz reverse engineering oraz kod assembly RISCowych architektur takich jak MIPS czy ARM to zapraszam Cię do takiego podstawowego kursu MIPS’a w kontekście bezpieczeństwa, który wypuściliśmy jakiś czas temu na Sekurak.pl:

• Lekcja #1 – Wstęp
• Lekcja #2 – Podstawy
• Lekcja #3 – Funkcje
• Lekcja #4 – Stos
• Lekcja #5 – Eksploitacja testowej binarki

I na sam koniec – dużo wiedzy wyniesiesz dla siebie czytając opisy błędów zamieszczonych w serwisie https://cve.mitre.org/cve/search_cve_list.html. Serwis ten jest kopalnią informacji o tym jak inni badacze podchodzili do testów różnych aplikacji w tym także sprzętu IoT.

Podczas swoich badań zaglądaj w miejsca, które nie są tak do końca oczywiste do sprawdzenia kierując się maksymą „Thinking outside the box”. Bądź kreatywny i wytrwały a na pewno to Ci się opłaci.

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