Martwisz się o giełdę Zero-Day? Oto co robić

Microsoft potwierdził dwie nowe luki zero-day w Microsoft Exchange Server (CVE-2022-41040 i CVE-2022-41082) są wykorzystywane w „ograniczonych, ukierunkowanych atakach”. W przypadku braku oficjalnej łatki organizacje powinny sprawdzić swoje środowiska pod kątem oznak eksploatacji, a następnie zastosować kroki łagodzące sytuację awaryjną.

• CVE-2022-41040 — Fałszowanie żądań po stronie serwera, umożliwiające uwierzytelnionym atakującym wysyłanie żądań podszywających się pod komputer, którego dotyczy problem
• CVE-2022-41082 — zdalne wykonywanie kodu, umożliwiające uwierzytelnionym atakującym wykonanie dowolnego programu PowerShell.

„Obecnie nie ma żadnych znanych skryptów potwierdzających koncepcję ani narzędzi eksploatacyjnych dostępnych na wolności” napisał John Hammond, łowczyni zagrożeń z Łowczynią. Oznacza to jednak, że zegar tyka. Po ponownym skupieniu się na luce, udostępnienie nowych exploitów lub skryptów sprawdzających koncepcję jest tylko kwestią czasu.

Kroki wykrywania wykorzystania

Pierwsza luka — luka w fałszowaniu żądań po stronie serwera — może zostać wykorzystana do osiągnięcia drugiej — luki w zdalnym wykonaniu kodu — ale wektor ataku wymaga, aby przeciwnik był już uwierzytelniony na serwerze.

Zgodnie z GTSC organizacje mogą sprawdzić, czy ich serwery Exchange zostały już wykorzystane, uruchamiając następujące polecenie PowerShell:

Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*Autodiscover.json.*@.*200

GTSC opracowało również narzędzie do wyszukiwania śladów eksploatacji i opublikowałem go na GitHub. Ta lista będzie aktualizowana w miarę udostępniania narzędzi przez inne firmy.

Narzędzia specyficzne dla firmy Microsoft

• Według Microsoft, w Microsoft Sentinel znajdują się zapytania, które można wykorzystać do polowania na to konkretne zagrożenie. Jednym z takich zapytań jest Wymień SSRF Autodiscover ProxyShell wykrywania, który powstał w odpowiedzi na ProxyShell. Nowa Podejrzane pobieranie plików z serwera Exchange zapytanie wyszukuje podejrzane pliki do pobrania w dziennikach IIS.
• Alerty Microsoft Defender for Endpoint dotyczące możliwej instalacji powłoki internetowej, możliwej powłoki internetowej IIS, podejrzanego wykonania procesu Exchange, możliwego wykorzystania luk Exchange Server, podejrzanych procesów wskazujących na powłokę internetową i możliwego naruszenia bezpieczeństwa IIS mogą również świadczyć o tym, że serwer Exchange został zagrożone przez dwie luki.
• Microsoft Defender wykryje próby po wykorzystaniu jako Backdoor: ASP/Webshell. Y i Backdoor: Win32/RewriteHttp.A.

Kilku producentów zabezpieczeń ogłosiło również aktualizacje swoich produktów w celu wykrywania nadużyć.

Huntress powiedział, że monitoruje około 4,500 serwerów Exchange i obecnie bada te serwery pod kątem potencjalnych oznak eksploatacji na tych serwerach. „W tej chwili Huntress nie zauważyła żadnych oznak eksploatacji ani oznak kompromisu na urządzeniach naszych partnerów” – napisał Hammond.

Kroki łagodzące do podjęcia

Microsoft obiecał, że przyspieszy poprawkę. Do tego czasu organizacje powinny stosować następujące środki zaradcze do programu Exchange Server, aby chronić swoje sieci.

Według firmy Microsoft lokalni klienci programu Microsoft Exchange powinni stosować nowe reguły za pomocą modułu reguł ponownego zapisywania adresów URL na serwerze IIS.

• W Menedżerze IIS -> Domyślna witryna sieci Web -> Automatyczne wykrywanie -> Przepisywanie adresu URL -> Akcje, wybierz opcję Zażądaj blokowania i dodaj następujący ciąg do ścieżki adresu URL:

.*autodiscover.json.*@.*Powershell.*

Wejście warunku powinno być ustawione na {REQUEST_URI}

• Zablokuj porty 5985 (HTTP) i 5986 (HTTPS), ponieważ są one używane przez Remote PowerShell.

Jeśli korzystasz z Exchange Online:

Microsoft powiedział, że klienci Exchange Online nie są dotknięci i nie muszą podejmować żadnych działań. Jednak organizacje korzystające z usługi Exchange Online prawdopodobnie będą miały hybrydowe środowiska Exchange z mieszanką systemów lokalnych i w chmurze. Powinni postępować zgodnie z powyższymi wskazówkami, aby chronić serwery lokalne.