Poniedziałek z trenerem – wykonanie kodu na firewallach PaloAlto

dodał 18 grudnia 2017 o 22:43 w kategorii HowTo, Info  z tagami:
Poniedziałek z trenerem – wykonanie kodu na firewallach PaloAlto

W dzisiejszym odcinku opiszemy ciekawą wpadkę, jaka dotknęła producenta urządzeń firewall – Palo Alto Networks. Dzięki trzem błędom w interfejsie zarządzania możliwe okazało się wykonanie poleceń w systemie operacyjnym.

Nie jest to pierwsza tego typu sytuacja. Staje się to szczególnie interesujące w kontekście faktu, iż mamy do czynienia z krytycznym elementem infrastruktury, pośredniczącym w ruchu sieciowym i odpowiadającym za bezpieczeństwo. Podatności dotyczą wersji systemu PAN-OS 6.1.18, 7.0.18, 7.1.13, 8.0.5 oraz wcześniejszych. Co prawda uruchamianie panelu zarządzania na zewnętrznych interfejsach nie jest zalecane, mimo to w sieci znajduje się wiele takich urządzeń. Do ostatecznego celu badacze wykorzystali łańcuch (przynajmniej) trzech osobnych podatności.

W poprzednich odcinkach

We wcześniejszych wpisach cyklu Poniedziałek z trenerem:

1. Częściowe ominięcie uwierzytelniania

Pierwszy z błędów umożliwia częściowe ominięcie uwierzytelniania w urządzeniu. W celu uzyskania dostępu do zasobów katalogu /php wymagane jest podanie w Cookie ważnej sesji użytkownika, co realizowane jest przez plik ustawień:

a dokładniej przez funkcję openAuthFilter() pochodzącą z pliku z kodem natywnym libpanApiWgetFilter.so. Funkcja ta odczytuje Cookie o nazwie PHPSESSID i przy pomocy kolejnej funkcji (readSessionVarsFromFile()) odczytuje zawartość zmiennych dlocuser. Właśnie tutaj pojawia się pierwszy błąd. Parser przetwarzający zapisane dane sesji nie jest kompatybilny z oryginalnym parserem PHP i niepoprawnie wczytuje niektóre ciągi. Format zapisanej sesji jest taki:

czyli na przykład

Jeśli w jakiś sposób możliwe okazałoby się wstrzyknięcie do sesji sekwencji:

umożliwiłoby to nadpisane zmiennych sesji. Dzięki odwołaniu do ścieżki /esp/cms_changeDeviceContext.esp możliwe było właśnie to. Dostęp do tej ścieżki nie jest ograniczony poprzednim mechanizmem, a uruchamiana funkcja panUserSetDeviceLocation()panmodule.so przyjmuje parametr device, którego wartość zapisywana jest do zmiennych sesyjnych dlocloc. Po wykonaniu takiego żądania:

W pliku sesyjnym, /tmp/sess_<id_sesji>, znajduje się fragment:

Po ponownym odczytaniu danych sesji z pliku przez readSessionVarsFromFile(), za wartość zmiennej user zostanie uznane 16:a’. Następnie odczytana wartość jest wykorzystywana jako fragment dokumentu XML, który z powodu wstrzykniętego apostrofu przybierze niepoprawną strukturę:

Jednak funkcja sprawdzająca ważność sesji, panCheckSessionExpired() nie jest przygotowana na ten błąd i uznaje, że uwierzytelnianie się powiodło. Wykorzystując ten błąd nie dysponujemy jeszcze poprawną sesją użytkownika i o ile większość chronionych skryptów z /php/ nie zadziała, część pozwoli nam na uruchomienie.

2. Utworzenie dowolnego katalogu

Kolejny błąd pozwala na utworzenie dowolnego katalogu w lokalnym systemie plików. Dzięki wykorzystaniu podatności nr 1 nie trzeba posiadać ważnej sesji do jego wykorzystania. Podatność ponownie związana jest przetwarzaniem XML. Plik /php/utils/router.php pozwala na odwołania do większości funkcji przy pomocy interfejsu przyjmującego dane w JSON. W szczególności możliwe jest odwołanie do Administrator.get(), a w efekcie wywołanie podatnej funkcji Direct::getConfigByXpath. Dane pochodzące od użytkownika wykorzystywane są do zbudowania zapytania, które może wyglądać tak:

Parametr jsonArgs->id nie jest zabezpieczony przed manipulacją i możliwe jest wstrzyknięcie dodatkowych parametrów do żądania. Przykładowo dodanie atrybutu async-mode=’yes’ powoduje utworzenie na serwerze katalogu tymczasowego i pliku:

który zawiera dane żądania. Dzięki kontroli również nad parametrem cookie, możliwe jest wykonanie ataku Path Traversal i utworzenie katalogu w wybranej lokalizacji. Na przykład żądanie POST do /php/utils/router.php o takiej treści:

Powoduje przetłumaczenie na takie zapytanie:

a w efekcie utworzenie katalogu /tmp/hacked. Przyznajmy szczerze – nie jest to najbardziej oczywisty do wykrycia i wykorzystania błąd, a wciąż nie jest jasne jak to się ma do wykonania poleceń. Uzasadnienie już za moment.

3. Command Injection w skrypcie cron

W systemie zapisany jest wpis cron’a uruchamiany co 15 minut, który uruchamia /usr/local/bin/genindex_batch.sh, a w efekcie /usr/local/bin/genindex.sh. Skrypt używany jest do odświeżenia indeksów plików w katalogu /opt/pancfg/mgmt/logdb/. Zawiera on dwa uruchomienia polecenia find, z których drugie bazuje na wyniku pierwszego. Ponieważ zmienna powłoki nie jest ograniczona cudzysłowami, możliwe jest wstrzyknięcie dodatkowego parametru do polecenia, np. opcji -exec. Podsumowując, poprzez utworzenie katalogu o nazwie (być może w dwóch krokach):

i po odczekaniu kilku minut <wybrane_polecenie> zostaje uruchomione. Co więcej, nasze polecenie uruchamiane jest na prawach superużytkownika, a co za tym idzie przejmujemy kontrolę nad firewallem.

Źródło: http://seclists.org/fulldisclosure/2017/Dec/38

Więcej o bezpieczeństwie WWW i nie tylko

Jeśli ciekawią Cię takie i podobne błędy, masz szanse usłyszeć więcej tego rodzaju historii już niedługo. Zapraszamy na najbliższe szkolenia.

Szkolenie z bezpieczeństwa aplikacji WWW

Bezpieczeństwo aplikacji WWW - atak i obrona

Wroclaw
Wrocław, 10 – 12 stycznia 2018

Warsaw-center-free-license-CC0
Warszawa, 19 – 21 lutego 2018

Czas trwania: 3 dni (20h), Prowadzący: Adam z z3s, Przemysław Sierociński
Liczba uczestników: maksymalnie 12 osób, cena: 3900 PLN netto

Szczegółowy opis szkolenia