Sari la conținut
Braincap
← Toate articolele

CubePilot, lovit prin DNS hijacking: cum „lacătul verde" poate ascunde un atacator

de Claudiu Hulea · IT Management Consultant

Ilustrație a unui atac de tip DNS hijacking care redirecționează traficul spre un server al atacatorului

Pe 24 iulie 2026, producătorul australian de autopiloți pentru drone CubePilot a fost lovit printr-un DNS hijacking: atacatorii au preluat controlul înregistrărilor DNS ale domeniului cubepilot.org, au obținut certificate TLS frauduloase pentru toate subdomeniile și au redirecționat utilizatorii spre serverele lor — cu „lacătul verde“ HTTPS aparent valid. E un caz-manual despre o lecție incomodă: stratul DNS și de domeniu e infrastructură critică, iar HTTPS „valid“ nu garantează că vorbești cu cine crezi.

Pe scurt

  • Cine e CubePilot? Producător de controlere de zbor și autopiloți pentru drone (UAV) folosite în cartografiere, căutare-salvare, agricultură și aplicații de apărare/guvernamentale.
  • Ce s-a întâmplat: DNS hijacking pe cubepilot.org (24 iulie 2026) — înregistrările DNS redirecționate spre infrastructura atacatorului.
  • Agravant: atacatorii au obținut certificate TLS frauduloase care acopereau toate subdomeniile → conexiuni HTTPS „valide“ spre servere controlate de ei (man-in-the-middle).
  • Servicii afectate: portal, forum comunitar, platforma de documentație, servicii OEM, sistemul ERP.
  • Reacție: controlul domeniului a fost redobândit în aceeași zi, certificatele au fost revocate, probele păstrate; serviciile au rămas offline pe durata investigației. Incident raportat la centrul australian de securitate cibernetică (ACSC).

Cum funcționează un DNS hijacking

DNS-ul este „cartea de telefon“ a internetului: traduce un nume (cubepilot.org) într-o adresă de server. Cine controlează înregistrările DNS ale unui domeniu poate trimite toți vizitatorii spre serverul lui, fără să spargă serverul real. Iar dacă atacatorul reușește să și emită certificate TLS pentru domeniu, browserul afișează lacătul și „conexiune sigură“ — deși în spate e serverul atacatorului. Rezultatul: un man-in-the-middle care arată perfect legitim.

Ce putea fi interceptat

  • Credențiale introduse pe 24 iulie pe portal și pe forum.
  • Descărcări de firmware: CubePilot a recomandat să nu se flash-uiască imagini descărcate în 24–25 iulie până la verificarea integrității; firmware-ul de dinainte de 24 iulie rămâne sigur.

Aici e miezul: firmware-ul pentru drone e o componentă de supply chain — o imagine compromisă, servită de pe un server fals, ar ajunge direct pe echipamentele utilizatorilor.

De ce contează pentru tine

  • Atacul e în amonte de infrastructura ta. Nu trebuie să fii „spart“ pe server ca să fii afectat — compromiterea DNS-ului sau a contului de registrar ocolește toate apărările din aplicație.
  • Lacătul HTTPS nu garantează identitatea dacă atacatorul poate emite certificate proprii pentru domeniu. Încrederea vizuală („e https, deci e ok“) e insuficientă.
  • Firmware/artefacte compromise = un canal direct de supply chain spre clientul final.

Ce ai de făcut

Dacă ești utilizator CubePilot:

  1. Schimbă-ți parolele, mai ales dacă le-ai reutilizat în altă parte.
  2. Nu flash-ui firmware descărcat în 24–25 iulie; folosește doar imagini verificate.
  3. Verifică telefonic orice cerere de plată, cu un contact cunoscut.

Lecții pentru orice organizație cu domeniu propriu:

  1. Protejează contul de registrar și DNS — 2FA, „registrar lock“, și DNSSEC acolo unde e posibil.
  2. Monitorizează certificatele emise pe domeniile tale prin Certificate Transparency — un certificat nou, neașteptat, e un semnal de alarmă.
  3. Semnează firmware-ul și artefactele și publică semnături/hash-uri, ca utilizatorii să poată verifica integritatea independent de canalul de descărcare.
  4. Alertează la schimbări DNS — modificările de înregistrări ar trebui să declanșeze notificări.

Ce reținem

DNS-ul și registrarul stau la baza identității tale online — sunt „cheile regatului“, iar compromiterea lor trece pe lângă tot ce ai construit la nivel de aplicație. Apărările reale sunt în amonte: registrar lock + DNSSEC, monitorizarea Certificate Transparency și semnarea artefactelor. Un audit de securitate verifică exact aceste puncte — configurația de domeniu, DNS și lanțul de livrare — iar un test de penetrare confirmă unde te-ar putea prinde un atacator.

Surse

Întrebări frecvente

Ce s-a întâmplat cu CubePilot?

Pe 24 iulie 2026, producătorul de autopiloți pentru drone CubePilot a fost lovit printr-un DNS hijacking: atacatorii au preluat înregistrările DNS ale domeniului cubepilot.org, au obținut certificate TLS frauduloase pentru toate subdomeniile și au redirecționat utilizatorii spre serverele lor, cu „lacătul verde" HTTPS aparent valid (man-in-the-middle).

De ce nu e suficient „lacătul verde" HTTPS?

Pentru că lacătul confirmă doar o conexiune criptată, nu identitatea reală a serverului. Dacă atacatorul controlează DNS-ul și poate emite certificate proprii pentru domeniu, browserul afișează „conexiune sigură" deși în spate e serverul lui. Încrederea vizuală („e https, deci e ok") e insuficientă.

De ce mă privește, chiar dacă nu sunt client CubePilot?

Pentru că atacul e în amonte de infrastructura ta: compromiterea DNS-ului sau a contului de registrar ocolește toate apărările din aplicație — nu trebuie să fii „spart" pe server ca să fii afectat. Orice organizație cu domeniu propriu are aceeași expunere.

Cum îmi protejez domeniul de DNS hijacking?

Protejează contul de registrar și DNS (2FA, registrar lock, DNSSEC), monitorizează certificatele emise pe domeniile tale prin Certificate Transparency (un certificat nou neașteptat e un semnal de alarmă), semnează firmware-ul și artefactele cu semnături/hash-uri publicate, și alertează la orice schimbare a înregistrărilor DNS.