W lutym 2020 roku Microsoft załatał krytyczną podatność w serwerach Exchange, który wykorzystana przez atakujących prowadzi do możliwości zdalnego wykonania kodu w kontekście systemu. Podatność została oznaczona kodem CVE-2020-0688 i wynika z faktu, że serwer pocztowy nie tworzył poprawnie unikatowych kluczy kryptograficznych podczas instalacji.
Poprawka została szybko wydana, a administratorzy ostrzeżeni, że niezałatane serwery są wykorzystywane przez grupy hackerskie.
Nowy pomiar telemetryczny wykonany przez Rapid7 ujawnił zadziwiające fakty. 61 procent wszystkich serwerów Exchange połączonych z Internetem, wciąż, po 8 miesiącach nie została zaktualizowana i jest podatna na tą lukę RCE.
Badacze Microsoft ostrzegali już w marcowym poradniku, że niezałatane serwery są wykorzystywane na wolności przez niebezpieczne grupy APT. Ataki rozpoczęły się pod koniec lutego i były wymierzone w liczne, obszerne organizacje. Specjaliści zaobserwowali, że atakujący wykorzystują tę lukę do uruchamiania poleceń systemowych w celu przeprowadzania rekonesansu, wdrażania backdoorów i modyfikacji struktur w pamięci po zakończeniu eksploatacji.
Wcześniej, w kwietniu, badacze Rapid7 odkryli, że ponad 80 procent serwerów było podatnych na ataki, z 433 464 zaobserwowanych serwerów Exchange połączonych z Internetem, co najmniej 357 629 było otwartych na tę lukę (stan na 24 marca). Naukowcy wykorzystali Project Sonar, narzędzie skanujące, do analizy serwerów Exchange połączonych z Internetem i wyszukania podatnych na usterkę.
Aktualizację dla CVE-2020-0688 należy zainstalować na każdym serwerze z włączonym panelem sterowania Exchange (ECP). Zwykle będą to serwery z rolą Client Access Server (CAS), w której użytkownicy będą uzyskiwać dostęp do aplikacji Outlook Web App (OWA). Exploit dotyczy wszystkich wersji Exchange o 2010 w górę.
Jak wykryć, czy nastąpił atak?
W ramach bieżącej aktywności administratorzy powinni również określić, czy ktoś próbował wykorzystać lukę w ich środowisku. Kod exploita, pozostawia na szczęście artefakty w dzienniku zdarzeń systemu Windows i logach IIS zarówno na serwerach z poprawkami, jak i bez poprawki.
Log Exchange
Jeśli chodzi o log wbudowany Exchange. Gdy coś pójdzie nie tak z ECP, zostaje stworzony folder o nazwie ServerException. Istnienie tego folderu i plików nie musi oznaczać, że serwer został wykorzystany przez atakujących. Jest to normalny katalog logowania w przypadku błędów:
\ Program Files \ Exchange Server \
- The serialized data is invalid.
- Exception has been thrown by the target of an invocation.
Ten log będzie również przechwytywał źródłowy adres IP żądania, adres URL i agenta użytkownika, który wykonał polecenie. Możemy wziąć na warsztat przechwycony URL i w polu „__VIEWSTATE” przekopiować cały blok w base64, zdekodować go i sprawdzić jakie komendy wykonywał ten użytkownik. Jeśli są dla nas niepokojące, może to świadczyć o wykorzystaniu tej podatności.
Log IIS
Istnieje też możliwość podobnej inwestygacji na podstawie logów IIS. Domyślnie serwery Exchange powinny rejestrować dostęp ECP za pośrednictwem standardowego logu IIS. Każdy dostęp przez ECP powinien być rejestrowany w tych plikach. Szukanie żądań przychodzących do ścieżki /ecp/default.aspx powinno wystarczyć do zawężenia wyszukiwania. Dalsze badanie tych dzienników powinno pokazać te same parametry, co w logach Exchange: __VIEWSTATEGENERATOR i __VIEWSTATE. Jak opisano powyżej, parametr __VIEWSTATE może być następnie dalej badany poprzez dekodowanie base64 w celu wyszukania oznak wykorzystania. Ten dziennik powinien również przechwytywać źródłowy adres IP i nazwę użytkownika, które zostały wykorzystane podczas ataku.
Web Directories
Osoba atakująca może zapisać złośliwe pliki i narzędzia w dowolnej lokalizacji. Jednak hackerzy nadzwyczaj często lubią zaczynać od umieszczenia powłoki internetowej (web shell) na serwerach Exchange. Każdy folder dostępny z Internetu za pośrednictwem przeglądarki internetowej jest potencjalnym celem. Poniżej katalogi, które na serwerach Exchange są najbardziej narażone na umieszczanie w nich złośliwych plików:
- \Inetpub\wwwroot\
- \Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
- \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\Auth
Warto sprawdzać ich zawartość pod kątem zgodności.
Podsumowanie
Podatność RCE w zabezpieczeniach Microsoft Exchange ECP dała atakującym kolejną okazję do włamania się do organizacji. Bycie na bieżąco z poprawkami jest najlepszą obroną. Na szczęście luka ta wymaga skompromitowanych danych uwierzytelniających użytkownika Exchange, aby dało się ją wykorzystać. Poznanie hasła do konta użytkownika nie jest jednak dużym wyzwaniem dla zmotywowanych atakujących.