Poniedziałek z trenerem – cztery błędy do zdalnego wykonania kodu

Minęły już czasy, kiedy każdy atak opierał się na wykorzystaniu jednego (często trywialnego) błędu. Dzisiaj, by dostać się do systemu, często trzeba tych błędów znaleźć kilka i sprytnie połączyć w jeden atak. Taki przykład znajdziecie poniżej.

Kontynuujemy dzisiaj nasz nowy cykl pt. Poniedziałek z Trenerem. Mamy nadzieję, że na stałe wejdzie do naszego i Waszego kalendarza. Dzisiaj Przemek Sierociński, trener prowadzący szkolenia z bezpieczeństwa aplikacji WWW, opisuje ciekawy zestaw błędów i długą podróż atakującego od prostego błędu ujawnienia danych do zdalnego wykonania kodu

Łańcuch czterech błędów – zdalne wykonanie kodu

W dzisiejszym odcinku mam przyjemność przybliżyć historię kilku powiązanych ze sobą błędów, które w połączeniu umożliwiły uruchomienie poleceń w systemie. Można powiedzieć, że wykorzystano do tego przynajmniej 4 podatności. Odkrywcą błędów jest ZephrFish.

Badacz szukał błędów w ramach jednego z programów bug bounty, a zaczęło się od natrafienia na instancje Oracle E-business Suite w nieaktualnej wersji. Po szybkim wyszukaniu informacji okazuje się, że program zawiera bardzo dużo błędów bezpieczeństwa. Jeden z nich, znany już od prawie 8 lat, umożliwia ominięcie potrzeby uwierzytelniania. Odwiedzając adres:

http://domena-ofiary/OA_HTML/OA.jsp

można uzyskać sesję użytkownika gościa (guest). Pozwoliło to wyświetlić szczegółowe komunikaty diagnostyczne w formularzu logowania. A zawarte tam były informacje takie jak rodzaj systemu operacyjnego, ścieżka instalacji w systemie plików oraz adres bazy danych z której korzysta aplikacja. Informacje z pewnością przydatne, choć i bez nich prawdopodobnie sytuacja zakończyłaby się podobnie.

Następnym krokiem było odkrycie podatności XML External Entity w jednej z funkcji Oracle EBS. Możliwe wykrzystanie błędu okazało się ograniczone do techniki „na ślepo” (blind), w skrócie wynik przetwarzania złośliwego pliku jest niewidoczny. Z jego pomocą ZephrFish przeczytał zawartość pliku /etc/hosts, gdzie znajdował się adres kolejnego serwera. Nie był on jednak dostępy bezpośrednio z Internetu. Kolejnym bardzo ciekawym plikiem który badacz odczytał był .bash_history zawierający historie wydanych przez użytkownika poleceń. W tej skarbnicy wiedzy znalazł się zewnętrzny adres, przy pomocy którego można się połączyć do serwera z Internetu.

Łańcuch błędów

Szczęśliwie domena znajdowała się w zakresie określonym przez reguły programu Bug Bounty. Wewnętrzna nazwa hosta przypominała ExperimentDB-92Hn192, była zatem dużo bardziej obiecująca niż zewnętrzny adres domeny, przypominający my.example.com. Znajdował się tam bliżej nieokreślony panel zarządzania i wyglądało na to, że domyślnie niezalogowani użytkownicy posiadają rolę gościa (parametr guest=1). Po chwili analizy ZephrFish odkrył parametr tabl=default podatny na… SQL Injection, oczywiście! Klasyczny błąd, można powiedzieć że pełnoletni.

Jak można było przeczytać wywołując funkcję version():

'+AND+SELECT+@@version+--

silnikiem bazodanowym okazał się Microsoft SQL Server 2005 – 9.00.

Wymagało to co prawda zakodowania znaku spacji przy pomocy + zamiast %20 z powodu prostego filtra zawartości parametru, nie było jednak w żadnym wypadku trudne. W kontekscie SQLi bazy danych od Microsoft znane są z niezwykle pomocnej atakującym funkcji xp_cmdshell. Umożliwia ona uruchamianie poleceń w systemie operacyjnym z poziomu zapytania SQL. Pierwsza próba skorzystania z niej nie powiodła się jednak – administrator wyłączył tę opcje. Co ciekawe okazało się, że to nie szkodzi, ponieważ tymi czterema payloadami poniżej:

'+AND+EXEC+sp_configure+'show advanced options',+1
'+AND+RECONFIGURE
'+AND+EXEC+sp_configure+'xp_cmdshell',+1
'+AND+RECONFIGURE

możliwe było jej ponowne aktywowanie. Następnie:

'+AND+EXEC+master.dbo.xp_cmdshell+'net users'

ujawniło, że w systemie istnieją użytkownicy Administrator i Guest. Kolejna dobra wiadomości, bo z dużym prawdopodobieństwem użytkownik bazy danych to właśnie konto z uprawnieniami administratora. Kolejnym krokiem było utworzenie pliku w systemie:

'+AND+EXEC+master.dbo.xp_cmdshell+'echo 1 > C:\Zephr.txt'

potwierdzenie, że faktycznie się zapisał oraz usunięcie go:

'+AND+EXEC+master.dbo.xp_cmdshell+'rm C:\Zephr.txt'

Voila, pozostało napisać i wysłać raport do testowanej instytucji, która naprawiła błędy usuwając podatny serwis. Podsumowując, w historii tej wykorzystano:

1. ominięcie potrzeby uwierzytelniania,
2. błąd XML External Entity w trybie „na ślepo”,
3. wyciek informacji (konfiguracja i logi),
4. SQL Injection.

Jest to bardzo dobry przykład na to, że gdy podatności łączą się ze sobą, negatywne konsekwencje nie tylko się dodają, ale nawet mnożą.

Jeśli chcecie nauczyć się znajdować takie błędy lub przed nimi chronić, zapraszamy na nasze szkolenie.

Szkolenie z bezpieczeństwa aplikacji WWW – także we Wrocławiu