MESTRADO EM COMPUTAÇÃO
CMP148 - Redes de Computadores II
Prof.ª Liane M. R. Tarouco
Aula 9 - Turma 1999/2
|
MESTRADO EM COMPUTAÇÃO CMP148 - Redes de Computadores II
Aula 9 - Turma 1999/2 |
|
| Obs.: | O relatório foi elaborado em conjunto. Cada um foi responsável por pesquisar e descrever uma vulnerabilidade específica e as contra-medidas foram discutidas em grande grupo. |
Capturar segmento contendo cabeçalho do protocolo TCP, explanando
o conteúdo de cada campo.
 |
- Porta Destino: identifica o serviço solicitado (n.º < 1024) - N.º de seqüência: n.º de seq. do 1º byte deste segmento TCP - N.º de ack: n.º de seq. do próx. byte que o host espera receber - Tamanho do cabeçalho: em palavras de 32 bits - Bits de controle: flags de 6 bits, que controlam a conexão - Tamanho da janela: contém o n.º de bytes começando com o indicado no campo ACK que o host espera receber - Checksum: faz a verificação da integridade do pacote através da soma de todos os bits - Ponteiro para pacotes urgentes: aponta para o último byte da seqüência de dados urgentes |
Os
seguintes tópicos estão contidas no relatório abaixo:
De modo a atingir seus objetivos, um determinado ataque pode tirar vantagem de uma vulnerabilidade da rede ou de um computador. Uma vulnerabilidade é uma falha que permite o acesso ou uso não autorizado de recursos. Uma vulnerabilidade pode aparecer de três modos. O mais conhecido deles é através de um bug de software, que representa um problema de implementação, apesar do projeto do sistema estar correto. Vários exemplos desse tipo de vulnerabilidade podem ser encontrados em sistemas Unix.
Vulnerabilidades do TCP
Assim, procuramos categorizar as vulnerabilidades do protocolo TCP de acordo com a taxonomia acima.
|
|
|
|
|
|
|
|
|
|
|
CHRIS CHAMBERS, JUSTIN DOLSKE, and
JAYARAMAN IYER
|
|
|
|
|
|
http://www.ciac.org |
|
|
|
|
|
S.M. Bellovin
|
|
|
|
|
|
CHRIS CHAMBERS, JUSTIN DOLSKE, and JAYARAMAN IYER
|
|
|
|
|
|
Terry Bernstein et al Ed. Campus |
|
|
|
|
|
CHRIS CHAMBERS, JUSTIN DOLSKE, and JAYARAMAN IYER
|
|
|
|
|
|
http://www.cert.org
|
|
|
|
|
ndd -set /dev/ip ip_forward_directed_broadcasts 0 ndd -set /dev/ip ip_forward_src_routed 0 ndd -set /dev/ip ip_forwarding 0
|
http://sunworld.com |
No ambiente da Internet, não é incomum a recepção de pacotes atrasados e fora de ordem. Para contornar essa situação, o protocolo TCP utiliza números de sequência para garantir a entrega dos dados na seqüência correta para a aplicação. Esses números de sequência são estabelecidos inicialmente durante a fase de abertura de uma conexão TCP, na chamada fase de three-way handshake.
Os ataques via SYN (também conhecidos como SYN flooding) se aproveitam de uma vulnerabilidade na implementação da fase de three-way handshake na maioria dos hosts [Guha, Mukherjee95]. Quando o host B recebe uma requisição SYN do host A, ele deve manter o estado dessa conexão parcialmente aberta em uma “fila de escuta” por pelo menos 75 segundos. Isso é necessário para permitir a abertura de conexões em redes de alta latência (satélite, por exemplo). O problema com esta técnica é que a maioria das implementações só pode controlar um número muito limitado de conexões (a maioria delas somente controla 5 conexões por default, embora outras implementações podem gerenciar até 1024 [Luckenbach96]). Um host A agindo de má-fé pode explorar esse tamanho reduzido da “fila de escuta” e enviar múltiplas requisições SYN para o host B, sem nunca responder ao SYN&ACK enviado pelo host B. Executando tal operação repetidas vezes, a “fila de escuta” do host destino é preenchida rapidamente, impedindo-o de aceitar novas conexões até que as conexões parcialmente atendidas da fila sejam processadas ou descartadas por timeout. Essa habilidade de remover um host da rede por pelo menos 75 segundos caracteriza um ataque de DoS (Denial of Service). Esse primeiro ataque pode ser utilizado como uma primeira fase de um ataque mais complexo, como oIP spoofing
Figure 1. SYN Flooding
-Aumentar o número de possíveis conexões que podem estar na “fila de escuta”.
-Alocar dinamicamente o espaço na fila ao invés da utilização de limites fixos.
-Diminuir o período de timeout (75 segundos).
Na prática, essas soluções podem reduzir a vulnerabilidade de maneira considerável, mas é bom notar que enquanto os períodos de timeout e de espaço na “fila de escuta” foram finitos, o problema irá persistir.
O IP Spoofing é um ataque onde um atacante finge enviar dados com um endereço IP de origem que não é o de sua própria máquina [Morris85, Bellovin89]. A camada IP não realiza nenhuma espécie de autenticação nos datagramas recebidos, permitindo que um determinado host possa forjar o endereço IP de origem de outro host (IP spoofing de um endereço).
Entretanto, existem duas dificuldades nessa técnica. A primeira delas é que o host remoto enviará todas as respostas para o endereço IP de origem verdadeiro, e nunca para o host que está originando o ataque. Isso acontece em função das rotas existentes nas tabelas de roteamento IP entre os hosts. Dessa forma, é provável que um ataque usando IP spoofing não tenha condições de observar a saída do host remoto (a menos que ele tenha condições de vasculhar a rede entre os dois hosts). A segunda dificuldade é que um atacante necessita utilizar a correta seqüência de números TCP para estabelecer uma conexão com o host remoto.
A ausência completa de esquemas de autenticação de pacotes no Ipv4 é uma falha geral da arquitetura TCP/IP.
Sem mecanismos de autenticação, não há garantias de que um pacote é originário de onde seu campo de IP origem diz ser. Esse é o ponto de partida do IP Spoofing e, conseqüentemente, um dos grandes desafios na área de segurança IP.
Desse modo, não há como erradicar esse tipo de problema, pelo menos até a versão Ipv6
Previsão do número de seqüência TCP
O número de seqüência utilizado nas conexões TCP é um número de 32 bits. Isso torna pouco provável que um atacante possa adivinhar o número de seqüência inicial (ISN) correto de uma dada conexão.
Entretanto, se o ISN de uma conexão é gerado de maneira pré-determinada e previsível, torna-se fácil adivinhá-lo. Essa falha na implementação do TCP/IP foi descoberta em meados de 1985, quando Robert Morris descreveu uma técnica para explorar ISNs previsíveis em BSD 4.2 [Morris85]. No BSD 4.2, o ISN para uma dada conexão é gerado de um contador global. Esse contador é incrementado de 128 a cada segundo, e em 64 após cada nova conexão (isto é, quando um novo ISN é gerado).
Ao estabelecer uma conexão real com a vítima, o atacante pode determinar o estado corrente do contador e supor que o próximo ISN associado pela vítima será provavelmente o anterior mais 64. O atacante tem uma chance ainda maior de adivinhar o ISN se ele enviar um certo número de pacotes IP forjados, cada um com um ISN diferente, porém provável.
Ao completar a sua fase de three-way handshake, o host receptor dos pacotes forjados enviará um SIN&ACK para o host cujo IP foi forjado pelo atacante. Esse host irá rejeitar o SYN&ACK, porque ele nunca iniciou uma conexão – ele indica isso enviando um comando RST (reset command) para o host remoto, finalizando a conexão do atacante. Para evitar isso, o atacante poderá utilizar o método de SYN flooding descrito acima para bloquear o host que ele está imitando. O SYN&ACK enviado pelo host atacado será então ignorado, junto com quaisquer outros pacotes enviados enquanto o host é inundado de pacotes. O atacante então terá liberdade para conduzir o seu ataque, mas sempre impedido de observar a saída do host remoto (a não ser, novamente, que ele esteja localizado no meio do caminho). Naturalmente, se o host impersonalizado está off-line (ou, de alguma forma, foi posto em off-line), o atacante não precisa se preocupar com o que a vítima está enviando.
Figura 2. IP Spoofing via Sequence Guessing
Incrementar o contador ISN com mais freqüência, como outros sistemas operacionais fazem, parece não resolver o problema. Mesmo se o contador seja incrementado 250.000 vezes por segundo (como sugerido pelo padrão TCP), um atacante ainda poderá ser capaz de adivinhar ISN de maneira aproximada. Pelo método da adivinhação, é provável que um atacante possa estabelecer uma conexão com um correto ISN em poucas horas [Bellovin89].
Contramedidas (Previsão de número de seqüência)
Para que o host A impersionalize um host B em uma conexão com o host C, A deve ser capaz de adquirir o número de seqüência que C envia como resposta (para B). Existem várias maneiras de obter esse número, e uma das mais simples é simplesmente adivinhá-lo. A maneira de impedir esse tipo de ataque é o uso de alguma técnica que impeça um atacante de adivinhar o próximo número de seqüência baseado no número de seqüência anterior.
Bellovin, no paper Security Problems in the TCP/IP Protocol Suite, descreve o processo de geração do ISN em sistemas Berkeley. Esse processo não segue o que está escrito na especificação do protocolo, que requer o incremento do contador 250.000 vezes por segundo. Se os sistemas seguissem corretamente as especificações, parece que esse tipo de ataque poderia ser eliminado. Mas Bellovin prova que isso não é suficiente em seu paper:
"Let us consider whether a counter that operated at a true 250,000 hz rate would help. For simplicity's sake, we will ignore the problem of other connections occurring, and only consider the fixed rate of change of this counter. To learn a current sequence number, one must send a SYN packet, and receive a response. The first spoof packet, which triggers generation of the next sequence number, can immediately follow the server's response to the probe packet. The sequence number used in the response is uniquely determined by the time between the origination of the message and the receipt at the server of the message. But this number is precisely the round-trip time between [spoofer] and [server]. Thus, if the spoofer can accurately measure (and predict) that time, even a 4 microsecond clock will not defeat this attack.
"How accurately can the trip time be measured? If we assume that stability is good, we can probably bound it within 10 milliseconds or so. Clearly, the Internet does not exhibit such stability over the long-term, but it is often good enough over the short term. There is thus an uncertainty of 2500 in the possible value for [the guessed sequence number]. If each trial takes 5 seconds, to allow time to re-measure the round-trip time, and intruder would have a reasonable likelihood of succeeding in 7500 seconds, and a near certainty within a day. More predictable (i.e., higher quality) networks, or more accurate measurements, would improve the odds even further in the intruder's favor. Clearly, simply following the letter of the TCP specification is not good enough." [Bellovin89]
O que deve ser feito então? Bellovin sugere a utilização de um gerador de números aleatórios. Ele também sugere que o padrão DES possa ser usado no lugar do gerador, já que é bastante conhecido e o resultado da criptografia de contadores crescentes é bem variado e difícil de prever. Naturalmente, todos os métodos que se baseiam na geração de números pseudo-aleatórios devem ser considerados com precaução, já que a descoberta da semente faz com que toda a seqüência passa a ser conhecida. Independente do método utilizado como solução, deve-se evitar a utilização de geradores de seqüência de números facilmente previsíveis.
Outra variante da técnica de IP spoofing faz uso da opção de “Source Routing” do IP [Bellovin89]. O roteamento pela origem permite que o originador do datagrama IP especifique a rota (ou caminho) que o receptor deverá utilizar para enviar-lhe as respostas. Um atacante pode se aproveitar dessa opção e especificar uma rota que evite o host real, direcionando o tráfego para um caminho que ele possa monitorar (para a sua própria rede local, por exemplo). Embora simples, esse ataque pode não ter muita eficácia atualmente, uma vez que a maioria dos roteadores está configurada para descartar pacotes que a opção de roteamento pela origem habilitada.
Figura 3. Source Routing
Contramedidas (source routing)
-Utilização de roteadores que descartem pacotes IP com a opção de roteamento pela origem habilitada
-Uso de firewalls
Connecting Hijacking (seqüestro de sessão)
Uma variante interessante do IP spoofing permite que um host se insira no meio de uma conexão entre dois hosts - connection hijacking [Joncheray95]. Sozinho, o IP spoofing é incapaz de violar camadas adicionais de segurança, tais como o mecanismo de senhas do Unix, ou sistemas que implementam senhas únicas e transitórias. Nesse ataque, o atacante pode permitir que a autenticação inicial ocorra normalmente entre os dois hosts e, a partir daí, tomar o controle da conexão.
Essa técnica explora um estado de desincronização na comunicação TCP. Quanto o número de seqüência recebido em um pacote não é o esperado, a conexão é dita estar “desincronizada”. Dependendo do valor do número de seqüência recebido, a camada TCP pode descartar ou armazenar o pacote em um buffer. Essa possibilidade de armazenamento existe porque o TCP utiliza um mecanismo de “janelas deslizantes” de forma a permitir um uso mais eficiente do canal de comunicação mesmo que haja perda de pacotes e alta latência de transmissão. Dessa forma, se o pacote recebido não é o esperado, mas está dentro da janela corrente, ele será armazenado com a expectativa de ser utilizado mais tarde. Se o pacote recebido estiver fora do limite da janela, ele é descartado.
Dessa forma, quando dois hosts estão desincronizados, eles começam a descartar (ou a ignorar) pacotes um do outro. Um atacante pode injetar pacotes forjados com números de seqüência corretos e potencialmente modificar ou adicionar comandos na comunicação. Obviamente, esta técnica requer que o atacante esteja localizado entre os dois hosts, para que a comunicação possa ser monitorada e para que pacotes replicados possam ser enviados. A chave para esse ataque é a criação do estado desincronizado. Joncheray descreve duas possíveis maneiras de realizar isso: uma é durante o processo de three-way handshake, e a outra é no meio de uma conexão normal já estabelecida.
Os pacotes ignorados podem gerar ACKs ao invés de serem completamente ignorados. Quanto um ponto da conexão recebe pacotes com números de seqüência incorretos, ele responde com um pacote ACK contendo o número de seqüência esperado. Mas o receptor desses ACKs descarta-os, pois eles possuem números de seqüência errados! O receptor então gera seus próprios ACKs para notificar o emissor. E o processo se repete. Desse modo, um grande número de ACKs é gerado nesse ataque. Essa “assinatura”, ou padrão, é útil para a detecção desse tipo de ataque.
Figura 4. Connection Hijacking
Contramedidas (connection hijacking)
- Forte autenticação e criptografia