Re: [GTER] Falha de segurança no serviço Vírtua Empresarial

[Paulo Condutta]

Andre blz,

Fui eu que fiz a reclamação na lista da Conetiva a qual vc se referiu.

Realmente, a Viruta gera um broadcast de requisições ARP muito perigosas 
alem de ocupar uma banda de pelo menos 15 Kbps durante todo o dia.

Efetuei varios chamados junto a Virtua reclamando que esse trafego nao 
poderia chegar até o cliente mas segundo foi dito, essa é uma caracteristica 
das comunicações via cabo utilizada pela Virtua e que nao seria possivel 
remoer esse trafego. Não conheço outras conexões via cabo utilizadas no 
Brasil mas parece que em outros paisoes tem operadoras que fazem da mesma 
forma que a Virtua.

Questionei quando a parte de segurança ma nada foi dito e ficou nessa.

Abraços

----- Original Message ----- 
From: "André Carezia" <andre at carezia.eng.br>
To: <gter at eng.registro.br>
Cc: <cert at cert.br>
Sent: Wednesday, August 03, 2005 6:11 PM
Subject: [GTER] Falha de segurança no serviço Vírtua Empresarial


Saudações,

Não sei se há no Brasil um lugar melhor para divulgar isso. Apreciarei
sugestões.

No dia 17/julho, um de meus clientes contratou o serviço Vírtua
Empresarial. Ao contrário do Vírtua Home, esse serviço possui IP fixo.

Quando observei o comportamento do tráfego, notei um elevado nível
residual. Esse resíduo responde por mais de 10% da banda de 600kbps do
serviço contratado, e é composto somente por pacotes do tipo ARP. Uma
captura com "tcpdump" à noite mostra tráfego constante e similar ao
trecho reproduzido abaixo:

   03.955641 arp who-has 201.6.40.70 tell 201.6.40.1
   03.975855 arp who-has 201.6.37.135 tell 201.6.36.1
   03.976275 arp who-has 201.6.56.192 tell 201.6.56.1
   03.984144 arp who-has 201.6.57.49 tell 201.6.56.1
   03.994188 arp who-has 201.6.169.52 tell 201.6.168.1
   04.021162 arp who-has 201.6.149.140 tell 201.6.149.1
   04.030519 arp who-has 201.6.168.120 tell 201.6.168.1
   04.044434 arp who-has 201.6.37.190 tell 201.6.36.1
   04.050012 arp who-has 201.6.176.202 tell 201.6.176.1
   04.062734 arp who-has 201.6.178.61 tell 201.6.176.1
   04.069215 arp who-has 201.6.48.135 tell 201.6.48.1
   04.088061 arp who-has 201.6.37.113 tell 201.6.36.1
   04.088602 arp who-has 201.6.106.86 tell 201.6.104.1
   04.091149 arp who-has 201.6.119.5 tell 201.6.118.1
   04.123058 arp who-has 201.6.172.207 tell 201.6.172.1
   04.125463 arp who-has 201.6.46.132 tell 201.6.44.1
   04.127947 arp who-has 201.6.50.238 tell 201.6.48.1
   04.222447 arp who-has 201.6.46.224 tell 201.6.44.1
   04.222872 arp who-has 201.6.105.134 tell 201.6.104.1
   04.230189 arp who-has 201.6.46.126 tell 201.6.44.1

Há dois problemas com esse tráfego:

  1. Ocupação artificial da banda com tráfego espúrio e não utilizado
pelo cliente;
  2. Possibilidade de seqüestro de qualquer endereço IP na faixa 201.6.x.x

O problema 2 é mais sério. Esse tráfego ARP de todas as faixas não
deveria chegar ao cliente. Essa operação em modo "broadcast" é insegura,
e permite que qualquer cliente cause um ataque DoS ("denial of service")
em toda a faixa de 65 mil endereços.

Devo salientar que esse ataque é *muito* simples, e ficaria surpreso se
já não estivesse ocorrendo.

Pior: tudo leva a crer que seja possível (não cheguei a testar), com a
falsificação do código MAC do lado do cliente, não só um ataque DoS mas
a comunicação plena com endereços arbitrários e simultâneos por *um
mesmo cliente*.

Os sintomas são de conhecimento público, como atestado por reclamação em
lista de discussão da Conectiva em dez/2004:


http://distro.conectiva.com.br/pipermail/seguranca/2004-December/005162.html


A técnica de "broadcast" ARP é conhecida e condenada por suas falhas de
segurança desde 2001:

   http://marc.theaimsgroup.com/?l=vuln-dev&m=98579844226689&w=2
   http://marc.theaimsgroup.com/?l=vuln-dev&m=98585081227823&w=2
   http://marc.theaimsgroup.com/?l=vuln-dev&m=98584801021412&w=2

Uma nota semelhante a esta foi enviada no dia 18 para a equipe de
segurança do Virtua. Não houve resposta. O suporte técnico telefônico
foi contactado duas vezes, e nenhuma providência foi tomada até agora.

Se alguém tiver idéia de como proceder para que eles se importem com o
problema e o corrijam, ficarei agradecido.

[]s,

-- 
André Carezia
Eng. de Telecomunicações
Carezia Consultoria - www.carezia.eng.br

--
gter list    https://eng.registro.br/mailman/listinfo/gter