segunda-feira, 26 de agosto de 2013

Segurança além da aplicação - Baselines, Hardening e o novo Projeto SANS SCORE

Introdução

Atualmente, os ataques cibernéticos vem crescendo exponencialmente em todo mundo. O Brasil não fica fora dessa estatística, de fato ele é um dos países mais afetados. A Akamai[1], uma empresa especializada em computação em nuvem e content delivery, disponibiliza um aplicativo em seu site onde é possível acompanhar os ataques em tempo real, como pode ser visto na Figura 1 abaixo.


Figura 1 - Ataques cibernéticos acontecem em tempo real. - Imagem feita às 15:16 do dia 20/08/2013

Um exemplo bem comum dos ataques realizados é o Local File Inclusion (LFI). Este ataque possibilita acesso aos arquivos locais no servidor, como por exemplo arquivos sensíveis, arquivos de configuração e arquivos de logs. Em alguns casos esse ataque permite a execução remota de código malicioso. Na Figura 2, é possível ver um exemplo de como este ataque é executado visando acesso não autorizado a um arquivo de log.
Figura 2 - Exemplo de LFI acessando o arquivo /var/log/auth.log do sistema - Fonte: http://lanmaster53.com/images/posts/lfi_rce_orig_auth.png

No exemplo citado, além da falha na aplicação, existe um problema de permissão, pois o servidor web não deveria ter acesso aos arquivos de log, ou seja, além de corrigir a falha é necessário ajustar as permissões do usuário do servidor web para que assim seja possível diminuir a possibilidade de ataque. Isto é o chamado Princípio do Menor Privilégio (ou Least Privilege Principle, em inglês), que diz que cada aplicação, usuário, plugin ou módulo, deve acessar apenas as informações necessárias para o seu funcionamento legítimo.

Como podemos diminuir essa superfície de ataque e aumentar a segurança? 

Nosso dia a dia é cercado de regras, e para isso existem leis e pessoas encarregadas de assegurar que tais regras seja seguidas e que existam punições caso contrário. Assim como as leis, os baselines são os requisitos mínimos de configurações e boas práticas que o sistema deve possuir antes de entrar em produção. 

Sabemos que para uma Lei funcionar, é necessário que tenha alguém monitorando e garantindo sua aplicação. O hardening é o responsável por isso, monitorando se os baselines estão sendo seguidos ou gerando alertas caso contrário.

No exemplo de LFI apresentado no começo, se o servidor seguisse algum Baseline e fosse aplicado o hardening, a possibilidade de sucesso em um ataque seria reduzida, pois provavelmente o acesso aos arquivos de logs não estaria disponível (a não ser por alguma necessidade especifica), fazendo com quem uma falta de validação dos parâmetros de entrada da aplicação não fosse o único fator determinante para o sucesso na exploração da vulnerabilidade.

Existem diversos Guias com sugestões de configurações de baselines, dentre os quais podemos citar:


Nesse post comentaremos sobre o CIS Bench e a iniciativa do SANS, chamada de SCORE.

O que é o tal do CIS Bench?

Center for Internet Security (CIS)[2] é uma organização sem fins lucrativos que ajuda as empresas a melhorar sua postura de segurança em relação a proteção de suas aplicações na web, o SCORE(Security Consensus Operational Readiness Evaluation)[3] é mais um dos vários recursos de melhoria de segurança que o CIS oferece como ajuda às empresas e governos. Como falado anteriormente, o CIS possui vários outros recursos que podem ser encontrados nesse link: Resources Publications.


Figura 3 - Checklist do CIS - Fonte:
http://benchmarks.cisecurity.org/images/screenshot_CIS-CAT_checklist.png
E qual a finalidade do SCORE?

O SCORE foi elaborado a partir do consenso de diversos profissionais gabaritados do mercado de segurança com o intuito de definir melhores padrões mínimos e gerar informações sobre melhores práticas de segurança. Ele também debate sobre técnicas já existentes, assim melhorando as mesmas e servindo como mecanismo de melhoria do CIS Bench.

O objetivo geral é demonstrar a importância do hardening tanto para empresas quanto para governos, criando e promovendo listas de discussões, debatendo e melhorando o processo todo, de forma contínua.

Alguns papers do SCORE já foram publicados como exemplo de “Descobrindo intrusos ” tanto para Windows[4] e Linux[5]. O projeto também disponibiliza um guia de estudos e uma serie de livros [6].

Conclusão

Problemas e falhas existem em qualquer aplicação. Como profissionais de segurança da informação é nosso dever diminuir essa exposição reduzindo a superfície do ataque e corrigindo falhas, com o objetivo de dificultar uma possível invasão. O trabalho de segurança em uma Aplicação Web ou qualquer outro software está relacionado à segurança da infraestrutura que o suporta, não limitando-se somente à blindagem da aplicação.

Na Conviso possuímos o Armature. Essa extensão do Conviso Security Compliance[7] possibilita a empresa a utilização de Baselines e Aplicação / Monitoramento do hardening. A solução é totalmente flexível, sendo que a empresa poderá utilizar Baselines desenvolvidos pelo Conviso Intelligence ou a criação seus próprios, que serão convertidos em regras para o monitoramento dos agentes em tempo real. Com essa extensão é adicionado mais contexto as falhas, possibilitando priorizar melhor as ações da Gestão de Vulnerabilidades, pois a empresa não só terá a criticidade da falha da aplicação, mas também da infraestrutura que suporta a mesma, correlacionando e gerando métricas com a real criticidade.

Peça uma demonstração https://www.conviso.com.br/contato.php caso tenha interesse.

[1] - http://www.akamai.com

terça-feira, 13 de agosto de 2013

Entendendo e explorando o CVE-2012-4576 para o Kernel do FreeBSD


Introdução


Dando continuidade a exploração de vulnerabilidades em kernel-land [1], neste artigo serão analisados os detalhes da vulnerabilidade registrada no CVE-2012-4576 e como podemos utilizá-la para obter execução de código no kernel do FreeBSD.

Esta vulnerabilidade foi reportada por Mateusz Guzik e o advisory [2] oficial do time de segurança do FreeBSD foi publicado no dia 22 de Novembro de 2012.

A falha ocorre devido a falta de validação em uma chamada de sistema. Como resultado, regiões de memória podem ser sobrescritas. A vulnerabilidade existe no módulo que adiciona a compatibilidade de execução de arquivos binários nativos do Linux no FreeBSD, então apenas sistemas que usam este recurso podem estar vulneráveis.

Todos os experimentos neste artigo foram realizados no sistema operacional FreeBSD 7.0, 8.2 e 9.0 arquitetura 32 bits (i386).

A vulnerabilidade


De acordo com o patch [3] disponibilizado pelo time de segurança oficial do FreeBSD, percebe-se que o código vulnerável se encontra no arquivo “sys/compat/linux/linux_ioctl.c” na função “linux_ifconf()”.

Arquivo: /usr/src/sys/compat/linux/linux_ioctl.c
---
2134  /*
2135   * Implement the SIOCGIFCONF ioctl
2136   */
2137 
2138  static int
2139  linux_ifconf(struct thread *td, struct ifconf *uifc)
2140  {
2141  #ifdef COMPAT_LINUX32
2142  struct l_ifconf ifc;
2143  #else
2144          struct ifconf ifc;
2145  #endif
...
2149          struct sbuf *sb;
...
2152          error = copyin(uifc, &ifc, sizeof(ifc));
2153          if (error != 0)
2154                  return (error);
...
2236         ifc.ifc_len = valid_len;
2237         sbuf_finish(sb);
2238         memcpy(PTRIN(ifc.ifc_buf), sbuf_data(sb), ifc.ifc_len);
2239         error = copyout(&ifc, uifc, sizeof(ifc));
2240         sbuf_delete(sb);
2241         CURVNET_RESTORE();
2242 
2243         return (error);
2244  }
---
Na linha 2139 vemos que a função recebe dois argumentos, sendo o primeiro o endereço para uma estrutura do tipo “thread” e o segundo o endereço para uma estrutura “ifconf”. Por acreditar ser desnecessário, o trecho de código que faz a chamada a função “linux_ifconf()” foi omitido, mas a única informação relevante para o correto entendimento desse artigo é que o segundo argumento passado é o endereço de memória que foi utilizado como argumento na chamada ioctl, portanto, o conteúdo da variável “uifc” é controlado pelo usuário. Exemplo da utilização da ioctl SIOCGIFCONF pode ser vista em [4].

Como podemos ver na linha 2152, o conteúdo da variável “uifc” é copiado para a variável “ifc” utilizando a função “copyin()” [5], a partir deste ponto a estrutura “ifc” também será controlada pelo usuário. Para quem não conhece, as funções “copyin()” e “copyout()” [6] são utilizadas para transferir dados do espaço de endereçamento do usuário para o kernel e vice-versa. Após isso, na linha 2238, o valor controlado pelo usuário é utilizado como primeiro argumento na chamada a função “memcpy()” [7]. Um detalhe relevante é que ao realizar a chamada ioctl podemos informar a quantidade de bytes que o endereço que passamos comporta, desta forma a função “linux_ifconf()” poderá calcular se irá ocorrer overflow ou não ao copiar os dados, durante esse cálculo o valor “ifc.ifc_len” é alterado e não é totalmente controlado pelo usuário.

O valor retornado pela chamada a função “sbuf_data(sb)” na linha 2238 são as configurações das interfaces disponíveis na máquina.

Exploração


Como mencionado anteriormente, o módulo que adiciona compatibilidade binária Linux ao FreeBSD, falha em validar um endereço passado como argumento na chamada a ioctl SIOCGIFCONF, permitindo que seja passado qualquer endereço de memória que terá seu conteúdo sobrescrito pelas configurações das interfaces da máquina. Para quem já tem alguma experiência com exploração de vulnerabilidades, inclusive no kernel, sabe que este tipo de falha em determinadas situações pode ser facilmente exploradas, em [8] você encontrará uma vulnerabilidade similar no kernel do linux encontrada pelo pesquisador Dan Rosenberg.

Existem estruturas importantes para o correto funcionamento do kernel que podem ser utilizadas como alvo e ter seus valores sobrescritos, o que permite redirecionar o fluxo de execução do kernel para um desejável por um atacante. Para realizar a exploração dessa vulnerabilidade foi selecionada a entrada número 3 da Interrupt Descriptor Table (IDT) [9] para ser sobrescrita pelos 16 bits mais significativos do nome da interface retornada. Os valores da entrada da IDT que serão sobrescritos são apenas os bits mais significativos do endereço de uma função. Como podem haver vários nomes para interfaces (“em”, “eth”, “lo”, “usbus”, etc), o exploit que foi escrito para essa vulnerabilidade obtêm esse valor em tempo de execução e ajusta o exploit de acordo com o nome da interface do ambiente. Este comportamento que permitiu o exploit funcionar tanto na versão 8 quanto na versão 9 do FreeBSD onde no mais recente a chamada a ioctl retorna “usbus0” e na versão 8 retorna “eth0”.

O endereço da função que irá gerenciar determinada interrupção fica dividido pela metade na IDT, os bits menos significativos armazenados no começo da entrada e os mais significativos no final da entrada, sendo que cada entrada tem o tamanho de 8 bytes. Assim, como falado anteriormente, somente os bits mais significativos serão sobrescritos, desta forma o novo endereço da função terá os bits mais significativos (os dois primeiros bytes) retornados pelo nome da interface e os bits menos significativos continuarão com os valores da função original. Antes de sobrescrever, será necessário mapear o novo endereço gerado e inserir o código que deseja ser executado quando uma nova interrupção da entrada sobrescrita for gerada, no caso do exploit escrito, essa interrupção é gerada usando a instrução chamada int3.

Partindo da premissa que os nomes das interfaces sejam caracteres ascii, não precisamos checar se o endereço gerado após a sobrescrita está dentro dos limites do espaço de endereçamento do usuário. Considerando que o nome da interface seja composto por letra e números, o maior valor em ascii é o caracter ‘z’ que tem o valor ‘7f’ em hexadecimal. Então considerando que a interface retornada seja ‘zz0’ e o endereço original da função na IDT seja 0xc0d33d08, após a sobrescrita o endereço será ‘0x7f7f3d08’, limite dentro do espaço de endereçamento do usuário.

Neste ponto já é possível obter execução de código, o próximo passo agora é reparar o estrago que foi feito na IDT com as outras informações da interface. Como as informações de cada interface são armazenadas em uma estrutura chamada “ifreq” e seu tamanho é 32 bytes, esse é o tamanho mínimo que conseguimos sobrescrever da IDT. Quanto menos valores conseguirmos sobrescrever, menor o estrago a ser reparado. No exploit liberado anteriormente não utilizava esse recurso e sobrescrevia muito mais que 32 bytes da IDT no caso do FreeBSD 8. Depois de consertar a IDT única coisa que resta é elevar os privilégios e retornar para userland, no exploit utilizamos a técnica “iret” [10] para esse propósito.

Através do método explicado acima foi possível escrever um exploit que funcionasse tanto na versão 7, 8 e 9 do FreeBSD sem precisar usar endereços fixos no código para cada versão. Não foi realizado nenhum teste em outras versões, mas é possível que o exploit também funcione normalmente desde que seja versão i386 do sistema operacional.

Outro fator importante é que, teoricamente, sobrescrever a IDT não é uma boa escolha devido ao motivo que o processo pode ser interrompido pelo scheduler logo após a sobrescrita e o novo processo acionar a interrupção da entrada sobrescrita ao invés do processo do exploit. Como o endereço que foi sobrescrito não é mapeado no novo processo, possivelmente um kernel panic irá ocorrer. Apesar disto, o exploit disponibilizado aqui foi executado e em nenhum momento aconteceu algo inesperado.

Conclusão


A correção feita pela equipe de segurança foi substituir a função “memcpy()” pela função “copyout()". Esta função automaticamente valida se os endereços passados como argumento pertencem ao seus devidos espaço de memória, evitando que seja feito a cópia de dados kernel <-> kernel e/ou user-land <-> user-land.

O exploit está disponível em [11], para utilizá-lo é necessário que seja compilado em um ambiente Linux e com a biblioteca structs.h [12] no mesmo diretório onde encontra-se o arquivo CVE-2012-4576-linux.c, após isso o binário gerado pode ser executado normalmente em uma versão vulnerável do FreeBSD. Não é necessário especificar nenhum parâmetro adicional ao compilador mas se o ambiente Linux estiver faltando alguma biblioteca necessária, recomenda-se utilizar a flag “-static” para o gcc. O ambiente Linux utilizado foi Ubuntu versão 12.04 instalado em uma máquina virtual VMWARE.

O vídeo abaixo demonstra a exploração da falha nos sistemas FreeBSD 7, 8.2 e 9.

Referências


[1] - http://blog.conviso.com.br/2012/12/uma-analise-do-cve-2012-0217.html
[2] - http://www.freebsd.org/security/advisories/FreeBSD-SA-12:08.linux.asc
[3] - http://security.FreeBSD.org/patches/SA-12:08/linux.patch
[4] - http://www.techpulp.com/blog/2008/10/get-list-of-interfaces-using-siocgifconf-ioctl/
[5] - http://www.unix.com/man-page/FreeBSD/9/copyin/
[6] - http://www.unix.com/man-page/FreeBSD/9/copyout/
[7] - http://linux.die.net/man/3/memcpy
[8] - http://www.vsecurity.com/download/tools/linux-rds-exploit.c
[9] - https://en.wikipedia.org/wiki/Interrupt_descriptor_table
[10] - https://www.blackhat.com/presentations/bh-usa-03/bh-us-03-cesare.pdf
[11] - https://github.com/andersonc0d3/exploits/blob/master/CVE-2012-4576-linux/CVE-2012-4576-linux.c
[12] - https://github.com/andersonc0d3/exploits/blob/master/exploits/CVE-2012-4576-linux/structs.h

terça-feira, 6 de agosto de 2013

BlackHat, DEF CON e BSidesLV


Recentemente, aconteceu uma das maiores conferências focadas na área de TI e segurança da informação, a BlackHat[1]. O evento ocorreu dos dias 27 de julho a 1 de agosto, com dezenas de palestras e atividades que ao decorrer das edições vem surpreendendo cada vez mais. Por exemplo, nesta ultima edição durante a conferência pesquisadores demonstraram como interceptar ligações em celulares, podendo espionar as conversas telefônicas, mensagens de texto ou até mesmo fotos enviadas e recebidas pelo usuário, utilizando a mesma tecnologia pelas empresas para aumentar a cobertura de telefonia celular[2]. Outra apresentação que chamou a atenção, foi a de Kevin McNamee, que mostrou como transformar um smartphone Android em uma máquina espiã (SpyPhone), podendo monitorar quase tudo que o telefone faz[3].

Uma grande perda para a comunidade de Segurança foi a morte de um lendário pesquisador e profissional de segurança, o Barnaby Jack, conhecido principalmente por ter feito dois caixas eletrônicos jogarem dinheiro em pleno palco durante uma apresentação anterior no evento. Dias antes de sua palestra na BlackHat sobre “Como invadir dispositivos médicos: Atacando pessoas que usam próteses eletrônicas”, o hacker foi encontrado morto em seu apartamento, não se sabe ao certo o motivo da morte, mas a hipótese de crime foi descartada pela polícia. [4]

Falando de grandes conferências, torna-se impossível não citar a DEF CON[5], um evento que já está em sua 21ª edição, e é uma das mais antigas conferências voltada à área de segurança da informação, que aconteceu nos dias 1 a 4 de Agosto este ano. A DEF CON tem a grande preferência do público, pois ela é mais técnica e menos formal, o que caracteriza a sensação de estar numa verdadeira conferência hacker. A DEF CON disponibilizou um documentário mostrando como é o evento[6], vale a pena assistir.

Outro evento que vem ganhando grande espaço no mundo da segurança da informação, são os eventos BSides. Estes geralmente acontecem dias antes ou depois de um grande evento nacional ou internacional. O BSides LasVegas[7] é uma ótima alternativa para quem gostaria de participar de eventos como a DEF CON ou a BlackHat, porém não tenha condições de pagar por eles. O BSidesLV chama a atenção por ser um evento de alta qualidade, a custo zero, que conta com a ajuda de patrocinadores e voluntários, e também, principalmente, por estar entre uma das maiores conferências na área de segurança em informação. No Brasil, temos a BSidesSP que acontece sempre antes ou depois do You Shot The Sheriff (YSTS) em maio e da Hackers to Hackers Conference (H2HC) em outubro.