Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Cisco Security Appliance 500 – kilka ciekawych podatności

17 kwietnia 2013, 10:33 | Teksty | 1 komentarz

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

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:

jose

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:

sa500_root

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:

testing_routers

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:

sqli1A 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:

sqli2

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:

norm

Standardowy komunikat o błędzie

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

nonnorm

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:

SELECT * FROM SSLVPNUser WHERE  Username = ‘$login’ AND Password = ‘$password’

$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:

SELECT Username, Password FROM SSLVPNUsers

Zapytanie, które zwraca pierwsze hasło w bazie wygląda więc tak:

SELECT Password FROM SSLVPNUser LIMIT 1 OFFSET 0
Z kolei takie wywołanie funkcji substr() pobiera pierwszą literę pierwszego hasła:
substr((SELECT Password FROM SSLVPNUser LIMIT 1 OFFSET 0),1,1)
Jeśli teraz użyjemy loginu:
‘ OR substr((SELECT Password FROM SSLVPNUser LIMIT 1 OFFSET 0),1,1)=‘a’–
To urządzenie wykona następujące zapytanie:
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:
brute

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Mateusz

    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?

    Odpowiedz

Odpowiedz