Teoria - Injeção de SQL vs Força Bruta XSS

A pedido do leitor Josemar Simpson, estarei falando nesse post sobre duas técnicas de invasão conhecidas como SQLi e XSS Brute Force.

A maior parte dos grandes sites atuais já possui ferramentas implementadas contra os dois tipos de ataque, porém, páginas "mal programadas" e serviços desatualizados fazem com que ainda seja possível ocorrer esse tipo de invasão.

Conceitos Básicos

A utilização da injeção de SQL consiste em manipular o banco de dados (SQL), na maior parte das vezes por meio de uma URL do próprio site, afim de obter alguma informação privilegiada como credenciais de login.

Já o ataque Cross Site Script (XSS) consiste na utilização de códigos maliciosos que geralmente são injetados em links ou qualquer outra caixa de texto de uma página, na maior parte dos ataques desse tipo, não há uma invasão propriamente dita, mas sim um erro na exibição do site/página afetada, podendo ser um "deface" (desfiguração de uma página), ou um buffer overflow (estouro da capacidade do servidor e consequente queda do site), ou ainda um simples redirecionamento, que pode levar o usuário à uma simples página de "deface" ou em casos mais perigosos em páginas de "phishing".

Programas mais Usados

Os programas mais famosos para a realização do SQLi são o Havij no windows e o SQLMap no linux.

Já no caso do XSS, o XSSBeef no linux, no windows não conheço programa funcional para a automatização desse tipo de ataque.

É claro que existem mais programas disponíveis na web, principalmente para a plataforma linux e também existe a exploração de ambas vulnerabilidades no "modo manual" utilizando-se somente um navegador e os códigos maliciosos.

Afinal, qual a melhor forma?

Para começar a responder essa pergunta, digo somente, "depende".

No caso do SQLi a utilização é mais eficaz em sistemas desatualizados e que possuam um banco de dados rodando a tecnologia SQL/MySQL, pois isso garante um maior sucesso na invasão. Com os programas, é possível também realizar ataques de força bruta em qualquer página que necessite de credenciais.

Do lado do XSS, há a "vantagem" de se poder injetá-lo em qualquer campo de texto disponível em um site e com o poder de um programa a possibilidade um Brute Force faz com que páginas de login ou qualquer uma que necessite de uma credencial possa ser passada mais facilmente.

Caso estejamos falando do "modo manual", ambas as técnicas podem durar o mesmo tempo e considerando que se quer um resultado mais devastador, o SQLi pode fornecer qualquer informação presente no banco de dados do servidor atacado.

Conclusão

Apesar de suas limitações, o SQLi pode ser uma opção bem interessante para obtenção de informações direto do banco de dados de um servidor. Já o XSS pode ser mais abrangente mas pode não ser tão invasivo em alguns casos.

A escolha final cabe ao atacante (devidamente autorizado), pois o emprego de técnicas de invasão dependem de quanto a técnica está dominada e o quanto está conhecida, pois "receitas de bolo" não existem.

Extra

Abaixo um gráfico que mostra os tipos de tecnologias mais afetadas em 2013 pelas duas falhas ao mesmo tempo.

Legenda:

Azul: Aplicações Web Proprietárias - 40%
Alaranjado: Plugins e Módulos para CMS - 30%
Cinza: Pequenos CMS - 25%
Amarelo: CMS mais Usadas - 5%

CMS: Content Management System (Sistema de Gerenciamento de Conteúdo, sigla em inglês).


O artigo completo do site, encontra-se aqui (em inglês).

Agradeço a leitura e te espero no nosso grupo do Facebook.

Read More

[Pesquisa] 96% das aplicações testadas em 2013 possuíam vulnerabilidades

De acordo com relatório publicado pela Cenzic, 96% das aplicações testadas em 2013 possuíam uma ou mais vulnerabilidades de segurança. A mediana comparada ao ano anterior teve um aumento de 13 para 14 vulnerabilidades por aplicação.

Muitas destas vulnerabilidades encontradas são relativamente simples de serem detectadas, bloqueadas e corrigidas durante o ciclo de desenvolvimento por times de segurança.

No topo da lista de vulnerabilidades encontradas nas aplicações, testadas em 2013, está o XSS (Cross Site Scripting) com 25% do total das mais frequentes. Logo após encontra-se: Vazamento de informação (23%); Autenticação e autorização (15%); Gerenciamento de sessão (13%); Injeção de código SQL (7%).

Em relação aos aplicativos móveis, como existem mais dados disponíveis para dispositivos móveis, a importância da segurança de suas aplicações vem crescendo. Dentre as vulnerabilidades mais comuns encontradas em aplicações móveis, violação de privacidade e privilégios excessivos aparecem em mais de 80% das aplicações. Bala Venkat, CMO da Cenzic, afirmou que o crescimento de tecnologias emergentes e novas categorias de aplicativos – como a nuvem e aplicativos móveis – aumenta a complexidade do empenho em segurança.

Veja mais informações através do link.

Fonte: SegInfo

Read More

OWASP Top 10: A3 Cross Site Scripting

E vamos continuar com nossa série, hoje vamos ver um pouco de Cross Site Scripting. Basicamente quando falamos de Cross Site Scripting (XSS) estamos falando de enviar códigos para o servidor ou diretamente para a vítima que diferente do Injection, vão ser executados e a resposta vai para o atacante. Como por exemplo, exibir informações indesejadas, redirecionar a vítima para um site falso ou até mesmo roubar informações de login.

No caso de injetar no servidor, você precisa ter acesso a uma área editável que interprete códigos, por exemplo uma área de comentários, onde você pode postar algo que sem moderação de um administrador vai ficar para sempre lá. Este tipo de ataque é conhecido como XSS Persistent, explico melhor e mais detalhado no post Explorando XSS com o OWASP ZAP.

Neste post vou falar de outro tipo de XSS, vou falar do Reflected. Neste caso, vamos enviar uma URL modificada, ou um site com parâmetros adulterados para quando a pessoa acessar ser infectada por algo. No nosso caso, vou apenas mostrar uma mensagem no site.

Para este teste não vou usar uma aplicação vulnerável propositalmente, vou usar um site oficial de venda de peças para uma certa marca de carros.

Um campo interessante para o XSS é o de busca que quase todos os sites tem e boa parte deles não é filtrada o que nos permite injetar esses códigos. Vamos fazer um teste, escrevendo "teste" no campo de busca:

Podemos ver que a minha string de busca foi parar na página, você pode ver que no topo da página tem um "parts matching teste" isso quer dizer que tem boas chances de o que eu colocar na busca pode ir parar na página, se for um código interpretado.

Agora vamos tentar colocar um teste que vai disparar uma mensagem de alerta quando a página for executada. Neste site em específico, depois do primeiro email que eu mandei avisando da falha, eles "resolveram" a falha restringindo o número de caracteres que eu posso digitar, nem pude terminar o comando, veja abaixo:

< script > alert ("teste") </ script>

Restringiram meu teste, mas veja como fica a URL quando eu pesquiso qualquer coisa:

Se eu colocar o código direto na URL ele vai sem filtro nenhum e é executado na página, mostrando o alerta que eu queria:

Agora que eu sei que a página executa qualquer código posso colocar um que redireciona o usuário para uma página falsa, ou mando um malware, ou se ele estiver logado roubo seus cookies, etc.

E para finalizar, todos os testes que eu fiz não alteraram nada no site e sim na url alterada que posso enviar para a vítima. Além do mais que eu já enviei inumeros avisos aos administradores do site sobre a falha.

Agora é com você, bons estudos e até a próxima.

Read More

Introdução à Segurança da Informação - Parte 10

E ai pessoal!

Esta semana eu participei da gravação do webinar da Clavis sobre OWASP Top 10 e como não poderia ser diferente, o próximo post do guia teria que ser sobre as principais vulnerabilidades de aplicações web.

Antes de mais nada, acredito que já saibam quem é a OWASP e o que é o OWASP Top 10 então não vou perder muito tempo com isso, se você não conhece absolutamente nada ou muito pouco sobre a OWASP ou sobre o Top 10 acesse o site da OWASP.

O Top 10 de mais conhecidas e exploradas vulnerabilidades de aplicações web teve uma atualização esse ano, mas pouca coisa mudou, alguns tópicos foram unidos, outros mudaram de posição e algumas novidades surgiram, mas apenas mudando a ordem, as ameaças "de sempre" continuam lá. Vamos ver elas uma a uma.

A1 - injection

Quando falamos de injection o que vem a cabeça é o famoso SQL Injection, mas não é só isso, injection é tudo que pode ser passado como parâmetro e uma aplicação vulnerável vai recebe-lo e será executada em algum lugar, como em um banco de dados, em sistemas como LDAP ou até mesmo na shell do sistema operacional. Isso quer dizer que o famoso SQL Injection é apenas uma das variantes desse tipo de ataque.

A2 - Broken Authentication and Session Management

Algumas aplicações que envolvem autenticação e gerenciamento de sessão normalmente não são implementadas corretamente permitindo que atacantes comprometam senhas, tokens e outras ferramentas de autenticação apenas manipulando URL's e alguns parâmetros, ou até mesmo elevando seus privilégios na aplicação para um ataque maior.

A3 – Cross-Site Scripting (XSS)

O XSS é basicamente um tipo de injeção, normalmente voltado ao usuário e seu browser específico, onde passando uma url com um código malicioso, ou de algum modo injetando isso para que quando a página seja carregada esse código seja carregado e infecte a vítima, ou mande seus dados de sessão para o atacante, ou fazendo um defacement no site, ou também enviando o usuário a um site malicioso.

A4 – Insecure Direct Object References

Uma referência dessas ocorre quando um desenvolvedor expõe uma referência a uma implementação de um objeto interno como um diretório, arquivo ou banco de dados. Sem um certo controle ou proteção, um atacante pode manipular essas referências e obter acesso não autorizado a estes arquivos.

A5 – Security Misconfiguration

Uma boa segurança requer ter uma aplicação bem configurada, tanto quanto frameworks, servidor, banco de dados, plataforma e tudo mais. Manter as configurações na instalação Default é normalmente inseguro. Manter softwares sempre atualizados é uma boa prática.

A6 – Sensitive Data Exposure

Muitas aplicações web não protegem de uma forma eficaz informações sensíveis, como número de cartão de crédito, CPF e credenciais. Atacantes mal intencionados podem roubar esses dados ou modifica-los para outros ataques, como engenharia social e roubo de identidade e outros. Esse tipo de informação necessita uma proteção extra como por exemplo uma boa criptografia e precaução quando são transmitidas com os browsers.

A7 – Missing Function Level Access Control

Boa parte das aplicações web atuais verificam todas as informações de permissão de acesso antes de torná-las visíveis em sua interface. Normalmente essas aplicações precisam fazer as mesmas verificações com o servidor, se essas requisições não forem verificadas e propriamente tratadas, os atacantes podem forjar requisições para tentar obter acesso não autorizado a certas informações.

A8 - Cross-Site Request Forgery (CSRF)

Um parente próximo do XSS, esse tipo de ataque força um usuário logado a mandar uma requisição HTTP e incluindo nela seu cookie e outras informações de autenticação para uma aplicação vulnerável. Isso permite que um usuário mal intencionado force o browser da vítima a gerar requisições em seu nome convencendo o servidor de que essas requisições são legítimas da vítima.

A9 - Using Components with Known Vulnerabilities

Basicamente é manter sua aplicação desatualizada, em uma versão com vulnerabilidades conhecidas e disponibilizadas publicamente. Normalmente essas aplicações rodam com todos os privilégios no sistema, se esta aplicação for explorada o atacante pode ter acesso total ao sistema em que a aplicação está rodando.

A10 – Unvalidated Redirects and Forwards

Aplicações web frequentemente redirecionam usuários para outras páginas e sites. Sem uma validação nesses dados de redirecionamento, pode-se redirecionar uma vítima para uma página com malware ou phishing, ou acessar conteúdo não autorizado.

Isto é uma explicação básica da atualização deste ano do OWASP Top 10. Nos próximos posts dessa série vamos ver na prática alguns exemplos de cada uma dessas categorias. Assim que o webinar for disponibilizado pela Clavis eu atualizo este post com o vídeo ou o link.

Até lá!


EDIT: Segue ai o vídeo do Webinar da Clavis.

Read More

Atacando browser por XSS com o BeeF

E ai pessoal!

Achei esse post muito interessante, e vamos traduzir aqui para o pessoal!

O BeeF é um framework para ataque a browsers, com ele podemos roubar sessões, roubar cookies e muito mais, mas primeiro precisamos infectar o alvo.

Para termos o alvo em nossas mãos, um modo é mandar uma url vulnerável a XSS alterada especialmente com nosso "payload".

O comando que precisamos injetar na url é o seguinte:

Lembrando, onde está escrito seu_ip é para colocar seu ip interno, do mesmo modo que a maioria dos ataques, é melhor praticar internamente antes de tentar algo externo que é muuuito mais complexo.

Já de posse de um site vulnerável a XSS, vamos injetar o nosso código e mandar para a vítima.

Assim que o alvo acessar o link vamos ver algo assim no terminal:

E no BeeF:

Este é um pequeno exemplo de como o XSS, conhecido por muitos como inútil, pode servir para algo. Assim que sobrar um tempo eu crio mais uns posts sobre ataques XSS com o BeeF.

Fonte: http://www.hacking-tutorial.com/

Read More