Atak DNS hijacking na CubePilot: przejęcie domeny zakłóciło usługi producenta oprogramowania dla dronów - Security Bez Tabu

Atak DNS hijacking na CubePilot: przejęcie domeny zakłóciło usługi producenta oprogramowania dla dronów

Cybersecurity news

Wprowadzenie do problemu / definicja

DNS hijacking to rodzaj ataku, w którym napastnik przejmuje kontrolę nad konfiguracją domeny lub infrastrukturą odpowiedzialną za tłumaczenie nazw na adresy IP. W praktyce pozwala to przekierować użytkowników do systemów kontrolowanych przez atakującego, mimo że wpisują oni poprawny adres usługi. Incydent dotyczący CubePilot pokazuje, że skutki takiego przejęcia mogą wykraczać daleko poza niedostępność serwisu i obejmować przechwytywanie poświadczeń, podszywanie się pod legalne usługi oraz potencjalne ryzyko naruszenia łańcucha dostaw oprogramowania.

W skrócie

CubePilot, australijski producent kontrolerów lotu i rozwiązań autopilota dla bezzałogowych statków powietrznych, poinformował o poważnym incydencie bezpieczeństwa związanym z przejęciem ustawień DNS swojej domeny. Według ujawnionych informacji atakujący uzyskał kontrolę nad konfiguracją DNS 24 lipca 2026 roku, co umożliwiło przechwytywanie ruchu kierowanego do wewnętrznych i publicznych usług firmy.

Dodatkowo napastnik miał pozyskać certyfikaty TLS obejmujące subdomeny organizacji, dzięki czemu użytkownicy mogli widzieć poprawne połączenie HTTPS mimo przekierowania na infrastrukturę kontrolowaną przez osobę nieuprawnioną. W odpowiedzi firma przywróciła kontrolę nad domeną, unieważniła nieautoryzowane certyfikaty, wyłączyła część usług i rozpoczęła analizę integralności obrazów firmware.

  • przejęcie konfiguracji DNS domeny producenta
  • możliwość przekierowania ruchu do fałszywej infrastruktury
  • pozyskanie certyfikatów TLS dla subdomen
  • czasowe wyłączenie wybranych usług i portali
  • ostrzeżenie dotyczące firmware pobranego 24 i 25 lipca 2026 roku

Kontekst / historia

CubePilot działa w segmencie UAV i dostarcza rozwiązania wykorzystywane między innymi w zastosowaniach przemysłowych, ratowniczych, rolniczych oraz administracyjnych. Z tego powodu incydent ma znaczenie nie tylko dla warstwy webowej, lecz także dla środowisk, w których bezpieczeństwo, integralność oprogramowania i ciągłość działania odgrywają kluczową rolę.

Z opublikowanych informacji wynika, że problem został wykryty po przejęciu ustawień DNS domeny organizacji. Firma wskazała, że zdarzenie miało miejsce 24 lipca 2026 roku i mogło objąć ruch kierowany do wielu usług działających w ramach subdomen. W ramach działań zapobiegawczych wyłączono między innymi usługi OEM, forum społeczności oraz portal dokumentacji. Tymczasowo odłączono także portal ERP, a użytkownikom zalecono, aby nie instalowali obrazów firmware pobranych 24 i 25 lipca 2026 roku do czasu zakończenia weryfikacji.

Analiza techniczna

Technicznie incydent ten stanowi klasyczny przykład sytuacji, w której kompromitacja warstwy DNS pozwala obejść zaufanie użytkownika do nazwy domenowej. Jeżeli napastnik przejmie konto u rejestratora, dostęp do dostawcy DNS albo mechanizm aktualizacji strefy, może zmodyfikować rekordy tak, aby domena i jej subdomeny wskazywały na kontrolowaną przez niego infrastrukturę.

W takim scenariuszu legalny ruch HTTP, HTTPS, API, pocztowy lub portalowy może zostać przekierowany bez wiedzy użytkownika. Szczególnie niebezpieczne w przypadku CubePilot jest to, że atakujący miał uzyskać poprawnie wystawione certyfikaty TLS dla subdomen. To oznacza, że użytkownicy nie musieli widzieć ostrzeżeń o błędnym certyfikacie, a przeglądarka mogła sygnalizować bezpieczne połączenie mimo trwającego ataku.

Takie połączenie przejęcia DNS i legalnie wyglądającego HTTPS znacząco zwiększa skuteczność operacji. Umożliwia bowiem przechwytywanie loginów, haseł, tokenów sesyjnych, danych operacyjnych, a także plików przesyłanych do portali producenta. W praktyce ofiara może nie zauważyć żadnych nietypowych objawów, ponieważ zarówno adres usługi, jak i warstwa szyfrowania sprawiają wrażenie prawidłowych.

Ryzyko rośnie jeszcze bardziej, gdy przejęte usługi odpowiadają za dystrybucję firmware, dokumentacji technicznej, aktualizacji lub artefaktów dla partnerów OEM. W takim modelu atak może stać się punktem wejścia do incydentu typu supply chain, jeśli użytkownicy pobiorą zmanipulowane obrazy, skrypty, paczki lub konfiguracje. Z tego względu ostrzeżenie dotyczące firmware pobranego w określonym przedziale czasu należy traktować jako poważny sygnał potencjalnej ekspozycji procesu aktualizacji.

W szerszym ujęciu DNS hijacking często wiąże się z przejęciem kont administracyjnych bez silnego MFA, phishingiem wymierzonym w operatorów domen, kompromitacją dostawcy usług DNS, nadużyciem procedur odzyskiwania dostępu albo problemami w procesie walidacji kontroli domeny przy wystawianiu certyfikatów. Z perspektywy detekcji jest to wyjątkowo wymagający scenariusz, ponieważ klasyczne systemy monitoringu aplikacji nie zawsze wykryją sam moment przekierowania, jeśli problem pojawia się jeszcze przed warstwą aplikacyjną.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem incydentu jest możliwość przejęcia poświadczeń wpisywanych do portali objętych atakiem w okresie kompromitacji. Jeśli użytkownicy wykorzystywali te same hasła również w innych usługach, zdarzenie może prowadzić do wtórnych naruszeń kont, eskalacji dostępu oraz dalszych kampanii phishingowych.

Drugim istotnym obszarem ryzyka pozostaje integralność oprogramowania i komponentów dystrybuowanych przez producenta. W środowiskach związanych z UAV nawet ograniczone wątpliwości dotyczące autentyczności firmware mogą mieć znaczenie operacyjne, ponieważ wpływają na bezpieczeństwo urządzeń, telemetrię, nawigację i procesy utrzymaniowe.

Trzecią konsekwencją są zakłócenia biznesowe. Wyłączenie portali, dokumentacji, forum i systemów wspierających partnerów przekłada się na obsługę klientów, wsparcie techniczne, aktualizacje oraz komunikację z ekosystemem integratorów. W przypadku producentów działających w segmentach o podwyższonej wrażliwości taki incydent może również skutkować utratą zaufania, koniecznością szerokiej rotacji sekretów, rewalidacją artefaktów oraz dodatkowymi obowiązkami związanymi z analizą powłamaniową.

Rekomendacje

Organizacje zarządzające własnymi domenami powinny traktować infrastrukturę DNS i konta u rejestratora jako zasoby krytyczne. W praktyce oznacza to wdrożenie odpornego na phishing MFA dla wszystkich kont administracyjnych, ograniczenie liczby administratorów, separację ról oraz stałe monitorowanie zmian w rekordach DNS, delegacjach i danych rejestrowych.

  • włączyć MFA dla wszystkich kont związanych z rejestratorem i usługami DNS
  • stosować registrar lock oraz ścisłą kontrolę procesu zmian
  • uruchomić alertowanie dla każdej modyfikacji strefy DNS i danych domeny
  • monitorować logi Certificate Transparency pod kątem nieautoryzowanych certyfikatów
  • utrzymywać zaufane kopie konfiguracji i procedury szybkiego odtwarzania rekordów
  • podpisywać kryptograficznie firmware i inne artefakty publikowane dla klientów
  • zapewnić niezależną weryfikację sum kontrolnych oraz możliwość natychmiastowego wycofania zaufania do podejrzanych wersji
  • po incydencie przeprowadzić rotację haseł, kluczy API, tokenów i certyfikatów

Dla klientów i partnerów równie ważna jest jasna komunikacja operacyjna. Organizacja powinna precyzyjnie wskazać, które usługi mogły zostać objęte incydentem, jakie przedziały czasowe są uznawane za ryzykowne, które hasła należy zresetować i jakie pliki wymagają ponownej walidacji przed użyciem w środowisku produkcyjnym.

Podsumowanie

Incydent CubePilot potwierdza, że przejęcie DNS pozostaje jednym z najbardziej niebezpiecznych scenariuszy ataku na internetową warstwę zaufania. Gdy kompromitacji towarzyszy wystawienie poprawnych certyfikatów TLS, użytkownik końcowy ma bardzo ograniczone możliwości samodzielnego wykrycia oszustwa.

W organizacjach dostarczających oprogramowanie, firmware i usługi dla urządzeń podłączonych do sieci skutki takiego zdarzenia mogą obejmować nie tylko kradzież poświadczeń, ale również zakłócenie łańcucha dostaw i podważenie integralności publikowanych komponentów. Dlatego bezpieczeństwo domen, rejestratora, DNS oraz procesu wydawania certyfikatów powinno być traktowane na równi z ochroną systemów produkcyjnych.

Źródła

  1. CubePilot drone software dev hit by DNS hijacking to intercept traffic — https://www.bleepingcomputer.com/news/security/cubepilot-drone-software-dev-hit-by-dns-hijacking-to-intercept-traffic/
  2. Ongoing DNS hijacking and mitigation advice — https://www.ncsc.gov.uk/news/ongoing-dns-hijacking-and-mitigation-advice
  3. APT28 exploit routers to enable DNS hijacking operations — https://www.ncsc.gov.uk/news/apt28-exploit-routers-to-enable-dns-hijacking-operations
  4. Domain Name System Security for Domain Owners — https://www.cyber.gov.au/sites/default/files/2023-03/PROTECT%20-%20Domain%20Name%20System%20Security%20for%20Domain%20Owners%20%28October%202021%29.pdf
  5. Cyber security incident response planning: Executive guidance — https://www.cyber.gov.au/business-government/detecting-responding-to-threats/cyber-security-incident-response/cyber-security-incident-response-planning-executive-guidance