OWASP Top 10: A5 Security Misconfiguration

E ai!

Hoje vamos falar de mais um grupo de falhas do OWASP top 10. Novamente, se você não viu os outros configura na página "Guias"

Dessa vez vai ser algo fácil, o nome já diz tudo, erros de configurações de segurança.

A OWASP teve de criar uma categoria de erros de configuração e configurações default, porque são absurdamente comuns. Quantas vezes já vimos relatos de alguém ou algum grupo que rodou scans em todos os IP's da internet e encontrou milhões de painéis de login com credenciais default. Tanto é verdade que temos o Shodan, que é basicamente um motor de buscas para páginas e equipamentos vulneráveis na internet, sendo a maioria com problemas de segurança ou erros de configuração.

Neste ponto temos problemas bem simples tanto de explorar quanto de resolver. O primeiro deles é as senhas padrões. Praticamente todas as ferramentas, aplicações e dispositivos vem com um padrão de senha bem simples, algo como admin/admin ou similar. Isso é um problema, ja que nenhum sistema de proteção vai conseguir impedir que alguém entre com as credenciais padrão se estiverem ativas.

Outra coisa muito importante é as configurações gerais e de segurança padrões. Você instalar e configurar seu sistema operacional com todas as opções no padrão, o famoso "Next, Next, Finish", não apresenta grandes problemas, os sistemas para usuário final já estão começando a se ligar nisso e proteger o usuário, já que ele mesmo não faz isso. Mas para servidores isso não funciona muito bem, um servidor web configurado por padrão, ou qualquer outro, pode deixar aberto diversas brechas que permitem que um usuário mal intencionado use isso para acessar páginas que não tem acesso, obter informações, atacar diretamente o servidor e por ai vai.

Patchs de segurança não aplicados, ou aplicados sem nenhuma verificação também entram nesse grupo. Não atualizar suas ferramentas e serviços é um problema, acredito que vocês já devem saber isso, mas atualizar tudo sem olhar também pode causar problemas. Um patch de segurança pode corrigir uma falha e causar outras falhas. Sempre é bom ler atentamente o que o patch vai fazer no seu sistema e testá-lo em um laboratório antes de instalar, para evitar novas falhas. Outra coisa que é interessante é apenas instalar as correções para serviços que são usados. Por exemplo, você tem uma aplicação web no servidor e o pacote office está instalado lá. Se vier uma atualização para o a aplicação web deve ser testada antes e se nao causar nada ai sim instalar, mas se vier para o Office não é tão necessário, até porque é um servidor, ele necessita mesmo ter o Office? Caso a resposta seja negativa aproveite e ja remova todo software desnecessário da máquina.

E para finalizar, a maioria das instalações por Default e por má prática da maioria das pessoas, normalmente se usa políticas de black list, bloqueando ameaças a cada incidente onde elas ocorrem, o que muitos sugerem é o uso de white list, onde tudo é bloqueado e só é liberado o que é garantido que não pode causar problemas.

E era isso por hoje! :)

Agora com um pouco mais de tempo livre pretendo terminar o OWASP Top 10 ainda esse ano. Até o próximo!

Read More

OWASP Top 10: A4 Insecure Direct Object References

Olá leitores, hoje vamos ver o quarto grupo de falhas do top 10 da OWASP. Se você não viu os outros três acesse a página "Guias" do site e confira.

Bom vamos lá!

Antes de mais nada, uma referência direta a objeto ocorre quando o desenvolvedor expõe uma referência a uma implementação de um objeto interno, por exemplo um arquivo, diretório, ou informação de banco de dados. Sem uma verificação de controle de acesso ou outro tipo de proteção, um atacante pode manipular essas referências para acessar informações não autorizadas.

Normalmente esse tipo de referência é feito pela URL, e muitas vezes a entrada do usuário vai ajudar a construir a URL, isso quer dizer que se nenhum filtro for aplicado, um usuário malicioso pode ter acesso a áreas onde não deveria ter acesso.

Um exemplo simples desse tipo de referência é os sistemas de blog. Provavelmente você já viu uma URL assim:

http://exemplo.com.br/archive/2014/12/

Se mudarmos na própria URL as datas, vamos direto para outro registro. Por exemplo, se mudarmos o 12 nesse exemplo acima para 11, os posts mostrados são os do mês de novembro, e se mudarmos o 2014 mudaremos o ano. Claro que nesse exemplo todos os posts e páginas são públicas a qualquer usuário, incluindo os não autenticados, mas o ponto aqui é, muitos sites usam esse tipo de referência e poucos se preocupam em verificar se o usuário é válido para a informação.

Um exemplo recente desse tipo de falha foi encontrado a algumas semanas no site Alibaba (Aliexpress), onde um usuário autenticado, pela sua página de informações pessoais conseguia manipular a URL e acessar as informações pessoais de outros usuários, como pode se ver nesse link.

Esse grupo é algo bem simples e fácil, não precisa de ferramentas e nem de muita informação, apenas testando a aplicação e colocando valores arbitrários pode levar a uma falha dessas.

Eu fico por aqui e logo logo pretendo publicar o grupo A5 que também é algo simples e rápido.

Até a próxima o/

Read More

OWASP Top 10: A2 Broken Authentication and Session Management

E ai pessoal!

A muito tempo atrás eu comecei a postar uma série explicando como funciona cada uma das 10 falhas mais comuns, classificadas pela OWASP. Só agora me sobrou um tempo para continuar postando.

Até agora temos 2 falhas já explicadas basicamente. Assim que eu tiver um tempo eu faço um repost um pouco mais detalhado.

Já atualizando para a nova versão do OWASP Top 10, temos até o momento:

OWASP Top 10: A1 Injection
OWASP Top 10: A3 Cross Site Scripting

E vamos ao que interessa!


Cerca de 90% das aplicações web hoje em dia usam simples formulários em HMTL para autenticação, capturando o usuário e senha informado e encaminhando para uma função de autenticação.

Funções de autenticação ou sessão são normalmente desenvolvidas com falhas graves que podem ser facilmente ignoradas podendo causar o vazamento de credenciais, e também causar escalação de privilégios horizontalmente. Escalação de privilégios horizontalmente quer dizer, um usuário comum acessar informações de outro usuário comum, e a escalação vertical é quando um usuário normal acessa informações de uma conta com acesso superior.

O comum nas aplicações web atuais é um sistema de login seguro e completamente blindado onde nenhuma requisição maliciosa pode passar, mas em outros campos como “Esqueci minha senha”, “Lembrar-me”, troca de senha, entre outros, nenhuma verificação de segurança é realizada e através desses campos as informações podem ser obtidas. 

O erro do desenvolvedor está em não dar a mesma atenção com relação a segurança a todos os campos e funções onde o usuário interage com a aplicação. Outro erro bem comum é utilizar exatamente a mesma função de segurança para todas as páginas e campos, o que pode causar algum bug e escapar dos métodos de segurança.

Este tipo de falha está cada vez mais comum hoje em dia, subindo para segundo lugar nesta última versão, tomando o lugar do XSS. Vejamos algumas falhas na criação das aplicações de hoje em dia:

- Senhas fracas: Muitas aplicações web hoje em dia ainda tem falhas críticas nas suas políticas de senha. É comum ver sites que permitem senhas muito curtas ou até mesmo em branco, permitem palavras presentes em dicionários ou nomes, uma senha padrão, ou até mesmo o login na senha.

- Possibilidade de Bruteforce: Sem dúvida você viu o vazamento de fotos que vazou de celebridades a algum tempo atrás. Isso foi causado por essa falta de cuidado. A aplicação permite que um usuário tente diversas vezes combinações de usuário/senha sem problema nenhum, isso quer dizer, permite o uso da técnica de bruteforce de tentar milhares de tentativas.

- Mensagens de erro vazando informação: Normalmente aplicações usam 2 ou mais campos para autenticar usuários, como por exemplo login/senha, e até mesmo outras informações como tokens, senhas de dois passos, datas de nascimento e etc. O maior erro dos desenvolvedores é avisar indiretamente, com mensagens de erros diferentes, qual é o campo que está errado, em vez de uma mensagem genérica.

- Falhas na funcionalidade de mudar a senha: Em muitas aplicações é comum que um campo seja informado errado e volte uma mensagem de erro informando que algum campo de login foi inserido errado. O erro dos desenvolvedores está em informar exatamente qual o campo está errado com mensagens de erro diferente. Um usuário mal intencionado pode usar isso para enumerar possíveis usuários da aplicação e depois executar um ataque de dicionário ou bruteforce para conseguir as senhas. O correto seria uma mensagem genérica de "usuário ou senha incorreta" para dificultar e não vazar informações sensíveis.

- Sistemas de troca de senha falhos: Sistemas de troca de senha ou recuperação de senha podem por descuido também informar informações sensíveis da senha atual. Por exemplo, o campo "Nova senha" pode retornar mensagens de erro como "Nova senha não pode ser igual a senha atual".

E vou ficando por aqui! Eu poderia escrever muito mais falhas e erros básicos que os desenvolvedores cometem até mesmo sem saber, no intuito de fazer algo bom e seguro, que entram nessa categoria de Broken Authentication, mas isso já está bom para exemplificar o que esta categoria do OWASP Top 10 quer dizer.

Imagens originalmente publicadas no livro The Web Application Hacker's Handbook.

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

OWASP Top 10: A1 Injection

E ai pessoal!

Como eu comentei no post Introdução à Segurança da Informação - Parte 10, vou fazer uma subsérie de posts com algumas práticas para mostrar como funcionam as principais vulnerabilidades na visão da OWASP.

Antes de começar tenho que avisar que este é a lista de 2010 não esta nova de 2013, acho que as aplicações vulneráveis de teste ainda não atualizaram as mudanças, mas como é pouca a diferença podemos nos basear muito bem por aqui. Estou usando a aplicação de testes também da OWASP a Multillidae que tem uma boa base para quem está começando, com dicas nas páginas vulneráveis, e também para os mais experientes, pois essas ajudas e a complexidade da falha podem ser alteradas.

Como comentado no post anterior dessa série, quando se fala em injection vem logo a cabeça o SQL Injection. Como estamos falando de Introdução à Segurança da Informação, podemos começar por ele mesmo, vou mostrar aqui alguns modos de atacar um site por SQL Injection.

Eu já postei aqui um paper em várias partes chamado "Pentest em sites com Metasploit", que o objetivo era mostrar como era possível fazer um pentest completo em uma aplicação web apenas com o Metasploit, mas o motivo de estar citando aqui essa série é porque em algumas partes eu citei o sqlmap e até foi mostrado como usa-lo para atacar falhas de SQL Injection. Se você já tem um conhecimento prévio recomendo dar uma olhada lá, caso esteja realmente iniciando agora recomendo que guarde esse link para depois e continue sua leitura aqui neste post.

Vamos ver algo bem básico neste post sobre SQL Injection.

Basicamente, as vulnerabilidades de Injection acontecem quando você pode passar todas as proteções e mandar códigos para serem executados no servidor ou banco de dados. No nosso caso aqui, vamos mandar alguns códigos para o servidor na hora da verificação de autenticação que vai nos liberar acesso a uma área restrita do site, logar sem ter um usuário e senha.

Para facilitar a explicação, deixei na dificuldade mínima e dicas habilitadas.

Neste caso temos o formulário de login, um teste básico que podemos fazer é colocar um apóstrofo no campo e enviar e ver o que acontece. Em muitos casos onde ha a vulnerabilidade as saídas de erro não são tratadas corretamente e acabam aparecendo na página.

No caso de um site real vulnerável você receberia uma página em branco ou a mesma página com a mensagem "/owaspbwa/owaspbwa-svn/var/www/mutillidae/classes/MySQLHandler.php on line 108: Error executing query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''' AND password=''' at line 1 () (0) [Exception] " aparecendo em algum lugar. As outras informações são as dicas do Mutillidae.

Para entendermos melhor como isso funciona, vamos observar a linha Diagnostic Information que contém o comando executado no banco de dados quando preenchemos os campos de login e senha.

Com um pouco de conhecimento em banco de dados SQL podemos ver que ele pega tudo da tabela accounts onde o usuário é ' (o apóstrofo que eu coloquei) e a senha é vazio. Se eu colocar qualquer coisa ali ele vai testar, ver que não encontrou nada igual no banco e retornar "false" que quer dizer que eu digitei o usuário ou senha errado. Neste caso eu obtive o erro porque a aplicação não soube lidar com o caractere que eu usei. Se você parar para notar, os conteúdos dos campos são delimitados pelos mesmos apóstrofos, com isso criei um conflito que misturou todo o comando e me retornou o erro. Isso quer dizer que, como ele aceitou numa boa um apóstrofo eu posso utilizá-lo para fechar o conteúdo do campo e continuar escrevendo o comando diretamente do formulário de login.

Vamos ao exemplo mais prático, o famoso ' or 1=1 --. Para os mais leigos, isso quer dizer que o comando que será executado no banco vai ser um pouco diferente, vejamos:

SELECT * FROM accounts WHERE username='' or 1=1 --' AND password='' or 1=1 --'

Com isso temos, pegue tudo da tabela accounts onde o usuário é vazio ou 1 é igual a 1 e a senha é vazio ou 1 é igual a 1 e ignore todo o resto (os dois traços). Lembram-se acima quando eu falei que o banco checaria e por não ter a combinação de usuário/senha ele retornaria "false"? E agora, o que você acha que ele vai retornar? "True"! Isso mesmo, por mais que ele não encontre as credenciais que eu passei ele sempre vai cair na verificação de que 1 é sempre igual a 1, por isso retorna "true" e nos autentica:

E ai está! Conseguimos os detalhes das contas cadastradas no site.

Mas não paramos por aqui, ainda temos algumas coisas a ressaltar. Não será em todos os casos que isso vai funcionar, os comandos variam com a linguagem que o banco de dados usa, veja abaixo algumas outras possibilidades:

b’ or ‘ 1=’
‘ or ’1
‘ or ‘|
‘ or ‘a’='a
‘ or ”=’
‘ or 1=1–
‘) or (‘a’='a
‘ or ’1′=’1
admin ‘ – -
‘ ou 0=0 –
“ou 0=0 –
ou 0=0 –
‘ ou 0=0 #
“ou 0=0 #
ou 0=0 #
‘ ou ‘ x’='x
“ou” x”=”x
‘) ou (‘ x’='x
‘ ou 1=1 –
“ou 1=1 –
ou 1=1 –
‘ ou a=a –
“ou” a”=”a
‘) ou (‘ a’='a
“) ou (“a”=”a
hi “ou” a”=”a
hi “ou 1=1 –
hi ‘ ou 1=1 –
hi ‘ ou ‘ a’='a
hi ‘) ou (‘ a’='a
hi”) ou (“a”=”a
‘ or ‘x’='x

Mas não pare por ai! Se nada der certo, procure forçar um erro para ter uma pista de qual banco de dados está sendo usado, com essa informação procure como que aquele banco em específico trata os comandos e entradas e use sua imaginação para bolar uma injeção de código. Nem sempre pegar o que já está pronto pode te ajudar.

Agora uma coisa muito interessante que poucos se preocupam em falar, como podemos proteger os sites de Injection? Mais simples do que você imagina, ou não depende da complexidade da sua aplicação. A regra mais importante aqui é "trate todo a entrada como maliciosa", com isso em mente você poderá prever todas ou boa parte das possibilidades. Avalie, filtre e trate antes de chegar ao banco de dados. Existem algumas funções já prontas, como o Magic Quotes por exemplo, que prometem filtrar esses parâmetros, não sou a melhor pessoa para falar sobre isso porque não sou programador, mas recomendo que procure mais sobre isso.

Não preciso comentar em manter sempre tudo atualizado e regularizado, isso pode não resolver, mas pode diminuir o estrago ou até mesmo diminuir a quantidade de informação vazada.

E para finalizar, um ultimo ponto que considero interessante é a utilização de um WAF (Web Application Firewall), que vai detectar essas ameaças e cortar a conexão antes que um dano maior ocorra, e um concelho, não mostre mais do que o necessário, trate todos os erros que sua aplicação pode gerar.

Eu fico por aqui depois desse longo post, espero que tenham entendido e gostado, porque querendo ou não tem pelo menos mais 9 desses vindo por ai :)

Também indico que baixem e testem o Multillidae, que tem várias situações para você tentar resolver que sem dúvida vão refinar seu conhecimento.

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