Kompleksowe szkolenie: wprowadzenie do bezpieczeństwa IT od sekuraka z rabatem 50%. Jedyna taka okazja w tym roku. Nie przegap! :-)

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

07 marca 2021, 14:25 | Aktualności | komentarzy 10

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: 

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ą: 

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

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Jest dużo prostsze rozwiązanie: przepuszczanie całego OWA przez proxy, np. Nginxa. Wówczas można po pierwsze ograniczyć dostępność całego OWA do wybranych klas adresowych (np. wszyscy najwięksi polscy ISP + adresy dopisywane na żądanie), ale już bez adresów chińskich, ruskich, czy np. cloudowych/vps-owych.

    A po drugie można się jeszcze wtedy pobawić w pisanie bardziej konkretnych regułek, wykrywających ten atak – i jeśli wystąpią podejrzane requesty, wówczas jeszcze poprosić o dodatkowe hasło za pomocą http auth – ale to jak już ktoś ma czas.

    Odpowiedz
    • Wujek Pawel

      Zlote Rady Tomasza Klima, tak jakby atakujacy zawsze robili to z chinskich czy rosyjskich adresow IP, a nie np. z adresow polskich shakowanych ISP.

      Odpowiedz
    • tjk

      zgadzam się, nginx jako proxy – banalnie prosty do postawienia – potrafi zmitygować wiele podatności, które dla oprogramowania np. legacy nie mają patchy, ale i te jak powyżej, które patche mają.

      Odpowiedz
  2. pacza, paczy, meczy

    Dobry art., konkretny.

    Byłby zupełnie super, gdyby nie powielane błędy językowe.

    Nie „zainstaluj patcha”, tylko „zainstaluj patch”.
    (Wskazówka: „napraw hamulec”, nie „napraw hamulca”).

    Nie „masz już patcha”, tylko „masz już patch”.
    (Wskazówka: „masz już rower”, nie „masz już rowera”).

    Nie „nie mogę zainstalować patchy”, tylko „nie mogę zainstalować patchów”.

    (Wskazówka: „piłkarze nie rozegrali meczów”, nie „piłkarze nie rozegrali meczy” (owca meczy ;-))).

    Odpowiedz
    • Bb

      Kto patrzy jak się patch pisze?
      Patchują Panie, a nie patrzą na pisanie.

      Odpowiedz
  3. Rafal

    Dodam tylko, ze Exchange rowniez zawiera podatnosci, a poprawka znajduje sie tu

    Odpowiedz
  4. Mateusz

    Hej Grzesiek, moze napisales ten artykul zanim zostalo to opublikowane, ale historia odkrycia tego bledu jak zostalo ujawnione niedawno byla inna – i jeszcze bardziej ciekawa. W skrocie, blad zostal odkryty przez researcherow z DEVCORE w Grudniu – miedzy innymi przez znanego powszechnie Orange Tsai. Zglosili oni blad do Msft, przekazujac rowniez exploit. Wszystko szlo pieknie do przodu, az nagle okazalo sie ze ten sam blad jest exploitowany „in the wild” – i co ciekawe, nie mamy doczynienia z kolizja bledow/podwojnym odkryciem, bo exploit „z dziczy” zostal przebadany przez DEVCORE, i zostalo potwierdzone ze to ten sam zgloszony exploit. To znaczy ze musial on w jakis sposob wyciec miedzy odkryciem bledu a odkryciem atakow. Zwazywszy na to jak powazny jest ten blad (co sam opisujesz) nie dziwi mnie to az tak – strzelam ze cena za niego mogla byc astronomiczna.

    Zrodlo: https://proxylogon.com/#timeline. Nie widzilem oficjalnego potwierdzenia od Msft, ale osobiscie watpie zeby respektowane osoby z DEVCORE/Orange narazali swoja reputacje.

    Odpowiedz
  5. Adek
    Odpowiedz
    • Już jest część PoCów dostępnych – wystarczy trochę poszukać. Pewnie za jakiś czas i my je podlinkujemy…

      Odpowiedz

Odpowiedz