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.

SA520 – img (c) Cisco

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:

Standardowy komunikat o błędzie

Spróbujmy użyć jako login i hasło innej kombinacji, tj.: ‘ or ‘1’=’1

Nietypowy komunikat o błędzie

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:

SELECT * FROM SSLVPNUser WHERE Username = ‘ ‘ OR substr((SELECT Password FROM SSLVPNUser LIMIT 1 OFFSET 0),1,1)=‘a’–’ AND Password =   ‘$password’

Jeśli przyjrzymy się temu zapytaniu dokładnie, to okaże się że zwraca ono wszystkie wiersze z tabeli (jeśli pierwsza litera pierwszego hasła to ‘a’), lub nie zwraca żadnych wierszy (jeśli pierwsza litera pierwszego hasła jest różna od a). Ale z poprzednich komunikatów o błędach jesteśmy już w stanie rozpoznawać tą sytuację. Zatem możemy prostym brute-force odzyskiwać hasła / loginy z urządzenia – niezależnie och ich złożoności. Widać to na zrzucie poniżej:

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.

Informacje prezentowane jedynie w celach edukacyjnych

Błąd został już pewien czas temu spatchowany.

— michal.sajdak <at> securitum.pl