S3 Ep102.5: Błędy wymiany „ProxyNotShell” – mówi ekspert [Audio + Text]

Znacznik czasu: 1 października 2022 10:05
Węzeł źródłowy: 1712650

by
Paweł Kaczor

NIE PANIKUJ… ALE BĄDŹ GOTOWY DO DZIAŁANIA

Z Paulem Ducklinem i Chesterem Wiśniewskim

Muzyka intro i outro autorstwa Edyta Mudge.

Kliknij i przeciągnij poniższe fale dźwiękowe, aby przejść do dowolnego punktu. Również możesz słuchaj bezpośrednio na Soundcloudzie.

Możesz nas posłuchać SoundCloud, Podcasty Apple, Podcasty Google, Spotify, Stitcher i wszędzie tam, gdzie można znaleźć dobre podcasty. Lub po prostu upuść URL naszego kanału RSS do swojego ulubionego podcatchera.

PRZECZYTAJ TRANSKRYPTU

[MOM MUZYCZNY]

KACZKA.  Witam wszystkich.

Witamy w kolejnym specjalnym mini-odcinku podcastu Naked Security.

Jestem Paul Ducklin, do którego ponownie dołączył mój przyjaciel i kolega Chester Wiśniewski.

Witaj Chet.

CHET.  [FAŁSZYWY AKCENT AUSSIE] Dzień dobry, Kaczorku.

KACZKA.  Cóż, Chet, jestem pewien, że wszyscy słuchają. jeśli słuchają wkrótce po ukazaniu się podcastu, wie, o czym będziemy rozmawiać!

I to musi być ta dwulufowa Microsoft Exchange dnia zerowego który wyszedł w praniu prawie ostatniego dnia września 2022 roku:

Nasi koledzy ze sprzedaży mówią: „Och, koniec miesiąca, koniec kwartału, to szalony czas… ale jutro wszyscy zostaną zresetowani do 0 USD”.

W ten weekend nie będzie tak dla Sysadminów i menedżerów IT!

CHET.  Kaczor, myślę, w nieśmiertelnych słowach drogiego zmarłego Douglasa Adamsa: "NIE PANIKOWAĆ" może być w porządku.

Wiele organizacji nie hostuje już własnych wiadomości e-mail lokalnie na serwerach Exchange, więc spora część osób może wziąć głęboki oddech i pozwolić, by w ten weekend upłynęło trochę czasu, nie denerwując się tym.

Ale jeśli korzystasz z programu Exchange lokalnie…

…gdybym to był ja, mógłbym pracować w nadgodzinach tylko po to, aby wprowadzić kilka łagodzeń, aby mieć pewność, że nie będę miał nieprzyjemnej niespodzianki w poniedziałek lub wtorek, kiedy to najprawdopodobniej przerodzi się w coś więcej dramatyczny.

KACZKA.  Więc jest to CVE-2022-41040 i CVE-2022-41042… to całkiem niezły kęs.

Widziałem, że na Twitterze jest to określane jako ProxyNotShell, ponieważ ma pewne podobieństwa do Powłoka proxy luka, która była wielką historią nieco ponad rok temu,

Ale chociaż ma te podobieństwa, jest to zupełnie nowa para exploitów, które łączą się ze sobą, potencjalnie umożliwiając zdalne wykonanie kodu – czy to prawda?

CHET.  Tak to brzmi.

Luki te zostały odkryte podczas aktywnego ataku na ofiarę, a wietnamska organizacja GTSC odkryła te dwie nowe luki, które umożliwiły przeciwnikom uzyskanie dostępu do niektórych swoich klientów.

Wygląda na to, że zostali odpowiedzialnie ujawnieni te luki do inicjatywy Zero Day Initiative [ZDI] prowadzonej przez firmę Trend Micro w celu odpowiedzialnego zgłaszania luk w zabezpieczeniach typu zero-day.

I oczywiście ZDI z kolei podzieliło się całą tą inteligencją z Microsoftem, nieco ponad trzy tygodnie temu.

A powodem, dla którego dzisiaj wychodzi, jest to, że myślę, że wietnamska grupa…

…wygląda na to, że stają się trochę niecierpliwi i zaniepokojeni, że minęły trzy tygodnie i że nie pojawiły się żadne ostrzeżenia ani porady, które pomogłyby chronić ludzi przed tymi rzekomymi aktorami państwowymi.

Postanowili więc wszcząć dzwony alarmowe i dać wszystkim znać, że muszą zrobić coś, aby się chronić.

KACZKA.  I, żeby być uczciwym, ostrożnie powiedzieli: „Nie ujawnimy dokładnie, jak wykorzystać te luki w zabezpieczeniach, ale przedstawimy środki łagodzące, które uznaliśmy za skuteczne”.

Wygląda na to, że sam exploit nie jest szczególnie niebezpieczny…

…ale połączone razem, oznacza to, że osoba spoza organizacji, która ma możliwość odczytywania wiadomości e-mail z serwera, może faktycznie użyć pierwszego błędu do otwarcia drzwi, a drugiego błędu do wszczepienia złośliwego oprogramowania na serwer Exchange.

CHET.  I to jest naprawdę ważny punkt do zrobienia, Duck, że powiedziałeś, „Ktoś, kto potrafi czytać wiadomości e-mail na twoim serwerze”.

To nie jest *nieuwierzytelniony* atak, więc osoby atakujące muszą mieć trochę informacji na temat Twojej organizacji, aby pomyślnie przeprowadzić te ataki.

KACZKA.  Teraz nie wiemy dokładnie, jakiego rodzaju poświadczeń potrzebują, ponieważ w czasie, gdy to nagrywamy [2022-09-30T23:00:00Z], wszystko jest nadal w dużej mierze tajne.

Ale z tego, co przeczytałem (od ludzi, którym jestem skłonny uwierzyć), wygląda na to, że pliki cookie sesji lub tokeny uwierzytelniające nie są wystarczająco dobre i faktycznie potrzebujesz hasła użytkownika.

Jednak po podaniu hasła, jeśli istniało uwierzytelnianie dwuskładnikowe [2FA], pierwszy błąd (ten, który otwiera drzwi) zostaje wyzwolony *pomiędzy momentem podania hasła a momentem, w którym kody 2FA byłyby wymagany*.

Potrzebujesz więc hasła, ale nie potrzebujesz kodu 2FA…

CHET.  Wygląda na to, że jest to „luka w połowie uwierzytelnienia”, jeśli chcesz to tak nazwać.

To mieszane błogosławieństwo.

Oznacza to, że zautomatyzowany skrypt Pythona nie może po prostu przeskanować całego Internetu i potencjalnie wykorzystać każdy serwer Exchange na świecie w ciągu kilku minut lub godzin, jak widzieliśmy w przypadku ProxyLogon i ProxyShell w 2021 roku.

W ciągu ostatnich 18 miesięcy zaobserwowaliśmy powrót robaków, ze szkodą dla wielu organizacji.

KACZKA.  „robactwo”?

CHET.  Robak, tak! [ŚMIECH]

KACZKA.  Czy to słowo?

Cóż, jeśli nie, to teraz!

Podoba mi się… może pożyczę, Chester. [ŚMIECH]

CHET.  Myślę, że jest to łagodnie podatne na robaki, prawda?

Potrzebujesz hasła, ale znalezienie jednej kombinacji adresu e-mail i hasła ważnej na dowolnym serwerze Exchange prawdopodobnie nie jest niestety zbyt trudne.

Kiedy mówisz o setkach lub tysiącach użytkowników… w wielu organizacjach jeden lub dwóch z nich prawdopodobnie ma słabe hasła.

Być może do tej pory nie zostałeś wykorzystany, ponieważ pomyślne zalogowanie się do programu Outlook Web Access [OWA] wymaga ich tokena FIDO, ich tokena uwierzytelniającego lub jakiegokolwiek drugiego czynnika, którego możesz użyć.

Ale ten atak nie wymaga tego drugiego czynnika.

Tak więc samo uzyskanie kombinacji nazwy użytkownika i hasła jest dość niską barierą…

KACZKA.  Teraz jest tu inna złożoność, prawda?

Mianowicie, że chociaż Wytyczne firmy Microsoft oficjalnie mówi, że klienci Microsoft Exchange Online mogą odstąpić od Blue Alert, jest to niebezpieczne tylko wtedy, gdy masz lokalny Exchange…

…jest zaskakująca liczba osób, które przeszły na chmurę, być może kilka lat temu, które jednocześnie podczas przejścia prowadziły zarówno usługę lokalną, jak i chmurową, które nigdy nie zdążyły się wyłączyć Wymiana serweru.

CHET.  Dokładnie!

Widzieliśmy, że wracamy do ProxyLogin i ProxyShell.

W wielu przypadkach przestępcy dostali się do ich sieci przez serwery Exchange, o których myśleli, że ich nie posiadają.

Na przykład ktoś nie sprawdził listy maszyn wirtualnych działających na ich serwerze VMware, aby zauważyć, że ich migrujące serwery Exchange, które pomagały mu podczas przenoszenia danych między siecią lokalną a siecią w chmurze…

…w rzeczywistości nadal były włączone, włączone i dostępne w Internecie.

A co gorsza, kiedy nie wiadomo, że tam są, jest jeszcze mniej prawdopodobne, że zostały załatane.

Mam na myśli, że organizacje, które mają Exchange, przynajmniej prawdopodobnie robią wszystko, aby regularnie planować ich konserwację.

Ale kiedy nie wiesz, że masz coś w swojej sieci „ponieważ zapomniałeś”, co jest naprawdę łatwe w przypadku maszyn wirtualnych, jesteś w jeszcze gorszej sytuacji, ponieważ prawdopodobnie nie stosowałeś aktualizacji systemu Windows ani aktualizacji Exchange.

KACZKA.  A prawo Murphy'ego mówi, że jeśli naprawdę polegasz na tym serwerze i nie dbasz o niego właściwie, ulegnie on awarii na dzień przed tym, jak naprawdę go potrzebujesz.

Ale jeśli nie wiesz, że tam jest i może być źle wykorzystany, szanse, że będzie działać przez lata i lata bez żadnych problemów, są prawdopodobnie dość wysokie. [ŚMIECH]

CHET.  Tak, niestety, to z pewnością moje doświadczenie!

Brzmi to głupio, ale skanowanie własnej sieci, aby dowiedzieć się, co masz, jest czymś, co i tak zalecamy regularnie.

Ale z pewnością, gdy słyszysz o biuletynie takim jak ten, jeśli jest to produkt, z którego wiesz, że korzystałeś w przeszłości, taki jak Microsoft Exchange, jest to dobry moment, aby uruchomić ten wewnętrzny Skanowanie Nmap...

…a może nawet zaloguj się do shodan.io i sprawdź swoje usługi zewnętrzne, aby upewnić się, że wszystkie te rzeczy zostały wyłączone.

KACZKA.  Wiemy teraz z własnej odpowiedzi Microsoftu, że gorączkowo odmawiają wydania łatek.

Kiedy pojawią się te łatki, lepiej nałóż je dość szybko, prawda?

Ponieważ jeśli jakakolwiek łata będzie kiedykolwiek celem inżynierii wstecznej w celu wykrycia exploita, będzie to coś w tym rodzaju.

CHET.  Tak, absolutnie, Kaczor!

Nawet po zainstalowaniu patcha pojawi się okno czasowe, prawda?

Chodzi mi o to, że zazwyczaj Microsoft na wtorki z łatami i tak wypuszcza swoje łatki o godzinie 10.00 czasu pacyficznego.

W tej chwili jesteśmy w czasie letnim, więc jest to UTC-7… więc około godziny 17:00 UTC jest zwykle momentem, w którym Microsoft wydaje łatki, więc większość ich pracowników ma cały dzień, aby odpowiedzieć na przychodzące zapytania w Seattle. [Kwatera główna Microsoftu znajduje się w Bellevue, Seattle, WA.]

Kluczem tutaj jest rodzaj „wyścigu” godzin, może minut, w zależności od tego, jak łatwo to wykorzystać, zanim zacznie się dziać.

I znowu, wracając do poprzednich przypadków wykorzystywania Exchange z ProxyShell i ProxyLogon, często stwierdzaliśmy, że nawet klienci, którzy załatali łatki w ciągu trzech, czterech, pięciu dni…

…co, szczerze mówiąc, jest dość szybki jak na serwer Exchange, bardzo trudno je załatać, wymaga wielu testów, aby upewnić się, że jest niezawodny, zanim zakłócisz działanie serwerów pocztowych.

To było wystarczająco dużo czasu, aby te serwery mogły się dostać powłoki internetowe, kryptominery, Wszystkie typy backdoory zainstalowane na nich.

A zatem, gdy oficjalny patch wyjdzie, nie tylko musisz działać szybko…

…*po* działaniu, warto wrócić i dokładnie sprawdzić te systemy w poszukiwaniu dowodów na to, że być może zostały zaatakowane w przerwie między udostępnieniem łatki a możliwością jej zastosowania.

Jestem pewien, że będzie dużo rozmów o Naked Security i dalej Twitter i innych miejscach, rozmawiając o typach ataków, które obserwujemy, abyś wiedział, czego szukać.

KACZKA.  Chociaż możesz iść i poszukać kilku skrótów znanego złośliwego oprogramowania, które zostało już rozpowszechnione w ograniczonej liczbie ataków…

…naprawdę, najważniejsze jest to, że wszelkiego rodzaju złośliwe oprogramowanie to możliwości.

I tak, jak myślę, że powiedziałeś w ostatni mini-odcinek to zrobiliśmy, nie wystarczy już czekać na alerty o czymś złym, które pojawiły się na pulpicie nawigacyjnym:

Musisz wyjść proaktywnie i szukać, na wypadek, gdyby oszuści byli już w twojej sieci i zostawili coś (co mogło być tam od wieków!), czego jeszcze nie zauważyłeś.

CHET.  Więc myślę, że to prowadzi nas do „Co robimy teraz, czekając na łatkę?”

Opublikowano blog Microsoft Security Research Center (MSRC) kilka porad dotyczących łagodzenia skutków i szczegóły… tyle, ile Microsoft chce obecnie ujawnić.

Powiedziałbym, że jeśli jesteś czysty Microsoft Exchange Online klient, jesteś prawie czysty i powinieneś po prostu uważać, jeśli coś się zmieni.

Ale jeśli jesteś w sytuacji hybrydowej lub nadal korzystasz z Microsoft Exchange lokalnie, myślę, że prawdopodobnie jest jakaś praca, którą warto wykonać dziś po południu lub jutro rano, jeśli nic więcej.

Oczywiście w czasie nagrywania jest to piątek po południu… więc naprawdę, kiedy tego słuchasz, „Natychmiast, kiedy to słyszysz, jeśli jeszcze tego nie zrobiłeś”.

Jakie są najlepsze praktyki tutaj, Duck?

Oczywiście jedną rzeczą, którą możesz zrobić, to po prostu wyłączyć zewnętrzny dostęp do sieci, dopóki łatka nie będzie dostępna.

Możesz po prostu zamknąć serwer IIS, a wtedy to zrobi!

KACZKA.  Podejrzewam, że wiele firm nie będzie w takiej sytuacji.

A Microsoft wymienia dwie rzeczy, które mówią… cóż, nie mówią, „To na pewno zadziała”.

Sugerują, że znacznie ograniczy to twoje ryzyko.

Jednym z nich jest reguła przepisywania adresów URL, którą można zastosować do serwera IIS. (Rozumiem, że to IIS akceptują połączenie przychodzące, które zamienia się w dostęp do usług internetowych Exchange [EWS].)

Jest więc ustawienie IIS, które możesz wprowadzić, które będzie szukać prawdopodobnych przypadków wykorzystania pierwszej dziury, co uniemożliwi uruchomienie wyzwalania PowerShell.

Istnieje również kilka portów TCP, które możesz zablokować na swoim serwerze Exchange.

Wierzę, że to porty 5985 i 5986, które zatrzymają to, co się nazywa PowerShell Remoting… zatrzyma te nieuczciwe polecenia zdalnego wykonania PowerShell, które zostaną wprowadzone do serwera Exchange.

Zwróć jednak uwagę, że Microsoft twierdzi, że to „ograniczy” Twoją ekspozycję, zamiast obiecywać, że wie, że to wszystko naprawi.

I to może być dlatego, że podejrzewają, że istnieją inne sposoby, które mogą to wywołać, ale po prostu nie do końca zorientowali się, czym one są. [ŚMIECH]

Żadne ustawienie nie jest czymś, co robisz w samym Exchange.

Jeden z nich znajduje się w IIS, a drugi to swego rodzaju reguła filtrowania sieci.

CHET.  Cóż, pomoże nam to przetrwać kilka następnych dni, podczas gdy Microsoft zapewni nam stałą poprawkę.

Dobrą wiadomością jest to, że myślę, że dużo oprogramowania zabezpieczającego, niezależnie od tego, czy jest to IPS, który może być zintegrowany z zaporą ogniową, czy produkty zabezpieczające punkty końcowe, które chronią infrastrukturę Microsoft Windows Server…

…ataki na to w wielu przypadkach (przynajmniej we wczesnych raportach) wyglądają bardzo podobnie do ProxyLogon, w związku z czym nie jest jasne, czy istniejące reguły będą chronić przed tymi atakami.

Mogą, ale poza tym wydaje się, że większość dostawców stara się je nieco zaostrzyć, aby upewnić się, że są tak gotowi, jak to tylko możliwe, na podstawie wszystkich wskaźników, które zostały obecnie publicznie udostępnione, aby mogli wykryć i wysyłać Ci alerty, jeśli miałyby one wystąpić na Twoich serwerach Exchange.

KACZKA.  Zgadza się, Chester.

Dobrą wiadomością dla klientów Sophos jest to, że możesz śledzić wykrycia specyficzne dla Sophos, jeśli chcesz przejrzeć swoje dzienniki.

Nie tylko dla IPS, niezależnie od tego, czy jest to IPS na zaporze, czy w punkcie końcowym, ale mamy też kilka reguł behawioralnych.

Możesz śledzić te nazwy wykrywania, jeśli chcesz ich poszukać… postępuj zgodnie z tym na @SophosxOps Kanał na Twitterze.

Ponieważ otrzymujemy nowe nazwy wykrywania, których możesz używać do polowania na zagrożenia, publikujemy je tam, abyś mógł je łatwo wyszukać:

CHET.  Jestem pewien, że będziemy mieli więcej do powiedzenia w podcastie w przyszłym tygodniu, czy będzie to powrót Douga, czy to, że znów zajmę miejsce dla gości.

Ale jestem przekonany, że przez jakiś czas nie będziemy w stanie położyć tego do łóżka….

KACZKA.  Myślę, że podobnie jak ProxyShell, jak Log4Shell, przez jakiś czas będzie rozbrzmiewać echo.

Więc może lepiej powiedzmy, jak zawsze, Chester:

Do następnego razu…

OBIE.  Bądź bezpieczny.

[MOM MUZYCZNY]

Znak czasu:

Więcej z Nagie bezpieczeństwo