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

Pokazał jak shakować zabawkę dla dzieci… bo producent zbankrutował

17 lutego 2025, 01:01 | Aktualności | 0 komentarzy

Historie takie jak ta w świecie inżynierii wstecznej lub ogólnie hackingu pojawiają się stosunkowo często. Producent kończy wsparcie urządzenia (lub jak w tym przypadku bankrutuje) i w efekcie tego po pewnym czasie produkt przestaje działać. Jednak nie zawsze oznacza to koniec danego rozwiązania. Kreatywność użytkowników pozwala powołać drugie życie np. zabawkom. Warto podkreślić, że w pewnych przypadkach dokonywanie dekompilacji i inżynierii wstecznej jest dozwolone przez ustawodawców nawet w bardziej restrykcyjnych krajach. Na przykład właśnie po to aby pozwolić na przywrócenie do działania oprogramowania, które utraciło wsparcie.

TLDR:

  • Jeden z rodziców zauważył, że interaktywna zabawka Jooki, przestała być wspierana przez producenta
  • Postanowił przyjrzeć się bliżej urządzeniu i sprawdzić, co można z tym fantem zrobić
Rysunek 1. Rozebrana zabawka. Na zdjęciu widać między innymi bardzo popularny układ ESP32 (źródło: https://nv1t.github.io/blog/reviving-jooki/)

Jooki to interaktywna zabawka służąca do słuchania muzyki oraz bajek przy pomocy integracji ze Spotify. Producent zakończył swoją działalność i nie ma możliwości kupna urządzenia. Nie są też wypuszczane nowe aktualizacje oprogramowania.

Autor posta otworzył urządzenie i zlokalizował kartę microSD, zawierającą cały system plików urządzenia, w tym partycje zawierające pliki konfiguracyjne np. do serwisu Spotify.

Rysunek 2. Lista partycji na karcie microSD (źródło: https://nv1t.github.io/blog/reviving-jooki/)

Analiza zawartości systemu plików pozwoliła na dojście do ciekawych wniosków:

  1. Urządzenie implementuje mechanizm aktualizacji OTA z wykorzystaniem oprogramowania mender.io. Urządzenie co jakiś czas kontaktuje się z serwerem aby sprawdzić czy dostępne jest nowe oprogramowanie. Aktualizacja firmware jest dokonywana w sposób całkiem bezpieczny, z dwiema partycjami, co pozwala na wycofanie upgrade w momencie natrafienia na błąd. Rysuje się tutaj też pierwsze zagrożenie – jeśli ktoś przejmie kontrolę nad serwerem aktualizacji, który zapisany jest w konfigu urządzenia, będzie mógł wymusić nową aktualizację i w konsekwencji przejąć kontrolę nad urządzeniem
  2.  Na urządzeniu działa serwer HTTP, który pozwala nim zarządzać. Oprócz standardowych funkcji takich jak konfigurowanie urządzenia, dostępne są “ukryte” funkcjonalności, takie jak wykonywanie poleceń (w formie… backdoora albo niechlujnie napisanego kodu). 

Urządzenie pozwala między innymi wgrać klucz publiczny do pliku authorized_keys w celu uzyskania sesji SSH

Rysunek 3. Zapisywanie klucza publicznego SSH (źródło: https://nv1t.github.io/blog/reviving-jooki/)

Nie mogło też zabraknąć kultowego RCE w urządzeniach IoT w postaci wykonania dowolnego polecenia wstrzykniętego w jednym z parametrów HTTP, który następnie trafia do wywołania funkcji system(). Funkcja wygląda na specjalnie przygotowaną w tym celu, jednak wykonanie poleceń nie jest w żaden sposób zabezpieczone. Wystarczy poznać (np. w wyniku inżynierii wstecznej lub brute force) endpoint /ll

Rysunek 4. RCE as a service – prawda, że piękne? (źródło: https://nv1t.github.io/blog/reviving-jooki/)

Dzięki tej funkcjonalności możliwe jest wykonanie kodu przy pomocy prostego zapytania:

curl 'http://192.168.188.169/ll?action=touch%20/tmp/pwned'

Inną ciekawostką jest sposób implementacji OTA z wykorzystaniem skryptów (po co inny mechanizm aktualizacji? Tego się niestety nie dowiemy). Otóż aktualizacji dokonuje skrypt powłoki heartbeat.sh, który w normalnych warunkach pełni rolę… heartbeatu, czyli regularnie odpytuje serwery producenta i oczekuje odpowiedzi zwrotnej o kodzie 200 OK. Jednak w przypadku gdy serwer zwróci w odpowiedzi zawartość poprzedzoną nagłówkiem ## ML_OTA, to Jooki wykona ten kod. 

run_ota() {
    /bin/ash $OTA 2>&1 || true
}

maybe_ota() {
    rm -f $OTA
    if grep -A1000 '## ML_OTA' "$RESPONSE" > $OTA; then
        echo "Running ota"
        run_ota 2>&1 > $OTA_OUT
        post_ota_out
    fi
}

Listing 1. Ciekawy mechanizm OTA (źródło: https://nv1t.github.io/blog/reviving-jooki/)

Jakby tego było mało, dane do aktualizacji pobierane są co prawda z wykorzystaniem programu socat przy pomocy protokołu HTTPS, to jednak skorzystano z opcji verify=0, co wyłącza sprawdzanie certyfikatów i pozwala na prosty atak polegający na zespoofowaniu domeny. 

Listing 2. Wywołanie socata z parametrem verify=0 – sugerujemy nie przeprowadzać w ten sposób aktualizacji (źródło: https://nv1t.github.io/blog/reviving-jooki/)

To kolejna możliwość na podmianę firmware w zabawce dla dzieci, w stosunkowo prosty sposób. Można ją przeprowadzić lokalnie podstawiając własny serwer aktualizacji po https, następnie przekierowując na niego zapytania płynące na adres jooki.rocks. 

Odkrycia badacza pozwoliły na znalezienie metody na naprawę/reset urządzenia w momencie gdy nie chce się ono podłączyć do sieci. Modyfikując flagi w katalogu /data/mode/*, a konkretnie usuwając ESP32_FIRMWARE_LOADED, doprowadza się do resetu do ustawień fabrycznych, co pozwala skonfigurować ESP32 ponownie. 

Urządzenie nie prezentuje zbyt wysokiego poziomu bezpieczeństwa. Producent nie zadbał o integralność podstawowych procesów aktualizacji zabawki. Pozostałe praktyki opisane przez badacza również nie napawają optymizmem :). Jednak jest to wdzięczne urządzenie do testów, ponieważ implementuje wiele podstawowych podatności, które będą w zasięgu nawet początkujących adeptów IT security. 

Czy nowe zabawki trafiające na rynek reprezentują wyższy poziom bezpieczeństwa? Jak to w przypadku urządzeń IoT bywa, odpowiedź na to pytanie nie jest jednoznaczna, jednak mamy swoje podejrzenia… 

~fc

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



Komentarze

Odpowiedz