Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Ciekawe potknięcia bezpieczeństwa przy popularnym startupie Rabbit R1

31 lipca 2024, 03:25 | W biegu | komentarze 3

Firmy technologiczne nie przestają przedstawiać AI jako rozwiązania większości problemów ludzkości. Do czatów bazujących na dużych modelach językowych (LLM), użytkownicy Internetu zdążyli już przywyknąć. Asystenci głosowi stali się kolejną funkcją smartfona. Nic więc dziwnego, że aby jeszcze bardziej ułatwić codzienne życie, powstały startupy rozwijające projekty takie jak Rabbit R1. Czym jest to urządzenie? Producent reklamuje je jako “kieszonkowego asystenta” używającego Large Action Model (w skrócie LAM), czyli sieci, które mają – oprócz rozumienia języka jak LLM – rozumieć także akcje czy czynności zaprezentowane przez człowieka. Łącząc zdolności modeli językowych z przetwarzaniem gestów, obrazów (urządzenie ma wbudowany aparat) oraz interakcji z zewnętrznymi aplikacjami, Rabbit R1 ma być personalnym asystentem. Tyle marketingowej teorii, ponieważ od samego początku projekt nie został dobrze przyjęty przez rynek. Można spotkać wiele negatywnych recenzji, które wskazują na brak przydatności (zwłaszcza w dobie telefonów komórkowych) w codziennym życiu, problemy z baterią czy ogólnym działaniem. Jednak to nie są największe problemy tego urządzenia. 

Rys. 1. Zdjęcie poglądowe urządzenia Rabbit R1

Rabbitude to projekt realizowany przez grupę badaczy oraz community zrzeszone wokół serwera na Discordzie. Jak sami siebie określają, ich działanie ma na celu poprawienie user experience korzystania z Rabbita i “uwolnienie” urządzenia. Przy okazji wyniki eksperymentów mają być publikowane na ich stronie WWW. 

Pod koniec czerwca na blogu projektu pojawił się wpis dotyczący uzyskania przez Rabbitude dostępu do kodów źródłowych asystenta, w którym znaleziono klucze API do usług takich jak:

  • ElevenLabs (usługa oferująca text-to-speech),
  • Azure (wykorzystywany jako speech-to-text),
  • Yelp (agregat opinii o firmach),
  • Google Maps (dobrze znane mapy Google, wykorzystywane do sprawdzania lokalizacji).

Klucze do pierwszej usługi umożliwiły badaczom uzyskanie dostępu do historii zapytań, zmianę głosu, który słychać z głośnika urządzenia, modyfikację rozwinięć skrótów (jeśli w czytanym tekście wystąpi “r1” to użytkownik usłyszy “ar one”) czy też dokonanie zmian w backendzie polegających na usunięciu głosów. Badacze twierdzą, że w efekcie wszystkie urządzenia R1 staną się bezużyteczne. Błędy zdarzają się każdemu, więc warto stworzyć dział bezpieczeństwa już na etapie planowania nowych projektów, aby uniknąć nieprzyjemności. Jednak dopiero odpowiedź zespołu pokazuje, że Rabbit R1 ma jeszcze długą drogę do przebycia w kwestii dojrzałości produktu i organizacji.

Badacze poinformowali o wycieku firmę, jednak ona postanowiła w pierwszej kolejności zignorować to zgłoszenie. Producent ignorujący zgłoszenia luk bezpieczeństwa? Nowe, nie znaliśmy 🙂

Dzień później badacze opublikowali kolejny post, który opisuje reakcję na poprzedni wpis. Według przytoczonej wiadomości z serwera discordowego projektu, podjęto działania mające na celu wymianę sekretów używanych do komunikacji z zewnętrznymi systemami:

Today we were made aware of an alleged data breach. Our security team immediately began investigating it. As of right now, we are not aware of any customer data being leaked or any compromise to our systems.

If we learn of any other relevant information, we will provide an update once we have more details

Jednak jak podają użytkownicy, nowy klucz do ElevenLabs nie został zsynchronizowany z urządzeniami, co w efekcie doprowadziło do soft-bricka urządzeń (np. zapętlenia, niemożności uruchomienia). Ale odnalezione sekrety nie były jedynymi, które znajdowały się w kodzie źródłowym pozyskanym przez badaczy. Po głębszej analizie odnaleźli oni klucze API do serwisu SendGrid, który jest wykorzystywany do wysyłania mailingu. Dzięki tym kluczom, badacze mogli wysyłać wiadomości e-mail z adresów @*.rabbit.tech oraz uzyskali oni dostęp do historii e-maili zawierających informacje o użytkownikach końcowych. 

Badacze skontaktowali się z dziennikarzami 404media.co i przesłali im wiadomości z adresów takich jak rabbit@r1.rabbit.tech (adres używany do przesyłania między innymi informacji o statusie projektu) czy też security@r1.rabbit.tech – adres chyba mówi sam za siebie. 

Dalszy przegląd kodu doprowadził do konkluzji, że urządzenie tak naprawdę nie jest tym, co obiecuje producent, czyli tzw. LAM, tylko po prostu kolejnym GPT obsługującym kilka skryptów do korzystania z zewnętrznych serwisów. Powoduje to, że np. zmiana interfejsu zewnętrznej aplikacji, z której korzysta urządzenie prowadzi do niedostępności funkcji aż do momentu aktualizacji produktu. 

Nieprzychylna i wolna reakcja na wszelką krytykę związaną z działaniem, czy obawy o bezpieczeństwo przechowywanych informacji o użytkownikach wywołało efekt odwrotny do zamierzonego. Zamiast zredukować zainteresowanie bezpieczeństwem produktu, badacze zaczęli bliżej przyglądać się temu rozwiązaniu. 

David Buchanan, zachęcony poprzednimi znaleziskami, postanowił kupić urządzenie i dokonać inżynierii wstecznej. Swoje spostrzeżenia umieścił we wpisie na blogu. Rabbit R1 używa starego SoC-u – podatnego MediaTek MT6765. Opublikowany eksploit dotyczy tzw. bootROMu, czyli kodu wypalonego na stałe w pamięci read-only. Bez dostępu do urządzenia (a czasami i wymiany SoC-u) nie ma możliwości jego aktualizacji. Atak pozwala na zainstalowanie innego systemu operacyjnego. Ale jakiego? Otóż Rabbit R1 używa… Androida 13. Tak zwany RabbitOS to w rzeczywistości aplikacja (APK) działająca na systemie Android skonfigurowanym w trybie przypominającym działanie kiosk mode

Konfiguracja, w jakiej dostarczane jest urządzenie, jest na tyle “luźna”, że wyżej wspomniany eksploit jest zbędny, ponieważ urządzenie można odblokować przy pomocy mtkclienta, mimo że początkowo urządzenie przychodzi z zablokowanym bootloaderem. 

Buchanowi udało się wykorzystać wspomniany wcześniej eksploit do ominięcia procesu secure boot i uruchomienia swojego payloadu na uruchomionym urządzeniu, uzyskując tym samym dostęp do powłoki systemu z uprawnieniami roota. Opisywany jailbreak dorobił się również fajnej nazwy – carrot.

Listing 1. Wykonanie poleceń systemowych jako root (źródło)

$ rlwrap nc 192.168.0.69 1337
# id
uid=0(root) gid=0(root) groups=0(root) context=u:r:rootkit:s0
# getprop ro.boot.verifiedbootstate
green

Dokonujący analizy pracy urządzenia badacz zauważył kilka niepokojących sygnałów, takich jak zbieranie logów zawierających lokalizację GPS, nazwę sieci WiFi (co również może być wykorzystane do lokalizacji użytkownika), identyfikatory okolicznych BTS-ów, IP i wiele innych. Jak wskazuje autor researchu, tak bogate logi nie powinny być potrzebne, zwłaszcza w sytuacji, w której urządzenie nie dysponuje żadnymi szczególnymi zabezpieczeniami fizycznymi. Dodatkowo badacz nie znalazł możliwości przeprowadzenia pełnego resetu do ustawień fabrycznych. To powoduje, że pozyskane z drugiej ręki urządzenia mogą być prawdziwą kopalnią wiedzy na temat poprzedniego właściciela. Problemy te zostały rozwiązane w nowym wydaniu RabbitOS

Cóż, wygląda na to, że urządzenie nie tylko zostało niezbyt ciepło przyjęte przez community, ale również firma stojąca za nim musi jeszcze popracować nad wieloma aspektami związanymi między innymi z bezpieczeństwem danych użytkowników końcowych. Zaznaczyć trzeba również, że podnoszone są zarzuty złamania licencji GPL2, autorzy nie opublikowali kodu źródłowego, mimo wykorzystywania jądra systemu Linux. W tak dynamicznym czasie rozwoju oprogramowania “wspieranego” przez szeroko pojęte AI, takie potknięcia mogą rzutować na przyszłość marki. 

~fc

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. maciek

    „podnoszone są zarzuty złamania licencji GPL2, autorzy nie opublikowali kodu źródłowego, mimo wykorzystywania jądra systemu Linux”
    Przecież samo korzystanie z jądra tego nie wymaga, chyba że je modyfikowali?

    Odpowiedz
    • Karol

      Wymaga wskazania źródła dokładnie odpowiadającego wersji binarnej przekazanej użytkownikom.
      Dostarczali w wersji skompilowanej – mają obowiązek opublikować albo udostępnić na żądanie klienta kod źródłowy dokładnie taki, jak ten, którego skompilowana postać jest w urządzeniu. Nawet gdyby nie modyfikowali nic i polecieli dokładnie na tym, co pobrali np. z kernel.org (co ekstremalnie mało prawdopodobne – konfigurację kompilacji musieli zrobić, jakieś sterowniki urządzeń zintegrowanych na płytce mogli dokładać itp.), to mają obowiązek wskazać palcem konkretną wersję z kernel.org z dokładnością do dnia/godziny/pojedynczej zmiany.

      Odpowiedz
  2. Ggggh

    To nie są potknięcia tylko kompletny brak wiedzy o bezpieczeństwie. Taka firma powinna nie istnieć

    Odpowiedz

Odpowiedz