Masz Microsoft Exchange? Zobacz, dlaczego ostatnia podatność jest inna niż znane wcześniej

Microsoft Exchange Server jest rozwiązaniem, które od prawie ćwierć wieku wyznacza pewien standard pracy grupowej. Warto pamiętać, że jest to nie tylko serwer pocztowy, a połączone z Outlookiem środowisko, pozwalające pracować w sposób, bez którego pracownicy największych firm na świecie nie wyobrażają sobie realizacji swoich codziennych zadań.

Nie bez powodu porównuje się go raczej do rozwiązań typu Lotus Notes czy GroupWise, a nie do serwerów pocztowych, których na rynku są dziesiątki. W efekcie Exchange stał się serwerem, który wprawdzie na zapleczu, ale realizuje krytyczne funkcje, jest używany w największych organizacjach i nawet najdrobniejsze zaburzenia jego działania natychmiast przekładają się niezadowolenie tysięcy użytkowników. Brzmi to jak gotowy przepis na serwer, przed którego patchowaniem (zwłaszcza automatycznym) administratorzy będą mieć ogromne obawy. Dodajmy do tego komunikację ze światem i bug pozwalający na RCE (Remote Code Execution), żeby dostać mieszankę wybuchową, której skutki odczuwają dziesiątki tysięcy firm na całym świecie. 

Historie bugów są przeróżne. Czasem developer zorientuje się, że coś pomieszał, czasem odkryją go badacze, a czasem, tak jak w przypadku błędów Exchange z marca 2021, ktoś zauważy, że wykonywane są ataki, w których wykorzystuje się nieznane szerzej mechanizmy przełamywania zabezpieczeń. Charakter serwerów Exchange sprawia, że w ich przypadku takie błędy powodują dość szybko reakcję Microsoftu i niemal od razu publikowana jest poprawka. Dla atakujących oznacza to tylko jedno: koniec działania po cichu, bo za chwilę wszystkie potencjalne cele zostaną połatane. Dodatkowo, atakiem zaczynają interesować się inni (i źli, i dobrzy) specjaliści i wykorzystują go w swoich działaniach. A administratorzy? Mają weekend. Muszą sprawdzić wpływ patcha w środowisku testowym. Muszą dostać komplet zgód od szefostwa. Które też ma weekend. Itd. Bo to przecież krytyczny z punktu widzenia biznesu system. 

Był sobie bug 

Ups… Przecież mam Exchange 

Jak to zwykle bywa, Microsoft zaczął od opublikowania poprawki wraz z jej dokumentacją. Wynika z niej, że problem dotyczy wersji 2013, 2016 i 2019 serwera Exchange. Masz którąś z tych wersji? Zastanów się, czy doczytać ten tekst do końca, czy jednak zacząć do instalacji poprawek, bo sprawa jest naprawdę pilna. Poprawki dostępne są pod poniższymi adresami: 

• Exchange Server 2013 (update wymaga CU 23) 
• Exchange Server 2016 (update wymaga CU 19 lub CU 18) 
• Exchange Server 2019 (update wymaga CU 8 lub CU 7) 

Skąd ta panika? 

Panika nie jest może najlepszym podejściem, ale najwyższy priorytet – już tak. Przyczyna jest bardzo prosta. Atak jest równocześnie prosty do przeprowadzenia, szeroko znany i dotyka wielu organizacji. Dodatkowo administratorzy zwlekają z łataniem systemu z powodów wspomnianych wcześniej. Jaki jest efekt? Przeprowadzony przez Rapid7 test wykazał, że potencjalny cel ataków to około 170 tysięcy nadal niezabezpieczonych organizacji. Dlatego najpierw zainstaluj patcha.

Co dalej? 

Jeżeli masz już patcha, to sprawdź, czy atak nie został przeprowadzony przed jego instalacją. Jeżeli go nie masz i z jakiegoś powodu nie możesz zainstalować – zastosuj działania ograniczające skuteczność ataków. Oba scenariusze opisane są poniżej. 

Czy zostałem trafiony? 

W największym uproszczeniu atak polega na podrzuceniu na serwer webowy (będący częścią Exchange’a) pliku ASPX działającego później jak webshell. Parametry przekazywane w wywołaniu strony są używane do wykonania kodu po stronie serwera. Tak same pliki, jak i skutki ich działania pozostawiają pewne ślady i na ich poszukiwaniu warto się najpierw skupić. Na podstawie badań wykonanych przez Volexity, poszukiwania powinny objąć: 

Zapytania HTTP POST do: 

• /owa/auth/Current/themes/resources/logon.css 
• /owa/auth/Current/themes/resources/owafont_ja.css 
• /owa/auth/Current/themes/resources/lgnbotl.gif 
• /owa/auth/Current/themes/resources/owafont_ko.css 

• /owa/auth/Current/themes/resources/SegoeUI-SemiBold.eot 
• /owa/auth/Current/themes/resources/SegoeUI-SemiLight.ttf 
• /owa/auth/Current/themes/resources/lgnbotl.gif 

Zapytania do Exchange Control Panel (logowane w \<exchange install path>\Logging\ECP\Server\) wyglądające podobnie do: 

• S:CMD=Set-OabVirtualDirectory.ExternalUrl=’ 

Sprawdzenie instnienia plików aspx działających jak webshell. Pliki takie mogą znajdować się w folderach: 

• \inetpub\wwwroot\aspnet_client\ (dowolny plik aspx w tym folderze albo podfolderach) 
• \<exchange install path>\FrontEnd\HttpProxy\ecp\auth\ (każdy plik poza TimeoutLogoff.aspx) 

• \<exchange install path>\FrontEnd\HttpProxy\owa\auth\ (każdy plik lub zmodyfikowane pliki nie będące częścią standardowej instalacji) 
• \<exchange install path>\FrontEnd\HttpProxy\owa\auth\Current\ (dowolny plik aspx w tym folderze lub podfolderach) 
• \<exchange install path>\FrontEnd\HttpProxy\owa\auth\<folder with version number>\ (dowolny plik aspx w tym folderze lub podfolderach) 

Więcej mniej oczywistych śladów przedstawione zostało w dokumencie opublikowanym przez amerykańską agencję CISA (Cybersecurity and Infrastructure SecurityAgency). Dodatkowo skanowanie istotnej części śladów może zostać zautomatyzowane prostym skryptem PowerShell opublikowanym przez Łotewski CERT. 

Naprawdę nie mogę zainstalować patchy 

Jeżeli patche naprawdę nie mogą zostać zainstalowane (nie wierzymy, ale i tak pomożemy), jakimś rozwiązaniem będzie ograniczenie możliwości ataku dzięki innym mechanizmom. Serwer będzie działał z wadliwym oprogramowaniem, ale obecnie przeprowadzane ataki będą nieskuteczne, dzięki czemu uda się uzyskać chwilę oddechu, żeby przygotować instalację poprawek tak szybko, jak to możliwe. Nie jest to rozwiązanie zalecane, ale na pewno lepsze niż żadne. Potrzebne w tym celu będą: 

• URL Rewrite Module zainstalowany na serwerze IIS, 
• Skrypt opublikowany przez Microsoft na GitHub. 

Cały proces opisany jest w szczegółach na stronach Microsoftu i w efekcie jego działania filtrowane są zapytania zawierające cookies X-AnonResource-Backend oraz X-BEResource. Cookies te wykorzystywane były w dotychczas obserwowanych atakach, więc nie ma gwarancji, że powstrzymają wszystkie przyszłe metody, ponieważ niespatchowany serwer nadal pozostaje podatny. Dodatkowo, rozwiązanie to nie zostało w pełni przetestowane, ale Microsoft podaje, że szybkie testy nie wykazały skutków ubocznych, a potencjalne korzyści są warte ewentualnych niedogodności. Warto również wiedzieć, że reguły tworzone przez skrypt zostaną nadpisane po zaktualizowaniu Exchange’a, ale to już raczej mało prawdopodobna sytuacja, ponieważ scenariusze, gdzie możliwy jest upgrade, ale niemożliwe jest zainstalowanie patcha nie są w praktyce spotykane. 

–Grzegorz Tworek