McAfee enviando tráfego na porta UDP 2054: esse comportamento é esperado?

Question 1

Isenção de responsabilidade: Eu não trabalho e não trabalhei na McAfee (ou na Intel). Não fiz auditorias de segurança em produtos McAfee.

Descobertas e hipóteses

O que você vê é o ARP sendo enviado por UDP por motivos desconhecidos. Eu diria que o trânsito ésuspeito.Pelo menos, é suspeito o suficiente que você pergunte sobre isso.

Minha primeira hipótese foi que se tratava de algum tipo de VPN. Você tem uma VPN? Se o que parece ser uma rede local estiver realmente funcionando na Internet, uma implementação de VPN que envie ARP por UDP pode fazer sentido.

Selecionando a porta 2054 para ARPtipo defaz sentido, porque oTipo Éterpara ARP é 2054 (0806 ₁₆ ).

Minha segunda hipótese é que a McAfee usa isso como uma forma de verificação dupla do ARP ou como uma tentativa de corrigir a falsificação de ARP. eu encontreinenhuma documentação sobre a McAfee que precisa da porta UDP 2054. Assim podemos dizereste não é um comportamento esperado.Eu me pergunto se isso é segurança pela obscuridade, espero que não seja.

Mesmo que a segunda hipótese esteja correta, pode ser um sintoma de outro problema.

Minha terceira hipótese seria um McAfee comprometido, mas não sei por que um malware que pode comprometer o McAfee enviaria esse tipo de tráfego...

... Exceto, talvez, que foi feito por um desenvolvedor que não entendeu a diferença entre um EtherType e uma porta (algumas documentações e ferramentas escritas livremente referem-se ao EtherType como portas de quadro Ethernet -exemplo).

Observe também que existem ferramentas que facilitam a criação de malware, permitindo que o usuário malicioso selecione uma carga útil e a envolva automaticamente no código necessário para propagação e infecção.

Minha quarta e última hipótese é que se trata de um bug do McAfee, que espero que tenham sido corrigidos em uma versão mais recente.

Investigar

Existe software escutando a porta UDP 2054 nas outras máquinas? Qual software é esse?
A McAfee na máquina remetente também está escutando a porta UDP 2054?
A McAfee alguma vez recebe uma resposta? Como é a resposta?

Eu sugiro correrWiresharkna máquina com o McAfee e outra máquina e capture quais pacotes eles trocam.

Sob a hipótese de que este seja um bug no McAfee ou tenha sido comprometido, sugiro verificar se o Windows e o McAfee estão atualizados e em boa integridade ( sfc /scannowpara Windows, assinaturas digitais executáveis para McAfee - presumo que sim, é melhor que tenham, ser de uma empresa de segurança).

Você também pode estar interessado em usar Autoruns e Procexp deSuíte Sysinternalspara verificar assinaturas e enviar amostras paraVirusTotalde software na inicialização (Autoruns) e em execução (Procexp).Dica profissional: Você pode executar Autoruns a partir do Mini Windows que vemBootCD de Hirene peça para ele analisar um sistema off-line, garantindo que o Autoruns não tenha sido comprometido pelo malware.

Se você acredita que tem um malware que comprometeu a máquina, considere usar um ISO de resgate ou uma solução antimalware de inicialização USB, pois seria praticamente impossível comprometê-los pelo malware.

Espero que você não precise invocar o fogo purificador.

Precedentes

Eu encontrei outrocaso da porta UDP 2054 no techsupportforum. Nesse caso, aparentemente a solução foi ~~purificar o fogo~~ e reinstalar o Windows.

Também encontrei casos de problemas com outras portas (aqui, eaqui).

Análise de Captura de Tráfego

Eu dei uma olhada na captura que você compartilha. Este foi meu processo de trabalho:

Se você realmente capturou um datagrama UDP enviado para a porta 2054, a porta de destino deverá ser a captura. 2054 em hexadecimal é 0806 e, com certeza, está no meio da segunda linha.

Portanto, temos:

/* ... data ... */
0806    Destination Port (2054)
/* ... data ... */

Agora, olhando para oCabeçalho UDP, Nós temos:

/* ... data ... */
/* UDP start */
d13b    Source Port (53563)
0806    Destination Port (2054)
0024    Length (36 bytes)
ba22    Checksum
/* ... data ... */

Não verifiquei a soma de verificação. Verifiquei o comprimento (que vai do início ao fim do cabeçalho UDP) e está correto.

Isso deve estar em um pacote IP. Então, vamos pegar oCabeçalho IP:

/* IP start */
4500    Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038    Total length (56 bytes)
16c5    Identification
0000    Flags & Fragment offset (unique fragment)
8011    TTL (128 hops)  Protocol (UDP)
d2c9    Header checksum
0a14    \
1e01    -> Source IP address (10.20.30.1)
0a14    \
1efe    -> Destination IP address (10.20.30.254)
/* UDP start */
d13b    Source Port (53563)
0806    Destination Port (2054)
0024    Length (36 bytes)
ba22    Checksum
/* ... data ... */

Vemos que 10.20.30.1 está enviando um datagrama UDP para 10.20.30.254. Nada chique. Novamente, verifiquei o comprimento, mas não a soma de verificação.

E o resto dos dados? Isso me levou um pouco para adivinhar. Qual protocolo envia um MAC? Bem, isso seria ARP, mas o ARP não roda em cima do UPD, certo?

Bem,ARPcorresponde:

/* IP start */
4500    Version (IPv4) IHL (20 bytes) Differentiated Services (Default Forwarding)
0038    Total length (56 bytes)
16c5    Identification
0000    Flags & Fragment offset (unique fragment)
8011    TTL (128 hops)  Protocol (UDP)
d2c9    Header checksum
0a14    \
1e01    -> Source IP address (10.20.30.1)
0a14    \
1efe    -> Destination IP address (10.20.30.254)
/* UDP start */
d13b    Source Port (53563)
0806    Destination Port (2054)
0024    Length (36 bytes)
ba22    Checksum
/* ARP start */
0001    Hardware Type (Ethernet)
0800    Protocol type (IPv4)
0604    Hardware length (6 bytes, MAC) Protocol length (4 bytes, IPv4)
0001    Operation (Request)
XXXX    \
XXXX    -> Sender hardware address (sender's MAC address)
XXXX    /
0a14    \
1e01    -> Sender protocol address (10.20.30.1)
ffff    \
ffff    -> Target hardware address (ignored in Operation = Request)
ffff    /
0a14    \
1efe    -> Target protocol address (10.20.30.254)

O ARP deve ser executado diretamente no topo do quadro, da mesma forma que o IP é executado. Em vez disso, é o ARP rodando sobre o UDP (que roda sobre o IP).

Porém, se olharmos apenas para a solicitação ARP, o que ela está fazendo? Parece estar pedindo 10.20.30.254 pelo seu MAC. Exceto, você sabe, ele está perguntando por UDP.

Answer