Twoje dziecko używa smartwatcha? Absurdalnie krytyczne podatności w kilku kolejnych modelach..

O bezpieczeństwie tzw. dziecięcych smartwatchy, pisaliśmy już parę razy. Pobieranie danych użytkownika (w tym jego lokalizacji) bez żadnych sprawdzeń uprawnień – czemu nie ;)  Serwer z wrażliwymi danymi z zegarków, który nie zapewnia ani szyfrowania ani w zasadzie żadnych metod ochrony – proszę bardzo.

Tym razem na celownik niemieckich badaczy poszło kilka marek: JBC, ANIO, Pingonaut oraz 3G Electronics. Plusy? Producenci współpracowali oni z badaczami oraz poprosili ich o weryfikację czy przygotowane łatki są skuteczne. Jeden z brandów – XPLORA – wypadł całkiem nieźle (tylko drobne uchybienia).

Minusy? W zasadzie prawie wszystkie modele produkowane przez 3G Electronics (a brandowane jako StarlianTracker, JBC, ANIO czy Polywell) wypadły marnie.

Jeśli ktoś nie wierzy, że podatność SQL injection występuje jeszcze w świecie rzeczywistym, niech zerknie na to (zwracam również uwagę na jedyną w swoim rodzaju implementację WAF-a po stronie klienckiej w appce Androidowej):

W trakcie testów API producenta 3G, stwierdziliśmy że prawie wszystkie parametry (!) API RESTowego były podatne na SQL injection. Część endpointów zwracała szczegółowe informacje w błędach.

Co ciekawe, w trakcie analizy appki androidowej znaleźliśmy, że filtruje ona (po stronie klienckiej!) pewne słowa kluczowe z SQLa, takie jak: SELECT, UNION, AND, LIKE czy OR. Jednak lista jest bardzo prosta i można ją ominąć (w zasadzie każdą walidację, która jest po stronie klienckiej można ominąć -przyp. sekuraka).

During our tests of the 3G API, we found that almost all parameters of the REST API were vulnerable to SQL injections. Some API endpoints even return the SQL error message and filter parameters containing SQL keywords. Interestingly, while analyzing the Android apps, we found that they employ client-side filtering for SQL keywords. These keywords include typical SQL control sequences like *, select, –, union, and ;. They also include conditional operators like and, or, and like. This filter list, however, is not exhaustive and does not reliably prevent SQL injection exploits.

Z innych ciekawostek API umożliwiało logowanie się za pomocą loginu oraz hashu MD5 hasła. Samo użycie MD5 w tym miejscu budzi zgrozę, a dodatkowo logowanie hasłem, powoduje że po jego wyciągnięciu z bazy (SQL injection), w ogóle nie trzeba go łamać – wystarczy przesłać w stosownym żądaniu.

Coś innego? Bardzo proszę:

Zegarek ANIO używa REST API po HTTPS (na razie wszystko OK – przyp. sekurak). Ale aplikacja nie sprawdza certyfikatu serwerowego, ani serwer w ogóle w żaden sposób się nie uwierzytelnia (czyli appka akceptuje jakikolwiek podstawiony przez atakującego certyfikat – zapewne również taki self signed – przyp. sekurak). Umożliwia to ataki klasy Man In The Middle.

The ANIO watch application uses a REST API over HTTPS to communicate with the application server. We found that the app does not check the server certificate and uses no server authentication at all. This is a critical vulnerability, as any active MitM can read and modify the API communication.

Uprawnienia? (tym razem już zupełnie wolne tłumaczenie).

Uprawnień nie stwierdzono, każdy użytkownik który się zaloguje może uzyskać dostęp do danych innych użytkowników – wystarczy podane stosownego userID ofiary.

The authorization checks employed by the ANIO API do not prevent a user from accessing other users’ data. The server checks if a user is logged in, but does not implement permission management. The only information necessary to access other users’ data is the user ID.

Więcej smaczków technicznych – w cytowanym dokumencie.

–ms