31 de janeiro de 2009

Race Condition

Em todos os sistemas que funcionam em rede, normalmente há um servidor que processa informações, permite o acesso e utilização de determinados serviços e responde a requisições.

Obviamente que, numa rede com um servidor, há mais de uma máquina cliente realizando requisições ao primeiro num mesmo período de tempo. Isso faz com que o servidor, em algum momento, tenha que realizar mais de uma operação simultaneamente, podendo em determinado ponto de seu processamento, ocorrer um conflite entre as operações simultâneas, já que para que tudo ocorra corretamente, as operações precisam ser processadas em determinada ordem.

Esse tipo de conflito não ocorre apenas em um sistema computacional, mas em todos os sistemas eletrônicos, onde uma operação para ocorrer depende de várias outras. Mas vamos nos ater ao escopo de TIC.

Em um computador, uma race condition pode ocorrer se requisições para ler ou alterar uma grande quantidade de dados são recebidas quase ao mesmo tempo, e o computador tenta sobrescrever parte ou todos os dados enquanto os dados antigos ainda estão sendo lidos. Os resultados podem ser os seguintes: travamento do sistema, “operação ilegal”, encerramento do programa, erros de leitura dos dados antigos ou erros na alteração dos novos dados.

Numa rede de computadores, uma race condition pode ocorrer se dois usuários tentam acessar a mesma linha de tráfego ao mesmo tempo e nenhum dos computadores recebem o sinal de que aquele canal está ocupado antes do sistema permitir o acesso.

Um atacante pode tirar vantagem desse tipo de falha – vulnerabilidade de race condition – e ganhar acesso não autorizado ao sistema. Esse tipo de vulnerabilidade também permite um atacante explorar o ataque conhecido como ARP Poisoning (pharming ou ARP Spoofing), onde o mesmo infecta o cache DNS do servidor redirecionando as requisições de determinado IP para um IP especificado pelo primeiro.

Até um tempo atrás, para realizar esse tipo de ataque o atacante precisaria realizar muitas tentativas para vencer a race condition e fazer com que sua requisição fosse processada ao mesmo tempo que uma requisição feita para o IP que seria redirecionado.

No entanto, Dan Kaminsky, um conhecido expert em DNS, descobriu uma falha nesse ano de 2008 que através de uma simples requisição, o atacante faria com que uma série de transações fossem realizadas pelo DNS para buscar o domínio requisitado, o que abriria uma janela de tempo que permitira que o atacante infectasse o cache DNS e redirecionasse o domínio requisitado para o IP de sua escolha. O atacante simplesmente venceu a corrida e infectou o servidor DNS.

Uma falha como essa é muito séria, razoavelmente fácil de explorar através da técnica de Man-In-The-Middle e só agora foi descoberta. Isso quer dizer que tem muito administrador por aí que ainda vai levar um tempo para instalar os devidos patches de segurança.

Resumindo, podemos dizer que uma race condition nada mais é do que uma corrida para ver qual a requisição chega primeiro no servidor e é processada. Sendo assim, é uma condição que pode ser explorada de diversas formas por um atacante habilidoso.

Referências

Kaminsky DNS Solution – www.ipam.nl/whitepapers/NitroSecuritys_Kaminsky_DNS_Solution.pdf

Kaminsky (finally) reveals gaping hole in internet - http://www.theregister.co.uk/2008/08/06/kaminsky_black_hat/

23 de janeiro de 2009

Segurança no Brasil. Qual é nossa realidade?

Trabalhando como consultor da área de segurança em TI, presenciei várias falhas, muitas vezes absurdas e primárias mesmo, em sistemas e redes, o que só mostra que o brasileiro ainda não está consciente dos riscos que corremos ao enfrentarmos um atacante com forte intenção maliciosa. Isso talvez seja devido ao fato de que a Internet só chegou no Brasil no meado dos anos 90, quando Kevin Mitnick já cumpria pena na prisão. A defasagem tecnológica que vivemos no início da era digital era muito grande, o que também afetou o desenvolvimento de metodologias e políticas de segurança. Tanto que a maioria das empresas não possui políticas de segurança bem definidas e nem procuram adquirir uma certificação ISO 27001 ou ISO 17799.

Um exemplo disso, é que só em 2008 o governo brasileiro decidiu liberar uma Instrução Normativa (a Instrução Normativa GSI nº1 - Disciplina a Gestão de Segurança da Informação e Comunicações na Administração Pública Federal, direta e indireta, e dá outras providências) que regula a adoção de políticas de segurança da informação em instituições públicas, sendo que nos EUA, por exemplo, essa é uma preocupação existente há muito anos.

Talvez, nossa nação não tenha a devida preocupação com tal necessidade, pelo fato de nunca ter presenciado ou participado de atividades que envolvessem furto de dados sigilosos que colocassem a segurança nacional em risco ou coisa do gênero, como já ocorreu em outros países (p. exemplo, EUA, URSS, Iraque, China e etc). E nem mesmo temos invasores maliciosos (crackers) com grandes conhecimentos técnicos, ou intenções, para causar grandes prejuízos ao governo. Talvez isso gere uma aparente sensação de segurança, onde achamos que vivemos em um ambiente inócuo e seguro. Lêdo engano, meus caros!

Não temos grandes ataques, mas temos pequenos roubos! Até aqui o jeitinho brasileiro de querer aproveitar-se em cima da ingenuidade dos outros prevalece. Mas se temos script kiddies que possuem conhecimento suficiente pra burlar sistemas bancários e financeiros, ou apenas enganar o usuário, em alguns anos poderemos ter atacantes profundamente perigosos, que vendem suas pilhagens para os concorrentes das empresas que invadiram. Esse é a paisagem que podemos vislumbrar se não conscientizarmos os usuários dos riscos que correm. Mas para isso, os administradores precisam se conscientizar em primeira mão.

Meu trabalho como articulista é basicamente esse: escrever sobre vulnerabilidades, técnicas e dar dicas sobre como um atacante age, ou como podemos criar sistemas robustos, mais difíceis de invadir. Pois nesse ponto tenho que concordar com Eugene H. Spafford, quando ele diz:

“O único sistema realmente seguro é aquele que está desligado, enterrado em um bloco de concreto e selado em uma sala cofre protegida por guardas armados.”

Como último exemplo desse artigo, vamos apenas testar o seguinte: digite na pesquisa do Google as palavras “Currículo + CPF”, sem aspas, e veja o resultado. Espantado? Então, imagine o que uma pessoa maliciosa, mesmo sem conhecimentos técnicos, poderia fazer com os dados das pessoas que aparecem nessa busca. E é justamente daí que surgem os laranjas.

Então, tenhamos mais cuidado, tanto com nossas informações pessoais, quanto profissionais.

Até a próxima!

Primeiro pensamento fora da caixa

Caros amigos, depois de algum tempo atuando e estudando na área de segurança em TI, decidi criar esse blog específico para discutir esse assunto através de artigos, dicas, resenhas de livros técnicos, indicações de cursos e aí por diante.

Procurarei manter uma periodicidade nas postagens, até pra que sempre tenham material atualizado em mãos para seus estudos e possam acompanhar esse assunto tão interessante que a segurança da informação.

Bem, é isso aí e vamos à nossa primeira matéria.

Sejam bem vindos à nossa trip virtual "thinking out of the box"!