Ist die TV Box infiziert?

458
Slavic

Ich habe übrigens auf meinem Computer merkwürdige Firewall-Protokolleinträge wie die folgenden bemerkt:

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 an zufälligen Ports, wie es aus dem Protokoll der Fall zu sein scheint.

Bin ich zu dem Schluss gekommen, dass die DVR-Box infiziert ist und einen Scanner für Sicherheitslücken ausführt?

UPDATE 1

Da ich ein umfassendes Bild erhalten wollte, nicht nur die Firewall blockierte den Datenverkehr, machte ich einige tcpdumps auf meinem Computer, die sich auf den betreffenden Host bezogen: tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65"(Beachten Sie, dass ich zwar auf einer WLAN-Schnittstelle höre), die TV-Box selbst ist am Ethernet, wenn es darauf ankommt)

Das Ergebnis war eine Reihe von Multicast-Anforderungen 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 mit folgendem Inhalt:

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 mir eine defekte SSDP-Implementierung nahe legen, aber jeder Input von sachkundigen Personen könnte die Situation beleuchten.

UPDATE 2

Ich habe den Schuldigen für die von der Firewall blockierte Gruppe von Nachrichten gefunden (192.168.1.65:1900 -> mein.computer:random_port). Google Chrome hielt jede Minute etwa so lange Multicasting-Anfragen zur SSDP-Erkennung. Aufgrund der Art der Codierung verwenden diese Anforderungen scheinbar zufällige Ports. Wenn eine legitime Antwort von der TV-Box kam, wurde sie gesperrt.

Dies klärt die erste Gruppe von Nachrichten. Ich möchte immer noch wissen, was die zweite Gruppe verursacht.

0
** 192.168.1.70 ** ist eine Intranet-Adresse, die außerhalb Ihres Netzwerks nicht vorhanden ist Ramhound vor 6 Jahren 0
"Bin ich zu Recht zu dem Schluss gekommen, dass die DVR-Box infiziert ist und einen Schwachstellenscanner ausführt?" - Nein; Es wäre nicht richtig, das anzunehmen. Ramhound vor 6 Jahren 1
@Ramhound ja - das ist tatsächlich eine Intranetadresse. Inwiefern widerspricht das meiner Hypothese? Slavic vor 6 Jahren 0
UDP 1900 ist oder sollte [SSDP aka UPnP] sein (https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol). Gibt es etwas auf Ihrem Rechner, das UPnP-Anfragen senden würde? Beachten Sie, dass die Anforderungen an Multicast gesendet werden. Dies kann dazu führen, dass Ihre Firewall diese Antworten nicht als zusammengehörig erkennt (vorausgesetzt, sie ist wie üblich so eingestellt). dave_thompson_085 vor 6 Jahren 0
@ dave_thompson_085 Wäre die Maschine in diesem Fall nicht an scheinbar zufällige Ports, sondern auch an 1900 zu senden? Slavic vor 6 Jahren 0
@Slavic - Im schlimmsten Fall würden Sie sich selbst angreifen, aber das passiert nicht. Ramhound vor 6 Jahren 0
Ihr Computer sendet die Anforderungen _von _ zufällig, vorübergehende Ports an 1900 (nicht blockiert und nicht protokolliert), und erhält dann _ _ Antworten auf diese Ports. dave_thompson_085 vor 6 Jahren 0

1 Antwort auf die Frage

1
interoperability

Dies kann aus einer Vielzahl von Gründen geschehen. Springen Sie also nicht zu schnell zu Schlussfolgerungen. Viele internetfähige Geräte führen in regelmäßigen Abständen oder wenn bestimmte Bedingungen erfüllt sind, Scans eines Netzwerks durch. Da Ersteres nicht der Fall zu sein scheint, hat der DVR möglicherweise eine Änderung im Netzwerk erkannt, beispielsweise ein neues Gerät, das Pakete sendet, eine Änderung der Netzwerksicherheit, bei der der vorinstallierte Schlüssel gleich geblieben ist (z. B. WPA to.) WPA2) oder sogar einen Unterschied in den Protokollversionen, die durch ein automatisches Update des Routers ausgelöst werden. Dies sind nur einige Gründe, warum das Gerät diese Aktion ausführen würde.

Mein Rat an Sie ist, einen Netzwerk-Scan durchzuführen. Sie können dies mit einer Vielzahl von Tools tun, z. B. NMap, einem sehr beliebten kostenlosen Netzwerk-Mapping-Tool, das Befehlszeilen- und grafische Optionen bietet. NMap und die meisten anderen Netzwerk-Mapping-Tools bieten eine Vielzahl von Details zu den zugeordneten Geräten. Ich empfehle Ihnen daher, Ihr Netzwerk abzubilden und verdächtige IP-Adressen auszurotten. Mit der modernen Fülle an ISP-erzwungener Port-Filterung und netzwerkweiten Firewalls, die standardmäßig aktiviert sind, kommen die meisten Angriffe nun aus dem Netzwerk (z. B. hat ein Angreifer in der Nähe Zugriff auf Ihr Wi-Fi-Netzwerk erhalten und protokolliert böswillige Angriffe). Daher ist das Mapping Ihres Netzwerks die beste Wahl, um bösartige Entitäten zu finden. Sie können auch ein Netzwerkerkennungssystem einsetzen, wie zSnort . Vorausgesetzt, Sie verwenden ein drahtloses Netzwerk, besteht der erste logische Schritt darin, den vorinstallierten Schlüssel (oder "Kennwort") in einen starken, vorzugsweise zufällig generierten Schlüssel zu ändern. Wie bereits erwähnt, kommen die meisten Angriffe aus Ihrem Netzwerk. Wenn der Angreifer nicht dauerhaft auf ein Gerät in Ihrem Netzwerk und / oder physischen Zugriff auf Ihren Router hat, werden viele Angreifer zumindest vorübergehend angehalten.

Ich sollte hinzufügen, dass der DVR dies kontinuierlich macht. Ungefähr 15 Mal pro Minute. Schon immer. Beachten Sie auch die verschiedenen Anschlüsse. Slavic vor 6 Jahren 0
Ich bin nicht sicher, ob ich folge - was versuche ich mit einem Netzwerkscan herauszufinden? Slavic vor 6 Jahren 0
Ihr Q zeigt alle 2 Minuten 4, nicht 15 pro Minute. dave_thompson_085 vor 6 Jahren 0
@Slavic Entschuldigung, wenn das nicht klar war. Der Zweck eines Netzwerk-Scans besteht darin, potenzielle Angreifer im Netzwerk zu finden. interoperability vor 6 Jahren 0
Wie Sie anhand von Updates und Kommentaren sehen können, habe ich einige Fortschritte bei der Erkennung des verrückten Verkehrs gemacht. Ich weiß immer noch nicht, warum die dvr-Multicasts auf Port 8082 (von scheinbar zufälligen Ports) sind, aber ich bin zumindest der Meinung, dass es sich nicht um eine Infektion handelt, sondern um eine seltsame [mis] -Konfiguration. Slavic vor 6 Jahren 0
@Slavic Die Begründung kann in der Dokumentation (Handbücher, technische Unterlagen usw.) der TV-Box beschrieben werden. Oder Sie können immer versuchen, über die Befehlszeile Zugriff zu erhalten, und führen Sie einfach `netstat -tulpn` aus, um herauszufinden, welche Programme auf welchen Ports laufen. interoperability vor 6 Jahren 0