Firma Huntress zajmująca się cyberbezpieczeństwem wydała poważny alert dotyczący powszechnego naruszenia bezpieczeństwa urządzeń SonicWall SSL VPN, ostrzegając, że osoby odpowiedzialne za zagrożenia wykorzystują ważne dane uwierzytelniające — a nie ataki brute-force — aby uzyskać szybki dostęp do wielu kont w różnych środowiskach.
„Od 10 października firma Huntress zaobserwowała powszechne naruszenie bezpieczeństwa urządzeń SonicWall SSLVPN w wielu środowiskach klientów. Osoby odpowiedzialne za zagrożenia szybko uwierzytelniają się na wielu kontach na naruszonych urządzeniach” — czytamy w ich komunikacie.
- Huntress donosi, że od 4 października ponad 100 kont SonicWall SSL VPN należących do 16 klientów zostało zhakowanych — wszystkie przy użyciu ważnych danych uwierzytelniających, a nie metod brute force.
- W wielu przypadkach atakujący logowali się z adresu IP 202.155.8[.]73 (lub powiązanych adresów).
- Niektórzy atakujący szybko się rozłączali (co sugeruje próby rozpoznania lub „sondowania”), podczas gdy inni przechodzili do fazy po eksploatacji: skanowania sieci wewnętrznych, sondowania kont Windows, ruchu bocznego i dodatkowego naruszenia bezpieczeństwa.
- Tempo tych ataków, w tym udanych logowań pomimo MFA w niektórych przypadkach, skłoniło niektórych obrońców do spekulacji na temat luki typu zero-day — chociaż SonicWall i inni odrzucili tę interpretację.
Większość uwagi śledczych skupia się obecnie na CVE-2024-40766, znanej luce wpływającej na SSL VPN firmy SonicWall (szczególnie w urządzeniach migrowanych z Gen 6 do Gen 7) oraz nieprawidłowych konfiguracjach kont użytkowników i domyślnych uprawnień LDAP.
CVE-2024-40766 jest sklasyfikowany jako nieprawidłowa słabość kontroli dostępu i otrzymał ocenę CVSS v3 wynoszącą 9,3, co wskazuje na krytyczny poziom zagrożenia.
Luka staje się szczególnie niebezpieczna, gdy lokalne konta użytkowników (np. konta administracyjne lub SSL VPN) są przenoszone podczas migracji zapory z Gen 6 do Gen 7 bez resetowania haseł. Atakujący mogą wykorzystać pozostałe zaufanie do tych niezmienionych kont.
W pewnych okolicznościach CVE-2024-40766 może umożliwić dostęp do chronionych zasobów, a nawet spowodować awarię zapory sieciowej pod obciążeniem lub w wyniku wprowadzenia nieprawidłowych danych.
Firma SonicWall stwierdza obecnie z „dużą pewnością”, że ostatnia fala ataków nie jest wynikiem nowego ataku typu zero-day, ale jest „znacząco powiązana” z luką CVE-2024-40766 i niewłaściwym wykorzystaniem poświadczeń.
Jednak firmy zajmujące się bezpieczeństwem nadal debatują, czy dodatkowe luki w zabezpieczeniach lub techniki ataku (np. kradzież nasion OTP, nieprawidłowo skonfigurowane grupy domyślne) również mogą odgrywać rolę.
Oprócz luki CVE-2024-40766, atakujący rzekomo wykorzystują nieprawidłowe konfiguracje i słabe ustawienia domyślne w instalacjach SonicWall:
- Domyślne przypisanie grupy LDAP: w niektórych konfiguracjach użytkownicy, którzy pomyślnie przeszli uwierzytelnianie LDAP, są automatycznie przypisywani do lokalnej grupy przyznającej uprawnienia SSL VPN lub administratora — nawet jeśli nie powinni ich mieć. Atakujący wykorzystują to do podwyższenia poziomu dostępu.
- Błędne konfiguracje Virtual Office (portalu SSL VPN): Błędy w konfiguracji tego interfejsu pozwalają osobom stanowiącym zagrożenie na wyłączenie lub zmianę konfiguracji MFA (np. powiązań TOTP) na kontach, które już częściowo zostały przejęte.
- Kradzież seed OTP / ominięcie MFA: Nawet konta chronione przez jednorazowe hasło czasowe (TOTP) MFA zostały podobno przejęte — co sugeruje, że atakujący mogli pozyskać nasiona lub zresetować MFA za pośrednictwem portalu.
- Niektóre raporty sugerują, że w pełni zaktualizowane urządzenia, nawet po zmianie danych uwierzytelniających, zostały przejęte — co podsyca spekulacje na temat nieznanych jeszcze luk w zabezpieczeniach.
Szerszy zakres naruszenia wykracza poza sieci VPN SSL. Firma SonicWall potwierdziła, że problem dotknął wszystkich użytkowników usługi kopii zapasowych w chmurze MySonicWall — co stanowi znaczną zmianę w stosunku do wcześniejszych publicznych oświadczeń, zgodnie z którymi problem dotyczył mniej niż 5% klientów.
Naruszenie dotyczyło konfiguracji zapory sieciowej i plików kopii zapasowych, które zawierają reguły sieciowe, zasady dostępu, ustawienia VPN, poświadczenia usług (LDAP, RADIUS, SNMP) oraz poświadczenia administratora, jeśli były przechowywane w tych konfiguracjach.
Mimo że pliki były zaszyfrowane, osoby atakujące mogą nadal wykorzystać ujawnione informacje do ustalenia topologii sieci, wykorzystania znanych słabych danych uwierzytelniających lub przeprowadzenia ukierunkowanych ataków, korzystając z wewnętrznej wiedzy na temat wdrożonych zasad i konfiguracji.
Początkowo firma SonicWall twierdziła, że problem dotknął mniej niż 5% klientów i że nie doszło do wycieku żadnych plików. Jednak dalsze dochodzenie zmusiło ją do bardziej radykalnego przyznania się do winy.
Wszystkim użytkownikom MySonicWall zaleca się:
- Zalogowanie się i sprawdzenie, czy włączono kopie zapasowe w chmurze. Jeśli nie, ryzyko jest mniejsze.
- Zidentyfikowanie wszystkich oznaczonych numerów seryjnych wskazujących na zapory, do których kopii zapasowych uzyskano dostęp.
- Zaimportować nowe pliki preferencji (proces, który resetuje dane uwierzytelniające) — należy jednak pamiętać, że spowoduje to zakłócenie działania sieci VPN IPSec, powiązań TOTP i dostępu użytkowników. Użytkownicy muszą ponownie skonfigurować klucze wstępne VPN, zresetować rejestrację TOTP, a następnie zresetować hasła użytkowników.
- Import należy przeprowadzić w czasie okien serwisowych lub poza godzinami pracy, ponieważ zapora sieciowa uruchamia się ponownie natychmiast po zaimportowaniu nowego pliku.
- Skorzystaj z zaktualizowanej listy urządzeń, która klasyfikuje zapory sieciowe według priorytetu, aby ustalić kolejność działań naprawczych.
SonicWall i powiązane organy ścigania badają pełny zakres zdarzenia i pracują nad powiadomieniem użytkowników, których dotyczy problem.
- Samo stosowanie poprawek nie wystarczy: wiele udanych ataków wynikało z ponownego wykorzystania danych uwierzytelniających, nieaktualnych kont i zaniedbanego resetowania haseł — zwłaszcza podczas migracji zapór sieciowych.
- Uwierzytelnianie wieloskładnikowe (MFA) ma kluczowe znaczenie, ale nie jest niezawodne: zdolność atakujących do ominięcia MFA (np. poprzez kradzież lub rekonfigurację seedów) wskazuje, że MFA musi być połączone z silną higieną tożsamości i monitorowaniem.
- Ważna jest głęboka ochrona: poleganie wyłącznie na SSL VPN zapory sieciowej jako kontroli obwodowej jest ryzykowne; należy segmentować sieci, egzekwować zasadę minimalnych uprawnień i monitorować ruch wschód-zachód.
- Higiena konfiguracji jest równie ważna jak poprawki kodu: błędne konfiguracje (domyślne przypisanie grup, otwarte portale, nieużywane konta) mogą osłabić systemy, które w innym przypadku zostałyby załatane.
- Zakładaj możliwość naruszenia bezpieczeństwa: biorąc pod uwagę tempo, w jakim ataki postępują po naruszeniu bezpieczeństwa, organizacje powinny działać w oparciu o założenie, że dostęp do obwodu może zostać naruszony, i stosować szybkie działania ograniczające, segmentację i reagowanie.
- Widoczność ma kluczowe znaczenie: rejestrowanie w czasie rzeczywistym lub prawie rzeczywistym oraz wykrywanie anomalii są niezbędne do wczesnego wykrywania nieautoryzowanych działań.
- Ekspozycja ekosystemu zwielokrotnia ryzyko: naruszenie bezpieczeństwa kopii zapasowej SonciWall w chmurze zwiększyło powierzchnię zagrożenia — wiedza na temat wewnętrznej zapory ogniowej (konfiguracje, topologia) daje teraz atakującym wgląd do wnętrza.
Zainteresowanych pełnym raportem zapraszamy tutaj: Huntress Threat Advisory: Widespread SonicWall SSLVPN Compromise | Huntress
