☰

A caixa de TV está infectada?

tag-icon • tag-icon upnp iptv
A caixa de TV está infectada?

Incidentalmente, notei entradas estranhas de log do 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 SRC é uma caixa 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 ao concluir que a caixa do DVR foi infectada e está executando algum scanner de vulnerabilidade?

ATUALIZAÇÃO 1

Como eu queria ter uma visão completa, não apenas o firewall bloqueando o tráfego, fui em frente 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 esteja ouvindo em uma interface wifi , a própria caixa de TV está em Ethernet, se for o caso)

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 com 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>

então, de vez em quando, as solicitações familiares bloqueadas pelo 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

Isto sugerir-me-ia uma implementação falha do SSDP, mas qualquer contribuição de pessoas com conhecimento poderia lançar luz sobre a situação.

ATUALIZAÇÃO 2

Encontrei o culpado pelo grupo de mensagens bloqueadas pelo firewall (192.168.1.65:1900 -> my.computer:random_port). O Google Chrome continuou transmitindo solicitações de descoberta de SSDP a cada minuto ou mais. Devido à forma como são codificados, essas solicitações utilizam portas aparentemente aleatórias e, portanto, quando uma resposta legítima vem da TV Box, ela é bloqueada.

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

Responder1

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

Meu conselho para você é executar uma verificação de rede. Você pode fazer isso usando uma variedade de ferramentas, comoNMapa, uma ferramenta gratuita de mapeamento de rede muito popular que oferece opções gráficas e de linha de comando. O NMap e a maioria das outras ferramentas de mapeamento de rede fornecem muitos detalhes sobre os dispositivos mapeados, então sugiro mapear sua rede e erradicar quaisquer endereços IP suspeitos. Com a abundância moderna de filtragem de portas imposta pelo ISP e firewalls "ativados por padrão" em toda a rede, 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 intrusão de rede, comoBufar. Desde que você esteja usando uma rede sem fio, o primeiro passo lógico seria alterar a chave pré-compartilhada (ou “senha”) para uma chave forte, de preferência gerada aleatoriamente. Como mencionado anteriormente, a maioria dos ataques vem de dentro da sua rede, portanto, a menos que o invasor tenha acesso persistente a um dispositivo na sua rede e/ou tenha acesso físico ao seu roteador, isso impedirá muitos invasores, pelo menos temporariamente.

informação relacionada