O Box da TV está infectado?

Question

Eu, incidentalmente, notei estranhas entradas de log de firewall como as seguintes no meu computador:

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

O dispositivo com o endereço IP do SRC é uma caixa do Telus DVR, conectada à Smart TV. Não vejo razão para que uma TV Box tente enviar mensagens para computadores na rede, especialmente em portas aleatórias, como parece ser o caso do log.

Estou certo em concluir que a caixa do DVR foi infectada e está executando algum scanner de vulnerabilidades?

UPDATE 1

Como queria ter uma imagem completa, não apenas o tráfego bloqueado pelo firewall, prossegui e executei alguns tcpdump-s no meu computador, relacionados ao host em questão: tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65" (observe que, embora eu ' m escutando em uma interface wifi, a própria caixa de TV está na Ethernet, se for importante)

O resultado foi um monte de solicitações multicast como estas:

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

cada uma das mensagens contendo conteúdo como este:

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>

depois, de vez em quando, as solicitações familiares bloqueadas por firewall:

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  

com conteúdo:

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

Isso me sugeriria uma falha na implementação do SSDP, mas qualquer contribuição de pessoas instruídas poderia esclarecer a situação.

UPDATE 2

Eu encontrei o culpado pelo grupo de mensagens bloqueadas pelo firewall (192.168.1.65:1900 - > my.computer:random_port). O Google Chrome manteve a multidifusão de solicitações de descoberta do SSDP a cada minuto. Devido à forma como é codificado, esses pedidos usam portas aparentemente aleatórias e, assim, quando uma resposta legítima veio da TV Box, ela foi bloqueada.

Isso esclarece o primeiro grupo de mensagens. Eu gostaria de saber o que causa o segundo grupo.

    

Answer 1

Isso pode estar acontecendo por vários motivos, por isso não tire conclusões precipitadas com muita rapidez. Muitos dispositivos habilitados para a Internet realizam varreduras de uma rede periodicamente ou quando certas condições são atendidas. Como o primeiro não parece ser o caso, o DVR pode ter detectado uma mudança na rede, como um novo dispositivo enviando pacotes, uma mudança na segurança da rede na qual a chave pré-compartilhada permanecia a mesma (ou seja, WPA para WPA2), ou até mesmo uma diferença nas versões do protocolo, desencadeada por uma atualização automática do roteador. Estas são apenas algumas das razões pelas quais o dispositivo executaria essa ação.

Meu conselho para você é executar uma varredura de rede. Você pode fazer isso usando uma variedade de ferramentas, como NMap , uma ferramenta de mapeamento de rede gratuita muito popular que oferece linha de comando e opções gráficas. O NMap e a maioria das outras ferramentas de mapeamento de rede fornecem muitos detalhes sobre os dispositivos mapeados, portanto sugiro mapear sua rede e eliminar endereços IP suspeitos. Com a abundância moderna de filtragem de portas reforçada por ISP e firewalls de rede "habilitados por padrão", os ataques mais comuns agora vêm de dentro da rede (por exemplo, um invasor próximo obteve acesso à sua rede Wi-Fi e registrou e lançou ataques maliciosos). Portanto, mapear sua rede será sua melhor aposta para encontrar entidades maliciosas. Você também pode empregar um sistema de detecção de invasão de rede, como Snort . Desde que você esteja usando uma rede sem fio, a primeira etapa lógica seria alterar a chave pré-compartilhada (ou "senha") para uma chave strong, de preferência gerada aleatoriamente. Como mencionado anteriormente, a maioria dos ataques é proveniente de sua rede, a menos que o invasor tenha acesso persistente a um dispositivo em sua rede e / ou tenha acesso físico ao seu roteador, isso impedirá muitos invasores, pelo menos temporariamente.