Mostrando postagens com marcador conceitos básicos. Mostrar todas as postagens
Mostrando postagens com marcador conceitos básicos. Mostrar todas as postagens

quinta-feira, 18 de dezembro de 2014

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!

segunda-feira, 15 de dezembro de 2014

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/

quinta-feira, 13 de novembro de 2014

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.

sábado, 20 de julho de 2013

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.

terça-feira, 16 de julho de 2013

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!

sábado, 13 de julho de 2013

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.


segunda-feira, 8 de julho de 2013

Continuando com nosso guia, vamos ver uma técnica usada em várias ocasiões para obter acesso sabendo parte ou nenhuma informação das credenciais, o Brute Force.


Brute Force

O brute force é considerado uma técnica de invasão, não muito eficaz na minha opinião, mas uma das mais antigas e conhecidas técnicas. Seu funcionamento é muito simples, o programa de brute force gera uma wordlist (lista de palavras) com milhares de possibilidades e vai tentando uma a uma, até conseguir descobrir a senha.

Wordlist


Wordlist é um arquivo de texto no formato .txt, lido por qualquer ferramenta, com várias palavras ou combinações de caracteres, um por linha e são usadas para tentar adivinhar credenciais. 

Provavelmente uma wordlist é o maior arquivo de texto puro que você verá, por exemplo, uma wordlist com todas as possibilidades de senhas de 8 a 12 caracteres vai conter milhões de combinações diferentes e vai ter mais de 1TB. Imagine quanto texto é necessário para preencher 1TB. Faça um teste, crie um arquivo no bloco de notas ou editor de texto, coloque apenas uma palavra e salve e veja o tamanho que da. Não mais que alguns KB's correto?

Criando uma wordlist

Existem vários programas e ferramentas que podem criar wordlists, o que eu vou falar aqui é um que considero simples, o crunch. A sintaxe do crunch é a seguinte:

crunch tamanho_minimo tamanho_maximo > arquivo_wordlist.txt

E um exemplo simples:

crunch 4 8 0123456789 > /root/Desktop/wordlist.txt
O comando do exemplo vai colocar no diretório do root, em um arquivo chamado wordlist.txt todas as combinações possíveis de 4 a 8 caracteres contendo apenas números. Veja este outro exemplo:


crunch 8 8 1234567890 -t joao@@@@ > /tmp/joaolist 

Neste outro exemplo, temos uma senha iniciada em joao e terminada em uma combinação de 4 números, salvando todas as possibilidades num arquivo chamado joaolist.

Já para a parte de quebrar senhas e brute force na prática vou deixar para um post separado. Já fiz um post sobre o john the ripper que é uma das melhores ferramentas para brute force.

Contras

Brute force parece algo milagroso né? Sim, o brute force sempre vai quebrar a senha, mas agora vem a notícia ruim, pode ser que isso leve alguns séculos. Quanto maior a complexidade da senha mais tempo vai levar para quebra-la, por isso que a dica de senha sempre é recomendado que tenha letras maiúsculas, minúsculas, números e símbolos. Quanto maior a quantidade de caracteres e de tipos de caracteres menor a possibilidade de quebrar. Como por exemplo no GRC, o Steve Gibson da o exemplo da senha D0g..................... que leva apenas 9.38 centenas de trilhões de trilhões de anos (pense num número grande :) ) e é uma senha relativamente simples de lembrar e usar.

Um outro detalhe que tem que se levar em conta é se o ataque vai ser online ou offline. Por exemplo, se você está fazendo brute force em um serviço como ssh, ftp e etc, você está fazendo um ataque online, se você conseguiu os hashs de senha você está executando um ataque offline.

Então, depois de tudo que vimos aqui neste post, podemos concluir que ataques de brute force devem ser usados em últimos casos, porque demandam um grande poder computacional e podem demorar e não retornar resultados interessantes. Para agilizar você pode usar técnicas das fases de levantamento de informações para gerar uma wordlist com possíveis palavras chave. Isso pode poupar bastante tempo.

Uma dica final: Baixar aquelas wordlists gigantescas com milhões de possibilidades e passar horas tentando não é uma prática muito boa.

segunda-feira, 1 de julho de 2013


Olá pessoal! Deixei um pouco de lado essa série por falta de tempo, mas não parei, ainda temos pelo menos mais 10 partes.

Na parte de hoje vamos conhecer as principais ameaças, quem são elas e como elas funcionam.

Backdoor

Os backdoors são programas instalados em máquinas previamente infectadas para manter o acesso remoto a esta máquina. Como o nome já diz, o Backdoor (porta de tras) abre uma porta na máquina para conectar-se ao atacante, normalmente. Com o avanço das tecnologias empregadas em segurança como antivirus e outros softwares, só abrir uma porta não é o suficiente. Os backdoors mais sofisticados podem ficar aguardando a conexão sem abrir a porta, ou até mesmo ficar escutando em uma porta conhecida e já em uso até receber a conexão. 

Também podem existir backdoors em programas, colocados lá pelos próprios programadores por motivos de testes ou controles, não documentados e as vezes não removidos depois dos testes, podendo causar um belo estrago em quem usa esses programas se descobertos.

Cavalo de Troia

Acho que não preciso dizer que o nome veio do presente grego aos troianos a um bom tempo atras, onde deram um cavalo de madeira com soldados dentro e blá, blá, blá.

No nosso caso, um Trojan se parece com um programa normal, ou o mais comum, é um programa normal pago que você crackeou. A função do trojan é basicamente ser uma coisa e se parecer com outra. O mais comum é que em quanto você está rodando o programa, ele ao mesmo tempo que funciona como você espera ele está capturando tudo o que você faz e mandando para quem o criou.

Os antivirus de hoje em dia conseguem pegar boa parte dos trojans, porque a maioria deles é feito da mesma maneira, mas a cada dia novas variantes surgem. O principal uso de um trojan é esconder o atacante do alvo, ou esconder rastros e arquivos para evitar que seja descoberto.

Rootkit

Rootkits são basicamente um conjunto de ferramentas que um atacante instala na máquina ou diretamente no kernel do sistema que da a ele diversas regalias. Trojans e Backdoors são componentes essenciais de um Rootkit.

Vírus

Vírus são programas genéricos para os mais diversos fins, entre eles os principais são infectar e modificar o sistema para que o atacante ganhe acesso ou obtenha informações do alvo.

Worm

O Worm é bem similar aos vírus, podem ser usados para as mais diversas coisas. A única diferença que os mantém em categorias diferentes é que um vírus ele necessita que o usuário execute o programa para que ele infecte a máquina, já o Worm consegue ir de máquina em máquina, explorando falhas específicas e infectando mais e mais computadores por conta própria.

Keylogger

Keyloggers são ferramentas que interceptam o que é digitado no teclado e enviam para o atacante. Boa parte dos interessados em hacking ou lammers começam por esses programas, mas o que poucos sabem é que existe o hardware Keylogger, que intercepta antes mesmo de o sinal chegar ao computador. Veja a imagem abaixo:


Do mesmo modo que os Backdoors, os Keyloggers tiveram de se reinventar. Com o aumento dos módulos de segurança de sites e bancos, os Keyloggers começaram a capturar a posição da tela e os mais "tops de linha" até tiram screenshots da tela a cada clique.

Isso é uma passagem básica pelos conceitos, nos próximos posts vamos ver mais a fundo cada uma delas.

terça-feira, 11 de junho de 2013


Algumas pessoas pensam que os pesquisadores de segurança precisam ser ex-hackers para serem eficazes.

Outras pessoas pensam que você pode treinar uma pessoa a tornar-se um pesquisador de segurança e eles serão capazes de fazer o seu trabalho muito bem.

Mas a simples verdade é que não importa se você é um hacker natural ou de um pesquisador de segurança treinado, você precisa saber o funcionamento interno do computador, a fim de tornar-se excepcional em seu trabalho.

Claro, você pode ser capaz de fugir com apenas saber o básico, mas se você realmente quer fazer um nome para si mesmo e se destacam na indústria, então você precisa saber computadores e redes dentro e por fora.

Você deve ser capaz de tomar essa informação e usá-la a seu favor.


Comece por Sistemas Operacionais

As primeiras aulas que você deve tomar para ser um pesquisador de computador é uma introdução à classe de sistemas operacionais.

Não importa se você está indo trabalhar em segurança de desktop ou manter a segurança da rede da sua empresa, você ainda terá que lidar com o desktop.

Mesmo em um servidor, o sistema operacional ainda é a coisa que governa tudo.

A maioria dos ataques de hackers resultará neles encontrar alguma maneira que eles são capazes de explorar o sistema operativo.

Eles podem fazer isso porque eles têm estudado o sistema operacional e como ele funciona.

Se você quer ser capaz de neutralizar um ataque como esse, você precisará ser capaz de conhecer as partes móveis de um sistema operacional também.

Isso não é algo que deve ser tomada de ânimo leve.

Se o seu adversário, que é o hacker black hat, sabe mais do que você faz, então eles já estão a meio caminho do jogo ganho.

Redes é a próxima

A próxima coisa que você deve estudar, se você ir para o topo é como as redes funcionam.

A maioria dos hacks são entregues através da internet para saber como é essencial para ser capaz de parar um ataque a internet e menores redes de trabalho.

Você precisa conhecer as teorias por trás das sete camadas da rede e que certos protocolos como TCP, HTTP, UDP e outros.

O que é mais importante é que você deve saber como esses protocolos interagem uns com os outros.

Dessa forma, se for necessário, você vai ser capaz de ler um ataque e contra-atacar na hora.

Estudos empresariais

A última aula que você deve ver para se preparar para a sua carreira em segurança informática é um curso de negócios.

A segurança dos computadores nos dias de hoje é mais apenas tentar encontrar e parar exploits acontecendo na rede.

Você também deve ser capaz de interagir com as pessoas que trabalham nessas empresas também.

Saber falar a língua deles é uma grande vantagem em fazer isto.

Você não tem a menor no mundo dos negócios para alcançar este objetivo, mas tendo uma ou duas classes não faria mal.

Se seu objetivo final é segurança da informação essas dicas podem te ajudar, te dar um foco e te mostrar o caminho para onde você deve ir. Depois de ter dominado esses três tópicos que você pode se aprofundar em conteúdos mais específicos.

sexta-feira, 31 de maio de 2013

E ai! Continuando com a série, hoje vamos ver um pouco sobre enumeração, algumas ferramentas e métodos para obtenção de informação sobre serviços e portas.

Enumeração

Esta etapa consiste na identificação dos serviços que estão rodando nas portas dos sistemas descobertos, além da descoberta do sistema operacional utilizado. Compilação de dados sobre recursos disponíveis, tais como compartilhamento e usuários existentes no sistema.

Antes de iniciar, quero reforçar que você deve conhecer e usar mais de uma ferramenta a partir dessa fase. Além de confirmar o serviço que esta rodando, utilizando mais de uma ferramenta você pode conseguir mais informações. É bem comum algumas ferramentas não conseguirem encontrar algum serviço específico, mas outra ferramenta encontrar.

Para obtermos esses dados, podemos usar o clássico telnet em cada uma das portas para capturarmos o banner. Não é necessário, mas é bom para confirmar, já que existem muitas ferramentas por ai que automatizam isso, então fica por sua escolha.

nmap

Como vimos no post anterior dessa série, podemos utilizar o nmap para obter informações como serviços, portas e sistema operacional.

Xprobe2

Outra ferramenta interessante que pode ser usada para obtenção de informações sobre o sistema operacional.

Ettercap

Em alguns casos, como demonstrado na parte 4 desta série, podemos usar até mesmo o ettercap para pegar informações sobre o sistema operacional e servidor web.

Maltego

Faz varredura de redes, serviços, protocolos, domínios e várias outras opções, informando de forma gráfica a relação entres os hosts ativos. 


Lanmap


Varre toda a rede e captura pacotes, criando ao longo de sua execução um arquivo .PNG com o mapa da rede, informando graficamente a relação das máquinas encontradas. 


Descoberta de Vulnerabilidades

Nessus

Uma das ferramentas mais conhecidas e completas para descoberta de vulnerabilidades, o Nessus é gratuito apenas para uso doméstico, e pode ser encontrado no site www.nessus.org. Contando com centenas de plugins para descoberta de vulnerabilidades nos sistemas e serviços, o Nessus é indispensável quando estiver em busca de vulnerabilidades.

Nikto

O Nikto é um scanner de vulnerabilidades de aplicações web. A ferramenta conta com mais de 8000 testes diferentes, para auditar todo o tipo de servidor, aplicação, arquivo ou string disponível.O Nikto já retorna informações sobre a falha encontrada, para você poder saber do que se trata e como explorar a falha.

WPScan

O WPScan é uma ferramenta voltada para sites Wordpress. Esta ferramenta pode encontrar muito mais do que apenas vulnerabilidades no site ou em plugins, pode também fazer enumeração de usuários, descoberta de diretórios, bruteforce no painel de login e muito mais.



Vega

Está ferramenta busca por vulnerabilidades em sistemas, bem similar ao Nessus, mas com suas limitações. Já temos um post falando um pouco melhor sobre esta ferramenta aqui. Ferramenta de fácil uso, apenas colocar o ip ou endereço que ela já começa a testar.

Acunetix

Bem similar ao Vega e ao Nessus. O Acunetix está disponível para Windows e além das funções de análise de vulnerabilidades, o Acunetix faz um ótimo trabalho listando diretórios e páginas do site.

Metasploit

Sim! Até o Metasploit pode ser usado para obter informações sobre serviços e vulnerabilidades. O Metasploit conta com vários módulos de scan de vulnerabilidades, não é sua função principal, mas assim como o nmap, pode ser usado para levantar informações sobre vulnerabilidades. Algumas desses módulos você pode conferir na série de posts "Pentest em Sites com Metasploit" que fizemos a algum tempo atrás.

Mas isso não é tudo. Existem milhares de ferramentas para isso, alguma mais focadas como o WPScan, para auditar sistemas e serviços específicos.

segunda-feira, 27 de maio de 2013

No-Tech Hacking e Engenharia Social

E ai pessoal, vamos dar continuidade com nossa série de posts sobre o básico da Segurança da Informação. O tópico de hoje é a engenharia social e todos os outros métodos conhecidos como No-Tech hacking. No-Tech Hacking é o termo utilizado para ataques voltados para computadores, infraestruturas ou até mesmo o usuário, sem necessariamente usar de tecnologia para isso. Veremos alguns exemplos daqui a pouco.


Engenharia Social



Segundo a Wikipedia, engenharia social é:

Em Segurança da informação, chama-se Engenharia Social as práticas utilizadas para obter acesso a informações importantes ou sigilosas em organizações ou sistemas por meio da enganação ou exploração da confiança das pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra personalidade, fingir que é um profissional de determinada área, etc. É uma forma de entrar em organizações que não necessita da força bruta ou de erros em máquinas. Explora as falhas de segurança das próprias pessoas que, quando não treinadas para esses ataques, podem ser facilmente manipuladas.

Basicamente, como explicado acima, engenharia social é a técnica que ataca o conhecido "elo mais fraco da corrente", o usuário. Se você pretende se aprofundar um pouco mais nesta nobre arte veja os posts Pentest Físico,  onde falo um pouco sobre o Tiger Team, um grupo de pentesters que usa de engenharia social para invadir lugares altamente seguros, a indicação do livro Social Engineering: The Art of Human Hacking, e um pequeno exemplo demonstrado no livro, e o filme baseado na captura de um dos maiores se não o maior engenheiro social de todos os tempos Kevin Mitnick.

Mas para os preguiçosos, vou deixar aqui um exemplo que se não me engano foi o Luiz Vieira que deu em uma palestra no SegInfo.

Veja como é fácil entrar em uma empresa, onde na porta de entrada tem um dispositivo de segurança como um leitor de digital ou cartão. O ser humano tem quase como instinto ajudar um semelhante. Se alguém da empresa está na porta e você chegar com uma caixa grande aparentando ser algo pesado, após a pessoa se autenticar e passar ela vai se dispor a segurar a porta para você entrar e nisso ela acaba comprometendo a segurança física da empresa, isso se chama tailgating.

Outro exemplo bem interessante é uma livraria. Você entra com uma sacola da livraria e sem que ninguém perceba pega um livro da prateleira e coloca na sacola e se dirige ao caixa. Ao chegar, com muito bom humor cumprimenta a pessoa que está no caixa e diz que ganhou este livro e que não gostou ou já tinha e que gostaria de trocar. Independente se a resposta for positiva ou negativa, você agradece e sai da livraria. Com isso você acaba de conseguir um livro gratuitamente.

Mas engenharia social não é só isso de ir pessoalmente até o alvo e interagir diretamente com ele, isso é apenas uma das atividades de um engenheiro social. Ataques também podem ser feitos por telefone, veja o filme do Mitnick, ou até mesmo por computador. Você provavelmente já recebeu spam com alguma coisa aleatória informando que você ganhou algo ou que algum orgão importante está te procurando e te sugere clicar num link, isso se chama Phishing. Pishing é outra atividade de um engenheiro social, se passar por uma pessoa ou instituição, chamar sua atenção e fazer você baixar algum arquivo malicioso para acessar seu computador. Esse é um dos métodos mais efetivos e comuns de ataque hoje em dia. Existe também o phishing direcionado, feito especialmente para um alvo em específico, esta técnica é conhecida como Spear Phishing.


Dumpster Diving



O dumpster diving é o ato de literalmente catar no lixo do alvo por informações sensíveis que podem ser usadas em um ataque. Você já parou para olhar o que vai para o lixo e como é tratado o lixo onde você trabalha? Alguém anota uma senha nova num papel e assim que memoriza este papel vai para o lixo. Outro exemplo citado no livro que eu indiquei anteriormente é onde o autor está fazendo uma auditoria e como já vinha sendo feita por outra empresa ele encontrou poucas ou quase nenhuma vulnerabilidade nos sistema da empresa e teve que apelar para o lado mais no-tech. Com uma pequena pesquisada no lixo ele encontrou informações sobre uma terceira empresa que prestava serviços as máquinas no alvo. Até encontrou nomes de funcionários, um cartão da empresa prestadora de serviços e os horários que eles normalmente passavam por lá para conferir os sistemas.

De posse dessas informações o autor ligou para a empresa prestadora de serviços se passando por um funcionário do alvo avisando que fechariam mais cedo naquele dia e que não precisava mandar ninguém naquele dia. No horário que a monitoria deveria acontecer ele se passou pelo funcionário e foi até o alvo, apresentou o cartão achado no lixo e teve acesso irrestrito aos sistemas da empresa, podendo fazer o que fosse necessário para infectar os sistemas.


Lockpicking


Lockpick é a arte de abrir portas, cadeados, e tudo mais que pode ser trancado com uma chave. Com essas ferramentas com com um pouco de estudo sobre os mecanismos de segurança usados em fechaduras você pode ser capaz de abrir qualquer porta trancada ou cadeado que esteja bloqueando seu caminho até a sala do servidor. Sempre que se fala nas lockpicks, conhecidas como michas aqui no Brasil, já se vem a cabeça sobre leis e muitas pessoas alegam ser crime andar com elas por ai e pode te trazer problemas. Teoricamente elas até estejam certas, mas pelo que eu ouvi falar você só vai ter problemas se for visto arrombando alguma porta ou cadeado ou se já tiver passagem pela polícia por algo similar. Em alguns casos, destrancar uma porta pode ser mais simples e valioso do que hackear um sistema.

Proteção

E agora, nem imaginávamos que existisse métodos deste tipo empregados em segurança da informação, como vamos fazer para proteger nossas empresas desse tipo de ataque?

Primeiro de tudo, os funcionários da empresa precisam ser treinados para esse tipo de coisa, mas um pouco de bom senso também vai bem. No caso da porta com autenticação, se você nunca viu a pessoa antes e sabe que para entrar é necessário a autenticação na porta não sinta-se mal em fechar a porta na cara da outra pessoa, por mais que pareça rude pode salvar a empresa de um ataque, ou um dano maior apenas evitando o tailgating. Também é bom prestar a atenção se não tem ninguém olhando quando você digita alguma senha ou informação confidencial. Também não é recomendado conversar sobre assuntos internos de respeito apenas de funcionários em locais públicos. E o mais importante, aprenda a fazer o descarte seguro de suas informações em papel, seja com fragmentadoras de papel ou outra ferramenta.

sábado, 18 de maio de 2013

Vamos continuar nesse post a obtenção de informação. Como comentado nos posts anteriores, toda a informação que você coletar é útil. Boa parte do tempo de um pentest é a obtenção de informação.

Então vamos lá! O que podemos adquirir de informação de um alvo? Podemos começar olhando o site e o seu código fonte para ver se conseguimos alguma informação de clientes, emails, tecnologias, e outras informações que a empresa faz questão de mostrar.

Outra fonte riquíssima de informação é a consulta de domínio. Com um simples comandos podemos obter bastante informações sobre o registro do domínio, o webmaster e em alguns casos informações de email e login no provedor do domínio.

Por exemplo, se rodarmos o comando whois aqui no blog, você vai receber várias informações sobre o domínio, site e pessoais do dono do site, neste caso eu.



OBS: catalogue todas as informações encontradas para por no relatório final. Se você usa Linux/Unix você pode usar o comando script antes de começar ou usar o comando tee para mandar todas as saídas para um arquivo.

Outro comando interessante é o dig. Com ele podemos obter algumas informações sobre os servidores DNS e redirecionamentos que o site usa. Por exemplo, se você rodar o comando dig -t MX brutalsecurity.com.br vai perceber que redirecionamos o nosso servidor de email para o servidor do zoho mail.

DICA: Para mais informações leia o manual dos comandos whois, script, tee e dig.

Você também pode usar sites como o Domain Tools e Netcraft para obter estas informações e algumas outras.

Existe também um site chamado You Get Signal, que um dos seus serviços é mostrar, através de buscas por DNS, quais sites estão hospedados no mesmo host. Isso pode ajudar também na obtenção de informação, mas lembre-se, mesmo que você tenha permissão para testar a segurança de um site, você não tem permissão de atacar sites de terceiros que estejam hospedados no mesmo servidor.

No blog temos também um post sobre o Dirb. O Dirb é um crawler, sua função é basicamente ficar procurando por páginas em um site. Outras ferramentas fazem isso, para Windows por exemplo temos o Acunetix.

Um lugar muito bom para obter informações de usuários e/ou funcionários é as redes sociais. É bem comum os usuários soltarem informações sensíveis sobre suas rotinas nas redes sociais, e isso pode ser usado contra eles mesmos em um próximo ataque futuro. Então fique ligado em redes sociais bastante usadas como Facebook, Twitter, Google +, Linkedin e etc.

Para ter uma noção, quando tiver um tempo livre crie um perfil fake em uma rede como o Facebook e faça um teste inofensivo, adicione alguns amigos e familiares e interaja com eles para ver o que eles podem soltar de informação sensível.


Fingerprint

O fingerprint é uma das principais técnicas de levantamento de informações. Com o fingerprint podemos obter informações bem específicas do servidor do alvo, como por exemplo, Sistema Operacional, portas abertas, banners, serviços rodando, versões de serviços, sniffing de rede e etc. Vamos ver algumas dessas técnicas a seguir.

Antes de iniciarmos os scans, precisamos levar em conta que existem dois tipos de fingerprint, o passivo e o ativo. O passivo seria as técnicas de sniffing, onde você não pede pela informação, você apenas captura quando ela passa, neste primeiro ponto vai ser necessário acesso físico a rede da empresa, como uma rede sem fio desprotegida por exemplo. Já o fingerprint ativo é onde vamos fazer requisições ao servidor e a partir das respostas avaliar quem é e o que está rodando no servidor do alvo.


Fingerprint Passivo

Para o fingerprint passivo vamos usar o ettercap. O ettercap tem milhares de funções, vamos vendo elas aos poucos. Como neste caso ainda não temos acesso físico a rede do alvo vamos tentar descobrir qual é o Sistema Operacional que está hospedando o site do alvo.

Para isso abra o ettercap e vá em Sniff > Unified sniffing...



Escolha a interface que será usada, no meu caso, eth0.



Agora inicie a ferramenta em Start > Start sniffing.



Após tudo iniciado, acesse o site que você deseja fazer o Fingerprint Passivo. No meu caso aqui vou acessar meu próprio site. Assim que o site carregar volte ao ettercap e vá em View > Profiles.





Se tudo deu certo você vai ver uma tela parecida com a abaixo. Agora basta clicar em cima do endereço do site e na janela que vai abrir vai ter qual é o SO que está rodando no servidor.




Estranho meu servidor não? Veja a imagem de um outro site:




Para o servidor, isso foi apenas um acesso normal, para nós foi extremamente útil, conseguimos mais um bocado de informações.



Fingerprint Ativo


Já o fingerprint ativo é um pouco mais intrusivo, porque vamos fazer uma série de requisições ao site de diversas formas e em diversas portas, isso provavelmente vai cair nos logs e levantar suspeitas.

Podemos começar com o ping, através do TTL (Time To Live) podemos identificar qual é o sistema do alvo. Mas cuidado, nem sempre isso vai estar certo, isso pode ser alterado, então não se baseie totalmente nisso.

Algumas opções de TTL para sistemas default:

● Cyclades - Normalmente 30

● Linux - Normalmente 64
● Windows - Normalmente 128

● Cisco - Normalmente 255

● Linux + iptables - Normalmente 255

Por exemplo, rodei o comando na Brutal Security e o TTL foi 245, já quebrando com essa lógica, neste caso o servidor onde hospedei o site mudou o TTL. Mas se adicionarmos os hops daria 255, o que indicaria um Linux + iptables.




Outro comando presente em praticamente todos os sistemas é o traceroute. Podemos ver quantos saltos nosso pacote dá até chegar ao servidor.




Podemos ver que nos hops 18 até 36 não obtivemos nenhuma informação, provavelmente seja algum tipo de filtro, firewall ou sistema de descartes de pacotes.
Continuando com o guia básico de Segurança da Informação, neste post vamos ver alguns truques de como usar o google para obter informações interessantes sobre os alvos de um pentest.

Está é a parte 3 de uma série de posts. Temos também a parte 1 e a parte 2.

Obtendo informação


Google Hacking


Vamos então iniciar nossas atividades mais práticas. Vamos começar por algo leve, vamos começar pelo google hacking. Google hacking é basicamente usar os motores de busca (não necessariamente só o google) para obter informações privilegiadas. Até o momento não estamos invadindo nada, estas informações estão disponíveis nos sites porque os bots dos motores de busca indexaram estas informações, e com a manipulação correta das buscas conseguimos algumas informações interessantes.

A primeira coisa que podemos verificar é uma versão mais antiga da página que estamos procurando. O Google sempre guarda em cache uma cópia de como o site era a alguns meses antes, você pode consultar essas informações diretamente nos resultados da pesquisa.



Isso pode ser útil caso você precise de informações de uma página que acabou de sair do ar.

Existe também um site chamado archive.org que cataloga todas as mudanças dos sites, bem similar ao Cache do Google.

Manipulações avançadas


Existem alguns tipos de strings que podem ser colocadas antes da sua pesquisa para filtrar os resultados e chegar a conteúdos que você dificilmente veria em uma pesquisa normal.

intitle e allintitle - Esta string diz a busca do Google para procurar as palavras após o comando no título do site. A única diferença é que o intitle procura apenas a próxima palavra e o allintitle procura todas as palavras após a string no título. Muito usado para procurar uma página específica em um site.

inurl e allinurl - Esta string é bem similar a anterior, mas no lugar de procurar no título, neste caso vai procurar na url do site. Muito usado para procurar por vulnerabilidades específicas que podem ser identificadas pela url, como por exemplo SQL Injection (noticia.php?id=1).

filetype - Basicamente, essa string pesquisa por determinados formatos de arquivos no google ou em determinado site.

allintext - Localiza a string dentro do texto da página.

site - Obter resultados apenas que contenham uma determinada url.

link - Buscar por links em determinada página.

related - Buscar por sites relacionados

info - Buscar informações sobre o site específico.


Exemplos: 

intitle:”Página de Login”
inurl:”noticia.php?id=”
filetype:PDF
allintext:”Brutal Security”
site:”brutalsecurity.com.br”
related:”www.brutalsecurity.com.br”
info:”brutalsecurity.com.br”
Esta é a parte 2 da série Introdução à Segurança da Informação! Se você ainda não leu, recomendo que leia a parte 1.


O Pentest

O Teste de Invasão, Teste de Intrusão, Teste de Penetração, Penetration Test ou seja lá como você chama, é um processo de análise de falhas de segurança de sistemas, aplicações web ou rede, normalmente do ponto de vista de uma pessoa mal intencionada, dentro de vários níveis diferentes, que veremos a seguir.

O objetivo principal deste teste é ver de uma forma controlada quais seriam as reações causadas por um ataque real, como os sistemas se comportariam perante a um ataque, e como a equipe de suporte resolveria este problema.


Tipos de Testes


Existem alguns tipos de testes, cada um com suas características próprias. Vamos a eles:

Blind ou Black Box - Neste tipo de teste, o auditor não tem nenhum conhecimento sobre o alvo, mas o alvo sabe quais testes serão executados, como e quando. Um dos testes mais próximos da realidade.

Double Blind - Similar ao Blind, mas neste teste nenhum lado tem informações, nem o auditor do alvo, nem o alvo do ataque. Também conhecido como Black Box.

Gray Box - Diferente do Black Box, neste caso o auditor tem um conhecimento parcial do alvo, não tão parecido como um ataque de fora, mais parecido com um ataque interno, de um funcionário insatisfeito.

Double Gray Box - Similar ao Gray Box, mas o atacante também sabe quando e como vai ser atacado.

Reversal ou White Box - Neste teste, o atacante tem total conhecimento da infraestrutura, usuários e sistemas. O teste mais longe da realidade, basicamente testando apenas a performance dos serviços em um ataque.

Tandem - Igual o teste acima, mas neste o alvo sabe que será atacado, no mesmo estilo do Double Gray Box.


O ataque


Se você reparar, boa parte das certificações de segurança seguem o mesmo estilo. Normalmente a fase de ataque está dividida em 5 partes: Levantamento de informações, Varredura, Ganhando acesso, Mantendo acesso e Limpando rastros.

Levantamento de informações - A fase mais importante de um Pentest. As informações que você conseguir obter do seu alvo serão usadas para moldar os ataques. Esta é a fase mais importante que o que você conseguir aqui vai ser essencial para que o ataque tenha sucesso. Se você falhar em obter informações possivelmente seu ataque será fraco e sem um objetivo certo, em alguns casos, é necessário voltar para essa fase no decorrer da auditoria, pode ser que quando você estiver mais a frente encontre coisas novas e vai precisar voltar para obter informações sobre essas novas descobertas. O levantamento de informações pode ser feito através do site da empresa, com engenharia social (exemplificado neste post), pelo lixo da empresa (dumpster diving), redes sociais, entre outros. Não existe informação inútil, toda informação que você obter é valiosa.

Varredura - Neste ponto vamos buscar informações mais precisas e técnicas do alvo, como por exemplo, que sistemas operacionais estão nas máquinas da empresa, quais serviços estão em execução, quais sistemas de proteção estão sendo usados, entre outros. Aqui entram em cena algumas ferramentas para varredura, a mais comum que falaremos em um post futuro deste guia é onmap.

Ganhando o acesso - Agora, de posse das informações da empresa e informações técnicas das máquinas da empresa, podemos moldar um ataque que vai nos dar acesso remoto a rede interna do alvo. Em muitos casos o pentest acaba aqui, mas varia muito de como o serviço foi acordado com o cliente, em alguns casos só mostrar que é possível invadir já é o suficiente. Para isso podemos explorar falhas nos serviços ou servidores do alvo, aplicações, roubo de credenciais ou o que ficar melhor, de acordo com as fases anteriores.

Mantendo o acesso - Para continuar os testes e escalar para pontos mais altos da rede, precisamos manter sempre uma porta de acesso no alvo, para isso vamos utilizar de malwares, backdoors, acesso remoto, vpn ou algum outro método de conexão remota.

Limpando os rastros - De nada adianta poder invadir qualquer sistema computacional se você deixar um rastro gigantesco de por onde passou ou o que fez. Algumas empresas contam com uma divisão chamada Resposta a Incidentes. Essa equipe tem a função de remontar seus passos. Caso esse seja o objetivo do teste é necessário que os rastros sejam cobertos. Como um pentester tem autorização para realizar aquele ataque ele não tem obrigração de apagar todos os rastros, esta decisão depende de como foi negociado o teste.


Tipos de ataques

Basicamente os ataques estão divididos em dois grandes grupos, os ataques Client Side e os ataquesServer Side. Quando nos referimos a Server Side, estamos falando de atacar diretamente o servidor, seja de fato explorando uma falha no servidor ou em algum serviço que está rodando nele, podemos usar como exemplo ataques a servidores web e suas aplicações e ataques a servidores DNS, os dois tipos de ataques serão vistos em um futuro post do guia.

Já os ataques Client Side são os ataques com alvo direto no cliente, diretamente na máquina do usuário. É bem comum ver tutoriais e guias de como usar esses ataques, mas na prática não é tão simples, tudo vai depender de como você se saiu na fase de obtenção de informação, porque um exploit vai funcionar para uma determinada versão de um software ou sistema. Exemplos de ataques Client Side são falhas em navegadores, falhas em softwares instalados na máquina, ou algum link que a vítima clica e a leva para um site com um conteúdo para baixar, esse conteúdo que vai abrir a conexão com o atacante.


Problemas Legais

Muito vem se falando ultimamente sobre crimes virtuais e leis e etc. Tudo isso porque a pouco que foi estabelecidas leis para crimes cibernéticos (como eles costumam chamar) no Brasil. Então, não custa lembrar, qualquer tipo de teste ou invasão a um site, serviço ou empresa agora é crime no Brasil. Estas leis ainda estão um pouco genéricas e generalizadas, mas já estão em vigor. Anteriormente os crimes eram categorizados como dano e sempre se ouvir falar na impunidade no país. Hoje em dia esse cenário está começando a mudar. Ainda existe impunidade, tem muita coisa passando em branco, mas está cada vez mais comum ver notícias de que cibercriminosos foram pegos.

Lembre-se sempre antes de iniciar qualquer teste, por mais simples que seja, ter um documento formal assinado pelo alvo com todas as informações do teste, como por exemplo, tipos de teste que serão realizados, duração, gravidade e etc.

No Brasil temos no momento duas leis sobre crimes virtuais em vigor. A lei 12.737/12, conhecida como LEI CAROLINA DIECKMANN tipifica os seguintes crimes:
  • Invasão de computadores para obter vantagem ilícita;
  • Falsificação de cartões e de documentos particulares;
  • Interrupção ou perturbação de serviço telegráfico, telefônico, informático, telemático ou de informação de utilidade pública.

E a outra lei, a 12.735/12 conhecida como LEI AZEREDO, diz o seguinte:
inclui um novo dispositivo na Lei de Combate ao Racismo (7.716/89) para obrigar que mensagens com conteúdo racista sejam retiradas do ar imediatamente, como já ocorre atualmente em outros meios de comunicação, como radiofônico, televisivo ou impresso;
prevê a criação das delegacias especializadas no combate a crimes cibernéticos na Polícia Federal e nas Polícias Civis

Da para ver que ainda não está bem certo, estas leis eram muito maiores e foram cortadas quando foram aprovadas, tudo indica é que ela vai ser modificada aos poucos, então fique ligado, agora temos leis para categorizar os crimes virtuais.
Olá pessoal!

Como boa parte dos leitores estão começando na área e estão se sentindo meio perdidos vou criar uma série de posts com a base da segurança e vou aprofundando, para meio que nivelar todos os leitores.

Então vamos lá, o que é segurança da informação? Segundo a wikipedia temos:
A segurança da informação está relacionada com proteção de um conjunto de informações, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. O conceito se aplica a todos os aspectos de proteção de informações e dados. O conceito de Segurança Informática ou Segurança de Computadores está intimamente relacionado com o de Segurança da Informação, incluindo não apenas a segurança dos dados/informação, mas também a dos sistemas em si.

Principais padrões e normas


Como qualquer outra categoria, a Segurança da Informação tem normas e padrões, para poder regularizar todo o processo e definir o que é seguro e funcional e o que não. Vamos ver a seguir os principais padrões e normas:

ISO 27001 - Esta norma aborda os padrões para sistemas de gestão de Segurança da Informação.

ISO 27002 - Baseada na norma ISO 27001, essa norma trata de boas práticas de segurança e possíveis controles e testes dentro delas.

PCI-DSS - Sigla para Payment Card Industry Data Security Standart é uma padronização para empresas que lidam com cartões de crédito, normas utilizadas para evitar fraudes relacionado com cartões.

ITIL - Mais voltada para TI e seus serviços e infraestrutura.

COBIT - Abreviação de Control Objectives for Information and related Technology, é um guia de boas práticas, também voltados para gestão de TI, com ferramentas próprias para implementação, auditoria e gerenciamento.

Agora, todo mundo fala por ai que cada vez mais é necessário saber pelo menos boas práticas de segurança, não vou entrar muito a fundo aqui, todos que chegaram até aqui provavelmente já estão cientes de quão importante a Segurança da Informação é. Alguns pontos que deixam bem óbvio essa necessidade são a facilidade de uso, quanto mais fácil e útil mais pessoas vão usar, interligação entre serviços e dispositivos, atacando um serviço específico pode ser que vários outros sejam atacados de tabela, e o maior problema de todos, a facilidade de uso e localização de ferramentas para um ataque complexo. Este último é o que mais preocupa.

Cada dia que passa, mais os “lammers” ganham mais poder, porque cada dia novas ferramentas de uso simples aparecem e estas ferramentas estão causando cada vez mais estragos. Por exemplo, hoje para explorar uma falha simples de SQL Injection, o “atacante” precisa saber apenas a url vulnerável, o resto o programa faz, tudo automático. Outro exemplo que está muito em foco no momento é o DDoS, em algumas ferramentas, só é necessário pressionar um botão e o ataque está lançado.

Os três pilares da Segurança da Informação


Três pontos são essenciais para a Segurança da Informação: Confidencialidade, Integridade e disponibilidade. Sem estes três pilares não temos a Segurança da Informação.

Confidencialidade - Este pilar define que a informação só deve ser acessível para quem foi concebido o direito de acesso pelos donos e/ou responsáveis desta informação.

Integridade - É necessário que as características sejam mantidas de acordo com o que foi determinado pelo dono da informação.

Disponibilidade - Outro ponto importante é a necessidade da informação estar disponível sempre que necessário, desde que respeitando as duas normas acima.



Certificações


Quem trabalha nesta área sabe que certificações são bastante valorizadas, em alguns casos até mais do que uma graduação em Informática ou Tecnologia. Não vou me alongar muito neste quesito porque já temos dois posts muito bons sobre o assunto aqui no blog, o “Certificação? Pra que serve isso?” e o “Lista de algumas das principais certificações na área de segurança da informação”.



War Games


War games são jogos onde o objetivo é invadir sistemas, mas sem comprometer um sistema real, tudo isso feito dentro de um ambiente controlado. Também não vou me aprofundar aqui porque temos a série “Invadindo sem ir para a cadeia!” com uma série de aplicações Web ou Máquinas Virtuais para download com diversos cenários e níveis de dificuldade diferente.
Subscribe to RSS Feed Follow me on Twitter!