Krytyczne luki w Unitree G1 pozwalają na zdalne przejęcie robota i atak łańcuchowy - Security Bez Tabu

Krytyczne luki w Unitree G1 pozwalają na zdalne przejęcie robota i atak łańcuchowy

Cybersecurity news

Wprowadzenie do problemu / definicja

Bezpieczeństwo robotów humanoidalnych i innych platform cyber-fizycznych staje się jednym z najważniejszych obszarów współczesnego cyberbezpieczeństwa. Przypadek Unitree G1 pokazuje, że połączenie błędów w komunikacji bezprzewodowej, usługach lokalnych oraz logice chmurowej może doprowadzić nie tylko do przejęcia pojedynczego urządzenia, ale także do dalszego rozprzestrzeniania ataku w środowisku operacyjnym.

W praktyce oznacza to, że robot przestaje być wyłącznie urządzeniem końcowym, a staje się aktywnym elementem powierzchni ataku. W środowiskach badawczych, przemysłowych i testowych taki scenariusz może mieć wpływ zarówno na bezpieczeństwo cyfrowe, jak i fizyczne.

W skrócie

Badania wykazały dwa łańcuchy podatności, które po połączeniu umożliwiają uzyskanie nieautoryzowanego dostępu root do robota Unitree G1. Atak obejmuje wykorzystanie słabo zabezpieczonej komunikacji BLE, błędów po stronie usług chmurowych, możliwości manipulacji konfiguracją sieciową oraz lokalnych podatności prowadzących do wykonania kodu.

  • możliwe jest zdalne przejęcie urządzenia bez pełnej autoryzacji właściciela,
  • atak może prowadzić do uzyskania uprawnień root,
  • przejęty robot może posłużyć do atakowania kolejnych urządzeń w pobliżu,
  • ryzyko obejmuje nie tylko dane, ale także bezpieczeństwo operacyjne i fizyczne.

Kontekst / historia

Roboty mobilne i humanoidalne trafiają dziś do laboratoriów, uczelni, centrów R&D, hal testowych i środowisk przemysłowych. Wraz ze wzrostem ich możliwości rośnie również złożoność architektury: aplikacje mobilne, backendy chmurowe, moduły AI, interfejsy radiowe oraz lokalne usługi systemowe tworzą rozbudowany ekosystem podatny na błędy projektowe i implementacyjne.

W opisywanym przypadku badacz bezpieczeństwa analizował Unitree G1 przez około trzy miesiące. Efektem były dwa zgłoszenia podatności oznaczone jako CVE-2026-76639 oraz CVE-2026-76640. Według dostępnych informacji część problemów została zaadresowana po stronie chmury, natomiast kwestie związane z firmware, BLE i lokalną logiką usług mogą wymagać głębszych zmian architektonicznych.

Analiza techniczna

Pierwszy wektor ataku dotyczył lokalnej usługi chatbota AI działającej na robocie. Mechanizm przesyłania plików typu knowledge nie zapewniał wystarczającej walidacji nazw plików, co otwierało drogę do ataku typu path traversal. W rezultacie atakujący mógł zapisać plik w wybranej lokalizacji systemu, także w katalogach wykorzystywanych przez usługi uruchamiane z wysokimi uprawnieniami.

W praktyce tworzyło to warunki do wykonania złośliwego kodu jako root. Tego rodzaju podatność jest szczególnie niebezpieczna w urządzeniach, które lokalnie uruchamiają skrypty, obsługują automatyzację lub przetwarzają dane pochodzące z wielu komponentów jednocześnie.

Drugi, bardziej zaawansowany łańcuch rozpoczynał się od komunikacji Bluetooth Low Energy. Badacz ustalił, że jedna z charakterystyk BLE akceptowała zapis bez uprzedniego parowania. Umożliwiało to pobranie zaszyfrowanego materiału wykorzystywanego w procesie ustanawiania zaufania. Problem pogłębiał fakt, że infrastruktura chmurowa odszyfrowywała taki materiał dla zalogowanego konta bez skutecznego sprawdzenia, czy użytkownik faktycznie jest właścicielem konkretnego robota.

Po uzyskaniu klucza AES atakujący mógł przejść przez mechanizm uwierzytelnienia BLE i odblokować komendy odpowiedzialne za konfigurację Wi‑Fi. Następnie wykorzystywany był błąd w skrypcie konfiguracyjnym, który przyjmował zbyt długie lub specjalnie spreparowane dane bez odpowiedniego oczyszczania. To pozwalało wymusić podłączenie robota do sieci kontrolowanej przez napastnika.

Kolejny etap obejmował przepełnienie bufora w serwerze Bluetooth. Zastosowanie starannie przygotowanego ładunku umożliwiało nadpisanie struktur pamięci i doprowadzenie do wykonania poleceń z uprawnieniami root. Choć mechanizmy ochronne utrudniały exploitację, informacje pozyskane z pierwszego łańcucha podatności zwiększały jej skuteczność i stabilność.

Najpoważniejszym elementem całego scenariusza jest zdolność do ruchu bocznego. Po przejęciu jednego Unitree G1 może on zostać wykorzystany jako punkt wyjścia do atakowania kolejnych robotów tego samego typu znajdujących się w zasięgu BLE. To nadaje incydentowi cechy ataku łańcuchowego i znacząco zwiększa jego potencjalny zasięg.

Konsekwencje / ryzyko

W przypadku robotów humanoidalnych skutki podatności nie ograniczają się do klasycznej utraty poufności, integralności lub dostępności. Dochodzi również komponent bezpieczeństwa fizycznego. Przejęte urządzenie może zostać użyte do podsłuchu, monitoringu otoczenia, manipulacji logiką działania albo zakłócania procesów realizowanych w jego otoczeniu.

  • utrata integralności systemu sterowania,
  • ekspozycja danych z kamer, mikrofonów i innych sensorów,
  • sabotaż operacyjny w laboratoriach i środowiskach testowych,
  • propagacja ataku na kolejne urządzenia,
  • zagrożenie dla ludzi i mienia wynikające z nieprzewidywalnego zachowania robota.

Z perspektywy zespołów bezpieczeństwa to czytelny przykład zacierania granic między IT, IoT, OT i safety. Ocena ryzyka dla takich platform musi obejmować nie tylko dane i usługi, ale także skutki kinetyczne oraz wpływ na ciągłość procesów fizycznych.

Rekomendacje

Organizacje wykorzystujące Unitree G1 lub podobne platformy robotyczne powinny wdrożyć podejście defense-in-depth obejmujące zarówno zabezpieczenia techniczne, jak i procedury operacyjne.

  • zweryfikować status poprawek firmware, aplikacji mobilnej i komponentów chmurowych,
  • ograniczyć fizyczny oraz radiowy dostęp do robotów, zwłaszcza w przestrzeniach współdzielonych,
  • segmentować sieć urządzeń robotycznych i odseparować ją od systemów biurowych oraz zasobów krytycznych,
  • monitorować komunikację BLE, Wi‑Fi i ruch wychodzący pod kątem anomalii,
  • wyłączyć lub ograniczyć nieużywane usługi lokalne, szczególnie te wykonujące skrypty,
  • wdrożyć kontrolę integralności plików i konfiguracji,
  • przeprowadzić przegląd modeli zagrożeń dla urządzeń cyber-fizycznych,
  • opracować procedury reagowania obejmujące izolację robota i bezpieczne zatrzymanie pracy.

Warto również rozważyć audyty bezpieczeństwa i testy red team dedykowane robotyce. Tradycyjne skanowanie podatności często nie obejmuje całego łańcucha zależności między aplikacją mobilną, protokołami radiowymi, backendem chmurowym i firmware urządzenia.

Podsumowanie

Incydent dotyczący Unitree G1 pokazuje, że nowoczesne roboty stają się pełnoprawnym celem zaawansowanych ataków. Połączenie błędów w BLE, usługach chmurowych i komponentach lokalnych umożliwiło zdalne uzyskanie uprawnień root oraz stworzyło warunki do dalszego rozprzestrzeniania się zagrożenia.

Dla organizacji wdrażających robotykę to wyraźny sygnał, że takie platformy należy traktować jak krytyczne elementy infrastruktury. Odpowiedzialne zarządzanie bezpieczeństwem robotów musi obejmować zarówno warstwę cyber, jak i potencjalny wpływ na bezpieczeństwo fizyczne otoczenia.

Źródła

  1. Security Affairs — Hack One Robot, Reach the Next: Unitree G1 Security Flaws — https://securityaffairs.com/198085/hacking/hack-one-robot-reach-the-next-unitree-g1-security-flaws.html
  2. The Hacker News — Researchers Uncover Wormable Exploits in Unitree G1 Humanoid Robot — https://thehackernews.com/