IoT-Gerät analysieren

Debian auf Notebooks und speziellen Geräten wie eingebetteten Systemen, Routern, Set-Top-Boxen, ...
Antworten
ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

IoT-Gerät analysieren

Beitrag von ernohl » 21.11.2018 17:42:51

Ich habe mir mehr aus Neugier als für den "produktiven" Einsatz eine (billige) IP-Kamera angeschafft. Ohne über die Zusammenhänge nachzudenken, war ich beim Kauf erst einmal von angepriesenen Möglichkeiten beeindruckt. Für mich ist das Thema völlig Neuland.
Nach der Installation ist mir einiges klarer und meine Alarmglocken läuten (Privacy). Ich selbst bekomme quasi keine technischen Hintergrundinformation und soll einfach eine App oder Windows-Software benutzen. Technisch sieht das so aus, das die Kamera alle Daten an einen Server irgendwo in der Welt (wahrscheinlich China) bläst und ich sie über die App dort (wo sie von Dritten analysiert und gespeichert werden können) abrufen kann. Kein angenehmer Gedanke.

Deshalb versuche ich, das Teil intern (im Heimnetz) zu benutzen und die Verbindung nach außen zu kappen. Allerdings fällt es mir schwer, die benötigten Informationen zu besorgen, also das Gerät (dieses spezielle, aber auch ganz allgemein) mit Debian-Bordmitteln zu analysieren.

Konkret: IP-Adresse und offene-Ports (hier rtsp/554) war noch einfach. Dass ich auf den Videostream über das virtuelle Interface onvif1zugreifen muss, habe ich nur zufällig im Internet gefunden.
Frage: Wie hätte ich das selbst am Gerät ermitteln können?

2. Alarmereignisse werden auf eine SD-Karte im Gerät gespeichert. Wie komme ich da ran?
3. Über die App lässt sich die Kamera auch steuern. Wie kann ich herausfinden, wie ich das Teil zum Absetzen von Steuerbefehlen ansprechen muss.
Wie genau die Steuerbefehle dann aussehen, weiß ich noch nicht, aber ohne 3. ...

Mich interessiert also besonders, was kann ich selbst wie analysieren, aber ich nehme natürlich auch sachdienliche ;-) Hinweise zu dieser Kamera (Stichworte FREDI und yoosee) entgegen.

Langer Text. Danke im Voraus.

reox
Beiträge: 2463
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von reox » 21.11.2018 21:41:01

Was immer geht: Ein WLAN Netz per hostapd erstellen, wireshark aufmachen und traffic beobachten.
Wenn du gar keine Ahnung hast, wie das Interface funktioniert, ist das reverse engineering unter umständen sehr schwer. Am einfachsten baut man sich zunächst eine Testumgebung, eben zB mit hostapd und wireshark, und probiert dann die diversen Steuerungskommandos aus und beobachtet was passiert. Entweder ist es dann eh offensichtlich was passiert, oder man muss sich halt langsam hinarbeiten.
Wenn es nicht so einfach ist, evt mal das Gerät aufmachen und schauen ob da eine Serielle Konsole oder JTAG drin ist. Manchmal kann man so recht leicht ins System rein. Ggf hilft bei so IoT zeugs aber nur Lötkolben, Oszi und eeprom reader...

Was für eine Kamera ist denn das? Ggf finden sich dazu ja bereits Infos im Netz. Hast du da schon mal geschaut?

ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

Re: IoT-Gerät analysieren

Beitrag von ernohl » 21.11.2018 22:27:29

Was immer geht: Ein WLAN Netz per hostapd erstellen
???
Wäre ich damit auf die virtuelle IP / das Verzeichnis onvif1 gekommen?
Description-de: Authentifikator für IEEE 802.11 AP und IEEE 802.1X/WPA/WPA2/EAP
Ursprünglich war hostapd eine optionale Userspace-Komponente für den
Host-AP-Treiber. hostapd fügt der im Kernel-Treiber enthaltenen
grundlegenden IEEE-802.11-Verwaltung weitere Funktionen hinzu: Nutzung
eines externen RADIUS-Authentifizierungsservers für Zugriffskontrolle
anhand der MAC-Adressen, IEEE-802.1X-Authentifikator und dynamisches
»WEP Keying«, RADIUS Accounting, WPA/WPA2-Authentifikator (IEEE
802.11i/RSN) und dynamisches »TKIP/CCMP Keying«.
.
Die aktuelle Version bietet Unterstützung für weitere Treiber,
einen integrierten EAP-Authentifikator (d.h. ermöglicht die volle
Authentifizierung, ohne einen externen RADIUS-Authentifizierungsserver
zu erfordern) und einen RADIUS-Authentifizierungsserver für die
EAP-Authentifizierung.
IP-Adresse und offene Ports hatte ich ja schon mit Blick in den Router (und DHCP-Server) sowie mit nmap ermittelt.

Welche Kamera? Ich hatte die Stichworte "FREDI" und "yoosee" bereits genannt. Eine echt Bezeichnung hat dieses Noname-Modell anscheinend nicht.
Ohne Werbung machen zu wollen: https://www.amazon.de/FREDI-%C3%9Cberwa ... Fredi+1080

Danke für dein Interesse.
Gruß
ernohl

Benutzeravatar
king-crash
Beiträge: 722
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von king-crash » 22.11.2018 02:19:06

Über die App lässt sich die Kamera auch steuern.
Da wäre wireshark ein erster Ansatz um den Paketverkehr mitzuschneiden.

Was meinst du mit "virtuelle IP"?
Alarmereignisse werden auf eine SD-Karte im Gerät gespeichert. Wie komme ich da ran?
Ohne anderweitige Infos aus dem Netz bleibt meines Erachtens nach nur das Öffnen des Gehäuses und Analysieren der Platine.
Was für ein Controller, externes Flash, Betriebssystem, UART Konsole?
Ich denke, das würde zu weit führen.

reox
Beiträge: 2463
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von reox » 22.11.2018 07:55:40

ernohl hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 22:27:29
Was immer geht: Ein WLAN Netz per hostapd erstellen
???
Wäre ich damit auf die virtuelle IP / das Verzeichnis onvif1 gekommen?
IP-Adresse und offene Ports hatte ich ja schon mit Blick in den Router (und DHCP-Server) sowie mit nmap ermittelt.
Virtuelle IP verstehe ich nicht ganz. Kurze Recherche zeigt, das onvif1 ein sehr häufiges verzeichnis auf solchen kameras ist - das scheint sogar eine art standard zu sein, vllt hilf das hier: https://www.onvif.org/profiles/specifications/. Aber dann hast du eh schon wireshark verwendet oder wie?
Der Sinn von Hostapd ist, das der gesamte Traffic über das Interface geht und du so mit Wireshark nichts verpasst. Da im WLAN aber sowieso immer alles übertragen wird, kannst du auch per Promiscuos mode und eingabe des Shared Key das Wlan in Wireshark sehen.
In der Theorie kannst du dann alle Pakete beobachten, welche zur Kamera gesendet werden und auch von dort weg.

Mhh ok zu der Kamera findet man wirklich nichts... Ich vermute aber, die wird nur in OEM von irgendeiner anderen Firma produziert. dH wenn du herausfindest welche Firma das "Original" baut, könntest du Glück haben.
GGf mal alle Texte auf Typenstickern oder so in die Suchmaschine deiner Wahl werfen.
Oder aufschrauben und schauen ob auf den PCBs was steht. Oft sind dort Kennzeichnungen der Hersteller drauf.
Ich hab auch gesehen, das manche von denen Telnet aufgedreht haben. Welche Ports sind denn auf der Kamera offen?

ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

Re: IoT-Gerät analysieren

Beitrag von ernohl » 22.11.2018 14:41:25

Da wäre wireshark ein erster Ansatz um den Paketverkehr mitzuschneiden.
Ich habe mich dazu etwas eingelesen und wireshark installiiert. Allerdings finde ich keine Checkbox, den Monitor-Modus zu aktivieren. Aufruf mit -I wird klaglos angenommen, hat aber anscheinend keine Wirkung.
erno@gauner:~$ cat /etc/debian_version
9.6
erno@gauner:~$ dpkg -l wireshark libcap*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-==============-============-============-=================================
un libcap-bin <keine> <keine> (keine Beschreibung vorhanden)
ii libcap-ng0:amd 0.7.7-3+b1 amd64 An alternate POSIX capabilities l
ii libcap2:amd64 1:2.25-1 amd64 POSIX 1003.1e capabilities (libra
ii libcap2-bin 1:2.25-1 amd64 POSIX 1003.1e capabilities (utili
ii wireshark 2.6.3-1~deb9 amd64 network traffic analyzer - meta-p
Wo ist mein Problem? :?:

PS. Wenn ich mich von meinem PC aus den Videostream öffne, sehe ich Pakete ohne Ende. Wenn ich den Stream nur auf dem Tablet betrachte, sehe ich in Wireshark keine Pakete. Laut Doku logisch, wenn kein Monitor-Modus aktiviert ist.
Gruß
ernohl

ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

Re: IoT-Gerät analysieren

Beitrag von ernohl » 22.11.2018 15:59:08

Ich bin jetzt auf folgende Fehlermeldung gestoßen:
The capture session could not be initiated on interface 'eth0' (That device doesn't support monitor mode).
Please check that you have the proper interface or pipe specified.
Damit lasse ich für dieses Thema die Finger von wireshark.

Benutzeravatar
MSfree
Beiträge: 10756
Registriert: 25.09.2007 19:59:30

Re: IoT-Gerät analysieren

Beitrag von MSfree » 22.11.2018 16:11:42

Die üblichen Plastikrouter haben keine Möglichkeit, den Netzwerkverkehr irgendwie mitzuschneiden. Professionelle Router, Switches und wohl auch APs haben oft Möglichkeiten, den Netzwerkverkehr über einen Monitorport zu beobachten. Wer einen Linuxrouter betreibt, kann das auch direkt auf dem Router machen.

Um den kompletten Datenverkehr eines Netzwerkgerätes (z.B. IoT-Device) mitzubekommen, kann man zwischen dem Internetrouter und dem Netzwerkgerät einen eigenständigen NAT-Router zu stecken, über den man volle Kontrolle hat.

Das kann man relativ einfach z.B. mit einem Raspberry Pi einrichten, der auf der einen Seite WLAN-AP spielt und auf der anderen Seite ins LAN per NAT durchleitet. Meldet man das Netzwerkgerät dann als WLAN-Client an so einem Raspi an, dann kann man sehr einfach mit Debiantcpdump, Debianwireshark oder auch mit Debianiptraf-ng den Netzwerkverkehr beobachten. Da kommen dann sicher einige Überraschungen zu Tage, z.B. wenn das Gerät von sich aus nach hause telefonieren will, oder trotz abgeschaltetem Cloudzugang alles in die Cloud rausposaunt.

reox
Beiträge: 2463
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von reox » 22.11.2018 16:13:04

ernohl hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 15:59:08
Ich bin jetzt auf folgende Fehlermeldung gestoßen:
The capture session could not be initiated on interface 'eth0' (That device doesn't support monitor mode).
Please check that you have the proper interface or pipe specified.
Damit lasse ich für dieses Thema die Finger von wireshark.
du kannst auch schwer den monitormode auf einem kabelinterface aufdrehen. Oder ist eth0 bei dir ein Wifi interface?
Es gibt aber genug Karten die den gar nicht können oder wo man den extra mit einem weiteren tool aufdrehen kann.

ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

Re: IoT-Gerät analysieren

Beitrag von ernohl » 22.11.2018 17:01:10

Okokok.
Gewisse Bedenken sind mir natürlich gekommen, als ich bei meinen Recherchen zum Monitoring mode ständig über 802.11 gestolpert bin.
Andererseits habe ich mich grundsätzlich gefragt, wie man in einem (verschlüsselten) WLAN den Traffic von Drittgeräten sniffen kann. Aber einmal wireshark installiert, wollte ich wenigstens schauen, was grundsätzlich damit möglich ist. Mir scheint, Auswertungsmöglichkeiten sind (fast) unendlich, sniffen kann tcpdump genauso gut. Oder?

reox
Beiträge: 2463
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von reox » 22.11.2018 17:11:09

ernohl hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 17:01:10
Andererseits habe ich mich grundsätzlich gefragt, wie man in einem (verschlüsselten) WLAN den Traffic von Drittgeräten sniffen kann.
Ja, du kannst bei Netzen mit PSK diesen eingeben und bekommst das dekodiert: https://wiki.wireshark.org/HowToDecrypt802.11
Aber einfacher ist es eben sein eigenes Netz zu machen und auf dem Gateway direkt zu sniffen.
ernohl hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 17:01:10
Mir scheint, Auswertungsmöglichkeiten sind (fast) unendlich, sniffen kann tcpdump genauso gut. Oder?
Vom Capturing is wireshark tcpdump in keinster weise überlegen. Allerdings ist es viel angenehmer dir den Traffic darin anzusehen.
Du kannst auch problemlos ein pcap mit tcpdump erzeugen und nachher in wireshark anschauen.
Die Möglichekeiten nach Paketen im Nachhinein zu filtern sind bei Wireshark wesentlich angenehmer.

ernohl
Beiträge: 1181
Registriert: 04.07.2002 08:11:56
Wohnort: HL

Re: IoT-Gerät analysieren

Beitrag von ernohl » 22.11.2018 17:50:39

Danke allen für die Hinweise. :)

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: IoT-Gerät analysieren

Beitrag von ReturnToSender » 22.11.2018 18:00:08

MSfree hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 16:11:42
Die üblichen Plastikrouter haben keine Möglichkeit, den Netzwerkverkehr irgendwie mitzuschneiden.
Dieser Thread hat mich jetzt einigermaßen beunruhigt. Den Grund kann man sich ja denken. Sind Plastikrouter solche Geräte, die man normalerweise von seinem DSL-Anbieter bei Vertragsabschluß bekommt? Wenn ja, reicht es denn nicht aus, solchen Web-Cams einfach in diesem Plastikrouter den Zugang zum Internet zu sperren. Das habe ich nämlich in meinem Router gemacht. Können die IP-Cams über ihre offenen Ports trotzdem noch raus nach China telefonieren?

mfg, RTS

Benutzeravatar
TRex
Moderator
Beiträge: 8071
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: IoT-Gerät analysieren

Beitrag von TRex » 22.11.2018 18:24:03

Der Begriff Plastikrouter mag gefallen sein, aber ich weiß zb von der Fritzbox 6340, dass dort ein Trafficmitschnitt möglich ist - der ist aber nicht durch die Menüs erreichbar, sondern nur durch die direkte Eingabe der URL in die Adressleiste. Plastikrouter ist nur eine abwertende Bezeichnung für die Consumer-orientierten Geräte, welche nicht selten stark beschnitten sind. Fritzboxen sind zwar aus Plastik, zähl ich aber nur bedingt als "Plastikrouter". Nimm mal den Schrott, den es beim ISP alternativ zur Fritzbox für weniger Geld gibt - da kräuseln sich die Fußnägel, wenn man auf der Web-UI navigieren muss. Kontrastprogramm sind so Teile wie der TL-ER6020 von tplink.

Und ja, man kann mit beiden sicher den Zugriff irgendwie unterbinden - und wenn man dafür das Kindersicherungsfoo missbrauchen muss. Am sichersten wäre natürlich ne Hardwarefirewall zwischen Internet und Gerät, aber sowas hat ja kaum einer zuhause rumstehen (mit vermutlich vielen Ausnahmen hier im Forum).

Verwechsle übrigens bitte nicht "offene Ports" (akzeptiert eingehende Verbindungen) nicht mit ausgehenden Verbindungen. Erstere sind im NAT/IPv4 per se erstmal deaktiviert (und die üblichen Plastikrouter und auch die Fritzbox haben ne Firewall auf IPv6. Ausgehende Verbindungen musst du aktiv sperren.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

ReturnToSender
Beiträge: 123
Registriert: 23.10.2018 18:06:09

Re: IoT-Gerät analysieren

Beitrag von ReturnToSender » 22.11.2018 18:30:53

TRex hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 18:24:03
Ausgehende Verbindungen musst du aktiv sperren.
Ok, ich glaube, das habe ich verstanden. Ich habe der IP-Cam eine feste IP-Adresse eingetragen, die immer gleich bleibt. Wenn ich also in der Fritzbox der Camera-IP-Adresse den Internetzugang verbiete, bin ich auf der sicheren Seite und die Cam kann nicht meine Live-Bilder nach China oder sonst wohin senden. Danke.

reox
Beiträge: 2463
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: IoT-Gerät analysieren

Beitrag von reox » 22.11.2018 19:09:25

ReturnToSender hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 18:30:53
TRex hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 18:24:03
Ausgehende Verbindungen musst du aktiv sperren.
Ok, ich glaube, das habe ich verstanden. Ich habe der IP-Cam eine feste IP-Adresse eingetragen, die immer gleich bleibt. Wenn ich also in der Fritzbox der Camera-IP-Adresse den Internetzugang verbiete, bin ich auf der sicheren Seite und die Cam kann nicht meine Live-Bilder nach China oder sonst wohin senden. Danke.
Naja also rein theoretisch könnte die Kamera eine Absenderadresse spoofen und so die IP Sperre umgehen... Wenn man den Verdacht hat, das die Kamera unkoschere Dinge tut, wäre vermutlich idealer die Kamera in ein eigenes VLAN hängen, welches keine Routen nach außen hat und nur der Port der Kamera von außen erreichbar ist.

Antworten