terça-feira, 5 de junho de 2012

Entender o espaço cibernético é vital para se defender de ataques digitais (II)

[Vejam a primeira parte da postagem.]

Parte II

Quebrando o código do iPhone

Em dezembro de 2010, Miller foi atrás da ajuda  de um amigo e colega da área de segurança, Dionysus Blazakis. Blazakis, de 30 anos, começou como hacker em 1994 e tem violado códigos desde então. Mas, em vez de infringir a lei, resolveu tornar-se um desenvolvedor de software. Ele e Miller trabalharam para a mesma empresa de segurança de computadores em Baltimore, Independent Security Evaluators. Ele é também um caçador de "dias zero".

Em mensagens de instant chats, os dois conversavam sobre detalhes do software do iPhone. Como fazem todos os hackers, queriam encontrar o caminho mais fácil para descobrir uma vulnerabilidade que lhes permitisse assumir o controle do processo.  Diferentemente da maioria dos hackers, eles tinham um prazo: a competição começava em 9 de março de 2011.

"Por onde começar? ... Em quê se concentrar?", Miller se lembra de ter perguntado a si mesmo. "A parte mais difícil é identificar a parte mais fácil a ser trabalhada". Ler completamente todas as instruções do software estava fora de cogitação. Isso poderia funcionar há duas décadas atrás, quando os sistemas computacionais eram mais simples, e a web era ainda uma novidade. Um computador de mesa na época poderia ter um milhão de linhas de software. Hoje, o software de um computador como esse pode ter 80 milhões de linhas ou mais. Encontrar os "dias zero" manualmente seria o mesmo que procurar agulha num palheiro.

Miller e Blazakis resolveram apoiar-se numa técnica de invasão conhecida como fuzzing -- inserir dados aleatórios em aplicativos e forçá-los a entrar em colapso. Forçar sistemas a entrar em colapso é mais fácil do que parece. Programas de software são milagres da engenhosidade humana, verdadeiras catedrais feitas de letras e dígitos.  Mas, ao contrário da Notre Dame em Paris ou do Duomo, de Milão -- que levaram uma vida para serem construídas e permanecem firmes até hoje -- a arquitetura digital está evoluindo constantemente, e pode ser jogada ao chão com um empurrão certo no local errado [para receber tal empurrão].

Miller atribui essa fragilidade a empresas que privilegiam vendas e novidades em vez da segurança computacional. "As empresas querem fazer dinheiro, não querem sentar-se para discutir e tornar seu software perfeito", diz ele. Muitas dessas vulnerabilidades estão relacionadas a erros em código projetado para analisar, ou grupar seletivamente, arquivos de dados enviados pela Internet. Um computador típico tem centenas de códigos de análise (parser codes) em seu sistema operacional. Um bom exemplo disso é um analisador de imagens. Ele identifica a informação que compõe uma imagem digital, faz seu processamento e então envia o arquivo para a parte da máquina projetada para expor a imagem. Hackers colocarão dados  infectados no código da foto,  para quebrar o software de análise, forçá-lo a entrar em colapso e abrir caminho para "sequestrá-lo".

"Se um aplicativo nunca sofreu fuzzing, alguma forma de fuzzing é passível de encontrar falhas (bugs)", disseram pesquisadores da Microsoft em um artigo recente sobre o uso de fuzzing para melhorar a segurança. Nenhum ser humano fazendo fuzzing manualmente poderia provocar um número suficiente de colapsos para, rotineiramente, permitir a um hacker a identificação de um "dia zero". Assim, Miller e outros escrevem programas para fazer isso. O programa de fuzzing de Miller lhe permite conectar-se com uma variedade de computadores, e fazer o rastreamento de milhares de colapsos com a indicação inclusive do local onde se deu o colapso.

"Em 99,999 por cento do tempo nada de ruim acontece", explica Miller. "Mas, faço isso um bilhão de vezes e algo acontece em número suficiente de vezes para tornar-se de interesse". No núcleo de seu programa há uma função que substitui, aleatoriamente, dados em um software escolhido como alvo. Ele chama de seu "molho especial" as 200 linhas de código que formam essa função.

Para iniciar sua invasão do iPhone, Miller utilizou quatro computadores da Apple, um deles um laptop tomado emprestado de sua mulher, e conectou-os a um outro computador que continha o software do iPhone. Miller rodou essa mini-rede 24 h por dia, durante semanas. Uma das máquinas operou como "capitão do time", lançando e coordenando os ataques de fuzzing, rastreando os colapsos e reunindo os detalhes.

Na sua vigília de acompanhamento do processamento, Miller estava particularmente atento a falhas que envolvessem o gerenciamento da memória do computador -- uma falha séria, que poderia abrir caminho para a invasão. "O gerenciador da memória mantém o acompanhamento de onde as coisas estão, para onde as coisas novas devem ir, etc.", lembra ele.  "Se um programa entra em colapso no gerenciador da memória, isso significa que o computador está confuso com relação a "o quê está onde". Isso é particularmente sério, porque significa que o computador está em um estado em que pode ser persuadido a achar que meus dados são algo que ele pensa ser completamente diferente".

Por enquanto, a maioria dos colapsos era trivial. Fevereiro se aproximava, o tempo estava curto, e Miller e Blazakis ainda não tinham tido seu "dia zero".

Em 24 de janeiro de 2011, Miller e Blazakis viram um vislumbre de esperança. Um colapso especialmente promissor parecia estar maduro para ser explorado. Eles o tinham encontrado dentro da parte do software do navegador que permite aos usuários do iPhone ver apresentações em PowerPoint. Envolvia porções do arquivo que armazenavam informações sobre a localização e o tamanho de formatos tais como um círculo, um quadrado e um triângulo que apareceriam numa página de uma apresentação.

"Na realidade, eram apenas bytes em um arquivo. Simplesmente aconteceu que tinha algo a ver com um formato [de figura]. Na realidade, não nos importamos", Miller disse mais tarde. "Contanto que estivesse fazendo algo errado com os dados". Isso poderia ser o "dia zero" deles, mas eram necessários mais testes para verificar se poderiam explorá-lo.

Os dois voltaram a mergulhar nos detalhes técnicos do software do PowerPoint do iPhone. Era um trabalho difícil, mesmo para hackers tão competentes como eles.  Blazakis passou a trabalhar 18 horas por dia tentando fazer engenharia reversa do aplicativo de PowerPoint, para assumir seu controle sem causar muita perturbação. Bit a bit, os dois começaram a dominar o layout do software do PowerPoint, e conseguiram entendê-lo de uma maneira que competia com a de seus desenvolvedores. Finalmente, conseguiram inserir seu código "maligno" no aplicativo e assumir o controle de uma parte do iPhone.  "Acho que agora está sob controle", disse Miller numa troca de mensagens em 27 de janeiro. "Beleza".

Agora, tinham que concluir o trabalho descobrindo um jeito de colocar seu código dentro de um iPhone e se assegurar de que poderiam sequestrar o dispositivo de uma maneira consistente. Diferentemente do que se vê nos filmes, em que se mostram hackers invadindo computadores como se estivessem violando cofres digitais, invasões bem sucedidas requerem muitas vezes burla e a cumplicidade inconsciente da vítima.

Em 3 de fevereiro, Miller brincou com seu amigo sobre a luta que enfrentavam: "À procura de falhas, fama, dinheiro, garotas, glória". Miller e Blazakis decidiram criar um jeito de atrair um usuário do iPhone para uma página falsa da web. Eles montariam a página, e enganariam um usuário fazendo-o baixar um arquivo PowerPoint. O arquivo pareceria ser normal, mas dentro dele estaria o código infectado deles (conhecida como "engenharia social", essa é a mesma técnica usada nas invasões do Google e da RSA).

Com o prazo final se aproximando, eles começaram a ter conference calls por vídeo. Ligaram seus computadores ao espaço cibernético e trabalharam em tandem. Os dois formavam uma dupla cansada, mas formidável. Cortando caminho em sua tarefa, como pesquisadores de segurança, à medida que avançavam em seu trabalho ardiloso.  "Os dois últimos dias foram caóticos", disse Blazakis. "Fiquei acordado a maior parte das noites fazendo isso".

Em 8 de março, Miller voou para a competição, que fazia parte de uma conferência sobre segurança em Vancouver, B.C. Mas, ele e Blazakis não estavam ainda seguros sobre o que tinham feito. Continuaram remexendo nisso até mesmo na véspera do evento, e inclusive na escala de Miller em Seattle. A chance deles aconteceu em 10 de março. Enquanto estava na sala com os juízes e outros hackers, Miller tinha ainda receios de que a invasão pudesse não ser conseguida quando solicitada. Pelas regras da competição, ele tinha apenas cinco tentativas para fazê-la funcionar.

Quando chegou a vez de Miller, ele foi para uma mesa comprida numa das extremidades da sala, onde estavam os juízes e seus computadores. Miller conectou seu velho laptop Apple e um dos juízes fez o papel do usuário irrefletido de iPhone. O telefone de teste foi colocado numa caixa de alumínio, para bloquear sinais sem fio indesejáveis, como medida adicional contra qualquer tentativa de roubo, por outros hackers, de uma busca por um "dia zero". Miller disse-lhe para navegar para uma página falsa da web, contendo uma apresentação em PowerPoint criada por Miller. Escondido nos dados da apresentação estava o código maligno.

A imagem do navegador do telefone foi projetada sobre uma tela grande. O juiz digitou um endereço para a página da web, mas a apresentação nunca aparecia. Em vez disso, a imagem na tela voltava para a home page do telefone. Miller, sentado com seu próprio computar, sabia exatamente o que tinha acontecido. Naquele momento, ele havia conseguido acessar todos os nomes e outras informações do arquivo de endereços do telefone. Ele havia encontrado uma maneira de eliminar as proteções de privacidade de uma parte importante do dispositivo.

Miller cutucou um dos juízes perto dele e apontou para a tela de seu monitor, que mostrava o arquivo de endereços do iPhone. Ele e Blazakis, que estava acompanhando a apresentação através de um vídeo mostrado em um iPhone que tinha à mão em Baltimore, tinham ganho a competição. No dia seguinte, Miller recebeu um cheque de US$ 15 mil e sorriu radiante quando vestiu a jaqueta branca de vencedor.

Algumas semanas mais tarde, a Apple indiretamente admitiu a invasão, quando emitiu um "patch" (correção). Como consequência do trabalho dos hackers, a falha que encontraram e exploraram não era mais um "dia zero".

Miller e Blazakis sabiam que, por trás da brincadeira irreverente da competição havia uma realidade séria que demandava atenção.  "Somos espertos e competentes, mas não somos nada de extraordinário", Miller disse mais tarde. "Imagine se você fosse um governo, ou uma quadrilha russa ou um sindicato criminoso e pudesse juntar 100 ou 1.000 caras como nós?"


Charlie Miller - (Foto: Wikipedia).



4 comentários:

  1. Amigo VASCO:
    Primeiramente, meus PARABÉNS pelo excelente artigo. Faz tempo que não via algo tão conciso e tão denso.
    A leitura da duas partes me trouxe à mente alguma sexperiências vividas, e algumas análises sobre esses problemas.
    Comecemos pelas últimas.
    Todo sistema computadorizado sofre de um problema identificado como GARGALO DE VON NEUMANN.
    Em que consiste isso? É simples de explicar, mas extremamente difícil de solucionar, independente do estágio tecnológico onde nos encontramos. Um computador, qualquer que seja o seu porte, tem que seguir uma série de instruções que, em síntese, representam o seu programa, ou seja sua finalidade. Isso significa que as instruções são executadas UMA DE CADA VEZ, e a seguinte tem que considerar os dados passados pela instrução anterior. Se houver algum embaraço nessa sequência de instruções, o computador TRAVA.

    Costumávamos representar esse problema com um
    exemplo: suponha que você programe um computador, dando a ele instruções do tipo - ABRA A PORTA E SAIA. Se a PORTA já ESTIVER ABERTA, ele não consegue cumprir a primeira ORDEM e, assim não conseguirá evoluir para a segunda ordem/instrução. ESSE É O GARGALO.
    Já há tentativas de se evoluir para aquilo que se chama PROCESSAMENTO PARALELO, algo como acontece com o nosso cérebro, mas ainda não atingimos um nivel tecnológico que nos permitam generalizar esse conceito. Sua aplicação em alguns instrumentos científicos, como telescópios de última geração, mostram-se seguros para realizar suas funções.
    Tenho mais a falar, derivado de experiências vividas, quando de minha atuação na chefia do Laboratório da EMBRATEL, mas fica para o próximo comentário, em sequência.
    Sergio LEVY

    ResponderExcluir
  2. Amigo VASCO:

    Vamos a segunda parte de meus cometários ao seu excelente artigo.
    Dessa vez, vou me limitar às minhas experiências, enquanto chefe do Laboratóriom da EMBRATEL, no período 1978-1986.
    Quando lá cheguei, encontrei uns dois projetos que envolviam os chamados micro-processadores, ainda em desenvolvimento.
    Destinavam-se a coletar informações de nossos sistemas de telecomunicações, até então analógicos, e processar esses dados, de forma a permitir ações de manutenção preventiva e corretiva nesses sistemas. Era uma AUTOMAÇÃO de sistema existentes que trabalhavam só com dados brutos, de difícil, ou longa, análise.
    Tais dispositivos eram inicialmente baseados em um microprocessador de fabricação da INTEL,
    nomeado 8080, que incorporava, em sua constituição, um conjunto de instruções que definiam os passos de programação que deveriam ser seguidos para obter um resultado.
    Nessa época, não existiam teclados no Brasil.
    Para possibilitar a entrada de dados numéricos ou alfabéticos em nossos microporocessadores, nossos engenheiros/pesquisadores desenvolveram uma INTERFACE que transformava uma máquina TELEX em um desses dispositivos. Cabe um parêntesis: oa primeiros teclados produzidos no Brasil, o foram por intermédio de um Engenheiro que chefiava nosso CPD, que criou uma emprêsa, a DIGIPONTO, para fabricar teclados de computador por essas bandas.
    Voltemos ao assunto.
    Eu acompanhava, com carinho, esses desenvolvimentos.
    Quando chegaram para mim para anunciar o término do projeto, me surgiu uma idéia que passei a aplicar em todos os nossos projetos que envolviam micro-processadores.
    Qual era a idèia? Uma teoria, não comprovada, mas possível segundo a idéia.
    Trata-se dom seguinte: coloque um MACACO em frente à uma máquina de escrever; dê-lhe tempo,e ele será capaz de digitar, por exemplo, a PRÓPRIA BÍBLIA!!!
    É a probabilidade aplicada ao processo.
    Assim, criei um teste chamado entre nós, de TESTE DO MACACO.
    Em que consistia isso?
    Teclar aleatoriamente em um teclado, sem preocupação com o que se estava teclando.
    O impressionante era que, em muitas vezes, essa seqüencia aleatória de tecladas BLOQUEAVAM o funcionamento do micro-processador.
    Isso obrigava nossos engenheiros à buscarem uma solução para o caso.
    Essa foi uma experiência vivida.

    Abraços - LEVY

    ResponderExcluir
  3. Amigo VASCO:
    Não resisti a fazer um comentário de natureza tecnológica sobre o assunto.
    Aqueles produtos baseados em micro-processadores de que falei em comentário anterior, tinham a seguinte configuração:
    - memória: 2kB (hoje, nada menos do que alguns GB):
    - memória pra guardar programas (equivalente hoje aos nossos discos rígidos): 6kB (hoje, qualquer coisa acima de 500 GB);
    - velocidade de processamento: na época, um múltimo da frequencia de cor dos televisores- 3,58 MHz- hoje alguns gigahertz.
    O meu primeiro computador, um CP-500, fabricado pela PROLOGICA, lá pelos anos 82, tinha 64kB de memória e cerca de 16kB de memória, que era compensada pelo uso de um gravador de audio adaptado para gravar dados dos programas.
    Podíamos nos comunicar com outros possuidores de aparelhos semelhantes, graças a um projeto,
    bem anterior à WEB, que nos possibilitava esse contato. Foi o PROJETO CIRANDA, implantado na EMBRATEL, a partir de 1982.
    A velocidade de comunicações era de impressionantes 2kbps !!! Hoje se fala em velocidades de MEGABITS/SEGUNDO.
    Eu participei de todos esses momentos.
    Não dápara esquecer.

    Abraços - Sergio LEVY

    ResponderExcluir
  4. Caro Levy,

    Realmente não dá p'ra esquecer. Quando me lembro daqueles decks de cartões que a gente tinha que carregar p'ra onde fosse rodar os programas ...

    Abraços,

    Vasco

    ResponderExcluir