Nadal spotykamy się z opinią, że firewalle brzegowe oraz antywirusy to wszystko, co powinno wystarczyć, aby zapewnić bezpieczeństwo. Nic bardziej mylnego! Postanowiliśmy napisać artykuł, w którym jako przestrogę publikujemy, odkryte w zeszłym roku, sześć krytycznych podatności urządzeniu SonicWall, z których dwie zostały załatane dopiero pod koniec 2019r. Poniżej znajdziecie opis jak je wykryto.

UWAGA! W Internecie nadal jest dostępnych wiele urządzeń SonicWall podatnych na ten atak, więc jeśli jeszcze nie zaktualizowaliście swojego sprzętu w firmach, to radzimy to zrobić jak najszybciej.


Firewall, a bezpieczeństwo

Celem urządzań zwanych potocznie firewall’ami, lub zaporą ogniową jest zapewnienie bezpiecznej separacji wewnętrznej sieci w firmie od Świata zewnętrznego (Internetu) oraz realizowanie wielu funkcji takich jak VPN, kontrola ruch, głęboka inspekcja pakietów itp. O firewallach szeroko pisaliśmy w naszym artykule tutaj.

Firewalle mogą być sprzętowe oraz w postaci dedykowanego oprogramowania instalowanego na serwerach. Jeśli decydujemy się na zakup firewall’a, który z założenia ma chronić firmę od zewnątrz, a także blokować ruch wychodzący powinniśmy mieć na uwadze to, że nie należy mu ufać w 100%. Istnieją metody obejść w protokołach i komunikacji, która pozwala w niezauważalny sposób przedostać się złośliwemu oprogramowaniu do wnętrza firm i z nich wyciągać dane lub komunikować się z zewnętrznymi serwerami C2 (patrz artykuł DNS Shell). Lecz co się stanie w sytuacji, jeśli samo urządzenie do utrzymania bezpieczeństwa realizujące funkcje bezpiecznej komunikacji jest samo w sobie podatne na atak? Wtedy zapala się czerwona lampka.

W ubiegłym roku specjalista Orange Tsai przeprowadził badania i odkrył kilka luk w zabezpieczeniach dostawców usługi SSL VPN na firewallach, które mogą pozwolić atakującemu włamać się do sieci za pośrednictwem samego urządzenia, które z założenia ma nas chronić. Producentami firewalli, którzy odnotowali poważne podatności w zeszłym roku byli:

  • Palo Alto
  • Fortinet
  • Pulse Secure
  • Mikrotik (używany w bardzo małych firmach)
  • SonicWall

Ironią staje się odkrywanie luk w urządzeniach związanych z bezpieczeństwem. Producenci konkurencyjnych firewalli wykorzystują takie sytuacje do nakręcania sprzedaży własnych produktów, przy czym sami nie mają świadomości, czy są bezpieczni. Tak się stało przypadku firmy SonicWall, która napisała na swoim portalu post twierdząc, że jego produkty nie są wrażliwe na podatność SSL VPN, która wystąpiła w urządzeniach Palo Alto. Jak się później okazało podatność SSL VPN dotknęła także Sonicwall’a, a autorem wykrytych podatności był nijaki Alain Mowat, który zgłosił je w czerwcu 2019 roku do producenta, a porady jak je naprawić zostały opublikowane przez SonicWalla dopiero 17 grudnia 2019. Czy zatem możemy czuć się w 100% bezpieczni kupując markowy firewall? Odpowiedź zostawimy Tobie drogi czytelniku.


Odkrywanie podatności w SonicWall

Prezentujemy w jaki sposób odkryto luki w SonicWall. Poniższe informacje mogą być ciekawe i pomocne jeżeli chcesz szukać innych podatności w innych systemach.

Jak stwierdził sam autor odkrytych luk w SonicWall, swoje badania rozpoczął od „spojrzenia na interfejs sieciowy udostępniony dla SSL-VPN”. Podczas jego analizy okazało się, że interfejs zawierał w folderze „cgi-bin” wiele plików CGI, które można było wywoływać zdalnie. Były to tylko 32-bitowe pliki binarne ELF działające na systemie Linux. Pozwoliło mu to zrozumieć jak SonicWall obsługiwał uwierzytelnianie użytkowników. W celu znalezienia luki w samym systemie uwierzytelniania musiał sprawdzić, które pliki można było wywoływać bez uwierzytelnienia. Takim plikiem CGI okazał się być supportLogin, służący do obsługi niektórych rodzajów uwierzytelniania. W nim Alain odkrył kilka luk w zabezpieczeniach, które można było wykorzystać bez konieczności posiadania konta, lecz wymagały włączenia modułu „Virtual Assist” na urządzeniu.

Pierwszą luką jaką odkrył była możliwość wykonania ataku SQL Injection i w konsekwencji wykonanie zdalnej exploitacji kodu, przy użyciu parametru o nazwie customerTID. Ponieważ SonicWall jak każdy Firewall, do zarządzania udostępnia aplikację webową, okazało się, że pod spodem korzysta ona z bazy danych SQLite i konstruuje kilka zapytań z danymi wejściowymi dostarczonymi przez użytkownika za pomocą funkcji printf w sqlite3.

Funkcja ta w większości przypadków używa formatera %q, aby odpowiednio uniknąć cudzysłowów. Jednak, jak można zobaczyć powyżej, w niektórych przypadkach zamiast niego używała formatera %s. Taka konfiguracja umożliwia wykonanie prostego ataku SQL Injection.
Autor odkrył także, że w tabeli o nazwie „Sessions”, w bazie SQLLite przechowywane są identyfikatory sesji dla uwierzytelnionych użytkowników. Wykorzystanie ich umożliwiło mu dostęp do SSL-VPN na różnym poziomie uprawnień.

Pierwsza luka w zabezpieczeniach została przypisana następującemu CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7481

Druga luka (przepełnienie bufora) została odkryta także w tym samym pliku CGI także podczas analizy klienta przeglądarki użytkownika. Użycie tej luki mogło prowadzić także do wykonania dowolnego kodu.
W tym przypadku można było wykonać przepełnienie bufora w sytuacji, kiedy agent przeglądarki udawałby, że jest przeglądarką Safari, co z kolei spowodowałoby wywołanie funkcji getSafariVersion w bibliotece libSys.so zawierającej podatną funkcje memcpy.

Powyższy kod można było łatwo wywrócić powodując awarię interfejsu CGI wykonując następujące żądanie do SonicWall’a:

W praktyce, po wykonaniu takiego żądania do urządzenia Sonicwall, po mniej niż 100 próbach, zazwyczaj możliwe jest uruchomienie dowolnych poleceń bez uprawnień na urządzeniu.

Ta luka dostała CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7482

Trzecia odkryta luka związana była z uwierzytelnieniem i całkiem bezużytecznym przechodzeniem przez katalog, ponieważ pozwala jedynie na sprawdzeniu istnienia pliku. Teoretycznie, jeśli plik pasuje do określonej struktury, możliwe było odczytanie jego części. Przypisano jej następujące CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7483

Urządzenie SonicWall jest podatne na zagrożenia, jeśli wykonamy następujące żądania:
/cgi-bin/handleWAFRedirect?repeated=1&hdl=../etc/doesntexist
oraz
/cgi-bin/handleWAFRedirect?repeated=1&hdl=../etc/passwd

Autor podczas analizy wykrył także trzy inne luki, lecz te wymagały zdobycia konta administratora:

  • CVE-2019-7484 – Authenticated SQL injection
  • CVE-2019-7485 – Authenticated Buffer Overflow
  • CVE-2019-7486 – Authenticated Code injection

Eksploitacja ostatniej luki wymaga wysłania następującego żądania do urządzenia:


Podsumowanie

Celem niniejszego artykułu nie jest krytykowanie lub faworyzowanie jednego lub drugiego dostawcy. Pokazujemy, że nie ma uniwersalnego zabezpieczenia. Nie możemy czuć się bezpiecznie. Powinniśmy ciągle rozbudowywać komponenty bezpieczeństwa i podnosić świadomość na temat nowych mechanizmów ataków i zagrożeń. To, że implementujemy rozwiązania do bezpieczeństwa jest oczywiście niezbędną praktyką. Pamiętajmy jednak, że to też są aplikacje, które mogą posiadać wewnętrzne, nieodkryte luki, które ktoś może skrupulatnie wykorzystywać. Może powstanie nowy trend w cyberbezpieczeństwie polegający na pilnowaniu aplikacji do bezpieczeństwa? Nie byłoby to nielogiczne. Aplikacje służące ochronie to dziś złożone systemy instalowane na środowisku IT, tak samo jak aplikacje do zarzadzania. Przejecie takiej aplikacji może spowodować uzyskanie tylnego wejścia do infrastruktury. Tak się dzieje w przypadku różnych dostawców. Ostatnio z rozwiązaniem firmy TrendMicro. Polecamy inny nasz artykuł, o przejęciu kontroli nad aplikacją do zarządzania o nazwie TeamViewer.