Wyzwanie: błąd bezpieczeństwa w Home Assistant

Czasami wyłapanie defektów w funkcjonującym już oprogramowaniu może być bardziej ekscytujące niż napisanie najwyższej jakości kodu - zwłaszcza, gdy odkrycie zwiększa ogólne bezpieczeństwo w Internecie.

Moja praca w Intive polega na odnajdywaniu słabych punktów kodu - błędów, które mogą mieć konsekwencje w postaci włamań. Ostatnio udało mi się zwiększyć bezpieczeństwo środowiska platformy Home Assistant. Pasjonują mnie wymagające projekty open-source.

Home Assistant to przyjazne dla użytkownika narzędzie, które ułatwia korzystanie z Internetu rzeczy i zwiększa jego dostępność dla każdego. Można je uruchomić na Raspberry Pi i integruje się bez problemu między innymi z : Alexa, Apple TV, Belkin WeMo, Google Cast, IKEA Tradfri, Philips Hue, Plex oraz Sonos. Oprogramowanie służy do zarządzania systemem domowej automatyki. Krótko mówiąc, twórcy widzą je jako przeskok z rozwiązań typu ,,jedna aplikacja na urządzenie’’ na platformę obsługującą je wszystkie. Inteligentne urządzenia powoli wprowadzają przełom w życiu codziennym, jednak ich słabe skomunikowanie jest częstą przeszkodą w funkcjonowaniu jako kompletnych, łatwo dostępnych systemów. Home Assistant to bezpłatne rozwiązanie, które komunikuje się przez wiele różnych protokołów używanych przez inne produkty. Służy jako poręczny translator z eleganckim UI.

Testowanie w czasie wolnym

Home Assistant - jako projekt open-source - jest świetnym polem do testowania rozmaitych problemów, z którymi deweloperzy mogą chcieć się zmierzyć. Otwarte i ogólnodostępne oprogramowanie opiera się na feedbacku użytkowników. Ja osobiście skupiłem się na testowaniu bezpieczeństwa systemu. W którymś momencie (pomiędzy moimi zadaniami związanymi z pracą w Intive) doszedłem do wniosku, że spróbuję zbadać czy platforma jest odporna na intruzów. Zrobiłem serię testów. Jeden dzień testowania walidacji danych wejściowych wystarczył by odkryć, że system jest podatny na XSS. Korzystając z końcowego /api/states/persistent_notification.httplogin (patrz: GIF powyżej) możliwe było osadzenie dowolnego kodu JavaScript, który będzie wykonany, gdy użytkownik odwiedzi główną stronę interfejsu webowego. Co oznacza, że atakujący mógłby potencjalnie wykonać jakiekolwiek działanie w imieniu uwierzytelnionego użytkownika.

Satysfakcja większa od poziomu zagrożenia

Mój proof of concept przeprowadziłem mając dostęp do sieci lokalnej i API. Dopóki jest wymagany, ryzyko bezpieczeństwa nie jest wielkie. Jednak z automatycznym wykrywaniem i wieloma komponentami zewnętrznymi, wspieranymi przez Home Assistant taka podatność mogła zostać wykorzystana - np. poprzez zainstalowanie złośliwej, autowykrywalnej usługi w sieci, albo wykorzystanie dziury w zewnętrznej, juz skonfigurowanej usłudze.

Intive Common Vulnerability Scoring System v3.0 Calculator (narzędzie oceniające według standardu definiującego zasady punktowej oceny ważności zagrożeń wynikających z podatności sprzętu i oprogramowania, niedawno udostępnione na stronie Intive) plasuje ten konkretny błąd jako 4.3/10 - czyli na średnim poziomie.

Reakcja teamu z była błyskawiczna i profesjonalna - w ciągu kilku dni brak zabezpieczenia został zniwelowany. Usłyszałem też podziękowanie, ale co ważniejsze mam poczucie, że wsparłem społeczność entuzjastów open-source. Dzięki działającym nadprogramowo deweloperom jakość i bezpieczeństwo oprogramowania testuje się na co dzień. Przynosi to korzyści użytkownikom, poprawia bezpieczeństwo oprogramowania i przy okazji poszerza wiedzę testerów. Klasyczny win-win.

Nowa wersja platformy

W listopadzie 2017 - ku mojej radości - udostępniono poprawioną wersję Home Assistant 0.57. Niektórzy dostawcy zamkniętych rozwiązań przychylnie reagują na takie testy, a nawet organizują programy bug bounty dla tych, którzy z zamiłowania śledzą słabości oprogramowania. W moim wypadku chodzi (aż i tylko) o kwestię bezpieczeństwa - zgłoszoną i rozwiązaną.