Badacz bezpieczeństwa ujawnił poważną lukę w chmurze, dotyczącą robotów odkurzających Shark, która mogła pozwolić atakującym na zdalne sterowanie urządzeniami, dostęp do obrazu z wbudowanych kamer, odczyt map domów i pobranie haseł Wi-Fi w postaci jawnego tekstu.
Problem zgłosił badacz posługujący się pseudonimem tokay0, który twierdzi, że lukę testował wyłącznie na odkurzaczach Shark, które sam kupił. Zgodnie z opisem w momencie publikacji badań słabość pozostawała niezałatana.
Najbardziej niepokojące jest to, że ta luka nie opiera się na skomplikowanym exploicie.
Żadnego uszkodzenia pamięci.
Żadnego zgadywania haseł.
Żadnej lokalnej eskalacji uprawnień.
Problem wydaje się natomiast wynikać ze zbyt szerokich uprawnień AWS IoT przypisanych do certyfikatów urządzeń.
Co poszło nie tak
Roboty odkurzające Shark komunikują się z chmurą za pomocą certyfikatów urządzeń.
W prawidłowo zabezpieczonym środowisku IoT każdy certyfikat urządzenia powinien mieć dostęp wyłącznie do tematów i poleceń chmurowych należących do tego konkretnego urządzenia.
Tutaj najwyraźniej tak nie było.
Według badacza certyfikat wyodrębniony z jednego odkurzacza Shark mógł posłużyć do interakcji z innymi odkurzaczami Shark w tym samym regionie AWS. Broker chmurowy akceptował polecenia adresowane do urządzeń innych niż to, do którego należał certyfikat.
Oznacza to, że problem nie leżał tylko w samym robocie.
Tkwił w chmurowym modelu zaufania obejmującym całą flotę urządzeń.
Dlaczego polityka AWS IoT ma znaczenie
AWS IoT obsługuje komunikację na poziomie poszczególnych urządzeń za pomocą tematów (topics) i device shadows.
Device shadow to przechowywany w chmurze dokument stanu, który zawiera informacje o urządzeniu i pozwala usługom chmurowym lub aplikacjom aktualizować jego żądany stan.
W tym przypadku badacz odkrył, że polecenia można umieścić w polu device shadow odczytywanym przez demona zarządzającego odkurzacza. Jeśli docelowy model obsługiwał procedurę obsługi poleceń, robot wykonywał instrukcję.
Główną przyczyną była zbyt liberalna polityka IoT.
AWS udostępnia kontrole audytowe wykrywające tego rodzaju błędy w ramach AWS IoT Device Defender. Jedna z nich oznacza polityki, które zezwalają na szeroki dostęp do $aws/things/* zamiast ograniczać dostęp do konkretnego podłączonego urządzenia.
AWS uznaje ten rodzaj problemu z polityką za krytyczny, ponieważ przejęty certyfikat może potencjalnie dać dostęp do shadows, jobs lub danych wykonania na wielu urządzeniach.
Fizyczny dostęp prowadzi do skutków w chmurze
Badacz twierdzi, że certyfikat można było wyodrębnić z odkurzacza przy użyciu fizycznego dostępu.
Urządzenie udostępniało ścieżki dostępu na poziomie sprzętu, dzięki którym badacz uzyskał powłokę roota i pobrał z systemu plików certyfikat oraz klucz przypisane do danego urządzenia.
Samo to byłoby niepokojące, ale prawdziwe niebezpieczeństwo wynika z tego, co ten certyfikat mógł zrobić później.
Certyfikat zabrany z jednego urządzenia według doniesień stawał się kluczem do interakcji z innymi urządzeniami w tym samym regionie AWS.
Zmienia to lokalną słabość sprzętową w ryzyko dla całej floty na skalę chmury.
Co mógłby zrobić atakujący
Według ujawnionych informacji podatna konfiguracja mogła umożliwiać zdalne wykonywanie poleceń na innych odkurzaczach Shark w tym samym regionie.
Potencjalne skutki obejmują:
- sterowanie robotem
- dostęp do wbudowanej kamery w obsługiwanych modelach
- pobieranie map domu
- wydobywanie haseł Wi-Fi w postaci jawnego tekstu
- uruchamianie poleceń na dotkniętych urządzeniach
- wykorzystanie urządzenia jako przyczółka w sieci domowej
Badacz zademonstrował problem na posiadanych przez siebie modelach, w tym użył certyfikatu jednego urządzenia, aby dotrzeć do innego modelu i uzyskać powłokę zwrotną (reverse shell).
Z oczywistych względów skrypty exploitów zostały wstrzymane, dopóki luka pozostawała aktywna.
Nie każde urządzenie jest „kluczem”
Luka składa się z dwóch odrębnych części.
Niektóre odkurzacze mogą pełnić rolę klucza, ponieważ ich certyfikaty są powiązane ze zbyt szerokimi uprawnieniami w chmurze.
Inne mogą być celem, ponieważ ich oprogramowanie sprzętowe obsługuje procedurę wykonującą instrukcje dostarczane z chmury.
Badacz stwierdził, że nowszy model docelowy miał prawidłowo ograniczony certyfikat, co oznacza, że nie dało się go użyć jako klucza uniwersalnego. Mógł jednak nadal zostać zaatakowany, jeśli użyto słabo ograniczonego certyfikatu innego urządzenia.
To rozróżnienie jest ważne.
Problem niekoniecznie polega na tym, że każdy odkurzacz Shark może odblokować każdy inny odkurzacz Shark. Ryzyko zależy od polityki certyfikatu, regionu oraz tego, czy docelowy model obsługuje podatne zachowanie poleceń.
Ograniczenia regionalne, ale nadal poważny problem
Badacz zauważył jeden czynnik ograniczający: certyfikaty wydają się przypisane do regionu AWS.
Certyfikat wyodrębniony z odkurzacza w jednym regionie dociera tylko do urządzeń obsługiwanych przez ten sam region.
To znacząca granica, ale nie usuwa ona ryzyka.
W obrębie jednego regionu badacz twierdzi, że w ciągu 24 godzin zaobserwował ponad 1,5 mln unikalnych numerów seryjnych Shark. Z nich ponad 670 000 wysyłało odpowiedzi zgodne z obsługą procedury obsługi poleceń.
Liczby te dotyczą zaobserwowanych urządzeń, a nie potwierdzonych przejęć.
Mimo to skala jest znacząca.
Przebieg ujawnienia budzi obawy
Według badacza z firmą SharkNinja skontaktowano się po raz pierwszy w marcu, a szczegóły techniczne otrzymała wkrótce potem.
Firma według doniesień potwierdziła otrzymanie zgłoszenia, a później poinformowała, że jest ono analizowane. Badacz twierdzi, że obiecano mu potwierdzoną datę zakończenia prac do 10 lipca, ale żadna informacja nie nadeszła.
Wyniki opublikował 13 lipca.
W chwili ujawnienia, jak podano, nie było publicznego biuletynu, identyfikatora CVE, wyniku CVSS ani jasnych działań zaradczych dla klientów poza odłączeniem urządzeń od Wi-Fi.
Brak identyfikatora utrudnia zespołom zarządzającym podatnościami śledzenie problemu.
Poprawka jest w większości po stronie serwera
To jeden z najważniejszych elementów tej sprawy.
Natychmiastowa poprawka niekoniecznie wymaga od każdego klienta instalacji nowego oprogramowania sprzętowego.
Najpilniejsze działanie zaradcze wydaje się leżeć w konfiguracji AWS IoT firmy SharkNinja.
Firma może zastąpić zbyt liberalną politykę IoT prawidłowo ograniczoną wersją, która zawęża każdy certyfikat do tożsamości jego własnego urządzenia. AWS obsługuje to za pomocą wersjonowania polityk, co pozwala ustawić poprawioną politykę jako domyślną dla certyfikatów, które z niej korzystają.
W dłuższej perspektywie SharkNinja może też musieć wydać nowe certyfikaty urządzeń i przejrzeć proces provisioningu starszych urządzeń.
Ale pierwszym krokiem powinno być zaostrzenie polityki w chmurze.
Co mogą zrobić właściciele
Indywidualni właściciele mają ograniczone możliwości.
Ponieważ słabość leży głównie w konfiguracji chmury producenta, klienci nie są w stanie w pełni jej naprawić samodzielnie.
Jedynym skutecznym środkiem zaradczym dostępnym dla właścicieli jest odłączenie odkurzacza od Wi-Fi.
Wyłącza to sterowanie przez chmurę, funkcje aplikacji, harmonogramy, mapowanie i dostęp zdalny, ale jednocześnie uniemożliwia robotowi komunikację z podatną infrastrukturą chmurową.
Właściciele powinni również rozważyć:
- zmianę hasła do domowej sieci Wi-Fi, jeśli podejrzewają narażenie
- usunięcie zapisanych map, o ile to możliwe
- przegląd uprawnień aplikacji
- sprawdzenie dostępności aktualizacji oprogramowania sprzętowego
- śledzenie biuletynów producenta
- unikanie pracy z włączoną kamerą w miejscach wrażliwych
Praktyczny problem polega na tym, że większość użytkowników nie dowie się, czy ich urządzenie zostało dotknięte, dopóki producent nie przekaże jasnych wskazówek.
Czego powinni się nauczyć producenci IoT
Ten incydent jest wyraźnym przypomnieniem, że bezpieczeństwo IoT to nie tylko oprogramowanie sprzętowe urządzeń.
Uprawnienia w chmurze są równie ważne.
Producenci powinni zadbać o to, aby:
- każdy certyfikat urządzenia był ograniczony wyłącznie do tego urządzenia
- polityki IoT nigdy nie zezwalały na szeroki dostęp z użyciem symboli wieloznacznych w całej flocie
- device shadows nie mogły przenosić niebezpiecznych pól poleceń bez ścisłej autoryzacji
- ścieżki wykonywania poleceń były zminimalizowane lub usunięte
- certyfikaty urządzeń były chronione sprzętowo
- oprogramowanie sprzętowe nie przechowywało poufnych sekretów w postaci jawnego tekstu
- dostęp do kamer i map był ściśle kontrolowany
- włączone były audyty AWS IoT Device Defender lub równoważne
- zgłoszenia podatności otrzymywały terminowe aktualizacje
Pojedyncza zbyt szeroka polityka w chmurze może zamienić jedno przejęte urządzenie w ryzyko dla całej floty.
Podsumowanie
Ujawnienie luki w robotach odkurzających Shark pokazuje, jak niebezpieczne mogą być błędy w zaufaniu w IoT.
Problem na poziomie urządzenia był poważny, ale model uprawnień w chmurze znacznie go pogorszył. Certyfikat wyodrębniony z jednego odkurzacza mógł według doniesień służyć do interakcji z innymi odkurzaczami w tym samym regionie AWS, a podatne cele mogły przyjmować zdalne instrukcje poleceń poprzez aktualizacje device shadow w chmurze.
Dla użytkowników ryzyko obejmuje naruszenie prywatności, dostęp do kamery, ujawnienie map domu, kradzież danych uwierzytelniających Wi-Fi i zdalne sterowanie urządzeniem. Dla producentów lekcja jest jasna: bezpieczeństwo IoT musi być egzekwowane na każdej warstwie.
Certyfikaty urządzeń muszą być ograniczone. Polityki w chmurze muszą być audytowane. Funkcje poleceń zdalnych muszą być ściśle kontrolowane. A gdy badacze zgłaszają ryzyko dla całej floty, obsługa ujawnienia musi być szybka, przejrzysta i zorientowana na klienta.
