☰

Ist die TV-Box infiziert?

tag-icon • tag-icon upnp iptv
Ist die TV-Box infiziert?

Mir sind übrigens merkwürdige Firewall-Logeinträge wie die folgenden auf meinem Rechner aufgefallen:

Apr  1 22:17:56 slavic-probook kernel: [23623.091873] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=39529 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303 
Apr  1 22:17:57 slavic-probook kernel: [23624.092666] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=39622 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303 
Apr  1 22:17:58 slavic-probook kernel: [23625.094162] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=40181 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303 
Apr  1 22:17:59 slavic-probook kernel: [23626.094239] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=40237 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303

Das Gerät mit der SRC-IP-Adresse ist eine Telus DVR-Box, die an den Smart TV angeschlossen ist. Ich sehe keinen Grund, warum eine TV-Box versuchen sollte, Nachrichten an Computer im Netzwerk zu senden, insbesondere über zufällige Ports, wie es laut Protokoll der Fall zu sein scheint.

Gehe ich recht in der Schlussfolgerung, dass die DVR-Box infiziert ist und einen Schwachstellenscanner ausführt?

AKTUALISIERUNG 1

Da ich mir ein umfassendes Bild machen wollte und nicht nur den von der Firewall blockierten Datenverkehr sehen wollte, führte ich auf meinem Computer einige TCPdumps in Bezug auf den betreffenden Host aus: tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65"(Beachten Sie, dass die TV-Box selbst über Ethernet verbunden ist, obwohl ich über eine WLAN-Schnittstelle lausche, falls das wichtig ist)

Das Ergebnis war eine Reihe von Multicast-Anfragen wie diese:

01:59:17.410558 IP (tos 0xa0, ttl 1, id 9041, offset 0, flags [DF], proto UDP (17), length 564)
    192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:20.482689 IP (tos 0xa0, ttl 1, id 11391, offset 0, flags [DF], proto UDP (17), length 564)
    192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:23.350033 IP (tos 0xa0, ttl 1, id 14259, offset 0, flags [DF], proto UDP (17), length 564)
    192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:26.421815 IP (tos 0xa0, ttl 1, id 16051, offset 0, flags [DF], proto UDP (17), length 564)
    192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:29.494329 IP (tos 0xa0, ttl 1, id 17699, offset 0, flags [DF], proto UDP (17), length 564)
    192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536

jede der Nachrichten hat einen Inhalt wie diesen:

NOTIFY * HTTP/1.1
x-type: dvr
x-filter: f0e4ba33-5680-459b-8c3d-a4fdeffdb2f9
x-lastUserActivity: 4/2/2018 7:26:29 AM
x-location: http://192.168.1.65:8080/dvrfs/info.xml
x-device: 0d90b7cc-3fc2-4890-b2b9-8f7026732fd6
x-debug: http://192.168.1.65:8080

<node count='7102'><activities><schedver dver='3' ver='57' pendcap='True' /><x/><p15n stamp='08D514D5EC333DF818B81F27ED06'/><recordver ver='46' verid='355872864' size='962072674304' free='952610324480' /><x/></activities></node>

dann ab und zu die bekannten, von der Firewall blockierten Anfragen:

02:02:28.005207 IP (tos 0xa0, ttl 64, id 34066, offset 0, flags [DF], proto UDP (17), length 323)
    192.168.1.65.1900 > 192.168.1.70.53280: [udp sum ok] UDP, length 295
02:02:28.900119 IP (tos 0xa0, ttl 64, id 34258, offset 0, flags [DF], proto UDP (17), length 323)
    192.168.1.65.1900 > 192.168.1.70.53280: [udp sum ok] UDP, length 295

mit Inhalt:

HTTP/1.1 200 OK
LOCATION: http://192.168.1.65:56790/dd.xml
CACHE-CONTROL: max-age=1800
EXT:
BOOTID.UPNP.ORG: 1
SERVER: Linux/2.6 UPnP/1.1 quick_ssdp/1.1
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:0d90b7cc-3fc2-4890-b2b9-8f7026732fd6::urn:dial-multiscreen-org:service:dial:1

Dies würde für mich auf eine fehlerhafte SSDP-Implementierung schließen, aber jeder Input von sachkundigen Leuten könnte Licht in die Situation bringen.

AKTUALISIERUNG 2

Ich habe den Schuldigen für die Gruppe von Nachrichten gefunden, die von der Firewall blockiert wurden (192.168.1.65:1900 -> mein.Computer:random_port). Google Chrome hat etwa jede Minute SSDP-Erkennungsanfragen per Multicast gesendet. Aufgrund der Codierung verwenden diese Anfragen scheinbar zufällige Ports, und wenn eine legitime Antwort von der TV-Box kam, wurde sie blockiert.

Damit ist die erste Gruppe von Meldungen geklärt. Ich wüsste noch gern, was die Ursache für die zweite Gruppe ist.

Antwort1

Dies kann aus einer Vielzahl von Gründen geschehen, ziehen Sie also nicht zu schnell Schlussfolgerungen. Viele internetfähige Geräte führen in regelmäßigen Abständen oder bei Erfüllung bestimmter Bedingungen Netzwerkscans durch. Da Ersteres nicht der Fall zu sein scheint, hat der DVR möglicherweise eine Änderung im Netzwerk erkannt, z. B. ein neues Gerät, das Pakete sendet, eine Änderung der Netzwerksicherheit, bei der der Pre-Shared Key gleich geblieben ist (z. B. von WPA zu WPA2), oder sogar einen Unterschied in den Protokollversionen, der durch ein automatisches Update des Routers ausgelöst wurde. Dies sind nur einige Gründe, warum das Gerät diese Aktion ausführen würde.

Ich rate Ihnen, einen Netzwerkscan durchzuführen. Sie können dies mit verschiedenen Tools tun, wie zum BeispielNMap, ein sehr beliebtes kostenloses Tool zur Netzwerkzuordnung, das sowohl Befehlszeilen- als auch grafische Optionen bietet. NMap und die meisten anderen Tools zur Netzwerkzuordnung bieten viele Details zu den zugeordneten Geräten, daher würde ich vorschlagen, Ihr Netzwerk zuzuordnen und alle verdächtigen IP-Adressen auszumerzen. Angesichts der modernen Fülle von ISP-erzwungenen Portfiltern und „standardmäßig aktivierten“ netzwerkweiten Firewalls kommen die meisten Angriffe heute von innerhalb des Netzwerks (z. B. hat sich ein Angreifer in der Nähe Zugriff auf Ihr WLAN-Netzwerk verschafft, sich angemeldet und bösartige Angriffe gestartet). Daher ist die Zuordnung Ihres Netzwerks Ihre beste Möglichkeit, bösartige Entitäten zu finden. Sie können auch ein Netzwerk-Intrusion-Detection-System wie verwendenSchnauben. Vorausgesetzt, Sie verwenden ein drahtloses Netzwerk, wäre der erste logische Schritt, den vorinstallierten Schlüssel (oder das „Passwort“) in einen starken, vorzugsweise zufällig generierten Schlüssel zu ändern. Wie bereits erwähnt, erfolgen die meisten Angriffe innerhalb Ihres Netzwerks. Sofern der Angreifer also keinen dauerhaften Zugriff auf ein Gerät in Ihrem Netzwerk und/oder physischen Zugriff auf Ihren Router hat, wird dies viele Angreifer zumindest vorübergehend stoppen.

verwandte Informationen