Vulnerabilidade no TCP afeta todos os sistemas

Alguém tem alguma idéia se o Kernel do Linux tem alguma correção ?
Pelo que li pode-se corrigir o problema se a tal "janela" da sequência de indentificação não for aceita.

do site q publicou a noticia original:

"The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports."

Nao estamos assim tao "ferrados". o atacante precisa saber portas de origem e destino, bem como enderecos de origem e destino, pra depois mandar um TCP-RESET ou FYN (derrubando a conexao)

Spoof ja eh tecnica conhecida a bastante tempo, e sobrevivemos ate agora :)

Claro que ha possibilidades de DoS e talvez ate adulteracao/inclusao de dados numa sessao TCP convencional, mas ja se fala disso a bastante tempo.

Tao fazendo meio q uma tempestade nessa historia. Segundo as informacoes do site, o mais problematico seria o protocolo BGP, q depende de sessoes TCP ad eternum (dando tempo ao camarada de tentar N portas/enderecos TCP origem e destino spoofados ou usar outras ferramentas mencionadas naquele site ate derrubar a sessao)

me corrigam se eu estiver errado :) (nao vele corrigir o portugues)

thefallen está certo.

O problema é antigo e se baseia em uma fraqueza do protocolo TCP: sequencial number.

Antigamente ele era mais problemático, já que o incremento do mesmo nas sessões era uma constate, sendo possível prever com facilidade qual seria o próximo pacote a ser aceito durante uma sessão tcp. Curiosamente, foi utilizando está técnica + spoofing + source route que o Mitnick invadiu a máquina do Shimomura, no famoso caso que acabou metendo ele atrás das grades.

Atualmente as pilhas TCP implementam uma janela TCP com Sequencial Numbers com ordem crescente randômica, o que dificulta muito esta técnica (menos o windows 98, por motivos óbvios).

O problema acaba sendo crítico para o protocolo BGP utilizado por roteadores para troca de informações. Por utilizar conexões TCP persistentes (ou seja, tamanhos de janela grandes) ele é mais sussetível a esse tipo de ataque, pois é mais fácil 'chutar' um pacote TCP com Sequencial number dentro este range maior, acabando sendo aceito. Se alguém consegue faze-lo, spoofando um pacote com flag RST (reset) ele acaba com a conexão criando uma situação de DoS.

Logo o ataque é perigoso proporcionalmente ao tamanho das janelas TCP. O problema não é o usuário final, mas quem é mais propício a tombar são roteadores e gateways (mas , denovo, se esses tombarem quem está atrás deles vão também...)

Hum.. nao sei nao... pode nao ter nada haver... masssss

Mas de uma semana pra cá, quando estou conectando de meu PC de casa, usando minha conexao DISCADA (diaul/up) de qualquer um dos provedores FREE que uso (IG, BRFree) etc... estou sofrendo inúmeras tentativas de PORTSCAN.

Aí eu apelo, reconecto novamente para pegar um outro IP e daí a pouco começa tudo de novo.. Tenho um personal firewall instalado q está barrando essas tentativas de invasão, mas isso está ficando muito chato !!

Sei lá.. achava comum o portscan em conexoes permanentes, mas agora as discadas tambem com tanta frequencia?!?!?!

RSM

isso nao tem a ver com esse bug, mas maquinas com IPs dinamicos costumam ser mais faceis de invadir do que um servidor com IP fixo (que eh o q os kiddies te scaneando estao procurando)

eh impressionante a quantidade de usuarios caseiros rodando sistemas/servicos bugados suscetiveis a invasao (sem contar os q tem backdoor/trojans rodando e nem sabem)

maquinas com IP fixo/permanente *costumam* ser mais bem configuradas ou protegidas :)

Bom, já que tocaram no assunto, e, desculpe a ignorância, mas alguém saberia me responder porque, quando estou no Windows, sem nenhum browser aberto nem cliente de e-mail, nenhum serviço que utiliza a internet (ao menos que eu saiba, :)) o mostrador de status de utilização da rede fica piscando de tempos em tempos (trocando informação com sei lá quem), e quando estou no Linux isso não acontece? É por motivos óbvios e posso começar a escrever uma teoria de conspiração ou tem outro motivo?

Paz

Olá pessoal,

Tem sido comentado de forma alarmante isso, mas isso "resetar conexões" já rola há muito tempo no underground e isso é velho ! :-)

Mas o pessoal de uma universidade britânica tem se falado e muito sobre isso :

http://www.uniras.gov.uk/vuls/2004/236929/index.htm
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

Já tem um exploit para windows circulando pela internet no qual o mesmo tem se tornado público :

http://www.k-otik.com/exploits/04222004.reset.dpr.php

Sem mais,

Rodrigo Lima - a.k.a rlima

RSM,

Isto tb está acontecendo comigo!.. e pode ter certeza que não é brincadeira de kiddies, ná maioria das vezes o IP que está rodando o PortScan é sempre de um Roteador da Intelig!..tb estou puto com isto.

Essa vulnabilidade, não parece afetar o ipv6....

Estamos longe de usá-lo ....

Thefallen, no meu caso, eu tenho o Linux e Windows instalados na maquina.
No caso do Windows este tambem esta protegido por firewall, anti-virus e anti-trojans, anti-spywares etc... Tento manter o firewall bem configurado e o antivirus atualizado e estou sempre monitorando os dois.. Nao uso o Outlook (inclusive barrei o mesmo no firweall) e o Windows é mantido atualizado (pelo menos ate onde teve atualizacao) Espero q isso seja suficiente para barrar ou minimizar os ataques...

CaFeCrAfT, eu também notei que vários portscans vieram de roteadores da Intelig também.. Não sei se foram todos, mas também acho que foram a maioria.. .

Vou observar melhor o fato ....

Esse técnica de ataque, como já foi comentado, é bem antiga, mas existe a possibilidade de um DoS.

Existem duas coisas que podem ser feitas que diminuem o risco para quase IMPOSSIVEL de sofrer esse tipo de ataque:

1 - Usar o SYN_COOKIES, que evita bastante ataque de DoS; (http://www.secforum.com.br/textos/tcp1.htm)

2 - Aplicar o patch grsecurity no kernel do Linux, e marcar as opções para aumentar a randmização de numeros sequenciais de conexões TCP, tornando praticamente impossível adivinhar o número de sequência das conexões.
(http://www.grsecurity.org)

Esse técnica de ataque, como já foi comentado, é bem antiga, mas existe a possibilidade de um DoS.

Existem duas coisas que podem ser feitas que diminuem o risco para quase IMPOSSIVEL de sofrer esse tipo de ataque:

1 - Usar o SYN_COOKIES, que evita bastante ataque de DoS; (http://www.secforum.com.br/textos/tcp1.htm)

2 - Aplicar o patch grsecurity no kernel do Linux, e marcar as opções para aumentar a randmização de numeros sequenciais de conexões TCP, tornando praticamente impossível adivinhar o número de sequência das conexões.
(http://www.grsecurity.org)

Bom, alguns comentários a respeito do assunto:

- Não é bem questão de se 'já existe kernel patch para solucionar'. O protocolo TCP é definido por alguma comissao ou orgao (como a IETF) que eu nao me recordo agora, então assim que o tal orgão 'redefinir' (se eh q isso vai acontecer) o protocolo (em outra RFC ou algo que o valha), o protocolo será reimplementado no kernel. Até lá eu soh acredito no máximo uma 'gambiarra' de proteção.

- Não me parece fazer muito sentido a alegação de que no IPv6 não existe esse problema, uma vez que o protocolo TCP e o protocolo de IP atuam em níveis diferentes (ou seja as informações de uma camada não são vistas pela outra), com funções e problemas diferentes. E depois de tanto ter se falado em IPv6 e as aplicacoes efetivas tendendo a zero, é POSSIVEL que o protocolo nunca seja efetivado (uma vez que exigiria a troca de muitos equipamentos).

- Quanto aos comentários que o OpenBSD seria o SO menos afetado pela vulnerabilidade, alguem saberia dizer mais a respeito?

Pelo que eu vi que os sites tão publicando, não parece que executar esse tipo de ataque não vai ser tão fácil como o professor lá descobriu ("Qualquer um que sair da minha palestra, já saberá exatamente o que fazer, não importa quão vaga seja a explicação")
O problema mesmo vai ser quando lammers e scripts desoculpados começaram a ficar derrubando pcs em massa pela rede >,<... mas até eles conseguirem fazer isso, espero que já tenham concertado o bug =P