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

[scsantos@unigranrio com br]

Bom dia,

Como evitar isso numa rede onde não há o interesse de divulgação de MAC 
entre clientes?

Um fraterno abraço !!!

       Silvio Cesar L. dos Santos
   Divisão de Tecnologia da Informação
Universidade do Grande Rio - UNIGRANRIO
-----------------------------------------
  (o_
  //\            - Software Livre -
  V_/_    conhecimento ao alcance de todos


"O próximo grande salto evolutivo da
humanidade será a descoberta de que
cooperar é melhor que competir"

Prof. Pietro Ubaldi


André Carezia wrote:
> 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,
>