codalabs

Nota: Testado no Mac OS Sierra usando Homebrew.

Recentemente precisei instalar o JtR (http://www.openwall.com/john/) em um Macbook Pro. Um pouco mais trabalhoso do que nas distribuições Linux em geral, mas nada impossível. Apesar de haver um build para OSX (http://download.openwall.net/pub/projects/john/contrib/macosx/), o arquivo data de 2012 e não possui diversas melhorias presentes nas versões mais recentes - incluindo o suporte a Kerberos TGS Tickets. Além disso, em geral, eu prefiro compilar o JtR a partir da versão mais recente no Github (bleeding-jumbo); então os passos abaixo fazem mais sentido para mim de qualquer forma.

Pré-requisitos

Passo 1: Cabeçalhos do OpenSSL

brew install openssl

brew link openssl --force

O último comando irá forçar o link do OpenSSL instalado pelo Homebrew (isto é, obriga que os cabeçalhos da versão do OpenSSL do sejam usados). A ação pode ser desfeita depois ou, como aconteceu no meu caso, pode acarretar numa mensagem de erro informando quais diretivas devem ser passadas para que o compilador use especificamente esses cabeçalhos. Tome nota desta informação, pois ela será útil durante o processo de compilação do JtR.

Alternativa: Baixar os fontes do Github funciona da mesma forma.

Passo 2: GCC - Por padrão, o comando “gcc” do XCode é na verdade clang. Como posto nas instruções de instalação do John (https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/doc/INSTALL), usar o gcc “de verdade” permite usar melhor o hardware e ganhar em performance.

brew install gcc

Passo 3: OpenMPI (opcional) - Eu gosto de usar MPI junto com o JtR, mas é completamente opcional.

brew install openmpi

Compilando

Passo 4: Baixar a última versão a partir do repositório no Github:

git clone https://github.com/magnumripper/JohnTheRipper.git -b bleeding-jumbo john

Passo 5: Compilar usando o GCC e os cabeçalhos corretos do OpenSSL:

cd john/src

./configure CC="gcc-6" LDFLAGS="-I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib" --enable-mpi && make clean && make

Nota: As variáveis CC e LDFLAGS podem mudar de acordo com o seu compilador e o diretório onde os cabeçalhos do OpenSSL estão localizados.

Testando

./john --test

Erros

Durante a compilação, alguns desses erros podem surgir:

configure: error: JtR requires OpenSSL headers being installed

Undefined symbols for architecture x86_64:  "_Camellia_cfb128_encrypt", referenced from:      _gpg_common_check in gpg_common_plug.o  "_Camellia_set_key", referenced from:      _gpg_common_check in gpg_common_plug.o

ld: symbol(s) not found for architecture x86_64

Próximo ao dia 24/09/2014 foi divulgada uma vulnerabilidade no GNU Bash - conhecida como Shellshock -  que permite a execução de código através de variáveis de ambiente. Esta é uma coletânea de links para referência futura e não tem pretensão de ser uma lista definitiva. O fato de um link estar aqui não significa que eu esteja atestando sua qualidade; quero também manter um registro pessoal de como a comunidade tratou o assunto.

Quem quiser colaborar, pode ficar à vontade. :)

CVEs

CVE-2014-6271 (CVE original)

CVE-2014-7169 (O fix para a vulnerabilidade original não foi suficiente, gerando um novo CVE)

BID: 70103

BID: 70137

Advisories

Thread original na oss-sec

US-CERT - TA14-268A

Cisco - cisco-sa-20140926-bash - GNU Bash Environment Variable Command Injection Vulnerability

Citrix - CTX200217 - Citrix Security Advisory for CVE-2014-6271

Posts relacionados a vulnerabilidade

[2014-09-24] Red Hat - ‏Bash specially-crafted environment variables code injection attack

[2014-09-24] Robert Graham (Errata Sec) - Bash bug as big as Heartbleed

[2014-09-24] Akamai - Environment Bashing

[2014-09-24] Robert Graham (Errata Sec) - Bash 'shellshock' scan of the Internet

[2014-09-24] Robert Graham (Errata Sec) - Bash 'shellshock' bug is wormable

[2014-09-24] CSO Online - Remote exploit vulnerability in bash CVE-2014-6271

[2014-09-24] CNET - ​'Bigger than Heartbleed': Bash bug could leave IT systems in shellshock

[2014-09-25] Robert Graham (Errata Sec) - Shellshock is 20 years old (get off my lawn) 

[2014-09-25] TrustedSec - Shellshock DHCP RCE Proof of Concept

[2014-09-25] Garage4Hackers - Everything you need to know about CVE-2014-6271

[2014-09-25] Troy Hunt - Everything you need to know about the Shellshock Bash bug

[2014-09-25] Security Street (Rapid7) - Bash-ing Into Your Network – Investigating CVE-2014-6271

[2014-09-25] Krypt3ia - SHELLSHOCK!

[2014-09-25] Internet Storm Center InfoSec Handlers Diary Blog - Update on CVE-2014-6271: Vulnerability in bash (shellshock)

[2014-09-25] Symantec - Shellshock: All you need to know about the Bash Bug vulnerability

[2014-09-25] Norton Comunity - Shellshock, The Latest Mac OSX and Linux Vulnerability—And What It Means For You

[2014-09-25] DigitalOcean - How to Protect your Server Against the Shellshock Bash Vulnerability

[2014-09-25] Veracode - Shellshock – what you need to know

[2014-09-25] ClevCode - CVE-2014-6271 / Shellshock & How to handle all the shells! ;)

[2014-09-25] Sucuri - Bash – ShellShocker – Attacks Increase in the Wild – Day 1

[2014-09-25] Thread no StackExchange - What is a specific example of how the shellshock bash bug could be exploited? 

[2014-09-26] Securelist - Shellshock and its early adopters

[2014-09-26] Red Hat - Frequently Asked Questions about the Shellshock Bash flaws

[2014-09-27] Robert Graham (Errata Sec) - The shockingly obsolete code of bash

[2014-09-27] Daniel Fox Franke - Shell Shock Exploitation Vectors

[2014-09-27] FireEye - Shellshock in the Wild 

[2014-09-27] Infosec Institute - Exploiting and Verifying Shellshock: CVE-2014-6271

[2014-09-28] IT Pro Portal - Shellshock bug is so bad it could take years to eradicate

[2014-09-28] Greg Karékinian - Shellshock (palestra no RailsCamp Germany)

[2014-09-29] TrendLabs - Summary of Shellshock-Related Stories and Materials

[2014-10-30] CloudFlare - Inside Shellshock: How hackers are using it to exploit systems

[2014-10-30] Ars Technica - Shellshock fixes beget another round of patches as attacks mount

[2014-10-01] Troy Hunt - The anatomy of a Shellshock attack in the wild

[2014-10-01] lcamtuf - Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)

PoCs, Exploits, Ferramentas

Detectify (Verifica se um site está vulnerável)

Mubix - shellshocker-pocs

PoC que surgiu no Pastebin

Metasploit DHCP server module for CVE-2014-6271

Dica do @antisnatchor para exploração usando BeEF

Brute Logic - Worm em 140 caracteres.

Shellshocking OpenVPN servers

Nessus Plugin ID: 7798 - GNU Bash Environment Variable Handling Code Injection via ProFTPD (Shellshock)

Script para Nmap - [Post original] [Versão 2] [Código da Versão 2 no Bitbucket]

Uma das atividades mais trabalhosas da minha pesquisa de senhas e hashes é, sem dúvida, coletar dumps de sites como o pastebin. Além da dificuldade natural de extrair informações – que surgem nos mais diversos formatos, variando desde saídas do sqlmap a senhas em texto claro e diferentes hashes no mesmo arquivo –, a organização e captura dos dados é um trabalho quase artesanal. 

Para economizar tempo, fiz um pequeno script que monitora alguns desses sites atrás de possíveis informações interessantes. Parcialmente inspirado no Dumpmon, ele faz o seguinte:

Monitora usuários que frequentemente postam dumps de hashes e senhas;

Monitora os trends do Pastebin;

Monitora atualizações gerais, usando a própria busca do Pastebin.

De forma geral o script funciona como um job agendado executando de hora em hora as funções acima e armazenando os dados que preciso. Pastes são guardados em arquivos de texto, enquanto paste IDs, usuários e outros dados ficam em uma base de dados.

Ainda assim senti a necessidade de ter mais um recurso para me ajudar a gerenciar um volume grande de pastes (separando conteúdo útil de dados desnecessários, marcando os pastes já tratados, etc). Resolvi então arriscar um pouco e criar uma interface web que me ajudasse na organização e no monitoramento do funcionamento do script. Eis aqui alguns screenshots:

A tela de pastes me mostra uma lista dos pastes obtidos. No canto superior esquerdo (1) posso ver quando ocorreu a última adição no banco, com a ideia de me ajudar a identificar rapidamente um paste interessante ou um problema de execução no script. Eu posso também adicionar um paste novo à lista (2); caso o usuário não exista, ele é automaticamente adicionado aos usuários monitorados e seus pastes são importados. Na lixeira (3), posso remover pastes que não são uteis para o trabalho. Apenas o arquivo é removido – o paste ID é mantido para evitar que um paste desnecessário seja novamente adicionado à lista. O botão de “Tratado” (4) talvez seja uma das funcionalidades mais simples da aplicação, apesar de útil: ele serve simplesmente para me ajudar a marcar um paste que já teve hashes e senhas extraídos e armazenados.

A tela de usuários é bem simples também. Além do mesmo menu, posso adicionar usuários (1) que serão monitorados e os pastes são automaticamente importados. Clicando no “X”, um usuário deixa de ser monitorado. Para usuários que não estão ativos, basta clicar no ícone do “olho” e ele passa novamente para a lista de monitorados.

A ideia é manter as coisas tão simples quanto possível, mas ainda estou trabalhando em algumas estatísticas para a página inicial.

Como não sou desenvolvedor em tempo integral - faço algumas poucas ferramentas ou scripts para atender alguma necessidade que eu tenho – aproveitei a oportunidade para aprender algumas coisas novas. Para desenvolver a parte web usei o micro framework Flask com Bootstrap e Flat UI para a interface. O Bootstrap é bem simples e há uma variedade grande de templates disponíveis gratuitamente. Quanto ao Flask, também não há muito mistério. A principal vantagem é poder investir o tempo maior na lógica da aplicação: as views recebem os requests e fazem o tratamento dos dados. As páginas são geradas no esquema de tempaltes usando Jinja2, o que facilita para quem não é um webdesigner habilidoso.

Saving your creative soul: Scott Berkun at TEDxDePaulU

Achei essa palestra muito interessante do Scott Berkun, autor do livro "Mindfire: Big Ideas for Curious Minds" (que eu li e recomendo). Berkun fala sobre o processo criativo e a importância de ouvir suas próprias ideias. Esse é um excelente conselho. Nossa comunidade é construída por pessoas com boas e más ideias com coragem para coloca-las em prática.

 O que mais gostei nesse vídeo foi a observação sobre como o produto dessas ideias é compartilhado, seja por artistas ou palestrantes: o processo criativo é representado do fim para o início, reproduzindo de forma inversa os passos para alcançar o resultado obtido. Pouca ou nenhuma importância é dada para os problemas e dificuldades que aparecem no meio do caminho.

Há alguns dias dei uma rápida atualizada repositório password-utils, onde guardo coisas úteis para password cracking e alguns dos resultados dos meus experimentos sobre o tema. Além das três novas wordlists, finalmente disponibilizei o script string2rule.py.

Observei, nos dumps que analisei até então, que variações do nome de sistemas, aplicativos e domínios eram recorrentes na construção de senhas. Criei esse script para gerar regras do john que sigam esse comportamento, adicionando variantes da string passada antes e depois de uma palavra:

python string2rule.py daniel

  Basta copiar as regras para o arquivo john.conf e usá-las:

john --rule:<regra> --wordlist=<wordlist> <hashes>

Um exemplo das senhas que o john irá testar:

Para as regras usei os mapeamentos mais comuns que encontrei - por isso 'x' não é substituído por '><', por exemplo. Também não estão otimizadas (ainda).

Ainda estou procurando uma forma de gerar uma regra que coloque as strings modificadas no meio da palavra (ex.: codaD@ni3Llabs), mas a combinação dessas regras com a wordlists de nomes próprios já têm funcionado bem nos meus últimos testes.

EDIT: Agora as regras adicionam caracteres especiais entre a string gerada e a palavra da wordlist (ex.: daniel_codalabs e codalabs_daniel).

PwnWiki.io is a collection TTPs (tools, tactics, and procedures) for what to do after access has been gained.

Ótima referência para pós-exploração. Basta clonar o repositório do GitHub para ter uma cópia local:

Nas últimas semanas grande parte das notícias sobre InfoSec foram sobre o Heartbleed (CVE-2014-0160), o bug no OpenSSL.

Este post é apenas um repositório de links que achei interessantes sobre o Heartbleed para referência futura. Rolou muita coisa desde a divulgação da falha, mas guardei apenas o que considerei mais relevante.

Heartbleed.com - Página original falando sobre o bug.

OpenSSL Heartbeat (Heartbleed) Vulnerability (CVE-2014-0160) and its High-Level Mechanics - Video com boa explicação sobre o funcionamento do bug.

OpenSSL TLS Heartbeat Extension Packets Handling Out-of-bounds Read Remote Memory Disclosure - Entrada no OSVDB.

#Eyebleed. A technical analysis of the fix (not the bug!) for the Heartbleed issue - Análise técnica do fix.

Extracting server private key using Heartbleed OpenSSL vulnerability - Ferramenta do indutny em node.js para extração de chaves privadas. Testada no desafio do CloudFlare

Using masscan to scan for heartbleed vulnerability

ssl-heartbleed.nse - Script para o Nmap.

Heartbleed War Room - Rapid7

Heartbleed for OpenVPN - Blog do time de pesquisa de Vulnerabilidade da Sourcefire. 

Heartbleed Impact in Belgium?

How Heartbleed transformed HTTPS security into the stuff of absurdist theater

Co0L BSidesSP v7 - Game of Hashes: Quebrando, passando e libertando senhas

No dia 24 de Novembro tive o prazer de apresentar mais uma palestra na BSidesSP. Como da outra vez, me diverti muito e estive com uma plateia fantástica! Espero que todos tenham se divertido tanto quanto eu.

O pessoal do Garoa tem feito um excelente trabalho organizando o evento, que parece estar crescendo a cada edição. Recomendo fortemente que a comunidade participe mais ativamente desse tipo de iniciativa, seja ajudando a organizar ou apresentando trabalhos.

Na sétima edição (pré-Black Hat Regional Summit) falei um pouco sobre algo que venho pesquisado há aproximadamente seis meses: ataques off-line contra hashes gerados em sistemas brasileiros. A ideia central da pesquisa é testar a eficiência das diversas wordlists popularmente usadas, verificar o comportamento do usuário brasileiro na geração das senhas em diversos cenários e estabelecer uma forma de construir wordlists voltadas para o público do Brasil. A palestra apresenta os resultados parciais obtidos até o momento.

Sildes da palestra: https://speakerdeck.com/0xc0da/game-of-hashes-quebrando-passando-e-libertando-senhas

Repositório no GitHub com scripts, wordlists e regras para o John e o Hashcat: https://github.com/0xc0da/password-utils

É bom ficar de olho no repositório, pois ele será atualizado com frequência.

Obrigado a todos que compareceram. Espero revê-los em breve!

Notei um padrão interessante nos testes que fiz em aplicativos para Android e iOS nos últimos meses: o uso do campo User-Agent para controle de acesso.

O cenário*: através do aplicativo, é possível acessar o formulário de login e todas as funcionalidades. Analisando um pouco mais percebi que o aplicativo era, na verdade, um navegador embutido que apenas exibia as respostas de uma aplicação. Mas quando tento utilizar outro navegador para acessar a URL do aplicativo, recebo como resposta 403 Forbidden:

 A primeira coisa que me veio à mente é que o campo user-agent da requisição seja verificado para permitir o acesso à aplicação que roda no servidor. E isso é fácil de resolver usando o User Agent Overrider (Firefox) ou User Agent Switcher (Chrome) para preenchendo o campo por um valor conveniente. Então, analisando novamente a requisição feita pelo aplicativo é possível ver qual o User-Agent utilizado:

E usando o User Agent Overrider, consigo mudar para valor correto.

E problema resolvido.

Ou seja: como é possível para o cliente modificar facilmente o campo User-Agent, esta não pode ser considerada uma forma eficaz de controle de acesso.

Agora, vamos fazer uma pausa aqui e ver o que a RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) fala a respeito do campo:

14.43 User-Agent The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.

Vemos uma boa dica no uso apresentado na RFC (“fins estatísticos, rastrear violações de protocolo e reconhecimento automático de navegadores para adequar respostas…”). O campo pode não ser uma boa para controle de acesso, mas talvez seja interessante para detectar ataques automatizados. Guardadas, claro, suas limitações (já que o valor do campo pode ser modificado pelo usuário - e é configurável na maior parte dos scanners).

Com isso em mente, fiz uma pequena pesquisa sobre os valores enviados no campo User-Agent por várias ferramentas. A coleta dos dados foi feita através da execução do software com suas opções default contra um servidor Apache rodando a DVWA e um simples servidor web em Python. No primeiro cenário, configurei o Apache para criar um arquivo de log apenas com o User-Agent das requisições; no segundo, o próprio script armazena o conteúdo do campo em um arquivo.

Coloquei o resultado aqui.

Note que esse tipo de monitoramento pode ser útil para script kiddies ou algum atacante mais desleixado, mas dificilmente será tão eficiente contra alguém que sabe o que está fazendo. A informação, entretanto, ajuda que a aplicação e WAFs façam pelo menos um tratamento preliminar.

Fique à vontade para colaborar com User-Agents de outras ferramentas!

* Simulei o cenário em laboratório, para evitar expôr informações de outros. ;)

Referências:

Resultados dos testes

User Agent Overrider (Firefox)

User Agent Switcher (Firefox e Chrome)

RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1)

Servidor web em Python utilizado nos experimentos

Uma boa para quem precisa dar uma olhada rápida no help de algum comando, o site mostra apenas a referência dos parâmetros utilizados.

Aqui vai uma forma simples e eficaz de retirar os acentos de um arquivo usando o sed:

sed 'y/áÁàÀãÃâÂéÉêÊíÍóÓõÕôÔúÚçÇ/aAaAaAaAeEeEiIoOoOoOuUcC/'

Exemplo:

daniel@codalabs:~$ cat /tmp/acentos.txt  Regida por decibéis, serpentina nos meus pés Dançando pelo salão

Usando o sed para retirar os acentos:

Introduction to HTML Injection (HTMLi) and Cross Site Scripting (XSS) Using Mutillidae - ISSA Kentuckiana workshop 9 - Jeremy Druin

HITB2012KUL - The Grugq - OPSEC: Because Jail is for wuftp

Há um tempo atrás postei os slides da palestra do The Grugq na Ekoparty. Esse é um vídeo da mesma apresentação, na HackInTheBox Malásia 2012.

O Irongeek compartilhou alguns videos da ShmooCon desse ano. Coisa fina!