Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Cisco Security Appliance 500 – kilka ciekawych podatności
W dzisiejszym odcinku z serii hacking devices zobaczymy dwie podatności umożliwiające uzyskanie dostępu jako OS root mając dostęp tylko do…ekranu logowania.
Bohaterem odcinka jest urządzenie z serii SA500 firmy Cisco. Całość jest o tyle interesująca, że SA to skrót od Security Appliance, czyli urządzenie mające na celu bronić naszej sieci.
Historia zaczęła się od tego, że otrzymałem sprzęt do testów od Gawła Mikołajczyka z polskiego oddziału Cisco. Myślę, że efekt był całkiem niezły, bo dzięki uprzejmości Gawła mogłem później całość pokazać uczestnikom wewnętrznej konferencji Cisco – Seccon:
Dzisiaj zaprezentuję wyniki na sekuraku :)
Zacznijmy od prostej sztuczki, którą opisałem kiedyś na innym urządzeniu. Po zalogowaniu się do sprzętu, przejdźmy na zakładkę z funkcjonalnością ping, a następnie spingujmy dowolny adres IP. Jednocześnie przechwyćmy na lokalnym HTTP proxy request, który nasza przeglądarka wysyła po odpaleniu pinga:
Po modyfikacji powyżej uruchamiamy polecenie w OS jako root (na zrzucie powyżej – polecenie ps). Przypominam – architektura środowiska testowego umożliwiająca tego typu operacje wygląda tak:
Co dalej? Podejrzanie wygląda zasób /tmp/system.db (patrz zrzut ekranowy wyżej z wynikiem polecenia ps). Zawartość system.db (a przynajmniej jej fragment) wygląda tak:
A więc mamy tutaj bazę SQLite w wersji 3. Format SQLite3 jest o tyle prosty, że m.in. struktury tabel widać jak na dłoni w – plain text. Przykład:
W bazie można między innymi można zlokalizować nazwę tabeli zawierającą użytkowników i hasła (swoją drogą hasła te są przechowywane plain text-em!).
Do czego z kolei przyda się nam tabela oraz jej struktura? Zobaczmy pewną ciekawostkę na ekranie logowania. Po wpisaniu nieprawidłowego użytkownika i hasła otrzymujemy standardowy komunikat o błędzie:
Spróbujmy użyć jako login i hasło innej kombinacji, tj.: ’ or '1’=’1
Tym razem otrzymujemy inny komunikat, więc prawdopodobnie mamy do czynienia z podatnością SQL injection.
W tym konkretnym przypadku dalsza droga będzie nieco wyboista – użyjemy tzw. blind SQL injection i pobierzemy dowolne hasło litera po literze. Najpierw kilka słów wstępu o SQLi.
Oryginalne zapytanie, które sprawdza tutaj poprawność użytkownika i hasła wygląda tak:
$login i $password to zmienne wpisywane w formularzu logowania.
Jeśli to zapytanie zwróci co najmniej jeden wiersz – podaliśmy poprawny login i hasło. Jeśli nie zwróci nic – podaliśmy niepoprawne dane logowania. Aby móc z całością iść dalej przypomnijmy sobie kilka konstrukcji w języku SQL:
Zapytanie które na tym urządzeniu pobiera użytkowników i hasła wygląda tak:
Zapytanie, które zwraca pierwsze hasło w bazie wygląda więc tak:
Zainteresowanych tematem polecam nasze inne autorskie materiały o podobnej tematyce:
http://sekurak.pl/nowy-backdoor-na-urzadzeniach-tp-link/
http://sekurak.pl/luka-w-tp-linkach-wiecej-szczegolow/
http://sekurak.pl/os-root-przez-snmp/
Zapraszam również na Sekurak Hacking Party, a już jutro zaprezentuję na żywo hackowanie urządzeń na imprezie krakyournet.
Nie jestem ekspertem ale mi to wygląda na brakoróbstwo producenta.
Wydawało mi się, że już od kilku lat istnieją (i są dobrze opisane) bezpieczne sposoby implementacji logowania via przeglądarka. Nie ma 100% zabezpieczenia no ale proszę… coś takiego?