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

[Tool] OWASP iOS Forensics

E ai pessoal!

Hoje vou indicar uma ferramenta bem interessante para forense no iOS.

O iOS Forensics é uma ferramenta desenvolvida em Python para analisar e recuperar dados de dispositivos iOS. A ferramenta é livre e gratuita, desenvolvida pela OWASP.

Dependências da ferramenta:

Linux

• OpenSSH
• sshpass
• sqlite3
• Python >= 2.6
• Python-magic
• plistutil

Dispositivo

• Dispositivo com Jailbreak
• OpenSSH
• Wifi habilitado
• Conectado via USB no firmware mode

A ferramenta parece ser muito boa, mas apenas para dispositivos com jailbreak. Para dispositivos com o sistema ainda íntegro não acredito que exista um meio simples ou possível de obter os dados.

Mais informações e download da ferramenta no GitHub.

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

Hacker rouba 100 mil dólares de usuários de um ISP da Califórnia apenas com um simples SQL Injection

Recentemente um grupo hacker chamado "TeamBerserk" declarou no Twitter que roubou cerca de $ 100.000 dólares obtido através de usuários e senhas capturadas de um ISP californiano e usando essas informações para acessar as suas contas bancárias.

Um vídeo prova foi upado, mostrando como eles usaram SQL Injection contra o ISP para acessar o banco de dados que continha email, usuários e senhas em texto plano e usaram essas informações para roubar dinheiro dos clientes.

Vamos ver o que é SQL Injection e quão sério um ataque deste tipo pode ser. SQLi é uma vulnerabilidade encontrada em aplicações web onde o atacante pode injetar códigos SQL no banco e utilizar isso para acessar recursos internos. Usando esta técnica, hackers maliciosos podem determinar a estrutura do banco e comprometer e/ou baixar todos os dados dos servidores.

Eles levaram apenas 15 minutos para hackear o site com uma ferramenta chamada sqlmap, roubaram os dados e tiveram acesso imediato a contas de email, Paypal e internet banking.

É muito difícil lembrar de diversas senhas, por isso o que a maioria faz é usar a mesma em tudo. Sua senha do Facebook é a mesma do Twitter? E a do site do seu banco?

Agora já deve estar mais do que explicado porque esse tipo de falha é extremamente perigosa. No vídeo de prova de conceito, o atacante escolhei randomicamente um usuário e sua respectiva senha e tentou logar em diversos outros sites, entre eles PayPal, Gmail e CitiBank, e o mais impressionante é que ele conseguiu.

Agora que você já está ciente que ataques podem vir de qualquer lugar, não deixe isso acontecer, se você usa internet banking, compra pela internet, ou acessa outros dados sensíveis, o melhor a se fazer, pelo menos para dificultar é usar senhas difíceis e variadas para cada serviço.

Fonte: The Hacker News

Read More

OWASP Top 10 2013 em português

OWASP TOP 10 2013 é um dos mais importantes documentos/guias sobre segurança focada em aplicações WEB. Leitura mais do que obrigatória para todos aqueles que desejam aprender mais sobre o assunto, por dois simples motivos:

Ele é didático e agora está em nossa língua.

Destaque para os pontos em que ele passa dicas para saber se vc está vulnerável, para como resolvê-la e exemplos de ataques.

A tradução para o português foi graças ao grupo de pesquisadores de nossa área. Já dei uma passada/lida no documento e posso dizer que ficou bem legal. Então aí vai o parabéns do pessoal do blog, mesmo sabendo que isso não vale muita coisa. 

O download desta versão poderá ser realizado a partir do seguinte link.

Fonte: Coruja de TI

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

Explorando XSS com o OWASP ZAP

Estou praticando a alguns dias minhas habilidades de segurança em geral no projeto Hacking-Lab da OWASP. Já postei aqui sobre esse projeto, ele está cada vez maior, com mais desafios e cada vez com mais empresas olhando. Recomendo a todos que criem uma conta, estudem pelos links disponibilizados nos próprios desafios e tente resolver os desafios. Já houve casos de contratação por empresas gigantescas através dos resultados no site.

Hoje resolvi o desafio de XSS na categoria OWASP Top 10, e tive que aprender algumas coisinhas para que tudo funcionasse, veja aqui algumas dicas (sim, não vou entregar tudo se não entrego a resposta do desafio :D ) que tive que aprender para resolver o desafio: 

Vamos pular a parte de baixar e configurar todo o lab, se vire com isso :)

O objetivo do desafio é que eu consiga postar nos comentários de um site específico deles um código malicioso que capture e envie para um site meu os cookies de todos os usuários autenticados que abrirem a página de comentários.

Antes de mais nada eu precisava descobrir algum lugar que fosse vulnerável a XSS, nas dicas do site tinha que eu deveria comprar uns sinos para vacas personalizados (sim o site é um e-commerce disso) para poder ver a área de comentários. Após colocar alguns sinos no carrinho finalizei a compra (com um cartão e usuários fictícios) tive acesso a área de comentários. Fiz então o que qualquer um faria, testar se o campo era vulnerável, colocando um código javascript no comentário e obtive a resposta de que o comentário só poderia conter letras, números, pontos e vírgulas, então meu código não iria funcionar. O código que eu usei foi o seguinte:

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

Como não posso usar nenhum símbolo o que eu posso fazer? Depois de pensar muuuuito eu lembrei de uma das minhas aulas da Clavis onde demos uma leve passada por uma tool chamada Burp Suite, que uma de suas funções é manipular os GETS, POSTS e tudo mais de uma aplicação web, com isso quem sabe eu poderia manipular depois desse teste meu input e assim explorar o XSS.

Depois de muito procurar na distro disponibilizada pelo hacking-lab percebi que eles não tinham o Burp Suite disponível para uso e então fui em busca do download pelos repositórios que também não tinham. Apos algumas buscas no Google consegui baixar mas não consegui usar, parece que não tem java essa vm...

Depois de perder um bom tempo dando voltas achando um modo de fazer aquilo funcionar decidi dar uma olhada nas tools que eles tinham disponíveis, e eis que encontro um tal de OWASP ZAP. Novamente fui para as buscas e manuais para aprender como usar e configurar essa tool e vi que não é muito difícil, no próprio site da tool tem tudo explicadinho.

Após tudo configurado e funcionando vamos ao site alvo. O OWASP ZAP é bem similar ao Burp Suite no que eu sei usar então não foi uma adaptação muito difícil.

O Firefox da VM tem um plug-in já configurado com o proxy do ZAP, só ativar e iniciar a interceptação no proxy, clicando nas duas setas verdes na barra de ferramentas, sendo uma delas para interceptar as requisições e a outra para as respostas do servidor.

Agora com tudo pronto vamos a exploração. Coloco qualquer coisa no campo de comentário e assim que eu clicar em adicionar (Add) eu já vou ter um resultado no ZAP.

Repare que no final da terceira linha eu tenho um parâmetro chamado comment=teste, vamos alterá-lo para nosso código malicioso de teste e ver o que acontece:

E ai está! Consegui burlar o filtro e injetar meu código que vai rodar para todos os usuários que visualizarem a página com os comentários. Agora para o desafio, só precisamos alterar o comando para o comando que manda o cookie, mas isso eu deixo para vocês para completarem o desafio.

Bons estudos!

Read More

Podcast: Um ótimo canal de comunicação sobre infosec

Olá novamente!

Estava eu vagando pela internet a procura de conteúdo para estudo sobre infosec e consequentemente para por no blog e eis que eu encontro um podcast muito interessante sobre o assunto. Como eu já tinha procurado no iTunes sobre isso, maior agregador de podcasts que existe, e encontrado muito pouco a respeito acabei acreditando que não existisse muitos podcasts focados em segurança da informação. Ai que me engano, após encontrar um desses podcasts em uma busca do Google meio ao acaso acabei novamente procurando mais sobre o assunto e desta vez encontrei bastante conteúdo.

Mas antes de citar os podcasts, vou explicar rapidamente o que é um podcast, que acredito que muitos leitores não conheçam ou não estão familiarizados com termo. Podcast é nada mais nada menos que um programa de audio gravado, com duração variável de 30 minutos a 3 horas, onde os participantes discutem sobre os mais variados assuntos, no nosso caso segurança da informação, TI, e relacionados. Sempre cito o exemplo que podcast é muito parecido com um programa de rádio para fácil entendimento, a diferença é que o podcast você pode baixar e ouvir a hora que quiser. Para mais informações sobre ou uma descrição melhor vá ver na Wikipedia.

Então vamos lá, vou listar aqui apenas os podcasts que eu já escutei ou ouvi falar, se você tem um podcast e não citei aqui não fique bravo, provavelmente eu não conheça, entre em contato e trocaremos informações. :)

Separando em 2 grupos, podcasts brasileiros e podcasts estrangeiros:

Brasileiros:

SegInfoCast - O podcast do Blog SegInfo, super conhecido, dispensa apresentações
Para sua Segurança - O podcast Para sua Segurança da vontade de um grupo de amigos em discutir questões relacionadas a Segurança, Controles Internos e Gestão de Riscos de forma mais descontraída.
Paulo Santanna - A idéia dos podcasts é bater um papo informal com profissionais de renome a respeito de temas pertinentes à nossa atividade e ao Mercado de TI.
Stay Safe Podcast - Podcast voltado para segurança da informação, papo descontraído e de muito boa qualidade.
NaoPod - Podcast do I Shot The Seriff, com assuntos do mundo de segurança, notícias e eventos pelo mundo.

Estrangeiros:

ASIS Security Management Podcast - Podcast da revista ASIS Security Management, voltado mais para a segurança física.
CyberSpeak - Podcast voltado para a área de forense.
Eurotrash Security Podcast - Podcast formado por pesquisadores e hackers europeus.
Exotic Liability Podcast - Podcast focado em pentest e engenharia social, com linguagem e conceitos obscenos.
OWASP Security Podcast - Voltado obviamente para aplicações web.
Network Security Podcast - Podcast com as notícias do mundo da infosec.
PaulDotCom Security Weekly - Um dos melhores, mais conhecidos e mais periódicos casts do gênero, podcast altamente técnico, com videocasts, noticias da semana, casts com convidados e muito mais, feito pelo pessoal da BSides e SANS.
Social-Engineering.org Podcast - Como o nome já entrega, podcast focado em engenharia social, altamente recomendado.



E com isso temos aqui bastante material para escutar. O bom dos podcasts é que pode-se escutar em qualquer lugar, e pode-se muito bem escutar em partes como melhor convir. Fica a dica ai para o pessoal que deseja receber sempre um bom conteúdo sem ter muito trabalho. Coloquei também os estrangeiros para quem tem uma boa noção de inglês e quer algo um pouco mais aprofundado.

O unico ponto não negativo, mas também não muito bom é a periodicidade desses casts. Alguns são semanais, alguns quinzenais e alguns mensais, mas tem alguns que são lançados novos a cada ocasião especial ou a cada momento de sobra nas vidas desses profissionais, mas isso não é desculpa para não ouvir.

Cada podcast tem seu estilo, com essa variedade você certamente achará um que agrade, e lembre-se, não adianta somente ouvir, você tem que estar interessado no assunto, prestando pelo menos a mínima atenção, caso contrário é só uma perda de tempo.

Eu fico por aqui e tenha uma boa noite ouvindo seu cast preferido.

Read More