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:

• dwa proste błędy w kodzie Facebooka,
• cztery błędy do zdalnego wykonania kodu,
• modyfikacja jednego parametru za 10 000 dolarów,
• ciekawe ataki na nagłówki wiadomości.

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

<Location /php>
  panAuthCheck on
</Location>

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 dloc i user. 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:

zmienna_pierwsza|s:dlugość_ciągu_1:"wartość ciągu";kolejna_zmienna|s:dlugość_ciągu_2:"inna wartość";...

czyli na przykład

foo|s:4:"test";bar|s:6:"rcerce";

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() z panmodule.so przyjmuje parametr device, którego wartość zapisywana jest do zmiennych sesyjnych dloc i loc. Po wykonaniu takiego żądania:

/esp/cms_changeDeviceContext.esp?device=aaaaa:a%27";user|s."z3s_";

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

`dloc|s:20:"8:a'";user|s."z3s_";";loc|s:27:"16:a'";user|s."z3s_";:vsys1";`

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

Entity: line 1: parser error : attributes construct error
<request cmd='op' cookie='16:a''  refresh='no'><operations
xml='yes'><show><cli>

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:

<request cmd="get" obj="/config/mgt-config/users/entry[@name='admin']"
cookie="wartość_cookie"/>

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:

/opt/pancfg/session/pan/user_tmp/<wartość_cookie>/<jobid>.xml

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:

{"action":"PanDirect","method":"execute","data":
["07c5807d0d927dcd0980f86024e5208b","Administrator.get",
{"changeMyPassword":true,"template":"asd","id":"admin']\"
async-mode='yes' refresh='yes'
cookie='../../../../../../tmp/hacked'/>\u0000"}],"type":"rpc","tid":713}

Powoduje przetłumaczenie na takie zapytanie:

<request cmd="get" obj="/config/mgt-config/users/entry[@name='admin']"
async-mode="yes" refresh="yes" cookie="../../../../../../tmp/hacked"/>

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

/opt/pancfg/mgmt/logdb/* -print -exec <wybrane_polecenie> ;/1

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