domingo, 1 de janeiro de 2012

Como sobreviver aos ataques de "hacktivistas" e pichadores virtuais de plantão

Em 2011 as atividades hackers foram bastante divulgadas e passaram de mera brincadeira de jovens desocupados para ações "organizadas" com cunho político libertário. Os grupos que ganharam um rápido prestigio foram o Anonymous e LuLzSec, uma boa parte do marketing em cima das ações destes grupos ficou a cargo das redes sociais, pastebin e do youtube. A partir dai novas facções como AnonymousBR, iPiratesGroup, LuLzSecBR, GreyHatBR, AntiSecBR e alguns pichadores virtuais  foram surgindo em busca de seus 15 min de fama. Analisando os resultados divulgados não é dificil entender o porque de tanto sucesso. Identifiquei erros simples como senhas fracas no ambiente de administação do sites ( e.g. admin@dominio/manager ) e muito mas muito SQLi e Blind SQLi. Abaixo passo algumas dicas de como sobreviver após o comprometimento de sua infra-estrutura e como mitigar as falhas.




1 - Web Backdoors

 Os web shells[1] [2] permitem o acesso ao ambiente comprometido mesmo após corrigidas as falhas. Estudar o código destas ferramentas facilita sua detecção e remoção. Nestes casos um AV ajuda muito tanto no Ambiente Windows quanto no Linux, mas muito cuidado pois nem todos os AVs são capazes de detectar web backdoors bastantes conhecidos ( e.g Symantec ). Uma forma de validar a varredura é fazendo buscas manuais: No Linux

grep -RPl --include=*.{php,txt,asp} "(passthru|shell_exec|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\(" /var/www/
No Windows Usando a ferramenta de busca procure pelas palavras acima.

 2 - Análise do alvo

 Após o incidente é muito importante entender quais foram as vulnerabilidades que permitiram a invasão. Ferramentas para análise de vulnerabilidades como o Nessus, Arachni, Uniscan, Acunetix são de fundamental importância, pois elas indicam as possíveis portas de entrada e facilitam a criação do plano de mitigação. Auditar o banco de dados é de extrema importância já que entradas indevidas podem ser adicionadas ( e.g contas fantasmas), e alguns lixos do ataque.



3 - Proteção extra e monitoramento
Aplicar uma camada a mais de segurança permite dificultar as tentativas de ataque não permitindo a varredura em busca de vulnerabilidades e portas abertas. Não deixe essa responsabilidade somente a cargo da ferramenta de proteção de borda ( e.g IPS ), por ela ser baseada em Pattern matching nem todos os ataques serão bloqueados e muito cuidado com os falsos positivos já que uma aplicação com falha no código fará com que o IPS entenda qualquer requisição como maliciosa, auditar todos os alertas muitas vezes sem bloqueá-los é o mais recomendado. O Ossec juntamente com o Splunk, Portsentry, Samhaim e o ModSecurity são ferramentas que auxiliam bastante nesta tarefa. Outro hábito pouco utilizado é a análise dos logs, uma simples busca por palavras como Nikto, Havij, perl, whitehat, Uniscan, acunetix, fuck, scanner, timthumb, pma, phpmyadmin nos logs do Apache e do IIS permitem identificar algumas tentativas de ataque.




4 - Atualização e restrição de acesso 
Manter o ambiente atualizado é uma boa prática pouco utilizada muito mais por medo principalmente quando o ambiente é de alta criticidade ( e.g SGBDs ). Nos ambientes Linux o cron-apt (Debian e derivados) e o Spacewalk (RedHat e derivados) ajudam muito, os sistemas Windows contam com o velho WSUS que geralmente fica esquecido sem a devida atenção. Restringir o acesso aos ambientes administrativos do site ( e.g wp-admin, admin, administration ) e o FTP evitando assim ataques de brute-force, outra boa prática é a utilização de senhas fortes, isto soa bastante clichê, porém após analisar algumas áreas administrativas encontrei senhas ridiculas de acesso. Conclusão Estas dicas apenas mostram o caminho a ser seguido. Experiência, bom senso e estudo continuo são fatores que diferenciam na resolução dos incidentes e na prevenção.


 Última dica: FERRAMENTAS FALHAM.


Post by: @alexandrosilva

quinta-feira, 29 de dezembro de 2011

Acunetix LFI Pos Exploitation - Downloading Files Structure Part 1


Olá pessoal! Pra comemorar meu aniversário, nada melhor que um post \o/

Neste artigo vou mostrar uma funcionalidade do Acunetix que eu acho bem interessante, o HTTP fuzzer.

Além de fazer o fuzzing de aplicações web e do protocolo http em si, poderemos usá-lo para explorar de forma bem efetiva uma falha conhecida como LFI ou Local File Include.

Deixei as referências da falha no link acima, caso você ainda não conheça a falha. Vamos ao que interessa:

Na tela principal do Acunetix, tanto na versão 7 quanto na 8 a feature pode ser localizada no lado esquerdo como mostrado na figura abaixo:



















Entendendo o fuzzer e montando a url:

Não vamos usar o fuzzer como um scanner, até daria, mas o próprio acunetix no seu core já faz isso muito bem, a ideia aqui é utilizar o fuzzer para extrair o maior número de informações possíveis do host alvo.

Na tela principal do Fuzzer (Requests) é mostrada uma típica requisição HTTP

GET http://hostname/path HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)
Accept: */*

Usaremos este espaço para montar nossa requisição afim de explorar o LFI, além disso, como o campo é liberado, podemos adicionar e/ou alterar
headers. Neste ponto você já deve saber qual a URL do LFI, como exemplifícado abaixo:

GET http://lfi.dc/lfi.php?pag= HTTP/1.1

User-Agent: Mozilla/4.0 (DcLabs)
Accept: */*

Logo, para exploração do LFI será usada a url
http://lfi.dc/lfi.php?pag= onde pag é a variável onde se encontra a falha. Troquei o User-Agent apenas para mostrar que os headers podem ser alterados/adicionados sem problemas.


Criado e configurando os Generators Como isto é um fuzzer evidentemente ele precisa  gerar strings, ints, chars repetidos e coisas do tipo, mas como foi dito acima, não vamos scanear e nem fuzzear nada, logo, vamos dar uma nova função para os generators, inicialmente precisaremos de dois, claro que, para ataques mais complexos serão necessários mais generators.

Character repeater e File generator

Como o próprio nome diz, o Character repeater vai repetir quantas vezes quisermos um determinado caracter ou string. Sendo assim, vamos preencher os campos para criação, use nomes intuitivos para cada generator, quando se tem vários, realmente fica complicado saber o que eles fazem usando apenas o nome padrão que o Acunetix gera, Gen_N, onde N é um número sequencial.

Name: dotslash => Nome intuitivo
Character/String: ../ => Se você não sabe o porque da utilização da string “../../” sugiro que volte ao inicio do artigo e leia a referência sobre LFI.
Initial count:1 => Irá iniciará o processo com a string ../../ uma vez
Final count:2 => Máximo de repetições da string ../../
Increment:1 => Incremento do contador da string
Encoding: None

Este generator foi configurado para um ataque
clássico de LFI, logo, o campo Initial count deve ser configurado de acordo com a quantidade de “dotslash’s” encontrados  para exploração da falha. Não precisaremos encodar a string neste caso, por isso o campo Encoding foi setado como None. Usar URL Encoding e base64 é uma boa opção para evasão de possíveis filtros.O segundo generator(File Generator), vai ler informações de um txt ou xml linha a linha, sendo assim, usaremos uma lista de nome de arquivos que provavelmente existem no servidor atacado. A idéia para montar essa lista foi simples, foi executado o comando abaixo em diversas distribuições e com diversas aplicações instaladas, como  Apache, mysql, wordpress, cacti, nagios,oracle e etc.

find / -type f > wordlist.txt

Depois  foi feito um append das listas e retiradas as linhas iguais, além disso, removida a  primeira “/” do arquivo final devido ou uso da string “../../”.

Completando os campos deste generator:

Name: filenames_wordlist => Nome intuitivo
Fileaname: wordlist.txt => Nome da sua wordlist
Filetype: txt => Tipo da sua wordlist
Encoding:nome => Mesmo esquema do Character repeater




Depois dos generators devidamente criados e configurados, é necessário adiciona-los ao request http:

Posicione o cursor logo depois de pag=, selecione o generator dotslash e clique em Insert Into Request, repita o processo para o filesnames_wordlist.
O resultado deverá ser algo assim:

GET http://lfi.dc/lfi.php?pag=${dotslash}${filenames_wordlist} HTTP/1.1

User-Agent: Mozilla/4.0 (DcLabs)
Accept: */*

Antes de iniciar a exploração, é interessante que sejam criados filtros para que sejam separados somente os resultados relavantes do ataque. Isso pode ser feito pela aba
Fuzzer Filters.Já existem dois filtros por padrão, Include Internal Server Error e Invalid username/password combination, este segundo, para o caso do LFI não será necessário, basta selecionar e deletar.

Criando e configurando filtros:

Rule Description: Failed to open => Nome intuitivo para o filtro(Mesmo caso dos generators)
Rule type: Exclusion => Caso o request caia na regra, será excluído do relatório
Apply to: Response => Onde a regra  fará o match, neste caso ele irá procurar a string em qualquer porte da resposta enviada pelo servidor.
Regular Expression: failed to open stream => Neste campo é preenchido com a string que fará match com a resposta do servidor e excluirá do report final, usei a string “failed to open stream” pelo fato de ser um erro genérico do PHP, quando um arquivo não é encontrado, não se tem permissão para acessá-lo ou qualquer outro motivo pelo qual o arquivo não pode ser lido:
Erro de permissão:
Warning: include(../../../etc/shadow) [function.include]: failed to open stream: Permission denied in /var/www/t.php on line 6

Warning: include() [function.include]: Failed opening '../../../etc/shadow' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/t.php on line 6 

Arquivo não existe:
Warning: include(../../../etc/dclabs) [function.include]: failed to open stream: No such file or directory in /var/www/t.php on line 6


Warning: include() [function.include]: Failed opening '../../../etc/dclabs' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/t.php on line 6 
Assim, filtramos várias possibilidades com uma única regra, depois de pronto clique em Add. Caso precise alterar a regra selecione a regra em questão e clique em update.

Lembrando que, esta regra foi feita para tratar uma erro genérico do
PHP, é bem possível que sejam encontrados códigos que tem o tratamento feito pelo programador, ou seja, seu filtro deverá ser ajustado de acordo com a mensagem de erro retornada pela aplicação.

Pronto, agora é só clicar no start  e colher os arquivos encontrados no servidor alvo.

Existem outros trick´s que vou mostrar no próximo post. Resolvi dividir em duas partes para que o artigo não fique cansativo.
O HTTP Fuzzer está liberado na versão Free do Acunetix. Fiz um vídeo que mostra a ferramenta em execução com uma wordlist menor:
 http://youtu.be/z357C_8H3Mc 






O próximo passo, além da parte 2, é escrever um código que faça este mesmo trabalho para ser integrado ao metasploit.

Lili, muito obrigado pela revisão! \o/ Qualquer dúvida #dclabs @ freenode Twitter: @crashbrz Até a próxima pessoal.