Wybrany post: Jak poprzez aplikację ManageEngine do zarządzania hasłami i SSO można zhakować całą firmę?

Do napisania tego artykułu zainspirowała nas informacja o tym, że specjaliści z Synacktiv niedawno odkryli luki bezpieczeństwa klasy „zero-day” w platformie do zarządzania hasłami w Microsoft Active Directory oraz jednokrotnym logowaniem SSO dla użytkowników końcowych. Postanowiliśmy dokładniej to opisać, ponieważ stanowi to duże zagrożenie dla firm.

Na wstępie wyjaśnimy, że luki umożliwiają nieuwierzytelnionemu atakującemu wykonanie dowolnego kodu na serwerze i tym samym przejęcia nad nim kontroli. W sieci natychmiast pojawiła się druga, ogólnoświatowa kampania wykorzystująca te podatności do ataków na firmy z branży obronnej, energetycznej oraz zdrowotnej. Ale o tym później, najpierw zacznijmy od opisu problemu.

Przejęcie kontroli nad środowiskiem IT

Jeśli zajmujesz się bezpieczeństwem IT to z pewnością wiesz, że istnieje wiele sposobów na przejęcie kontroli nad środowiskiem IT. Piszemy o nich na Kapitanie. Phishing, eksploitacje środowiska, ataki wewnętrzne (przez insider’ów), ataki na usługi AD, DNS, VPN, SMB i inne, ataki aplikacje takie jak np. Exchange i inne, to tylko niektóre z przykładów ataków, w których cyberprzestępcy zdobywają dostęp do środowiska. Dzięki temu mogą próbować wyłudzić od klienta okup i sparaliżować dostęp np. poprzez atak ransomware lub wykraść dane.

Firmy bardzo często, oprócz wdrażania aplikacji do prowadzenia biznesu, instalują w swoich środowiskach informatycznych dodatkowe narzędzia pozwalające zabezpieczyć, monitorować i usprawniać zarządzanie. Podatności systemów operacyjnych i instalowanych na nich aplikacji to jedno. Lecz czy kiedykolwiek zastanawiałeś się, co może się stać, jeśli taka aplikacja firmy trzeciej zawiera w sobie lukę bezpieczeństwa lub firma nie kontroluje w odpowiedni sposób dostępu do takiej aplikacji? Dla atakującego możliwość taka stanowi łatwy kąsek do przejęcia kontroli nad środowiskiem. Znamy na to dużo przykładów z ostatnich lat i miesięcy. Można posunąć się tutaj do stwierdzenia, że:

„Przejęcie kontroli nad oprogramowaniem do zarzadzania środowiskiem IT pozwala przejąć kontrolę nad zarządzanym środowiskiem”

Oprogramowanie takie często działa na wysoko uprzywilejowanych kontach serwisowych lub implementuje funkcjonalności, za pomocą których takie uprawnienia można uzyskać. Doskonałym przykładem na to są aplikacje do dystrybucji oprogramowania, zarządzania użytkownikami, aplikacje do monitorowania, które używają agentów oraz bezpieczeństwa. I tutaj pewnie zapaliła Ci się czerwona lampka! Otóż te aplikacje często działają również na wysoko uprzywilejowanych użytkownikach lub używają agentów do zbierania informacji ze środowiska – są więc też w pewnym sensie platformami do zarządzania. Dlatego powinniśmy zwrócić szczególna uwagę na dostępy do takich aplikacji i przyjrzeć się bliżej ich architekturze i jak najlepiej je zabezpieczyć (patrz nasz artykuł o Zero Trust).

Dziury w aplikacji do zarządzania samoobsługą użytkowników

Niewątpliwie do jednych z najtrudniejszych przypadków włamań i ich wykrycia należą błędy (podatności) we wdrożonych aplikacjach firm trzecich w środowisku IT. Tak jest w opisywanym dzisiaj przypadku.
Zoho ManageEngine ADSelfService Plus to samoobsługowa platforma do zarządzania hasłami i jednokrotnym logowaniem (SSO) do aplikacji Active Directory i aplikacji w chmurze. Korzystają z niej i wdrażana jest w wielu firmach na Świecie oraz w Polsce. Nowe, odkryte podatności w tej aplikacji i ich exploitacja przez cyberprzestępcę oznacza dla firm, że każdy cyberatakujący, który mógłby przejąć kontrolę nad platformą, miałby wiele punktów odniesienia do obu aplikacji o krytycznym znaczeniu (i ich danych wrażliwych) i innych części sieci firmowej za pośrednictwem Active Directory. Innymi słowy, jest to potężna, wysoce uprzywilejowana aplikacja, która może działać jako wygodny punkt wejścia do obszarów znajdujących się głęboko w procesach działania przedsiębiorstwa, zarówno dla użytkowników, jak i atakujących.

Pisaliśmy niedawno o atakach na łańcuch dostaw, które należą do najtrudniejszych do wychwycenia. Przejęcie kontroli atakującego nad aplikacją ADSelfService Plus jest jednym z przykładów takiego ataku, który pozwoli mu w łatwy sposób na uzyskanie dostępu do środowiska i dalszą jego penetrację. Firmy, które mają wystawiony portal aplikacji dla użytkowników udostępniony na zewnątrz infrastruktury powinny jak najszybciej go zablokować.

Zobaczmy dokładniej jak haker może się dostać do takiej firmy za pomocą ADSelfService Plus na podstawie analizy poniższych podatności.

Podatności w ADSelfService Plus

Odkrycia błędów w oprogramowaniu ASSelfService Plus dokonali Antoine Cervoise oraz Wilfried Bécard z firmy Synacktiv zajmującej się wykonywaniem testów penetracyjnych. Ciekawostką jest, że nie są to pierwsze luki związane z tym problemem. Wcześniejszy problem z programem ADSelfService Plus został zgłoszony 8 września i posiadał publicznie dostępnego exploit’a. Pisaliśmy o tym problemie tutaj.
Producent rozwiązania szybko wdrożył poprawkę bezpieczeństwa i opublikował artykuł, który następnie był kilkakrotnie aktualizowany. Na początku zespół ManageEngine wspominał jedynie o exploicie związanym z REST API.
Specjaliści z Syncaktiv postanowili wziąć problem pod lupę, wdrożyli w laboratorium wersję podatną na lukę oraz poprawioną wersję rozwiązania i zaczęli bardziej zagłębiać się w problem. Wykorzystali środowisko Meld3 do porównania zmian między wersjami na plikach i podfolderach oraz zauważyli szereg nieprawidłowości, które postanowili bliżej zgłębić.

A ponieważ ADSelfService Plus to całkiem sporawa aplikacja napisana w języku Java, a jak to z Javą bywa, kod może czasami kryć wiele zakamarków 🙂 Specjaliści postanowili szybko porównać skróty (hashe) między obiema wersjami licznych dołączonych jarów co pozwoliło im zidentyfikować części kodu źródłowego, które uległy zmianie wraz z aktualizacją. Różnice widać poniżej.

Po dogłębniej analizie kodu aplikacji i odkryli 3 nowe podatności:

1. Możliwość ominięcia uwierzytelniania do aplikacji

Specjaliści na podstawie wcześniejszej łatki w REST API aplikacji wydanej przez producenta byli w stanie stwierdzić wykonane zmiany w kodzie. Podczas testów penetracyjnych okazało się, że przy pewnych warunkach nowa poprawka aplikacji związana z normalizacją adresu URI (z ang. path traversal) nie rozwiązuje do końca problemu.
Naukowcy postanowili stworzyć specjalny payload (dostępny tutaj), w którym wysłali specjalny ciąg znaków „/./”w wywołaniu POST do serwera aplikacyjnego i porównali odpowiedzi serwera (zarówno w starej jak i zaktualizowanej wersji kodu).

W odpowiedzi otrzymali wynik z kodem 200 (udana komunikacja). Dzięki temu byli w stanie ominąć mechanizm uwierzytelniania do aplikacji.

2. Możliwość przesyłania dowolnych plików poprzez API

W kolejnym kroku pentesterzy postanowili sprawdzić, czy będą w stanie przesłać przez API aplikacji na jej serwer jakiś plik, który następnie będzie można uruchomić. Tym razem zawiódł w aplikacji kod jednej z metod o nazwie „Unspecified”.
Dokładna analiza tej metody pozwoliła na określenie parametrów niezbędnych do załadowania pliku na serwer. Kolejne wywołanie, pokazane poniżej pozwala przesłać dowolny plik i umieścić go na serwerze w folderze „ManageEngine\ADSelfService Plus\bin”.

Wynik załadowania pliku test.txt na serwerze aplikacyjnym ManageEngine.

3. Możliwość wstrzyknięcia dowolnego argumentu do wywołania API

Kolejną rzeczą jaką sprawdzili badacze była możliwość przesłania dowolnej komendy w wywołaniu URI do API aplikacji, za pomocą której będzie można uruchomić wcześniej przesłany plik na serwerze. Pod lupę wzięli „/RestAPI/Connection” i kasę „com.adventnet.sym.adsm.common.webclient.admin.ConnectionAction”. Po głębszej analizie okazało się, że aplikacja uruchamia wewnątrz narzędzie „keytool.exe”, które stało się celem ataku. Jednak, aby móc tego dokonać pentesterzy musieli znaleźć sposób na ominięcie możliwość ucieczki z zabezpieczonej funkcji „Runtime.getRuntime().exec()” i go znaleźli.
Jak stwierdzili „jedną z cech keytool jest możliwość załadowania klasy Java. Jeśli możemy zbudować własną klasę Java, przesłać ją za pomocą wywołania API do LogonCustomization, moglibyśmy użyć jej z keytool w celu wykonania komendy”

Sposób znajduje się poniżej.

Połączenie trzech luk w jeden exploit

Na podstawie wcześniejszych odkrytych luk i ich możliwości pentesterzy postanowili stworzyć POC exploita, który pozwala ominąć proces uwierzytelniania, dodając fragment „/./” do trasy REST API, wykonuje przesyłanie dowolnego pliku oraz załadować własną klasy Java poprzez wstrzyknięcie jej do parametrów binarnych narzędzia keytool. Dzięki temu byli w stanie uzyskać wykonanie dowolnego kodu (RCE).

Poniższy kod Java, który uruchamia zdalnie kalkulator na serwerze „calc.exe”, został użyty jako dowód koncepcji.

To, na co zwracają uwagę twórcy exploit‘a to konieczność kompilacji kodu ich własnej klasy Java tą samą wersją kompilatora Javy co rozwiązanie Manage Engine.

W wyniku uruchomienia exploit’a na serwerze zostanie uruchomiony kalkulator.

Cały exploit dostępny na GitHub.

Wnioski i podsumowanie

Na podstawie powyższego przykładu możemy się dowiedzieć, że nieodpowiednio załatane podatności w oprogramowaniu firm trzecich mogą skutkować wystąpieniem kolejnych podatności zero-day i powstaniem nowych exploitów. Naukowcy i cyberprzestępcy na całym Świecie analizują opublikowane błędy i wydane dla nich poprawki. Są w stanie dokładnie sprawdzić /przeanalizować, czy dany problem wciąż może wystąpić. Warto tutaj dodać, że problemy z nieodpowiednim łataniem błędów aplikacji zdarzają się także najlepszym (patrz łatana kilkakrotnie przez Microsoft podatność PrintNightmare w systemie Windows).
Tak jak w przypadku innych publicznie opisywanych podatności tak i w opisywanym przypadku szybko po opublikowaniu exploitów w Internecie zaczęły pojawiać się kampanie hackerskie. Najgroźniejsza z nich to Godzilla (z zeszłego tygodnia), która dzięki temu exploitowi umieszcza na zhackowanych serwerach złośliwe oprogramowanie oraz backdoora typu open source opartego na Golangu o nazwie NGLite oraz nowego złodzieja danych uwierzytelniających śledzonego jako KdcSponge.
Na koniec warto sobie wziąć do serca stwierdzenie, że aplikacje do zarządzania infrastrukturą w firmie powinny być tak samo chronione jak systemy, czy inne usługi w firmie. Przykład ManageEngine nie jest jedyny na rynku. Należy również pamiętać, że podobny los może spotkać także inną aplikację działającą w twojej infrastrukturze.