Einem Smart TV beim Nachhausetelefonieren zusehen

[spiralnebelverdreher]

Hallo zusammmen,
ich hatte ja letzthin diesen Diskussionsfaden gestartet viewtopic.php?f=30&t=159244 und der hat mich in meinem Entschluss bestärkt, meinem neuen Fernsehgerät (LG 32LF6509 LED-TV) den Zugang zum Internet in der FritzBox zu sperren.
Ich habe es auch unterlassen, meine Zustimmung zu Nutzungsbedingungen und Datenschutzerklärung gegenüber LG abzugeben. Ich habe auch den Hbb-TV Bedingungen der Fernsehsender (z.B. ARD) nicht zugestimmt.
In der Zwischenzeit habe ich auf meinem Raspi einen dnsmasq aufgesetzt, der für mein gesamtes LAN den Adblocker macht. Heute habe ich mal geschaut, was das Fernsehgerät denn im dnsmasq an Logspuren hinterlässt.

Code: Alles auswählen

Feb 12 18:28:27 dnsmasq[3829]: query[A] wpad.fritz.box from 192.168.178.24
Feb 12 18:28:27 dnsmasq[3829]: query[AAAA] wpad.fritz.box from 192.168.178.24
Feb 12 18:28:27 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:27 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:27 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:29 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:29 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:29 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:32 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:32 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:32 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:39 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:39 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:39 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:46 dnsmasq[3829]: query[A] srv.giraffic.com from 192.168.178.24
Feb 12 18:28:46 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:46 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:46 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:57 dnsmasq[3829]: query[A] itv.ard.de from 192.168.178.24
Feb 12 18:28:57 dnsmasq[3829]: query[AAAA] itv.ard.de from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[AAAA] fritz.box from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[AAAA] fritz.box from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:28:58 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:01 dnsmasq[3829]: query[A] http://www.google.com from 192.168.178.24
Feb 12 18:29:06 dnsmasq[3829]: query[A] clients3.google.com from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] oksdzuhdklm from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] oksdzuhdklm.fritz.box from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] bveuglachb from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] bveuglachb.fritz.box from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] sasudoekefksjga from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] sasudoekefksjga.fritz.box from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] bveuglachb from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] bveuglachb.fritz.box from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] oksdzuhdklm from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] oksdzuhdklm.fritz.box from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] sasudoekefksjga from 192.168.178.24
Feb 12 18:29:08 dnsmasq[3829]: query[A] sasudoekefksjga.fritz.box from 192.168.178.24
Feb 12 18:29:09 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:29:09 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:09 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:11 dnsmasq[3829]: query[A] ssl.gstatic.com from 192.168.178.24
Feb 12 18:29:29 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:29:29 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:29 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:44 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:29:44 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:29:44 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:30:08 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:30:08 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:30:08 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:30:27 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:30:27 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:30:27 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:31:00 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:31:00 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:31:00 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:31:23 dnsmasq[3829]: query[A] lgtvonline.lge.com from 192.168.178.24
Feb 12 18:31:23 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:31:23 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 18:33:14 dnsmasq[3829]: query[A] safebrowsing.google.com from 192.168.178.24
Feb 12 18:33:14 dnsmasq[3829]: query[AAAA] srv.giraffic.com from 192.168.178.24
Feb 12 18:33:14 dnsmasq[3829]: query[A] alt1-safebrowsing.google.com from 192.168.178.24
Feb 12 18:58:46 dnsmasq[3829]: query[A] srv.giraffic.com from 192.168.178.24
Feb 12 18:58:46 dnsmasq[3829]: query[AAAA] srv.giraffic.com from 192.168.178.24
Feb 12 19:03:46 dnsmasq[3829]: query[A] srv.giraffic.com from 192.168.178.24
Feb 12 19:03:46 dnsmasq[3829]: query[AAAA] srv.giraffic.com from 192.168.178.24
Feb 12 19:04:35 dnsmasq[3829]: query[A] itv.ard.de from 192.168.178.24
Feb 12 19:04:35 dnsmasq[3829]: query[AAAA] itv.ard.de from 192.168.178.24
Feb 12 19:04:36 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 19:04:36 dnsmasq[3829]: query[AAAA] fritz.box from 192.168.178.24
Feb 12 19:04:36 dnsmasq[3829]: query[A] fritz.box from 192.168.178.24
Feb 12 19:04:36 dnsmasq[3829]: query[AAAA] fritz.box from 192.168.178.24

Wie man sieht, sucht das Smart-TV gleich nach dem Einschalten im LAN nach einem "WPAD" Gerät - das scheint wohl so ne Art Netz-Fernbedienung zu sein. Hat mich niemand darüber informiert, aber das will ich gerne als Bemühen um Komfort durchgehen lassen.
Dann wird erstmal versucht nach Hause zu telefonieren (lgtvonline.lge.com), dann würde es gerne einen Server der Firma Giraffic (srv.giraffic.com) besuchen. Möglicherweise um eine Bezahlung für die Nutzung ihrer Netzwerkbeschleunigungs-Software anzustoßen, oder Updates zu laden, oder oder ...
Interessant ist auch noch, dass die ARD - Seite itv.ard.de besucht werden soll, obwohl ich wie gesagt dem Hbb-TV Bedningungen nicht zugestimmt habe. Google ist natürlich auch in der Liste vertreten, wer hätte anderes erwartet.
Was ich nicht so ganz verstehe, sind die Versuche Namen wie sasudoekefksjga.fritz.box aufzulösen. Die scheinen mir irgendwie zufällig ausgewürfelt zu sein. Aber so, dass eigentlich klar ist dass es die im LAN nicht geben wird. Eine Stunde später sind es dann andere zusammengewürfelte Namen wie bvaarpghx.fritz.box , die das Smart-TV gerne aufgelöst hätte. Was haben die Programmierer den mit diesen Abfragen im Sinn? Warum wollen sie im LAN Namen aufgelöst haben, die sie sich ausgewürfelt haben? Hat jemand eine Idee?

[TBT]

Der Rechner mit dem Namen wpad (Web Proxy Automatic Discovery) stellt im
Netz die Proxyinformationen bereit, die Suche danach wird normalerweise von
jedem Gerät gemacht, welches per DHCP läuft.

[MSfree]

Der Rechner mit dem Namen wpad (Web Proxy Automatic Discovery) stellt im
Netz die Proxyinformationen bereit

Korrekt und völlig unproblematisch.

die Suche danach wird normalerweise von jedem Gerät gemacht, welches per DHCP läuft.

Nein, mit DHCP hat das überhaupt nichts zu tun.

WPAD wird von Webbrowsers gesucht, um den Proxy dafür zu konfigurieren, es sei denn, man stellt dort "direkte Verbindung ins Internet" (oder ähnlich formuliert) ein. Die gängigen Webbrowser (IE, FF, Konqueror) sind auf automatische Proxykonfiguration vorkonfiguriert und suchen daher nach WPAD. Der Browser im LG-TV macht es offensichtlich auch.

Leicht OT:

Technisch gesehen ist WPAD normalerweise ein CNAME-Eintrag im DNS, der auf einen Rechner mit einem laufenden HTTP-Server (z.B. Apache, nginx...) verweist. Der Browser lädt intern, ohne manuelles zutun, das HTML-Dokument http://wpad/wpad.dat auf, und in dem könnte folgender Inhalt stehen:

Code: Alles auswählen

function FindProxyForURL(url, host)
{
  return "PROXY proxy.privates.netzwerk:8080;";
}

Auf dem Host proxy.privates.netzwerk läuft dann z.B. ein squid, der auf Port 8080 lauscht.

[reox]

Was ich nicht so ganz verstehe, sind die Versuche Namen wie sasudoekefksjga.fritz.box aufzulösen. Die scheinen mir irgendwie zufällig ausgewürfelt zu sein. Aber so, dass eigentlich klar ist dass es die im LAN nicht geben wird. Eine Stunde später sind es dann andere zusammengewürfelte Namen wie bvaarpghx.fritz.box , die das Smart-TV gerne aufgelöst hätte. Was haben die Programmierer den mit diesen Abfragen im Sinn? Warum wollen sie im LAN Namen aufgelöst haben, die sie sich ausgewürfelt haben? Hat jemand eine Idee?

Ohne das genau zu wissen: vielleicht testet das gerät den DNS Server und erwartet sich von sowas quasi einen Fehler. Wenn er dort zB ne Adresse bekommen würde macht er vllt was anderes?

[r4pt0r]

Das einzige was mir bei solchen scheinbar random zusammengewürfelten host-/domainnamen einfällt, sind C&C-Server von diversen Botnetzen. Da wird dann aber logischerweise nach öffentlichen Namen gesucht, nicht in der lokalen Domain...

Hast du nen lokalen Nameserver laufen? Dann richte doch mal spaßeshalber ein sinkhole/default-record ein, der für alles zurückgegeben wird was sonst einen NXDOMAIN erzeugen würde und schau was der smart-TV dann damit anstellt bzw was er dorthin abladen möchte. Geht z.b. ganz simpel per netcat und dump in Datei. Zum mithorchen an einer Verbindung die der TV aufbaut sind tshark/wireshark deine besten Freunde.
Um den Datenstrom auch noch zu filtern/modifizieren sind dann Mallory oder Burp Suite hervorragend geeignet, idealerweise in ner VM die der TV als router eingerichtet bekommt, oder gleich per WPAD unterjubeln wenn er sowieso danach sucht.
So ne VM als "MITM-Router" ist auch bei Fehleranalysen im Netzwerk oft Gold wert, speziell wenn man Probleme mit undokumentierten/proprietären Protokollen oder Programmen fixen muss...

[spiralnebelverdreher]

Hast du nen lokalen Nameserver laufen? Dann richte doch mal spaßeshalber ein sinkhole/default-record ein, der für alles zurückgegeben wird was sonst einen NXDOMAIN erzeugen würde und schau was der smart-TV dann damit anstellt bzw was er dorthin abladen möchte. Geht z.b. ganz simpel per netcat und dump in Datei. Zum mithorchen an einer Verbindung die der TV aufbaut sind tshark/wireshark deine besten Freunde.

Vielen Dank für deine Anregungen!

Ja, ich hab nen dnsmasq auf dem Raspi laufen (Raspi und TV stehen nahe beieinander und hängen an einem alten Hub). Ich habe in der Vergangenheit auf dem Raspi mit Tshark aufgezeichnet und das dann später mit Wireshark am PC im Arbeitszimmer ausgewertet. Weißt du zufällig wie der Eintrag bei dnsmasq lauten müsste, damit die Anfrage dieser ausgewürfelten Hostnamen funktioniert? In der letzten aufgezeichneten Sitzung waren es wieder andere Namen wie zfedaimz oder uoykoargyp.

Um den Datenstrom auch noch zu filtern/modifizieren sind dann Mallory oder Burp Suite hervorragend geeignet, idealerweise in ner VM die der TV als router eingerichtet bekommt, oder gleich per WPAD unterjubeln wenn er sowieso danach sucht.
So ne VM als "MITM-Router" ist auch bei Fehleranalysen im Netzwerk oft Gold wert, speziell wenn man Probleme mit undokumentierten/proprietären Protokollen oder Programmen fixen muss...

Ich habe auf dem Raspi bereits mitmproxy installiert und werde mich mal dran machen, die TLSv2 und TLS Verbindungen aufzubrechen, die das Gerät mit den folgenden Domains aufbauen will: DE.lgtvsdp.com, DE.info.lgsmartad.com, ssl.gstatic.com, sb.l.google.com und safebrowsing.cache.l.google.com. Die Verbindungen in Richtung ARD, ZDF, RTL und Konsorten wird unverschlüsselt aufgebaut.

Ich sehe dann noch Multicast Pakete in Wireshark wie

Code: Alles auswählen

User Datagram Protocol, Src Port: mdns (5353), Dst Port: mdns (5353)

Answers
 _alljoyn._tcp.local: type PTR, class IN, 81a64b353ab2aa9145c1c194f47500fe._alljoyn._tcp.local

 81a64b353ab2aa9145c1c194f47500fe._alljoyn._tcp.local: type SRV, class IN, priority 1, weight 1, port 9955, 
 target 81a64b353ab2aa9145c1c194f47500fe.local

die ich erstmal nicht weiter untersuchen werde.

Weitere Vorschläge sind willkommen!

[r4pt0r]

Habe das bisher nur mit BIND gebaut (redirect zones), nicht mit dnsmasq - aber eine Suche nach "<DNS-Server> NXDOMAIN redirection" bringt sicher genug brauchbare Ergebnisse. Alternativ kann auch nach "NXDOMAIN hijacking" gesucht werden - da findet man aber eher die endlosen Berichte über ISPs die damit ihren Werbemüll verteilen (T-Online war/ist da z.B. auch ganz dick dabei...).
Für reine Tests kann man auch einfach einen eigenen DNS-Server für das Subnetz des/der "bösen Geräte" bauen, der auf alle Anfragen die IP des lokalen sinkhole/MITM-proxy zurückgibt. Selbst ne umgebogene hosts-Datei auf dem Client (falls vorhanden) funktioniert - unterm Strich soll der client ja einfach nur die Verbindung zu einem kontrollierten Host aufbauen bzw darüber die Verbindung laufen lassen.


Ich würde auch mal einen Blick auf Verbindungen auf exotischeren Ports und speziell auf "nicht-HTML-Traffic" auf Port 80 werfen - Stichwort remote-Konfiguration per XML-RPC (teilweise auch SOAP) und remote updates. Da stellen sich einem meistens die Fußnägel auf was da so alles (unverschlüsselt!) durchs Netz geschoben wird - in beide Richtungen!
Nicht selten sind da so Dinge wie WLAN-Zugangsdaten, Dateinamen von Daten auf angeschlossenen USB-Sticks und andere sensible/private, nicht anonymisierte "Metadaten" dabei und in die Gegenrichtung akzeptiert das Gerät oft ungeprüft alles was an konfiguration/RPC/updates reinkommt. Dagegen sind Router mit ihren oft grausigen TR-096/SOAP-Implementierungen die reinsten Bollwerke...
Ahja: Und falls da zwischen dem ganzen XML-Rauschen doch mal was verschlüsselt aussieht: Das ist nicht selten der hochkomplizierte und unknackbare XOR-Algorithmus

[spiralnebelverdreher]

Ich würde auch mal einen Blick auf Verbindungen auf exotischeren Ports und speziell auf "nicht-HTML-Traffic" auf Port 80 werfen - Stichwort remote-Konfiguration per XML-RPC (teilweise auch SOAP) und remote updates. Da stellen sich einem meistens die Fußnägel auf was da so alles (unverschlüsselt!) durchs Netz geschoben wird - in beide Richtungen!
Nicht selten sind da so Dinge wie WLAN-Zugangsdaten, Dateinamen von Daten auf angeschlossenen USB-Sticks und andere sensible/private, nicht anonymisierte "Metadaten" dabei und in die Gegenrichtung akzeptiert das Gerät oft ungeprüft alles was an konfiguration/RPC/updates reinkommt. Dagegen sind Router mit ihren oft grausigen TR-096/SOAP-Implementierungen die reinsten Bollwerke...
Ahja: Und falls da zwischen dem ganzen XML-Rauschen doch mal was verschlüsselt aussieht: Das ist nicht selten der hochkomplizierte und unknackbare XOR-Algorithmus

Ich hab mit tshark erstmal alles mitgeschnitten was beim normalen TV-Glotzen so übers Kabel huscht, da ist nicht nur Port 80 dabei. Mir ist da bisher noch nichts groß aufgefallen - aber ich hab der Glotze ja immer noch kein OK für irgendwelche Benutzungsbedingungen und Datenschutzerklärungen gegeben. Die Sessions mit angeschlossenem USB-Stick (Fotos, Videos drauf) und Wiedergabe vom lokalen NAS kommen noch. Klein anfangen ist meine Devise.

Was meinst du mit dem XOR-Algorithmus? Symmetrische Verschlüsselung?

[r4pt0r]

Was meinst du mit dem XOR-Algorithmus? Symmetrische Verschlüsselung?

Verschlüsselung ist übertrieben - auch wenns viele Hersteller von smart-/IOT-Geräten es gerne so nennen. Es wird einfach alles ge-XORt. Die Maske ist dabei in den meisten Fällen entweder sehr kurz, einfach zu erraten (vor allem mit selbst generierten payloads = plaintext attacke), für alle Geräte identisch in der firmware hartcodiert oder wird sogar im header oder bei einem handshake mitgesendet. Oft treffen auch mehrere davon zu.

Wikipedia zu XOR-Cipher: https://en.wikipedia.org/wiki/XOR_cipher

[reox]

Das einzige was mir bei solchen scheinbar random zusammengewürfelten host-/domainnamen einfällt, sind C&C-Server von diversen Botnetzen. Da wird dann aber logischerweise nach öffentlichen Namen gesucht, nicht in der lokalen Domain...

ja nur ein DNS Request auf irgendwas ohne TLD? Die Domain ist ja nicht mal registrierbar. Könnte natürlich sein, dass die bei dem Fernseher davon ausgehen, dass ihr eigener DNS Server verwendet wird, der diese Domains auflösen kann. Keine Ahnung was das nützen soll aber wäre vorstellbar.

[MSfree]

ja nur ein DNS Request auf irgendwas ohne TLD? Die Domain ist ja nicht mal registrierbar. Könnte natürlich sein, dass die bei dem Fernseher davon ausgehen, dass ihr eigener DNS Server verwendet wird, der diese Domains auflösen kann. Keine Ahnung was das nützen soll aber wäre vorstellbar.

Man kann mit diesen scheinbar zufällig aussehenden DNS-Anfragen einen TCP-Tunnel oder sogar ein VPN betreiben:
http://analogbit.com/2008/07/27/tcp-ove ... are-howto/

Allerdings macht das diese Smart-TV nicht gerade seriöser. Das sind Techniken, die gerne in Botnetzen angewendet werden, die auf einem Haushaltsgerät rein gar ncihts zu suchen haben. Ich werden meinen Smart-TV jedenfalls weiterhin nicht an meinen Netzwerkswitch lassen sondern ihn als das Betreiben, für das er gekauft wurde: zum Fernsehen und als Motnitor für den DVD-Player.

[eggy]

Interessant wäre vielleicht mal ein Mitschnitt der DHCP Anfragen - ich könnte mir vorstellen, dass das Gerät testet, ob es sich mit dem zusammengewürfelten Namen via DHCP selbst im lokalen DNS eintragen konnte.

[eggy]

@MSfree: dann sollte da aber ne andere Domain dran sein, so kommt die Anfrage nicht am Tunnelende an

[spiralnebelverdreher]

Interessant wäre vielleicht mal ein Mitschnitt der DHCP Anfragen - ich könnte mir vorstellen, dass das Gerät testet, ob es sich mit dem zusammengewürfelten Namen via DHCP selbst im lokalen DNS eintragen konnte.

Interessanter Punkt. Ich hatte dem TV-Gerät feste Netzwerkeinstellungen verpasst und DHCP kam deshalb nicht zum Zuge. Ich könnte das natürlich auch anders einstellen und schauen was dann passiert.

[reox]

ja nur ein DNS Request auf irgendwas ohne TLD? Die Domain ist ja nicht mal registrierbar. Könnte natürlich sein, dass die bei dem Fernseher davon ausgehen, dass ihr eigener DNS Server verwendet wird, der diese Domains auflösen kann. Keine Ahnung was das nützen soll aber wäre vorstellbar.

Man kann mit diesen scheinbar zufällig aussehenden DNS-Anfragen einen TCP-Tunnel oder sogar ein VPN betreiben:
http://analogbit.com/2008/07/27/tcp-ove ... are-howto/

Genau sowas meinte ich. Evt sollen damit Daten an allen möglichen Firewalls vorbei geschleußt werden. Bei dem Tunnel ansatz muss man aber anfragen an den eignen nameserver weiterleiten (über den lokalen DNS) daher ist zumindest eine valide TLD erforderlich. das die Abfrage einfach nur hfjkhsdksdfjh ist, erscheint mir ein bisserl komisch - vielleicht kenn ich aber auch irgendwelche neuen web2.x techniken nicht und das is eigentlich ganz normal

[spiralnebelverdreher]

Ich hätte mal gerne eine Meinung von euch zu folgenden Paketen, die ich an einem Hub (mit tshark) aufgezeichnet habe. An einem Hub hängen ein Raspberry Pi (auf dem läuft u.a. tshark und dnsmasq) und ein sogenanntes Smart TV von LG (IP Adresse 192.168.178.27). Dieser Hub ist mit meiner FritzBox verbunden, in der ich dem TV-Gerät das Zugangsprofil "Gesperrt" zugeordnet habe - also keine Kommunikation aus dem LAN hinaus ins Internet (oder umgekehrt).

Das TV-Gerät fragt über DNS die Adresse eines Google Servers ab und erhält als Antwort: 173.194.112.162 - so weit so gut. Dann ist noch folgendes zu sehen:

Code: Alles auswählen

No.     Time               Source                Destination           Protocol Length Info
    130 21:10:55.068925000 192.168.178.27        173.194.112.162       TCP      74     54834 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=4294940937 TSecr=0 WS=128
Transmission Control Protocol, Src Port: 54834 (54834), Dst Port: http (80), Seq: 0, Len: 0

    131 21:10:55.069565000 173.194.112.162       192.168.178.27        TCP      74     http > 54834 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=154983558 TSecr=4294940937 WS=32
Transmission Control Protocol, Src Port: http (80), Dst Port: 54834 (54834), Seq: 0, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
    132 21:10:55.069888000 192.168.178.27        173.194.112.162       TCP      66     54834 > http [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4294940938 TSecr=154983558
Transmission Control Protocol, Src Port: 54834 (54834), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
    133 21:10:55.070034000 192.168.178.27        173.194.112.162       TCP      66     54834 > http [FIN, ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=4294940938 TSecr=154983558
Transmission Control Protocol, Src Port: 54834 (54834), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No.     Time               Source                Destination           Protocol Length Info
    144 21:10:55.074235000 173.194.112.162       192.168.178.27        TCP      66     http > 54834 [FIN, ACK] Seq=1 Ack=2 Win=14496 Len=0 TSval=154983558 TSecr=4294940938
Transmission Control Protocol, Src Port: http (80), Dst Port: 54834 (54834), Seq: 1, Ack: 2, Len: 0

No.     Time               Source                Destination           Protocol Length Info
    146 21:10:55.074598000 192.168.178.27        173.194.112.162       TCP      66     54834 > http [ACK] Seq=2 Ack=2 Win=29312 Len=0 TSval=4294940938 TSecr=154983558
Transmission Control Protocol, Src Port: 54834 (54834), Dst Port: http (80), Seq: 2, Ack: 2, Len: 0

Meine Frage dazu: Sehe ich das richtig, dass das TV-Gerät auf dem google-Server versucht eine TCP-Verbindung zu etablieren um eine http-Abfrage zu starten (weil Port 80) und dass die FritzBox diese Pakete auch nach außen durchlässt? Sie scheinen ja beantwortet zu werden. Oder spricht die Antwortzeit von 0.000640000 Sekunden dafür, dass die Antwort den Google Server nicht erreicht und von der FritzBox kommt? Eine Session mit http-Daten kommt nicht zustande und ein ping auf die Zieladresse heute Abend dauert ca 18 ms. Wie lange es zum Zeitpunkt der Aufzeichnung gedauert hätte kann ich nicht sagen, aber im WAN hatte ich noch nie Ping-Zeiten unter einer Millisekunde gesehen.

[reox]

könntest du das pcap file posten? solltest du halt nicht machen wenn dort möglicherweise passwörter drin sind oder du die mac adressen lieber für dich behälst.

Für mich schaut das so aus, als würde vom 173.194.112.162 die Anfrage beantwortet (kommt ja auch brav ein SYNACK daher).
Wenn der Router das wirklich sperren würde, würde ich mir ein RST erwarten? Was der Router da nach spezifikation machen sollte weiß ich nicht. Ist schon länger her das ich das mal lernen musste

[r4pt0r]

Wenn der Router das wirklich sperren würde, würde ich mir ein RST erwarten? Was der Router da nach spezifikation machen sollte weiß ich nicht. Ist schon länger her das ich das mal lernen musste

Liegt vermutlich daran, dass NAT eben keine Firewall ist - das blockiert nix

Der komplette 173.194.0.0/16 block ist IIRC für instanzen/hosting in der google cloud reserviert. Muss also nix (direkt) mit google zu tun haben sondern Samsung lässt dort evtl seine (datamining-)Dienste für die Smart-TVs laufen.

Um zu sehen was wirklich los ist wäre die payload nötig.

[reox]

Wenn der Router das wirklich sperren würde, würde ich mir ein RST erwarten? Was der Router da nach spezifikation machen sollte weiß ich nicht. Ist schon länger her das ich das mal lernen musste

Liegt vermutlich daran, dass NAT eben keine Firewall ist - das blockiert nix

spiralnebelverdreher schrieb ja, dass er am Router den Host auf gesperrt gesetzt hat. Klingt für mich nach "der darf nicht nach hause telefonieren". Aber da ist halt die Frage wie sie das genau machen.

[r4pt0r]

spiralnebelverdreher schrieb ja, dass er am Router den Host auf gesperrt gesetzt hat. Klingt für mich nach "der darf nicht nach hause telefonieren". Aber da ist halt die Frage wie sie das genau machen.

Evtl wird die lokale IP oder MAC vom NAT ausgenommen. Aber:

Man kann mit diesen scheinbar zufällig aussehenden DNS-Anfragen einen TCP-Tunnel oder sogar ein VPN betreiben:
http://analogbit.com/2008/07/27/tcp-ove ... are-howto/

[spiralnebelverdreher]

könntest du das pcap file posten? solltest du halt nicht machen wenn dort möglicherweise passwörter drin sind oder du die mac adressen lieber für dich behälst.

Passwörter sind in der Aufzeichnung nicht enthalten. Welchen Unfug könnte jemand treiben, wenn er die MAC-Adresse des Ethernet-Interfaces des Fernsehers bzw. meiner FitzBox erfährt?

spiralnebelverdreher schrieb ja, dass er am Router den Host auf gesperrt gesetzt hat. Klingt für mich nach "der darf nicht nach hause telefonieren". Aber da ist halt die Frage wie sie das genau machen.

Genau das ist dIe Frage, wie die Fritzbox meine Anweisung, dass ein bestimmter Host im LAN nicht nach draussen kommunizieren darf, umsetzt. Die Fritzbox könnte die Anfragen nach Verbindungsaufbau einfach in die Tonne treten. Dann würde bei der anfordernden Anwendung (z.B. Browser) aber relative lange gewartet, bis die Erfolglosigkeit bemerkt wird. Mir scheint (gestützt auf die kurze Antworzeit) eher naheliegend, dass die FritzBox (als Man-in-the-Middle) so tut, als würde eine Verbindung mit dem Server im Google-Imperium aufgebaut werden um diese dann kurze zeit später wieder ordentlich zu beenden.

Evtl wird die lokale IP oder MAC vom NAT ausgenommen. Aber:

Man kann mit diesen scheinbar zufällig aussehenden DNS-Anfragen einen TCP-Tunnel oder sogar ein VPN betreiben:
http://analogbit.com/2008/07/27/tcp-ove ... are-howto/

Der Link beschreibt einen Weg, wie man einen Tunnel für TCP (durch Hinzufügen von Payload zu DNS-Abfragen) herstellen kann. So wie ich die Abfolge und den Inhalt der Pakete deute, liegt bei mir der Tunneling-Fall nicht vor.

[spiralnebelverdreher]

Hier mal das Ergebnis eines Port-Scans auf die IP-Adresse des WLAN-Adapters am Fernseher (die MAC-Adresse ist händisch geändert):

nmap -v -sS 192.168.178.24

Code: Alles auswählen

Starting Nmap 6.00 ( http://nmap.org ) at 2016-03-20 23:11 CET
Initiating ARP Ping Scan at 23:11
Scanning 192.168.178.24 [1 port]
Completed ARP Ping Scan at 23:11, 0.09s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 23:11
Completed Parallel DNS resolution of 1 host. at 23:11, 0.00s elapsed
Initiating SYN Stealth Scan at 23:11
Scanning LGwebOSTV.fritz.box (192.168.178.24) [1000 ports]
Discovered open port 1151/tcp on 192.168.178.24
Discovered open port 3001/tcp on 192.168.178.24
Discovered open port 2009/tcp on 192.168.178.24
Discovered open port 3000/tcp on 192.168.178.24
Discovered open port 7778/tcp on 192.168.178.24
Discovered open port 9998/tcp on 192.168.178.24
Completed SYN Stealth Scan at 23:11, 1.78s elapsed (1000 total ports)
Nmap scan report for LGwebOSTV.fritz.box (192.168.178.24)
Host is up (0.013s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
1151/tcp open  unizensus
2009/tcp open  news
3000/tcp open  ppp
3001/tcp open  nessus
7778/tcp open  interwise
9998/tcp open  distinct32
MAC Address: E8:F2:E2:6D:00:00 (Unknown)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.95 seconds
           Raw packets sent: 1002 (44.072KB) | Rcvd: 1001 (40.052KB)

Sehe ich das richtig, dass möglicherweise auf dem TV Gerät (Port 3001) ein Portscanner läuft?

[DeletedUserReAsG]

Soweit mir bekannt, stammt die Zuordnung aus der /etc/services und muss daher nicht zwangsläufig etwas mit dem zu tun haben, das dort tatsächlich läuft. Nessus ist/war übrigens ‘n „bisschen“ was anderes, als ein Portscanner

Aber wenn’s Nessus/OpenVAS sein sollte, müsstest du das ziemlich gut im Browser sehen können, wenn du dich zu der Adresse verbindest.

[spiralnebelverdreher]

Soweit mir bekannt, stammt die Zuordnung aus der /etc/services und muss daher nicht zwangsläufig etwas mit dem zu tun haben, das dort tatsächlich läuft. Nessus ist/war übrigens ‘n „bisschen“ was anderes, als ein Portscanner

Aber wenn’s Nessus/OpenVAS sein sollte, müsstest du das ziemlich gut im Browser sehen können, wenn du dich zu der Adresse verbindest.

Danke für die Antwort!
Ich habe im Browser mal alle offenen Ports durchprobiert und bei zwei Ports (Nessus war nicht dabei) habe ich im Browser eine Antwort sehen können:

Port 3001:
Hello world

Port 9998:
Inspectable web views
None found, make sure that you have set the developerExtrasEnabled preference property on your WebView.

Auf Port 9998 ist die Antwort im html Header recht ausführlich:

Code: Alles auswählen

<!DOCTYPE html>
<html><head>
<script type="text/javascript">
function createPageList() {
    var xhr = new XMLHttpRequest;
    xhr.open("GET", "/pagelist.json");
    xhr.onload = function(e) {
        if (xhr.status == 200) {
            var pages = JSON.parse(xhr.responseText);
            if (pages.length)
                document.getElementById("noPageNotice").style.display = "none";

            var pageList = document.createElement("ol");
            for (var i in pages) {
                var link = document.createElement("a");
                var title = pages[i].title ? pages[i].title : ("Page " + (Number(pages[i].id)));
                var url = pages[i].url;
                link.appendChild(document.createTextNode(title + (url ? (" [" + url + "]") : "" )));
                link.setAttribute("href", pages[i].inspectorUrl);
                var pageListItem = document.createElement("li");
                pageListItem.appendChild(link);
                pageList.appendChild(pageListItem);
            }
            document.body.appendChild(pageList);
        }
    };
    xhr.send();
}

document.addEventListener("DOMContentLoaded", createPageList, false);
</script>
</head><body>
<h1>Inspectable web views</h1>
<p id="noPageNotice" style="color:grey">None found, make sure that you have set the developerExtrasEnabled preference property on your WebView.</p>
</body></html>

Hier auf 9998 scheint ein Webserver zu laufen, der wohl bereit wäre mit entsprechenden Apps zu kommunizieren.

[DeletedUserReAsG]

Wenn im Manual nix zu den offenen Ports steht, könnte man mal beim Hersteller anfragen, was es damit auf sich hat und ob er die Doku zur Verfügung stellt. Wird doch schließlich in seinem Interesse sein, wenn die Features nutzbar gemacht werden ….