Luki w SonicWall SMA 1000 i atak na DNS

Dwa poważne incydenty, jeden wspólny mianownik

Początek października 2026 roku przyniósł dwie głośne informacje ze świata bezpieczeństwa. Z jednej strony SonicWall wydał poprawki dla urządzeń SMA 1000, w których wykryto kilka luk, w tym jedną ocenioną na CVSS 10.0. Z drugiej — ujawniono atak na trzy rejestry domen krajowych, który umożliwił wystawienie nieautoryzowanych certyfikatów HTTPS dla części domen Google i YouTube.

Oba przypadki pokazują, jak duże znaczenie mają dziś DNS, certyfikaty i zaufanie do infrastruktury sieciowej. Gdy te elementy zostaną naruszone, atakujący mogą podszyć się pod legalne usługi albo uzyskać dostęp do funkcji, które normalnie są zablokowane.

SonicWall SMA 1000: krytyczna luka przed uwierzytelnieniem

SonicWall poinformował o czterech podatnościach w rodzinie Secure Mobile Access (SMA) 1000. To rozwiązanie klasy enterprise służące do zdalnego dostępu, ZTNA i połączeń VPN w środowiskach hybrydowych oraz lokalnych.

Najgroźniejsza z luk to CVE-2026-102255. Otrzymała ona CVSS 10.0 i dotyczy błędu typu pre-authentication SSRF w interfejsie Work Place. W praktyce oznacza to, że zdalny, nieuwierzytelniony napastnik mógłby zmusić urządzenie do wykonywania żądań w swoim imieniu i dotrzeć do funkcji wewnętrznych, a następnie wykonać nieautoryzowane operacje.

Pozostałe błędy to:

• CVE-2026-102256 — post-authentication Remote Code Execution przez OS Command Injection;
• CVE-2026-102257 — post-authentication Zip Slip, pozwalający wypakować pliki poza docelowy katalog;
• CVE-2026-102258 — post-authentication stored XSS w konsoli zarządzania.

Kto powinien zareagować

Podatności dotyczą modeli SMA 6210, 7210 oraz 8200v w określonych wersjach firmware:

• 12.4.3-03526 i starszych,
• 12.5.0-02952 i starszych.

Producent udostępnił już poprawione wersje:

• 12.4.3-03670 i nowsze,
• 12.5.0-03082 i nowsze.

Na moment publikacji nie potwierdzono aktywnej eksploatacji tych luk, ale rekomendacja jest jednoznaczna: aktualizacja powinna zostać wykonana jak najszybciej.

Przejęte rejestry DNS i fałszywe certyfikaty dla Google

Równolegle ujawniono atak, w którym napastnicy przejęli trzy rejestry krajowych domen najwyższego poziomu: .gh, .sl i .as. Chodzi odpowiednio o domeny związane z Ghaną, Sierra Leone i Samoa Amerykańskim.

W wyniku tej operacji udało się uzyskać nieautoryzowane certyfikaty HTTPS dla części nazw związanych z Google i YouTube, w tym m.in. dla domen takich jak:

• google.com.gh,
• google.sl,
• google.as.

W publicznych logach Certificate Transparency pojawiło się co najmniej 12 certyfikatów wystawionych między 22 a 27 września. Wystawili je głównie Let’s Encrypt oraz w jednym przypadku ZeroSSL.

Dlaczego to groźne

Taki certyfikat nie oznacza automatycznie włamania do systemów Google. Problem polega na tym, że atakujący, mając certyfikat dla legalnie wyglądającej domeny, może udawać prawdziwą usługę w szyfrowanym połączeniu. To otwiera drogę do przechwytywania danych użytkowników, jeśli ofiara trafi na spreparowaną infrastrukturę.

Google podkreślił, że jego własne systemy nie zostały naruszone. Firma zareagowała jednak szybko: Chrome blokował nieautoryzowane certyfikaty dzięki CRLSet, a wystawiające je urzędy certyfikacji podjęły działania, by je unieważnić.

Jak do tego doszło

Według opisu zdarzenia, certyfikaty zostały wydane po tym, jak napastnicy przejęli rekordy DNS i w ten sposób udowodnili kontrolę nad domenami w oczach urzędów certyfikacji. Nie ma przesłanek, by obarczać winą same CA — działały one zgodnie z procedurą, opierając się na stanie DNS widocznym w danym momencie.

To ważne przypomnienie, że w przypadku ataku na DNS nawet poprawnie działające mechanizmy walidacji mogą zostać chwilowo oszukane.

Co powinni zrobić administratorzy domen

Z całego zdarzenia płyną trzy praktyczne wnioski dla właścicieli domen:

1. Monitorować Certificate Transparency logs dla wszystkich swoich domen, także regionalnych i parkingowych.
2. Ustawić strict CAA record, czyli rekord ograniczający, które CA mogą wystawiać certyfikaty dla danej domeny.
3. Zgłaszać do urzędu certyfikacji każdy certyfikat, którego właściciel nie zamawiał.

Warto przy tym pamiętać, że sam rekord CAA nie zatrzyma certyfikatu wystawionego w trakcie aktywnego hijacku DNS, ale utrudni kolejne nadużycia po odzyskaniu kontroli nad domeną.

Szybka lekcja dla całej branży

W obu opisanych incydentach widać ten sam problem: bezpieczeństwo kończy się tam, gdzie zawodzi zaufana infrastruktura. W przypadku SonicWall chodzi o lukę w urządzeniach brzegowych, a w przypadku przejętych rejestrów domen — o mechanizmy, od których zależy wiarygodność HTTPS.

Dla administratorów wniosek jest prosty: aktualizacje, monitoring CT i ścisła kontrola DNS nie są dodatkiem, ale podstawą obrony.