Jakiś czas temu trafiła do nas na „testy” bardzo ciekawa pod względem możliwości sprzętowych „budżetowa” obrotowa kamera z AI, a do tego z polskiej dystrybucji. Jak każdemu nowemu urządzeniu w naszym portfolio czy serwisie, również i temu postanowiliśmy poświęcić chwilę czasu. Szybka analiza urządzenia pozwoliła stwierdzić, że jest to prawdopodobnie urządzenie produkowane w Azji z oprogramowaniem dostarczanym pod marką Hankvision, a konkretniej opracowanym przez Shenzhen Hankvision Technology Co., Ltd. założoną w 2012 roku firmę która w ciągu 12 lat rozwoju stała się jednym z wiodących dostawców nowoczesnych rozwiązań wideo AI w dziedzinie inteligentnych zabezpieczeń.
Produkty oparte o rozwiązania sprzętowe i programowe od Hankvision obserwujemy na polskim rynku od wielu lat, a ich gama coraz bardziej się poszerza. Ostatnio dołączyła do nich wspomniana kamera KPT-01-Tuya-ZL oparta o bardzo popularny i obecny w 
wielu innych kamerach SoC firmy Fullhan FH8852V210, z obsługą H.264/H.265 i przetworników do 4MP@5fps (sama kamera jest wyposażona w 3MP), 
następcę równie popularnego SoC MStar335. Co ciekawe oprogramowanie w DeviceID przedstawia urządzenie jak V6202IR-SC3335 choć w rzeczywistości nie jest ono oparte sprzętowo o SC3335, a o znacznie bardziej zaawansowany FH8852V210 z dwurdzeniowym CPU o taktowaniu do 696MHz (master) / 464 MHz (slave) oraz wewnętrznym 64MB RAM DDR2, 3xI2C,3xSPI, 3xUART, 2xSDIO, USB2.0, 2xSADC i 12xPWM.
Jednym słowem, bardzo ciekawy i budżetowy model z wsparciem dla obsługi Tuya Smart – międzynarodowej chmury/platformy skupiającej się na rozwoju rozwiązań AI i IoT których w ofercie mamy coraz więcej. Ta grupa produktowa jest dla nas szczególnie interesująca z jeszcze jednego powodu – Internet Rzeczy IoT stanowi obecnie największe wyzwanie w zakresie cyber-bezpieczeństwa, dlatego tak dużą uwagę poświęcamy wszystkim nowym produktom z tej grupy. Grupy w której praktycznie w każdym nowym produkcie trafiającym na rynek znajdują się mniejsze lub większe podatności związane z bezpieczeństwem, co miejmy nadzieję w najbliższej przyszłości uporządkuje unijna Dyrektywy NIS 2, czyli „Dyrektywy Parlamentu Europejskiego i Rady (UE) 2022/2555 w sprawie œrodków na rzecz wysokiego wspólnego poziomu cyber-bezpieczeństwa na terytorium Unii Europejskiej, oraz zapewnienie bezpieczeństwa cybernetycznego i usprawnienie pracy obsługiwanych organizacji i podmiotów. Dyrektywa która wymusi na producentach oferujących swoje rozwiązania na terenie EU większą dbałość o cyber-bezpieczeństwo swoich produktów, kamer, urządzeń sieciowych, urządzeń IoT i wielu wielu innych.
Taką potencjalną podatność znaleźliśmy również w tej grupie produktów CCTV/IoT opartych jak się okazało o jedną wspólną i spójną dla wielu urządzeń platformę sprzętowo programową dostarczaną przez Hankvision, a ponieważ naszym celem jest wzrost świadomości i zapotrzebowania na bezpieczeństwo postanowiliśmy przeanalizować wszystkie potencjalne słabe strony tych rozwiązań i napisać jak zawsze dla was o tym w kilku zdaniach na naszym blogu. Pierwszym zastanawiającym (jak na produkty tak doświadczonej firmy) spostrzeżeniem było to, że łącząc się do tej grupy urządzeń z zewnątrz można wydobyć z kamer kilka interesujących z punktu widzenia potencjalnego atakującego informacji. Oczywiście pod warunkiem, że atakujący jest już wewnątrz tej samej sieci w której pracują urządzenia.
Odpytanie zasobów pod adresem http://camera:10081/OwnUserInfo.txt ujawniło dane zawierające domyślne loginy i hasła które można wykorzystać w panelu web’owym (na szczęście domyślenie wyłączonym w testowanej przez nas wersji firmware), aczkolwiek wciąż dających się wykorzystać w zakresie exploitacji pracującego w kamerach systemowego procesu watchall, który nasłuchuje na porcie tcp/20203 i tcp/10081 o czym dalej. Domyślna nazwa użytkownika to admin, a hasło … na cóż … też admin. Tu ważna uwaga, bo nawet jeśli zostanie zmienione istnieje drugie niewidoczne zakodowane na stałe konto, które również daje dostęp do interfejsu administratora.
Inna ścieżka http://cameraip:10081/SysInfo … zwróciła dane dot. urządzenia. Jednak ma się to nijak do znacznie bardziej problematycznego i groźnego w skutkach faktu, dotyczącego tego, że dane logowania do sieci WiFi (w przypadku połączenia bezprzewodowego kamery) są zapisane w pliku który można łatwo pobrać z urządzenia http://cameraip:10081/WifiInfo bez autoryzacji i są zapisane plain’textem w formie jawnej !
W innej ścieżce można odczytać PID, UUID i AUTHKEY do usługi Tuya Smart, i tym sposobem prawdopodobnie uzyskać dostęp do sterowania wszystkimi urządzeniami IoT sparowanymi z danym kontem Tuya, a to już może stanowić realne zagrożenie bezpieczeństwa użytkownika produktu. Tutaj też zaczynają się dalsze potencjalne zagrożenia o których należy mieć świadomość aby prawidłowo skonfigurować sieć i zablokować połączenia na konkretne porty.
Wspomniany wcześniej proces wykonywalny watchall pracujących w kamerach tej serii (istniejący co najmniej w kilku różnych wersjach) jest odpowiedzialny za uruchomienie wszystkich głównych plików binarnych kamery.
Ponadto otwiera port tcp/20203 stanowiący potencjalny wektor ataku dla backdoora, który umożliwia uzyskanie informacji z kamery, przywrócenie konfiguracji fabrycznej, ponowne uruchomienie kamery lub aktualizację oprogramowania układowego.
Wszystkie te operacje wymagają zalogowania się do urządzenia przy użyciu zakodowanych na stałe poświadczeń do których również bardzo łatwo można uzyskać dostęp odpytując odpowiednią ścieżkę… przy użyciu tego samego portu służącego do „konserwacji” urządzenia pozwala to bardzo łatwo uzyskać powłokę root’a przy użyciu bibliotek obecnych w samym pliku binarnym, a w przypadku jednej z wersji z wykorzystaniem uClibc. Inną alternatywną metodą „zbadania” wnętrza kamery pozostaje oczywiście otwarcie urządzenia, i przylutowanie się do odpowiednich pinów RS232 na płycie SoC, w tym wypadku jednak nie było to konieczne…
Wewnątrz klasycznie … linux, i zakodowane na stałe konto z jednym spójnym dla szerokiej gamy urządzeń hasłem root’a, zapewne (dedukując na podstawie samego hasła) pozostawionym tam na bliżej nie określone potrzeby producenta (o wewnętrznym haśle 
root’a na dzień naszego zgłoszenie product manager ze strony dystrybutora nie miał wiedzy). Hasła, ani jego pełnej zahashowanej formy z oczywistych powodów tu nie podajemy, a jedynie PoC na jego istnienie. W przypadku kont root’a warto dla bezpieczeństwa po instalacji urządzeń zmienić je na własne, jednak z praktyki nie wszyscy producencji je udostępniają użytkownikowi końcowemu. Co innego w przypadku wysokowyspecjalizowanych produktów do bardziej zaawansaowanych aplikacji związanych z szerokopojętym bezpieczeństwem.
Powyższe nie jest dla niczym nowym ani zaskakującym ponieważ w dzisiejszych czasach bezpieczeństwo korzystania z IoT zależy w głównej mierze od bezpieczeństwa sieci w której pracują same urządzenia, a nie od urządzeń w których, aż roi się od potencjalnych możliwych do wykorzystania przy odrobinie wiedzy backdoor’ów, lub furtek pozostawionych przez producentów na potrzeby późniejszych integracji ich produktów. Wielokrotnie o tym pisaliśmy jak choćby w przypadku równie popularnych urządzeń opartych o SoC HiSilicon Hi3520D i jego klony.
Warto mieć o tym świadomość gdy zaczyna się przygody z Internetem Rzeczy 🙂 Product manager dystrybutora w Polsce został przez nas szczegółowo poinformowany o naszych spostrzeżeniach, a wspomniane podatności zapewne zostaną załatane w kolejnych wersjach firmware’u pobieranego automatycznie przez urządzenia. Jeśli w swoich instalacjach i sieciach korzystacie za IoT zawsze warto rozważyć czy urządzenia nie powinny dla bezpieczeństwa pracować w odizolowanej sieci prywatnej bez bezpośredniego dostępu do Internetu z odpowiednią konfiguracją ACL dla jakichkolwiek portów otwartych na zewnątrz – tutaj szczególna uwaga na UPnP (ang. Universal Plug-and-Play).
Takich przykładów do głębszej analizy w oparciu o wiele innych układów SoC jest jednak znacznie więcej, a przynajmniej tyle ile jest samych układów SoC, spośród których z tych najbardziej popularnych można wymienić chociażby… oczywiście kluczem do bezpieczeństwa jest pracujące w nich oprogramowanie, a tutaj w przypadku produktów z Azji bywa bardzo ciekawie…
Ambarella S2L
Ambarella S3L
Anyka AK3916Ev301
Anyka AK3918Ev200
Fullhan FH8632
Fullhan FH8852v100
Fullhan FH8852v200
Fullhan FH8852v210
Fullhan FH8856v100
Fullhan FH8856v200
Fullhan FH8856v210
Fullhan FH8858v200
Fullhan FH8858v210
Goke GK7102S
Goke GK7202v300
Goke GK7205v200
Goke GK7205v300
Goke GK7605v100
GrainMedia GM8135
GrainMedia GM8136
HiSilicon Hi3516Av100
HiSilicon Hi3516Av200
HiSilicon Hi3516Av300
HiSilicon Hi3516Cv100
HiSilicon Hi3516Cv200
HiSilicon Hi3516Cv300
HiSilicon Hi3516Cv500
HiSilicon Hi3516Dv100
HiSilicon Hi3516Dv200
HiSilicon Hi3516Dv300
HiSilicon Hi3516Ev100
HiSilicon Hi3516Ev200
HiSilicon Hi3516Ev300
HiSilicon Hi3518Cv100
HiSilicon Hi3518Ev100
HiSilicon Hi3518Ev200
HiSilicon Hi3518Ev300
HiSilicon Hi3519v101
Ingenic T10
Ingenic T20
Ingenic T21
Ingenic T31
MStar MSC313E
MStar MSC316D
Novatek NT98562
Novatek NT98566
SigmaStar SSC325
SigmaStar SSC335
SigmaStar SSC337
SigmaStar SSC337DE
Xiongmai XM510
Xiongmai XM530
Xiongmai XM550
