Histórias do Concurso de Hacking Interno, parte II

No post anterior desta série, comentei sobre alguns quesitos de projeto que procurei levar em conta ao implementar a aplicação vulnerável para um concurso de "hacking" interno que estamos promovendo aqui na Tempest. Hoje vou contar as regras do jogo, o prêmio e alguns dos melhores momentos até agora.

O Prêmio e a Participação

Vou começar pelo prêmio: os dois vencedores vão ganhar passagens e hospedagens para a Ekoparty, uma conferência sobre insegurança contra omissões técnicas que acontecerá em Buenos Aires nos dias 16-17 de setembro. Parece justo afirmar que isso já assegura uma motivação razoável.

Naturalmente, o site do concurso fica fechado na hora do expediente, senão a produtividade aqui iria cair a níveis inaceitáveis e nós, como todo mundo, temos prazos a cumprir e clientes a satisfazer. Portanto, a participação é totalmente voluntária, sujeita a inscrição.

O Conceito

O site a ser atacado é vagamente inspirado em um subconjunto das atividades de uma empresa de vigilância patrimonial: essa empresa hipotética instalaria sensores de movimento nos vários ambientes de suas clientes, que seriam ativados através de um console de controle pela última pessoa que sai no final do expediente.

Quando algum sensor de movimento é ativado, um alarme é enviado para a empresa de vigilânica. O sistema computadorizado então lança um "incidente" no sistema, que aparece na tela de algum operador de plantão que já não esteja ocupado lidando com outro incidente. O operador deve então "atender" o incidente, clicando em um botão na tela, para indicar que está ocupado tratando o assunto.

Ao atender um incidente, o operador segue uma lista de procedimentos. O primeiro deles é eliminar os alarmes falsos, que, na prática, costumam ser 99% dos casos. Ele faz isso ligando para um número de telefone previamente cadastrado e pedindo que a pessoa que atender informe seu nome e sua contra-senha. Se a contra-senha bater com a cadastrada para aquela pessoa, o atendente assume que ela provavelmente deve estar autorizada para estar lá e fecha o incidente registrando-o como "alarme falso". Se, ao invés, ninguém atender em nenhum dos telefones cadastrados ou dentro de um certo tempo, ela aciona uma equipe de rua ou mesmo a polícia.

No sistema simulado que fiz, criei um banco de dados de clientes hipotéticos (pesquisando no Google usando técnicas parecidas com as que descrevi neste post, achei um cadastro prontinho que eu filtrei e reduzi para uns quinhentos e poucos itens), uma outra tabela de atendentes e suas senhas de acesso ao sistema web de tratamento de incidentes (esses eu inventei com muito cuidado).

Por fim, criei uma outra tabela com pouco mais de 13 mil funcionários e contra-senhas, criadas aleatoriamente através de um gerador procedimental.

Essas contra-senhas são um bem valioso no "mercado negro": de posse do nome e contra-senha de alguém, um criminoso pode invadir uma empresa e, quando a vigilância ligar, eles dizem a contra-senha correta, fazendo com que a vigilância trate a ocorrência como alarme falso. Por isso, essa tabela de contra-senhas deveria ser muitíssimo bem guardada e mantida. O concurso simula um sistema criado por desenvolvedores que não estavam lá muito atentos a esse requisito.

As Regras

Os objetivo dos atacantes é tentar todas as técnicas que conhecem para invadir esse sistema de despacho de incidentes e me enviar a maior quantidade possível de nomes e contra-senhas. Eles são pontuados da seguinte maneira: o primeiro a reportar uma contra-senha ganha um ponto; o segundo a reportar uma contra-senha que já tenha sido reportada ganha 1/2 ponto; o terceiro, 1/3 ponto, e assim sucessivamente. Assim, quem reportar primeiro ganha mais pontos. Isso também ajuda no acompanhamento do progresso, pois desencoraja que os atacantes fiquem guardando seus resultados até o último momento antes do encerramento do concurso.

No meu sistema simulado, os incidentes eram gerados esporádica e aleatoriamente por outro robô. Ajustei as coisas para que acontecesse pelo menos um incidente por noite, mas poderia chegar até dez. Nas duas semanas que o sistema está no ar, já foram gerados vinte e poucos incidentes.

Além dos 12 atacantes, inscreveram-se 7 defensores. Eles tinham acesso a uma conta especial no sistema web que lhes permitia bloquear as contas de outros usuários, desde que soubessem o login e senha exatos do usuário que queriam bloquear. Além disso, tinham acesso via SSH a uma máquina que recebia todos os logs do webserver e do banco de dados, bem como uma captura de pacotes (feita pelo tcpdump) de todo o tráfego entrando e saindo do webserver. Fora isso, não recebiam mais nada: cabia a eles selecionar, instalar e usar as ferramentas necessárias para analisar esses insumos.

Os defensores são pontuados da seguinte maneira: ganham um ponto para cada usuário que bloquearem. Todavia, na apuração que será feita no final do concurso, vou catar no log do tcpdump o que estava sendo feito na conta daquele usuário na hora em que o defensor o bloquedou e se nada me parecer um ataque, aplicarei uma penalidade de -10 pontos àquele defensor. Fiz assim para evitar que os defensores simplesmente saíssem bloqueando todos os usuários a esmo.

Ganharão os prêmios o atacante e o defensor que tiver mais pontos. Em caso de empate, o prêmio será sorteado entre os empatados.

Histórias do Campo de Batalha

Como eu disse no post anterior, a entrada dos usuários legítimos no sistema é feita por nome e senha. Então, um ponto de partida natural é tentar chutar as senhas dos usuários. De fato, vários deles tinham algumas das senhas ruins clássicas, tipo "123456", "12345678", nomes de pessoas, líderes religiosos, times de futebol, etc. Os atacantes só não conseguiram achar esses casos com mais facilidade porque o bloqueio a cada cinco erros de senha os detiveram consideravelmente.

A estratégia padrão nesses casos é fazer o que se chama de "força bruta horizontal", onde, ao invés de testar várias senhas para um mesmo usuário, testa-se a mesma senha para vários usuários. Os veteranos fizeram exatamente isso, mas foram atropelados pelos novatos, que aparentemente não – o resultado foi um buruçu hilariante, com alguns dos veteranos bufando de frustração. Há um robô que desbloqueia as contas de tempos em tempos, simulando os usuários pedindo ao admin que restaure seus acessos, mas ele não dá conta nem de longe. Até hoje, quase toda noite eu desfaço os bloqueios para que os atacantes possam prosseguir.

Entre os defensores, temos alguns membros da equipe de Gestão de Logs e Eventos da Tempest. Eles também têm um vício: no dia-a-dia do trabalho deles, eles operam um sistema enorme de coleta e análise de dados que montamos ao longo de vários anos. Ao encararem o desafio do concurso, descobriram-se tendo de reinventar essas ferramentas. É um pouco como o cara que está acostumado a usar uma escavadeira e se descobre tendo que cavar um buraco enorme sem ter sequer uma pá. Por isso, gastaram vários dias só para entenderem o que os logs lhes ofereciam e instalarem ferramentas para dar conta do volume cavalar de dados – o histórico de pacotes de rede gerado pelo tcpdump já passa dos 50GB, log do banco de dados é duas vezes maior que isso e o log do webserver já vai em uns 3GB. Em outras palavras: tiveram que criar sua própria escavadeira do zero.

A maior parte dos defensores viu facilmente as milhares de tentativas de nome+senha dos atacantes e, quando estes últimos conseguiram, os primeiros prontamente bloqueavam-lhe o acesso. Alguns defensores, porém, pecaram por excesso de zelo: fizeram um programa de computador que bloqueava o usuário assim que ele entrava com sucesso no sistema; resultado: detiveram os atacantes, mas negaram acesso aos usuários legítimos, ofesa que lhes rendeu muitas penalidades. Aprenderam, na prática, que sistemas de contramedidas automáticos geram altos tiros que saem pela culatra em caso de falsos positivos.

Eu ainda não analisei os logs em detalhe suficiente para verificar se os defensores detectaram as tentativas de ataque mais sofisticadas dos atacantes. Mas vi que apenas quatro dos sete defensores efetivamente efetuaram bloqueios.

Já, dentre os atacantes, apenas quatro dos 12 me enviaram pouco menos de 200 contra-senhas. Achei isso um pouco decepcionante. Temi ter "errado na mão" e tornado o desafio mais difícil do que eu queria. No geral, o começo foi meio marasmático, mas a coisa foi esquentando com o passar do tempo.

Como não poderia deixar de ser, teve atacante que resolveu tentar uma outra estratégia totalmente diferente: fazer engenharia social no organizador do concurso. Isso também estava previsto – seguindo o procedimento, denunciei o atrevido aos colegas. O levante de reprovação teve um efeito muito mais poderoso do que qualquer coisa que eu pudesse dizer ou fazer. :)

Vários dos participantes ativos, tanto atacantes quanto defensores, vieram me dizer que, apesar das noites mal dormidas, estavam se divertindo bastante. Contudo, eu ainda estava sentido falta de algo – estava um pouco decepcionado que o jogo estava meio travado nos ataques de força bruta e ninguém tinha achado as vulnerabilidades mais bacanas que eu tinha plantado.

Em um assomo de sadismo, soltei aqui e acolá umas afirmações enigmáticas sobre eles terem passado várias vezes sobre os pontos vulneráveis e não os terem reconhecido como tais. Falei sobre "pensar fora da caixa", que as vulnerabilidades não eram tão difíceis assim, que eram "parecidas mas diferentes" do que eles estavam acostumados. Todavia, tive muito cuidado em não dar nenhuma pista realmente útil.

Mas, em última instância, eu queria que eles achassem as vulnerabilidades. Eu as preparei com muito esmero para que tivessem o efeito didático e de "quebrar os vícios" que eu achava que a equipe precisava. Só a partir daí é que o jogo iria ficar realmente divertido.

Foi o que finalmente aconteceu ontem e esse vai ser o assunto do próximo post.

Parte anterior

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Álisson Bertochi | 2010-12-28 19:02:03 | permalink | topo

Valeu pelo apoio, com certeza será de grande ajuda, porém o nosso evento será presencial, ou seja, ao vivo e a cores aqui na minha cidade, Erechim - RS. Quando estiver tudo pronto, avisarei aqui com mais um post. Ótima idéia essa do Playground, vai ser bem bacana pra galera participar :D Abraço!

Marco Carnut | 2010-12-27 13:43:01 | permalink | topo

Oi Álisson,

Sim, haverá não só novos posts, mas estou também trabalhando em um projeto (nome provisório "Tempest PlayGround") onde vamos colocar os concursos antigos online, abertos para o público "brincar". Fique ligado!

Quando colocar seu CtF no ar, manda o link pra gente, teremos prazer em divulgar.

-K.

Álisson Bertochi | 2010-12-26 09:40:58 | permalink | topo

Esqueci de perguntar, terá mais posts de continuação da saga? Abraço!

Álisson Bertochi | 2010-12-26 09:40:16 | permalink | topo

Excelente idéia de cenário fictício para um evento interno desses. Estamos bolando um evento estilo Capture the Flag (www.TecLand.com.br) aqui na minha cidade, porém o nível das primeiras edições será bem inferior ao de vocês! Parabéns pela brilhante idéia! Grande abraço e fiquem com Deus.

Marco Carnut | 2010-09-02 10:20:41 | permalink | topo

Petuti,

Confesso que em vários instantes eu também cheguei a achar que tinha "errado na mão". :)

Todavia, sempre pudemos contar com o brilhantismo de vocês e é isso que está tornando o concurso tão divertido. Agradeço os elogios, mas a verdade é os geniais, na realidade, são vocês.

-K.

Joao Lins | 2010-09-02 09:48:35 | permalink | topo

A "bomba" foi encontrada, mas não basta "cortar os fios". O desafio continua. :P

Confesso que por um instante achei que você tinha "errado na mão", agora tenho certeza que sua ideia foi genial.

Show de bola esse Concurso. Acredito que todos aqueles que brincaram um pouco estão aprendendo bastante.

[]'s