ProxyToken, czyli podatność pozwalająca na obejście uwierzytelniania w MS Exchange

W marcu tego roku pisaliśmy o krytycznej podatności ProxyLogon (CVE-2021-26855), która pozwalała atakującemu na ominięcie uwierzytelniania i zdalne wykonanie kodu w Microsoft Exchange Server:

Jak podkreślił badacz bezpieczeństwa Organge Tsai, wyżej wspomniana podatność to jedynie “wierzchołek góry lodowej”, ponieważ architektura MS Exchange stanowi nową powierzchnię ataku, o której badacz mówił na  ostatniej konferencji DEFCON:

To jednak nie koniec problemów z Microsoft Exchange. Firma Zero Day Initiative przedstawiła szczegóły dotyczące podatności ProxyToken. Luka pozwalała nieuwierzytelnionemu atakującemu wykonywać działania konfiguracyjne na skrzynkach pocztowych dowolnego użytkownika. W praktyce atakujący mógł w ten sposób np. skopiować wszystkie wiadomości e-mail zaadresowane do konta ofiary i przesłać je na konto, które kontrolował. Tak prezentuje się Proof of Concept dla tej podatności:

Aby lepiej zrozumieć podatność ProxyToken, polecamy obejrzeć wystąpienie badacza Orange Tasi. W skrócie – Microsoft Exchange możemy podzielić na stronę frontendową oraz backendową. Witryna frontendowa jest w większości tylko serwerem proxy do backendu. Aby zezwolić na dostęp wymagający uwierzytelniania, frontend obsługuje podstrony takie jak “/owa/auth/logon.aspx”. W przypadku żądań wykonywanych po uwierzytelnieniu, główną rolą frontendu jest przepakowanie żądań i przekazywanie ich do odpowiednich punktów końcowych backendu MS Exchange. Frontend następnie zbiera odpowiedzi z backendu i przesyła je do klienta:

W przypadku ProxyToken problem leżał w module “DelegatedAuthModule” i nieodpowiedniej konfiguracji backendu MS Exchange. Kiedy frontend wykryje ciasteczko “SecurityToken”, z automatu wie, że żądanie powinno zostać najpierw uwierzytelnione po stronie backendu. Tymczasem backend jest nieświadomy faktu, że musi uwierzytelnić niektóre żądania na podstawie ciasteczka SecurityToken, ponieważ moduł “DelegatedAuthModule” nie jest ładowany w serwerach MS Exchange, które nie zostały uprzednio skonfigurowane do korzystania z funkcji “Delegated Authentication”. W rezultacie wysyłanie żądania z ciasteczkiem “SecurityToken” nie wymaga wtedy uprzedniego uwierzytelnienia:

Jest i dobra wiadomość: poprawka dla tej podatności pojawiła się w czerwcu tego roku, a w przypadku ProxyToken atakujący musi posiadać dostęp do konta na tym samym serwerze Exchange co ofiara (aby móc przekierować e-maile z konta ofiary na własne konto). 

Jeśli  jednak administrator serwera Exchange wprowadził pewne zmiany konfiguracyjne, wymóg posiadania konta przez atakującego na tym samym serwerze nie jest konieczny do powodzenia ataku. Badacz ostrzega również, że mogą istnieć inne metody wykorzystania tej podatności. Ta i inne luki znalezione w ostatnim czasie są błędami logicznymi, dlatego ich wykorzystanie jest o wiele łatwiejsze niż błędów związanych np. z uszkodzeniem pamięci (memory corruption).

~ Jakub Bielaszewski