Jakiś czas temu zakupiłem wideodomofon firmy Fermax (nie wart swojej ceny). Jako, że urządzenie wymaga połączenia z siecią aby umożliwić przesyłanie strumienia audio,video zainteresowałem się tym tematem. Jak ono to robi, że nie wymagane jest przekierowanie portów. Z jakich protokołów korzysta i gdzie, co przesyła.
Przy okazji zawsze czegoś nowego można się nauczyć.
Zacząłem analiza od przeskanowania portów sieciowych. Oto wynik:
PORT STATE SERVICE VERSION
23/tcp open telnet BusyBox telnetd
80/tcp open http Qualvision -HTTPServer
| fingerprint-strings:
| GetRequest:
| HTTP/1.0 302 Redirect
| Server: Qualvision -HTTPServer
| Date: Mon Oct 22 16:23:51 2018
| Pragma: no-cache
| Cache-Control: no-cache
| Content-Type: text/html
| Location: http://IPCamera/index.htm
| <html><head></head><body>
| This document has moved to a new <a href="http://IPCamera/index.htm">location</a>.
| Please update your documents to reflect the new location.
| </body></html>
| HTTPOptions, RTSPRequest:
| HTTP/1.1 400 Page not found
| Server: Qualvision -HTTPServer
| Date: Mon Oct 22 16:23:51 2018
| Pragma: no-cache
| Cache-Control: no-cache
| Content-Type: text/html
| <html><head><title>Document Error: Page not found</title></head>
| <body><h2>Access Error: Page not found</h2>
| <p>Bad request type</p></body></html>
| Help, SSLSessionReq:
| HTTP/1.1 400 Page not found
| Server: Qualvision -HTTPServer
| Date: Mon Oct 22 16:24:16 2018
| Pragma: no-cache
| Cache-Control: no-cache
| Content-Type: text/html
| <html><head><title>Document Error: Page not found</title></head>
| <body><h2>Access Error: Page not found</h2>
|_ <p>Bad request type</p></body></html>
|_http-server-header: Qualvision -HTTPServer
554/tcp open rtsp
| fingerprint-strings:
| FourOhFourRequest, GenericLines, GetRequest:
| RTSP/1.0 400 Bad Request
| CSeq: 0
| Server: QV RTSP Server(v0.1.0.0)
| Allow: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, GET_PARAMETER, SET_PARAMETER
| HTTPOptions, RTSPRequest:
| RTSP/1.0 200 OK
| CSeq: 0
| Server: QV RTSP Server(v0.1.0.0)
| Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, GET_PARAMETER, SET_PARAMETER
| SIPOptions:
| RTSP/1.0 200 OK
| CSeq: 42
| Server: QV RTSP Server(v0.1.0.0)
|_ Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, GET_PARAMETER, SET_PARAMETER
|_rtsp-methods: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, GET_PARAMETER, SET_PARAMETER
5801/tcp open vnc-http-1?
49152/tcp open unknown
| fingerprint-strings:
| FourOhFourRequest, GenericLines:
| HTTP/1.1 200 OK
| Content-Type: application/xml; charset="UTF-8"
| Content-Length: 1104
| <?xml version="1.0" ?>
| <root xmlns="urn:schemas-upnp-org:device-1-0">
| <specVersion>
| <major>1</major>
| <minor>0</minor>
| </specVersion>
| <device>
| <deviceType>urn:schemas-upnp-org:device:3.0-TZC4GW351W01060</deviceType>
| <friendlyName>IPCamera - um0000000000</friendlyName>
| <manufacturer></manufacturer>
| <manufacturerURL></manufacturerURL>
| <modelDescription>IPCamera</modelDescription>
| <modelName>IPCamera</modelName>
| <modelNumber>IPCamera</modelNumber>
| <modelURL></modelURL>
| <serialNumber>vpks2jdjq7h7</serialNumber>
| <UDN>uuid:Upnp-IPCamera-vpks2jdjq7h7</UDN>
| <UPC></UPC>
| <serviceList>
| <service>
| <serviceType>urn:schemas-upnp-org:service:Dummy:1</serviceType>
| <serviceId>urn:upnp-org:serviceId:dummy1</serviceId>
Zacząłem od telnet-a. Niestety prosi o login i hasło. Atak słownikowy za pomocą ncarack-a skończył się z marnym skutkiem. Telnet ma zabezpieczenie, które przy wiekszej próbie blokuje tymczasowo port. Chwilowo ślepa uliczka.
Próba połączenia się z port 80 też kończy się fiaskiem. Podobnie ma się sytuacja jeśli chodzi o protokół rtsp 554, (nie znam parametrów do odpalenia strumienia) jaki połączenie na port 5801. Natomiast z portu 49152 dostajemy informacje odnośnie unpn w formacie xml.
Jedyne co rzuciło mi się w oczy to łańcuch QualVision. Szybkie sprawdzenie w google i wiemy że to firma z Chin zajmująca się "Video Surveillance". Mianowicie produkująca kamery analogowe, cyfrowe oraz urządzenia nagrywające DVR (Oj coś czuję że ten hiszpański fermax to wcale nie taki hiszpanki jakby mogło się wydawać). Przeglądając ich stronę internetową znalazłem też informacje że produkują domofony. Niestety to wszystko, ich strona internetowa wygląda jakby była porzucona. Brak jakichkolwiek aktualizacji, ostanie wpisy z 2014. Dział downloadu pusty.
Mam stary router na którym działa openWRT który pełni funkcję AP (szkoda było wrzucać). Do zrzucenia pakietów wkorzystam program tcpdump (Wtedy jeszcze nie miałem pojęcia o arp spoofing). Instalacja programu:
root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install tcpdump
I zaczynamy , tuż po uruchimieniu komendy zrestartowałem wideodomofon.
root@OpenWrt:~# tcpdump -i wlan0 -s 0 -w fermax.pcap
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: pcap_loop: corrupted frame on kernel ring mac offset 256 + caplen 1718772078 > frame len 262144
571 packets captured
578 packets received by filter
0 packets dropped by kernel
Kopjujemy pliczek na komputer i analizujemy:
dawid@arch:~/trash$ scp [email protected]:/root/fermax.pcap .
Analizując komunikację sieciową zebrałem kilka kluczowych infromacji:
Powstało w celu ujednolicenia wszelkich elementów przesyłu danych pomiędzy urządzeniami monitoringu IP umożliwiających im poprawne działania. Uproszcząjąc przesyła dane wykorzystując protokól gSOAP. Sprawdźmy co nam zdradzi. Szybkie sprawdzenie github-a i mamy gotowe API : https://github.com/quatanium/python-onvif. Skrypt również znajduje się w repozytorium pip-a (sudo pip2 instal onvif). Jako loginu i hasła użyłem ten domyślny z urządzenia, a mianowicie admin, 1234. (Działa również guest + puste hasło oraze pusty user i hasło - to wyszło pózniej podczas analizy). Spis wszystkich funkcji znajdziemy na: https://www.onvif.org/onvif/ver20/util/operationIndex.html. Niestety urządzenie nie wspiera wszystki komendy. Poniżej kilka ciekawszych informacji z działających zapytań:
dawid@arch:~/trash$ onvif-cli --host 192.168.1.10 -u 'admin' -a '1234' --port 80 --wsdl /usr/wsdl/
ONVIF >>> cmd devicemgmt GetUsers
True: [{'Username': admin, 'UserLevel': Administrator}, {'Username': guest, 'UserLevel': User}]
ONVIF >>> cmd devicemgmt GetDeviceInformation
True: {'Model': NVT, 'SerialNumber': 000000000000, 'HardwareId': 1, 'FirmwareVersion': V500.R001.A003.00.CG0021.B003, 'Manufacturer': None} (serial ukryłem)
ONVIF >>> cmd devicemgmt GetNetworkInterfaces
True: [{'Info': (NetworkInterfaceInfo){
Name = "wlan0"
HwAddress = "00:00:00:00:00:00" (MAC adres = SerialNumber - ukryłem)
MTU = 1500
}, '_token': wlan0, 'Enabled': True, 'Link': (NetworkInterfaceLink){
AdminSettings =
(NetworkInterfaceConnectionSetting){
AutoNegotiation = True
Speed = 100
Duplex = "Full"
}
OperSettings =
(NetworkInterfaceConnectionSetting){
AutoNegotiation = True
Speed = 100
Duplex = "Full"
}
InterfaceType = "0"
}, 'IPv4': (IPv4NetworkInterface){
Enabled = True
Config =
(IPv4Configuration){
FromDHCP =
(PrefixedIPv4Address){
Address = "192.168.1.10"
PrefixLength = 24
}
DHCP = True
}
}, 'IPv6': (IPv6NetworkInterface){
Enabled = False
}}]
ONVIF >>> cmd media GetStreamUri {'ProfileToken': 'Profile_1', 'StreamSetup': {'Stream': 'RTP-Unicast', 'Transport': {'Protocol': 'UDP'}}}
True: {'InvalidAfterReboot': False, 'Timeout': PT10S, 'Uri': rtsp://192.168.1.10:554/mode=real&idc=1&ids=1, 'InvalidAfterConnect': False}
Zebraliśmy następujące informacje:
Zacząłem od sprawdzenia strumienia wideo. Zawsze mam po ręką VLC, więc użyłem tego programu. Niestety pojawia się niebieski ekran z datą i godziną (screen poniżej). Dopiero wyzolenie podglądu na telefonie komórkowym wyśwwietla poprawny obraz video z kamery wideodomofonu przy bramce. Niestety urządzenie to działa w taki sposób, że obraz video może być wyświetlony w danej chwili na jednym urządzeniu. A mianowice na wyświetlaczu dołączonym do zestawu bądź telefonie komórkowym. Dziwnym trafem w VLC obraz się pojawia. Niestety rozdzielczość sygnału video nie jest oszałająca 704x576. To nawet nie HD Ready, bieda jak na dzisiejsze czasy. Cena urządzenie powinna być stanowczo niższa.
Poszukałem jeszcze jakiś informacji na temat podatności onvif. Najciekawsza była oznaczona numerem CVE-2018-19081 Polega na wstrzyknięciu własnej komendy do urządzenia (coś ala sql injection). Niesety zakończyła się fiaskiem, sprzęt jest zabezpieczony.
dawid@arch:~/trash$ onvif-cli --host 192.168.1.59 -u 'admin' -a '1234' --port 80 --wsdl /usr/wsdl/ devicemgmt SetDNS "{'FromDHCP': False, 'DNSManual': {'Type':'IPv4', 'IPv4Address':"`whoami`"}}"
False: Invalid address
Na tym etapie moje pomysły jak dobrać sie do urządzonka praktycznie skończyły się. Pobawiłem się jeszcze w przechwytywanie danych z użyciem tcpdump. Udało mi się dodatkowo przechwicić parę JSON-ów (istotne informacje zamieniłem na xxx)
{"b":{"client_id":"xxx","client_lang":1,"client_token":"a5c635e329de42dbedcc00f744da08a8","client_type":3,"custom_flag":"1000000148","disable_push_other_users":1,"enable_push":1,"no_login_mode":1,"param_content":"intent:#Intent;launchFlags=0x10000000;package=com.pp.yl;component=com.fermax.wayfi/com.quvii.bell.activity.LoadingActivity;i.DevChNo={DevChNo};S.DevUmid={DevUmid};i.AlarmEvent={AlarmEvent};S.AlarmTime={AlarmTime};end","param_type":"intent","unread_count":0},"h":{"e":0,"i":279,"s":"","v":2}}
{"b":{"alarm_events":[7,18],"client_id":"xxx","client_type":3,"custom_flag":"1000000148","no_login_devs":[{"channel":0,"dev_id":"xxx","dev_name":"Dom 1","passwd":"1234","umid":"vpks2jxxx","user":"admin"}],"no_login_mode":1,"notify_param":"a5c635e329de42dbedcc00f744da08a8","notify_type":1,"opcode":1},"h":{"e":0,"i":272,"s":"","v":2}}
{"b":{"custom_flag":"1000000148","devs":["vpks2jxxx"],"need_arm_state":0},"h":{"e":0,"i":235,"s":"","v":2}}
{"b":{"client_id":"xxx","client_type":3,"custom_flag":"1000000148","dev_id":"xxx","no_login_mode":1},"h":{"e":0,"i":271,"s":"","v":2}}
Wszystkie "dżejsonki" lecą do: api2.qvcloud.net:8888/umeye_api. Co to za api? kolejne ?. Google i mamy. Kolejna chinska firma UMEYE - You My Eye (facepalm - ale ten wideodomofon hiszpański jak ja brazylijski :P). Przynajmniej SDK udostępniają oraz aplikacjie na telefony. Niestety cała strona po chinsku więc trzeba z google translate korzystać.