W zeszłym miesiącu Microsoft załatał prawdopodobnie jeden z najpoważniejszych błędów, jakie kiedykolwiek zgłoszono firmie. Luka nazwana Zerologon umożliwia atakującym infiltrację firm poprzez uzyskanie uprawnień administracyjnych, dając im dostęp do firmowych kontrolerów domeny Active Directory. Luka otrzymała maksymalną ilość punktów na skali CVSS, jednak żadne szczegóły nie zostały upublicznione przez Microsoft. Oznacza to, że użytkownicy i administratorzy IT nie wiedzieli, z jak niebezpieczną podatnością mieli do czynienia. Więcej informacji znajdziecie poniżej.
1. Zerologon pozwala na przejęcie kontrolera domeny w 3…2..1…
Przy okazji każdego Centrum Bezpieczeństwa Xopero przypominamy, jak istotne są regularne aktualizacje. Niestety, na własnej skórze mogą przekonać się o tym wszystkie organizacje, które w terminie nie zastosowały sierpniowych aktualizacji Microsoftu. Wtedy, bez większego echa załatana została luka CVE-2020-1472 (10/10) umożliwiająca podniesienie uprawnień w protokole zdalnym Netlogon (MS-NRPC).
CVE-2020-1472 (aka Zerologon) dotyczy wszystkich obsługiwanych wersji systemu Windows Server od 2008 wzwyż. Zagrożenie jest jednak największe w przypadku serwerów, które działają jako kontrolery domeny Active Directory w sieciach korporacyjnych.
Luka wynika z błędu w schemacie uwierzytelniania kryptograficznego używanego przez Netlogon Remote Protocol. Netlogon korzysta z algorytmu AES, w trybie CFB8. Ten wykorzystuje dość często spotykany w kryptografii IV, a inżynierowie Microsoftu wymagają żeby składał się on z samych zer (!). Wystarczy 256 prób (a można próbować do woli), aby serwer zaakceptował logowanie – to powinno zająć ok…3 sekund.
Atakujący może zmienić hasło kontrolera domeny, przechowywane w usłudze AD, a następnie wykorzystać je do uzyskania poświadczeń administratora. Podatność nie wymaga posiadania żadnego konta, exploit jest szybki i działa bardzo stabilnie, dotyka wszystkich obsługiwanych serwerów Windows i umożliwia pełen dostęp do administratora domeny.
W ciągu ostatniego tygodnia opublikowano wiele proofs-of-concept (PoC), a efektywność wielu z nich została potwierdzona. Exploit ten znalazł również zastosowanie w najnowszej wersji Mimikatz.
Badacze z Secura opublikowali skrypt Pythona, który organizacje mogą wykorzystać do sprawdzenia, czy kontroler domeny jest podatny na ataki.
Zerologon – jak się chronić?
Systemy, które otrzymały sierpniową poprawkę są zabezpieczone przed atakiem. Aktualizacja kontrolerów domeny usługi Active Directory umożliwi domyślną ochronę urządzeń z systemem Windows. Pełne środki zaradcze zadziałają dopiero po wdrożeniu przez organizację trybu wymuszania kontrolera domeny, który wymaga aby wszystkie urządzenia używały bezpiecznego NRPC. Choć organizacje mogą wdrożyć go natychmiast, od 9 lutego 2021 r. kontrolery domeny zostaną domyślnie przełączone w tryb wymuszania.
2. BLESA, czyli miliardy urządzeń IoT z podatnością w zabezpieczeniach Bluetooth
Smartphony, tablety, laptopy i urządzenia IoT… Wszystkie posiadają podatność w zabezpieczeniach Bluetooth o nazwie BLESA (Bluetooth Low Energy Spoofing Attack). Problem dotyczy wszystkich urządzeń wykorzystujących protokół Bluetooth Low Energy (BLE). Z uwagi na funkcję oszczędzania baterii, protokół BLE w ciągu ostatniej dekady stał się technologią niemal wszechobecną w prawie wszystkich urządzeniach zasilanych baterią.
Nowy atak BLESA bazuje na procesie nawiązywania ponownego połączenia Bluetooth. W przeciwieństwie do poprzednich luk – najczęściej występujących podczas operacji parowania – proces ponownego łączenia ma miejsce po tym, jak dwa urządzenia BLE (klient i serwer) znalazły się poza wzajemnym zasięgiem. Zwykle podczas ponownego łączenia oba urządzenia BLE powinny wzajemnie sprawdzać klucze kryptograficzne wynegocjowane podczas procesu parowania, a także kontynuować przerwaną wymianę danych za pośrednictwem BLE.
Jednak zespół akademików z Purdue odkrył, że uwierzytelnianie podczas ponownego połączenia urządzenia jest opcjonalne, a nie obowiązkowe. Uwierzytelnianie można też potencjalnie obejść, jeśli urządzenie użytkownika nie wymusi na urządzeniu IoT uwierzytelnienia przesyłanych danych.
Demo ataku BLESA
Te dwie kwestie otwierają furtkę przestępcom do przeprowadzenia ataku BLESA. Atakujący są w stanie ominąć weryfikację ponownego połączenia a następnie przesłać sfałszowane dane do urządzenia BLE z niepoprawnymi informacjami. Efekt? Mogą w ten sposób skłonić użytkowników oraz zautomatyzowane procesy do podejmowania „błędnych” decyzji.
Problemy z załataniem podatności. Niestety, podobnie jak w przypadku wszystkich poprzednich błędów Bluetooth, łatanie wszystkich podatnych urządzeń może okazać się niezwykle trudne. A vw przypadku niektórych urządzeń – wręcz niemożliwe. Wiele urządzeń IoT nie ma wbudowanego mechanizmu aktualizacji, co oznacza, że nie otrzymają one stosowanej aktualizacji i tym samym pozostaną trwale podatne na atak.
3. Nowa forma „przemycania” żądań HTTP stanowi poważne zagrożenie dla wszystkich typów proxy
HTTP Request Smuggling to atak polegający na „przemycaniu”, czyli łączeniu złośliwych żądań HTTP z tymi prawdziwymi. Jak się okazuje – może on doprowadzić do poważnego spustoszenia wewnątrz atakowanej organizacji. Dlaczego?
Właściwie to szczególnie niebezpieczna jest nowa odmiana tego ataku – nazwana przez specjalistów „h2c smuggling”. H2c jest ustalonym skrótem protokołu dla HTTP/2 inicjowanym przez nagłówek aktualizacji HTTP/1.1 przesłany komunikacją cleartext. Atak ma miejsce, gdy haker używa h2c do wysyłania żądań do serwera pośredniczącego (znanego jako serwer proxy), która może następnie ominąć kontrolę dostępu do serwera.
Konsekwencje? Hakerzy mogą uzyskać dostęp do punktów końcowych sieci, a tym samym użytkowników lub witryn internetowych. Dzieje się tak dla tego, ponieważ zdobywają dostęp do backendu.
Kto jest narażony na h2c smuggling? Bishop Fox – firma zajmująca się bezpieczeństwem, która odkryła tę nową formę ataku – znalazła podatne na atak serwery u wielu swoich klientów. Podatność dotyczy „dowolnych” serwerów proxy, dlatego liczba podatnych na atak organizacji będzie bardzo duża.
Wydaje się, że luka w zabezpieczeniach może mieć tak duży zakres wpływu, ponieważ może dotyczyć„ dowolnego ”serwera proxy (w tym tych końcowych /api/ lub /payments/).
Konsumenci nie są bezpośrednio narażeni na atak h2c smuggling. Jednak należy pamiętać, że może dojść do nieuprawnionego dostępu do ich danych lub działań podejmowanych na ich kontach. Pamiętajmy, że przestępcy zdobywają dostęp do backendu.
Jak powstrzymać h2c smuggling? Jak dotąd istnieją dwie metody powstrzymania takiego ataku. Upoważnić WebSockety do wspierania wyłącznie zaktualizowanych nagłówków HTTP/1.1. Druga metoda opiera się na wyłączenie obsługi WebSocket’ów i przesyłania dalej tych problematychych headerów.
Bishop Fox udostępniło narzędzie umożliwiające weryfikację, czy organizacja jest narażona na atak h2c smuggling. Więcej informacji można znaleźć w ich repozytorium GitHub tutaj.
4. Atak BlindSide umożliwia obejście zabezpieczenia ASLR procesorów
Naukowcy opracowali nową technikę atakowania bezpiecznych systemów komputerowych. Polega ona na nadużywaniu funkcji spekulatywnego wykonywania, która służy zwiększaniu wydajności procesora. Atak BlindSide wykorzystuje ją do omijania mechanizmów obronnych systemu operacyjnego.
Na trop BlindSide wpadli naukowcy ze Stevens Institute of Technology w New Jersey, ETH Zurich i Vrije University w Amsterdamie. Twierdzą, że technikę tę można wykorzystać do tworzenia exploitów, które omijają zabezpieczenia ASLR w nowoczesnych systemach operacyjnych.
ASLR (Address Space Layout Randomization) to mechanizm randomizacji układu przestrzeni adresowej, który chroni system przed przepełnieniem bufora na skutek wykorzystania exploita w systemie. Zabezpiecza wszystkie działające procesy w pamięci RAM przed ich zlokalizowaniem przez złośliwy kod. Mechanizm ten wykorzystują również programy antywirusowe do automatycznego zabezpieczenia swoich procesów.
Atakujący musi znać adresy pamięci. Jeśli wie, gdzie aplikacja wykonuje swój kod, to może dostroić swoje exploity w taki sposób, aby atakowały określone aplikacje i wykradały poufne aplikacje.
Dwie techniki ataku
Ominięcie ASLR to nie lada wyzwanie. Atakujący musi najpierw znaleźć lukę typu „wyciek informacji o pamięci” lub sondować pamięć i odnaleźć właściwą lokalizację, w której działa inna aplikacja. Następnie musi zmodyfikować kod, aby wskazać tę podatną na atak przestrzeń adresową pamięci. Obie techniki są trudne do zrealizowania, szczególnie druga, która może doprowadzić do awarii systemu lub szybko zaalarmować antywirusy.
Atak BlindSide działa poprzez przeniesienie tego sondującego zachowania w sferę spekulatywnego wykonania. Według naukowców, ten sam proces, który służy do przyspieszania działania procesorów może więc podnieść wagę typowych luk w oprogramowaniu. Takich jak błędy uszkodzenia pamięci, poprzez przeprowadzenie sondowania spekulatywnego. W efekcie BlindSide wykorzystuje lukę w aplikacji i sonduje pamięć z użyciem wykonywania spekulatywnego, do momentu aż uda mu się ominąć ASLR.
Ponieważ ten atak ma miejsce w sferze wykonywania spekulatywnego, wszystkie nieudane sondy i awarie nie wpływają na procesor ani na jego stabilność w czasie ich trwania. Są jedynie tłumione i odrzucane.
Na poniższym wideo, naukowcy prezentują kilka prostych kroków użycia podatności na przykładzie pojedynczego przepełnienia bufora w jądrze Linuxa.
BlindSide skutecznie umożliwia więc atakującym „hakowanie na ślepo” bez konieczności martwienia się o ASLR. Technika działa niezależnie od architektury, dotyczy więc zarówno procesorów Intel, jak i AMD. W dodatku jest możliwa pomimo poprawek wprowadzonych przez producentów przeciwko wcześniejszym atakom spekulacyjnym Spectre i Meltdown.