Jak zhakować niezałatany serwer Exchange za pomocą nieuczciwego kodu PowerShell

Niecałe dwa miesiące temu pojawiły się niepokojące informacje o błędach: ogłoszono dwie luki dnia zerowego w Microsoft Exchange.

Jak radził w tym czasie, te luki, oficjalnie wyznaczone CVE-2022-41040 i CVE-2022-41082:

[były] dwa dni zerowe, które [można] połączyć w łańcuch, przy czym pierwszy błąd został użyty zdalnie, aby otworzyć wystarczającą dziurę, aby wywołać drugi błąd, co potencjalnie umożliwia zdalne wykonanie kodu (RCE) na samym serwerze Exchange.

Pierwsza luka przypominała kłopotliwą i powszechnie wykorzystywaną Luka w zabezpieczeniach ProxyShell od sierpnia 2021 r., ponieważ opierał się na niebezpiecznym zachowaniu funkcji automatycznego wykrywania Exchange, opisane przez Microsoft jako protokół tj „używany przez klientów Outlook i EAS [Exchange ActiveSync] do znajdowania i łączenia się ze skrzynkami pocztowymi w Exchange”.

Na szczęście błąd funkcji Autodiscover, który mógł zostać wykorzystany w ataku ProxyShell przez dowolnego użytkownika zdalnego, niezależnie od tego, czy jest zalogowany, czy nie, został załatane ponad rok temu.

Niestety, łatki ProxyShell nie zrobiły wystarczająco dużo, aby zamknąć exploita dla uwierzytelnionych użytkowników, co doprowadziło do nowego dnia zerowego CVE-2022-40140, który wkrótce został lakonicznie, choć mylący, dubbingowane ProxyNotShell.

Nie tak niebezpieczne, ale jednak niebezpieczne

Najwyraźniej ProxyNotShell nie był tak niebezpieczny jak oryginalny ProxyShell, biorąc pod uwagę, że wymagał tak zwanego uwierzytelnionego dostępu, więc nie był narażony na nadużycia ze strony kogokolwiek z dowolnego miejsca.

Szybko jednak okazało się, że na wielu serwerach Exchange znajomość nazwy logowania i hasła dowolnego użytkownika wystarczyłaby, aby przejść jako uwierzytelniony i przeprowadzić ten atak, nawet jeśli ten użytkownik sam musiałby użyć uwierzytelniania dwuskładnikowego (2FA), aby zalogować się poprawnie, aby uzyskać dostęp ich e-mail.

Jako ekspert Sophos, Chester Wiśniewski połóż to wtedy:

Jest to „luka w połowie uwierzytelniania”, jeśli chcesz to tak nazwać. To mieszane błogosławieństwo. Oznacza to, że zautomatyzowany skrypt Pythona nie może po prostu przeskanować całego Internetu i potencjalnie wykorzystać każdego serwera Exchange na świecie w ciągu kilku minut lub godzin, jak widzieliśmy w przypadku ProxyLogon i ProxyShell w 2021 roku. […]

Potrzebujesz hasła, ale znalezienie jednej kombinacji adresu e-mail i hasła obowiązującej na dowolnym serwerze Exchange prawdopodobnie nie jest niestety zbyt trudne. Być może do tej pory nie zostałeś wykorzystany, ponieważ pomyślne zalogowanie się do programu Outlook Web Access [OWA] wymaga ich tokena FIDO, ich uwierzytelnienia lub innego drugiego czynnika, którego możesz używać.

Ale ten atak nie wymaga tego drugiego czynnika. […] Samo zdobycie kombinacji nazwy użytkownika i hasła jest dość niską barierą.

Jak zapewne pamiętacie, wielu z nas zakładało (lub przynajmniej miało taką nadzieję), że Microsoft będzie spieszył się z naprawą luk w ProxyNotShell, biorąc pod uwagę, że do październikowego wtorku z poprawkami pozostały jeszcze dwa tygodnie.

Ale byliśmy rozczarowani, gdy stwierdziliśmy, że najwyraźniej była to niezawodna poprawka bardziej złożone niż oczekiwano, a październik przyszedł i zniknął z ProxyNotShell, na który nałożono jedynie obejścia, a nie odpowiednie łatki.

Nawet listopadowy Patch Tuesday nie dostarczył bezpośrednio potrzebnych poprawek, chociaż łatki mimo to wyszedł tego samego dnia w ramach aktualizacji zabezpieczeń specyficznej dla programu Exchange, którą można pobrać i zainstalować oddzielnie:

Ujawniono dowód słuszności koncepcji

Teraz, gdy kurz opadł i wszyscy mieli czas na załatanie swoich serwerów Exchange (przynajmniej tych, o których nie zapomnieli), badacze z Zero Day Initiative (ZDI), któremu pierwotnie ujawniono te luki w celu przesłania do Microsoftu, wytłumaczyłem jak można wykorzystać błędy.

Zła wiadomość, w zależności od twojej opinii na temat jawnych ujawnień exploitów, jest taka, że ​​zespół ZDI skutecznie dostarczył dowód koncepcji (PoC) wyjaśniający, jak atakować serwery Exchange.

Dobra wiadomość jest oczywiście taka, że:

• Możemy teraz sami przestudiować i zrozumieć błędy. To nie tylko pomaga nam wszystkim upewnić się, że ogólne środki ostrożności, które podjęliśmy (nie ograniczając się tylko do instalowania łatek) prawdopodobnie zapewnią oczekiwaną ochronę, ale także informuje nas o praktykach programowania, których będziemy chcieli uniknąć w przyszłości, więc nie nie daj się złapać w pułapkę otwierania błędów tego rodzaju w naszym własnym kodzie po stronie serwera.
• Nie mamy teraz żadnych wymówek, aby nie zastosować poprawek. Jeśli ociągaliśmy się z aktualizacją, wyjaśnienie ZDI, dlaczego atak działa, jasno pokazuje, że lekarstwo jest zdecydowanie lepsze niż choroba.

Jak to działa?

ZDI wyjaśnienie tej luki tworzy fascynującą opowieść o tym, jak skomplikowane może być połączenie wszystkich części potrzebnych do przekształcenia luki w opłacalny exploit.

Warto również przeczytać, aby zrozumieć, dlaczego zagłębianie się w istniejący exploit może pomóc ujawnić inne sposoby niewłaściwego wykorzystania luki, potencjalnie skłaniając do dodatkowych poprawek, nakłaniając do zmian w konfiguracji i promując nowe praktyki programistyczne, które mogły nie być oczywiste po samej naprawie oryginalny otwór.

Wyjaśnienie jest z konieczności skomplikowane i dość techniczne i prowadzi cię do przodu przez długą serię kroków, aby na końcu osiągnąć zdalne wykonanie kodu (RCE).

W nadziei, że łatwiej będzie ci śledzić szczegółowe informacje, jeśli zdecydujesz się przeczytać raport ZDI, oto mam nadzieję niezbyt uproszczone podsumowanie z krokami wymienionymi w odwrotnej kolejności…

…więc z góry będziesz wiedział, dlaczego historia zmierza w takim kierunku, w jakim się toczy:

• KROK 4. Zdalnie oszukaj Exchange, aby utworzył instancję wybranego obiektu .NET z wybranym parametrem inicjalizacji.

We współczesnym kodowaniu an utworzony obiekt to żargonowe słowo oznaczające przydzieloną porcję pamięci, automatycznie inicjowaną danymi i zasobami, których będzie potrzebować podczas jej używania, oraz powiązaną z określonym zestawem funkcji, które mogą na niej działać. (Instancja to tylko wymyślne określenie Stwórz.)

Obiekty mogą być zarządzane i kontrolowane przez sam system operacyjny, aby uniknąć błędów związanych z niewłaściwym zarządzaniem pamięcią, typowych dla języków takich jak C, gdzie zwykle trzeba samodzielnie przydzielić pamięć, ręcznie wypełnić odpowiednie pola danych i pamiętać o zwolnij używaną pamięć i zasoby, takie jak gniazda sieciowe lub pliki na dysku, kiedy skończysz.

Obiekty generalnie mają powiązaną z nimi funkcję programistyczną o nazwie a konstruktor, która jest wykonywana automatycznie po utworzeniu nowego obiektu w celu przydzielenia odpowiedniej ilości pamięci i prawidłowego zestawu zasobów systemowych.

Zwykle musisz przekazać jeden lub więcej parametrów jako argumenty do konstruktora, aby wskazać, jak obiekt ma być skonfigurowany na początku.

Mówiąc najprościej, jeśli utworzysz instancję, powiedzmy, a TextString obiekt (wymyślamy te nazwy, ale rozumiesz o co chodzi) używając parametru, który sam jest łańcuchem tekstowym, takim jak example.com:8888...

… prawdopodobnie skończysz z buforem pamięci przydzielonym do przechowywania tekstu, zainicjowanym tak, aby zawierał tę samą wartość, którą przekazałeś, a mianowicie nieprzetworzony tekst example.com:8888.

W tym kontekście ciąg tekstowy przekazywany jako dane do konstruktora obiektów nie stanowi od razu żadnego oczywistego zagrożenia dla bezpieczeństwa cybernetycznego po zdalnym uruchomieniu konstruktora, poza możliwą odmową usługi (DoS) poprzez wielokrotne proszenie o coraz większe ciągi do spróbuj wyczerpać pamięć.

Ale jeśli miałbyś utworzyć instancję, powiedzmy, a ConnectedTCPClient obiekt przy użyciu tego samego parametru ciągu tekstowego co example.com:8888, możesz skończyć z buforem pamięci gotowym do przechowywania danych tymczasowych, wraz z gniazdem sieciowym przydzielonym przez system operacyjny, które jest gotowe do wymiany danych z serwerem example.com przez port TCP 8888.

Możesz tam zobaczyć ryzyko zdalnego wykonania kodu, nawet jeśli nigdy nie wyślesz żadnych danych do otwartego gniazda, biorąc pod uwagę, że oszukałeś serwer, aby dzwonił do domu do lokalizacji, którą kontrolujesz.

Możesz nawet znaleźć obiekt o nazwie, powiedzmy, RunCmdAndReadOutput, gdzie ciąg tekstowy, który wysyłasz jako parametr, jest dosłownie poleceniem, które ma zostać uruchomione automatycznie zaraz po utworzeniu obiektu, dzięki czemu możesz później zebrać jego dane wyjściowe.

Nawet jeśli nigdy nie odzyskasz danych wyjściowych polecenia, samo utworzenie instancji takiego obiektu pozwoliłoby ci wybrać polecenie do uruchomienia, dając w ten sposób ogólne zdalne wykonanie kodu i przedstawiając ryzyko ograniczone tylko prawami dostępu do samego procesu serwera .

Oczywiście atak jest tak łatwy, gdy dojdziesz do ostatniego etapu, czego nie powinieneś być w stanie zrobić, ponieważ Exchange ma ścisłą listę dozwolonych, która uniemożliwia wybranie dowolnego starego obiektu do utworzenia instancji.

Teoretycznie tylko obiekty bezpieczne lub obiekty niskiego ryzyka mogą być tworzone zdalnie za pomocą programu PowerShell, dzięki czemu tworzenie instancji naszych wyimaginowanych TextString powyżej lub A SimpleIntegerValue, można uznać za akceptowalne, podczas gdy a ConnectedTCPClient lub RunCmdAndReadOutput na pewno by nie było.

Ale badacze ZDI zauważają, że przed uruchomieniem ostatniego kroku mogli to zrobić:

• KROK 3. Zdalnie oszukaj Exchange, aby pomyślał, że obiekt niskiego ryzyka, który przeszedł test bezpieczeństwa, jest w rzeczywistości innym wybranym przez Ciebie obiektem.

Mimo to można oczekiwać, że Exchange zapobiegnie zdalnemu tworzeniu nawet obiektów niskiego ryzyka, aby jeszcze bardziej zminimalizować zagrożenie.

Ale naukowcy odkryli, że mogą:

• KROK 2. Zdalnie oszukaj Exchange, aby używał jego PowerShell Remoting możliwość tworzenia obiektu na podstawie parametrów inicjalizacyjnych sterowanych zewnętrznie.

Było to możliwe dzięki dziurze podobnej do ProxyShell, która została tylko częściowo załatana:

• KROK 1. Zdalnie oszukaj Exchange, aby zaakceptował i przetworzył żądanie sieciowe z kodem, umieszczając plik valid username:password pole również w żądaniu.

Nawet jeśli użytkownik wymieniony w żądaniu nie był w rzeczywistości zalogowany i musiałby przejść przez jakiś proces 2FA, aby uzyskać dostęp do własnej skrzynki pocztowej, osoba atakująca, która znała ich username:password taka kombinacja miałaby wystarczającą ilość informacji uwierzytelniających, aby nakłonić Exchange do zaakceptowania połączenia internetowego, które mogłoby zostać użyte do rozpoczęcia łańcucha ataków opisanego w krokach od 2 do 4 powyżej.

Luźno mówiąc, każdy ważny username:password kombinacja wystarczyłaby, biorąc pod uwagę, że „uwierzytelnianie” było potrzebne po prostu, aby uniemożliwić Exchange odrzucenie żądania HTTP z góry.

Co robić?

Pamiętaj, że ten atak działa tylko:

• Jeśli masz lokalne serwery Exchange. Microsoft twierdzi, że szybko zablokował własne usługi w chmurze, więc nie ma to wpływu na Exchange Online. Upewnij się, że wiedzieć, gdzie znajdują się serwery Exchange. Nawet jeśli korzystasz teraz z usługi Exchange Online, nadal możesz mieć uruchomione serwery lokalne, być może pozostawione przez pomyłkę po procesie migracji.
• Jeśli twoje serwery nie są zaktualizowane. Upewnij się, że zastosował aktualizację oprogramowania Exchange z dnia 2022-11-08 do zamknij luki w zabezpieczeniach tego wymaga exploit.
• Jeśli Twoje serwery nadal akceptują uwierzytelnianie podstawowe, znane również jako starsze uwierzytelnianie. Upewnij się, że zablokował wszystkie aspekty uwierzytelniania starszego typu więc twoje serwery nie zaakceptują username:password nagłówków wymienionych powyżej i przede wszystkim nie będzie akceptować ryzykownych żądań protokołu Autodiscover. Ten zatrzymuje napastników oszukiwanie serwera, aby zaakceptował sztuczki tworzenia instancji obiektów z pułapkami-pułapkami, nawet jeśli ten serwer nie jest załatany.

Możesz śledzić naszych oficjalnych porad dotyczących zapobiegania, naprawy i reagowania, a klienci Sophos mogą śledzić nazwy wykrywania zagrożeń używane przez nasze produkty za pośrednictwem kanału Sophos X-Ops na Twitterze (@SophosxOps).

Opublikowano nowe informacje dotyczące CVE-2022-41040 i CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) Listopad 21, 2022

---

DOWIEDZ SIĘ WIĘCEJ O UWIERZYTELNIANIU WYMIANY I OAUTH2

Z Paulem Ducklinem i Chesterem Wiśniewskim
Muzyka intro i outro autorstwa Edyta Mudge.

---