Conviso Application Security: outubro 2013

segunda-feira, 28 de outubro de 2013

Cross-Site Scripting usando CSS

Quando estamos executando um projeto de revisão de código, sempre que encontramos algum trecho de código suspeito, investimos um certo tempo para ter a certeza que aquele ponto é ou não uma vulnerabilidade.

Em um destes projetos, nos deparamos com um trecho de código similar ao abaixo:

Arquivo: arquivo_teste.php
---

1 <html>
 2   <head>
 3     <style>
 4          <?php echo strip_tags($_GET['style']); ?>
 5     </style>
 6   </head>
 7   <body>
 8   </body>
 9 </html>

---

Neste caso, a chamada a função strip_tags() não será suficiente para evitar que ataques de Cross-Site Scripting sejam realizados com sucesso. Através de códigos CSS, que não precisam das tags que são removidas pela função strip_tags(), é possível inserir códigos Javascript que serão interpretados por alguns browsers. É o caso do método expression()[1] para o Internet Explorer (IE) e a propriedade CSS -moz-binding para o Gecko, utilizado pelo Firefox. Aqui iremos falar apenas sobre o caso do IE. O método 'expression()' funciona por padrão no IE versão 5 até 7 e 8 ou superior em modo compatibilidade [2].

Com base nisso, utilizei o seguinte payload para chamar o método alert() e imprimir a mensagem 'CODIGO_MALICIOSO_EXECUTADO' no IE versão 10 executado em modo de compatibilidade.

body{
left:expression(alert(String.fromCharCode(0×43,0×4f,0×44,0×49,0×47,0×4f,0×5f,0×4d,0×41,0×4c,0×49,0×43,0×49,0×4f,0×53,
0×4f,0×5f,0×45,0×58,0×45,0×43,0×55,0×54,0×41,0×44,0×4f)));
}

Foi necessário usar o método '.fromCharCode' do objeto 'String' porque no ambiente de teste, a opção magic_quotes do PHP estava habilitada, evitando a inserção do carácter aspas-simples.

Em [3] também há outros exemplos, inclusive a utilização do -moz-binding para execução de códigos Javascript.

[1] - http://msdn.microsoft.com/en-us/library/ms537634.aspx
[2] - http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-expressions.aspx
[3] - https://code.google.com/p/google-caja/wiki/CssAllowsArbitraryCodeExecution

quarta-feira, 23 de outubro de 2013

[Update CSC] - Novas funcionalidades: Tags e Dashboard interativo

Nessa atualização focamos aumentar a granularidade das informações cadastradas, melhorar as opções de filtros no Dashboard e expandir automaticamente os resultados com gráficos clicáveis.

Sempre buscando inovar e facilitar a gestão das vulnerabilidades, bem como melhorar a granularidade das métricas, adicionamos a funcionalidade de Tags ao produto. A antiga aba Áreas agora chama-se Tags, sendo que as Áreas já existentes agora são Tags.

Um dos grandes diferenciais dessa nova funcionalidade é que os projetos agora podem participar de várias Tags, não somente uma como eram com as Áreas.

Com essa granularidade em potencial, os Dashboards ficaram mais poderosos pois podem ter filtros e comparações entre múltiplas Tag. Abaixo um passo a passo com exemplos e uso da nova funcionalidade :

1. Adição de Nova Tag

Ao criar ou editar um projeto (Figura 1), você poderá simplesmente digitar a nova Tag que deseja, apertar Enter e quando salvar a edição ou novo projeto, a Tag será salva. Na opção Tags do menu, você poderá clicar em “Nova Tag”, digitar o nome e salvar (Figura 2).

Figura 1

[1] – Para criar uma nova Tag, simplesmente digite e salve a edição, no próximo projeto ela estará na listagem.

Figura 2

2. Editando um projeto

Um projeto agora pode pertencer a várias Tags (Figura 3), não somente a uma Área como era anteriormente, essa configuração também poderá ser feita de duas maneiras. O mesmo processo pode ser feito na opção Tags do menu (Figura 4).

Figura 3

[1] – Clicando em lista você terá acesso a todas as Tags cadastradas no seu escopo

[2] – Nessa campo caso comece a digitar o nome da Tag, terá a opção de auto complete. Caso queira uma Tag ainda não existente, simplesmente digite e salve a edição, no próximo projeto ela estará na listagem

Figura 4

[1] Selecione a Tag que deseja ver os projetos associados ou que adicionara algum projeto

[2] Selecione os projetos que deseja selecionar a Tag selecionada, os projetos já marcados já são parte da Tag, quando clicar aparecerá que está salvando. O projeto já está como parte da Tag.

3. Dashboard

No Dashboard é possível é comparar projetos buscando por Tags distintas. Na Figura 5 comparamos dois departamentos que contenham servidores que façam parte do escopo PCI.

Figura 5

[1] Listagem das tags, para selecionar

[2] Tags selecionadas no filtro, pode digitar e tem o sistema de auto completar.

[3] Opção de especificar período que deseja as dashboards, por padrão pegará tudo cadastrado.

4. Drill down nos gráficos

O resultados dos filtros da dashboard (Figura 6) podem ser clicados, dando opção rápida para análise detalhada das falhas.

Figura 6

[1] Clicando em cima do Path traversal por exemplo, ele respeitará o filtro da dashboard além de especificar esse ataque, resultando no resultado da Figura 7.

[2] Caso queira listar as 11 falhas críticas, bastaria clicar no Alto conforme apontado na imagem.

Figura 7

Clientes com dúvidas poderão solicitar uma Conferência Web para melhor explicação, teremos enorme prazer em detalhar as novidades.

quarta-feira, 16 de outubro de 2013

Gestão de Segurança em Banco de Dados

Além da aplicação que é a interface com os usuários, existem outros recursos que trabalham em conjunto, cooperando entre si para que seu serviço consiga entregar valor a quem o usa e que se não estiverem protegidos adequadamente poderão ser explorados por um atacante, comprometendo seus investimentos.

Quando se discute segurança em aplicações geralmente a primeira coisa a se pensar é fazer um trabalho de Pentest na interface da aplicação para encontrar vulnerabilidades. Por outra perspectiva, eu pergunto: "e seu Banco de Dados, está seguro?".

Nesta dissertiva será evitado especificar uma tecnologia como DB2, Oracle, SQL Server, PostgreSQL, MySQL etc. Inclusive os Bancos de Dados conhecidos como NoSQL. Veremos uma versão global de gestão para proteção de repositórios de dados.

De acordo com a estrutura da NBR ISO/IEC 27001, o Item 3 (três) que especifica os "Termos e Definições", podemos destacar três importantes itens (existem outros que não será foco da nossa proposta atual) que descrevem bem o que será tratato aqui:

Disponibilidade: propriedade de estar acessível e utilizável sob demanda por uma entidade autorizada
Confidencialidade: propriedade de que uma informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados.
Integridade: propriedade de salvaguarda da exatidão e completeza de ativos

Imagine uma Aplicação Web que precisa acessar um Banco de Dados para exibir informações à usuários. Como nosso foco é o Banco de Dados deixemos de lado os usuários que interagem com a camada de visão da aplicação. Nesse exemplo, a "entidade autorizada" pelo Banco de Dados é a "Aplicação Web" que tem nome de usuário, senha e limites sobre o que pode acessar sempre que for solicitado, isto é, sob demanda. Por fim, tudo que foi dito é o que define a Disponibilidade.

Você pode estar se perguntando sobre a demanda que não é um termo de segurança da informação e sim apenas uma questão de recursos computacionais como configuração, adicionar mais memória, usar um melhor processador, adicionar redundância ou distribuição dos recursos. Mas existe uma outra faceta da disponibilidade. Imagine agora se o seu servidor de Banco de Dados estiver sofrendo um ataque de Denial of Service (DoS). Isto, também, pode afetar no atendimento a sua demanda. E pior, isso pode deixar o serviço indisponível. Logo disponibilidade por demanda é, também, item de segurança da informação.

Outro ponto importante é a administração de usuários de um Banco de Dados. É comum encontrar um mesmo usuário que tenha acesso a várias databases sem que as databases se relacionem. Ou seja, uma mesma empresa com diferentes aplicações e um único usuário no Banco de Dados. Esta prática é condenável, pois se alguém indevidamente consegue as credenciais de uma aplicação todas as databases serão afetadas e não apenas uma. Para piorar não é novidade aplicações usarem a senha de administrador (ou de root ou do system) do Banco de Dados que, em posse do atacante, dará autonomia completa ao repositório de dados.

Para mitigar esse problema é necessário que cada diferente aplicação tenha seu próprio usuário (diferente do usuário administrador ou root ou system) no Banco de Dados limitado a certa(s) database(s). Para cada database é possível, também, dizer se o usuário tem acesso apenas read-only (só leitura) e/ou de escrita. Indo mais além, é possível limitar o acesso por endereço IP de origem. Isso completa o que chamamos de Confidencialidade.

A grande maioria dos SGDBs (Sistemas Gerenciadores de Banco de Dados) tem o conceito de ACID (Atômicidade, Consistência, Isolamento e Durabilidade) que caracteriza as transações em um Banco de Dados. Transações são unidades lógicas de trabalho. Ou seja, quando iniciadas não devem sofrer interferências externas até chegar ao seu fim.

Atômicidade: Uma transação não pode ser dividida.
Consistência: Uma transação deve ser iniciada a partir de um estado consistente do Banco de Dados para outro estado, também, consistente.
Isolamento: Conjunto de técnicas para que transações paralelas não interfiram uma nas outras.
Durabilidade: Os efeitos de uma transação devem ser persistidas (commit) no Banco de Dados

Com isso fechamos o item Integridade, converse com seu DBA se seu Banco de Dados possui essa importante característica.

Outras dicas importantes:

Se todas as conexões do seu Banco de Dados são realizadas de um único IP de origem configure-o para só aceitar conexões deste IP.
Atualize sempre o executável e as bibliotecas do Banco de Dados, atento as correções de falhas de segurança.
Faça com que o sistema de arquivos onde fica os dados do banco fique protegido para que só o Administrador de Sistemas (ou, no caso do Linux, o root) tenha acesso.
Utilize senhas fortes para o usuário administrador ou root ou system.

terça-feira, 8 de outubro de 2013

Automação de atividades para Pentest

Neste blog post, vamos abordar automação de atividades relacionadas a Pentest. Com a delegação de trabalho automatizável, o analista ganha tempo para realização de testes manuais, análises mais sofisticadas e preparação de relatório final.

Como o nosso amigo Benjamin Franklin falava,“time is money”(talvez um dos fatos de estar estampado na nota de 100 dólares).

Quando pensamos em automatizar tarefas vem em mente "Shell script" ou mesmo o uso do famoso "Expect ", são ótimos para os problemas em que precisamos de uma solução rápida, mas vamos ver outros mares onde podemos ver algo com benefícios diferentes, evitando que este "post" se torne um mero clichê.

Automação para execução de programas

Para automação de tarefas onde temos poder de fogo via comando, podemos passar variáveis por parâmetros "argumentos", podemos usar o syscall execve() para executar um programa, podemos usar também funções como system(), popen()...

Este exemplo ilustra o uso do popen(), claro que poderia usar o argumento "-p 22" do nmap e filtrar sem usar um programa, mas fica para o aprendizado, este programa faz abstração de uma varredura do nmap, depois filtra os IPs que estão com serviço SSH em Open, então salva em um determinado arquivo de log.

https://github.com/CoolerVoid/C/blob/master/popen_example.c

Mas então vem a pergunta, "em linguagem de alto nível como seria?".

Em Perl poderia fazer algo como:

#!/usr/bin/perl

@array=`/usr/bin/nmap localhost`;
foreach(@array)
{
# aqui poderiamos tratar a saida do comando...
 print $_;
}

Em Ruby:

cmd = IO.popen('/usr/bin/nmap localhost')
puts cmd.readlines

Esta só foi uma dica de como automatizar a execução de um comando e tratar sua saída, partindo desse ponto podemos executar outros comandos, criar condições, fazer algo concorrente, enfim fazer o que a criatividade mandar.

Agendando execução de programas

Algo muito importante é agendar a execução de uma ferramenta, testar a segurança periodicamente, para assim gerar novos relatórios.

Para tal feito em algumas linguagens temos alguns recursos:
* Python podemos usar APScheduler.
* Ruby temos o Rufus-Scheduler.

Quem dispõe do uso desta função é o "Accuracy", mais informações AQUI.

Por que fazer um código para agendar sendo que posso usar o crontab ? Portabilidade é tudo, nada mais inconveniente que fazer uma gambiarra por cliente, lembre-se tempo é dinheiro...

Agilizando na construção da documentação

Uma das partes mais importantes e complexas durante a realização de um Pentest é a consolidação do conteúdo coletado através dos ataques e geração do relatório (exige habilidade de análise e síntese).

Nada mais chato que ficar selecionando colando informação e formatando um relatório, perde-se muito tempo para, pegar a documentação e fazer a correlação, tudo isto é tempo que poderia ser aproveitado.

Bom aqui na CONVISO, como funcionário sou muito feliz em dizer que temos uma solução para isso, temos o CSC para gerência de risco, e para automação de inserção de dados de vulnerabilidades temos os "Drones".

O que é um Drone ?

Seria um Agente, que atua no processo de automação para canalização de vulnerabilidades para o CSC, atualmente o que ele faz é pegar entradas de ferramentas(seja em XML,TXT,HTML,JSON), logo fazer uma abstração das vulnerabilidades e envia-las para o CSC.

Em suma com o uso de um "Drone" ganha-se tempo no cadastro de vulnerabilidades, o que evidentemente agiliza a entrega da documentação, lembrando que as funcionalidades de um drone estão muito além das funcionalidades apresentadas aqui basta ler na documentação.

quinta-feira, 3 de outubro de 2013

Ekoparty 2013 - Diário de Bordo: Capture The Flag

Sem via de dúvidas a Ekoparty é um dos maiores eventos de segurança/hacking da América Latina. E por ser um evento na terra de los hermanos o que não faltou foi ouvir várias vezes a frase "Maradona es mejor que Pelé", pois apesar da excelente e calorosa recepção de nossos vizinhos (muchas gracias @maxisoler) essa pequena rivalidade sempre existiu e sempre existirá. Porém o que se restringia somente ao futebol, durante o evento virou um duelo de hacking skills. Sim, estou falando do Capture the Flags.

O Local

O primeiro ponto que merece destaque é o local. Aos fundos de onde ocorria os workshops era possível ver uma entrada com uma cortina preta e uma seta escrito "Capture The Flag". Ao atravessar a porta, era necessário seguir um corredor e a medida que a iluminação iria diminuindo ouvia-se um som mirabolante, semelhante a um filme de suspense.

Finalmente chegamos a uma sala sem janelas, com as paredes pretas, pouca iluminação e um clima no ar que é impossível descrever. Estava ali rolando uma disputa entre brasileiros e argentinos que perseverava desde edições passadas.

No final da sala era possível notar uma tela com o placar dos desafios e em cima uma sirene vermelha que acendia e apitava sempre que alguma equipe enviava uma flag válida. Confesso que gerava um certo desconforto quando tentávamos nos concentrar em resolver algum problema e de repente a sirene tocava duas ou até três vezes em um pequeno intervalo de tempo.

As Equipes

No placar era possível ver mais de uma dezena de equipes inscritas, porém analisando cuidadosamente o ambiente era possível concluir que ao invés de 10 equipes na verdade existiam duas grandes equipes: os argentinos e os brasileiros.

Apesar de equipes distintas, os argentinos estava colaborando entre si para solucionarem os problemas (ou pelo menos para compartilharem as flags). Já a equipe brasileira estava sendo representada por um pessoal de campinas (CTI Renato Archer) e por um chileno (@jptosso). Então não pensamos duas vezes e nos juntamos à equipe brasileira para somar esforços e, é claro, ter o prazer de bater de frente com los hermanos. A experiência foi no mínimo divertida.

No primeiro dia do CTF infelizmente havíamos deixado nossos notebooks no hotel, o que nos limitou absurdamente de recursos. Uma alternativa foi olhar os challenges e dar algumas dicas para tentar resolvê-los. O chileno havia pego um binário e prontamente tomei posse da máquina dele pra tentar fazer uma análise rápida. Então peguei o código assembly, copiei pra um editor de textos e comecei a fazer comentários para as chamadas de rotinas, endereços de memória, fluxo de execução etc. No segundo dia comecei a fazer análise, rodei uns fuzzers mas sem sucesso para identificar algum possível buffer overflow. Acredito que analisando com mais calma esse binário possa ser assunto de uma outra publicação.

Os Desafios

Existiam desafios em três categorias de pontos: 100, 300 e 500 pontos, sendo que cada tipo de pontos existiam três desafios de ataque e três de defesa, totalizando 18 desafios. Confesso que não conseguia olhar para um desafio e definir se era de ataque ou de defesa. Pra mim todos eles eram simplesmente challenges.

Os desafios estavam organizados nos mais variados níveis de dificuldade e categoria. Tínhamos desafios de criptografia, de engenharia reversa (ELF e PE), web exploitation, low level exploitation, forense etc. Inclusive uma das flags era enviada para rede através de um pacote broadcast UDP. Para se ter uma noção, o desafio mais fácil ao meu ver era um simples código brainfuck que ao ser passado para qualquer interpretador resultava na flag necessária para ganhar os pontinhos. Porém ao falar de um challenge difícil não é fácil escolher um e afirmar "esse foi o mais difícil". Tínhamos challenges de análise de binário (PE) onde ao digitar uma senha a mesma era utilizada como chave para decodificar uma rotina do binário e então chamá-la. Um dos challenges era uma mensagem "deformada" e um monte de números cuja dica era a palavra "fourier". Nunca pensei que encontraria um challenge em segurança que me fizesse pensar em FFT. Um outro challenge consistia em um LFI padrão onde foi necessário utilizar HPP para conseguir explorar. Enfim, existiam challenges para todos os gostos, bastaria escolher qual atacar e correr atrás da bandeira.

O Resultado

Não que sejamos a bala de prata para a rivalidade com los hermanos, mas acredito que se no primeiro dia do CTF nossa dedicação não tivesse sido tão pífia e tivéssemos ido para o evento com o propósito prioritário de competir no capture the flag o resultado poderia ser melhor.

No placar final a diferença não foi grande. Se tivéssemos o tempo hábil para terminar uma questão de 500 pontos que nos dedicamos uma parte da tarde para fazer teríamos passado as outras equipes e tomaríamos o topo. Espero que isso não sirva somente de lição para mim, mas também para as pessoas que entraram pra ajudar nossos compatriotas.

Conclusão

Ano que vem promete. Indo para a Ekoparty 2014, um dos objetivos será competir no Capture The Flag, e ir com o arsenal preparado e pronto pra guerra. E o resultado só pode ser um: "Missão dada, parceiro, é missão cumprida!" (Capitão Nascimento).

quarta-feira, 2 de outubro de 2013

ekoparty 2013 - Wrap Up of 1st Day

Ekoparty is an Infomartion Security Conference that happens every year in Buenos Aires Argentina. And it is known as one of the best InfoSec Conferences in Latin America, if not the best, at least in my opinion so far.

The first day at Ekoparty 2013 was mostly for Registration, Workshops and Wardriving. The venue is really nice, as it has an underground like look and feel. You really feel that you are at a hacker conference. I went first to the workshop called Mobile Apps and How to Pentest them. It was in Spanish but it was quite easy to understand as it was full of technical terms and words in english, also, they have simultaneous translation to english if necessary.

The workshop talked about how to create your own penetration testing lab for mobile applications. The speaker name was Gustavo Sorondo, aka puky. He started showing the different types of mobile apps, systems and devices, and how to work with all of those. He talked about the OWASP Mobile Security Project, which is a very interesting project made by OWASP for Mobile Applications. It has its own OWASP Top 10 for Mobile Apps and also insecure apps for learning like the iGoat or GoatDroid, versions of WebGoat for iOS and Android respectively.

He demonstrated how to set up and user the Android emulator and how to perfom Memory Analysis, Reverse the source code, analyze the logic of the application and how to bypass some security controls that are made by the developers and how to capture and view the communications between the application and it’s servers.

Overall it was a quite interesting workshop and the topic it is very important nowadays as companies are creating more and more mobile apps and they need to be safe and protect their clients data.

After the workshops there was Wardriving contest. We all gathered inside a pirate-ship-like bus and did a city tour with hackers full of big antennas and all their gears to perform wardriving. The wardriving was made to see who gets the biggest amout of wireless networks. That was it for the first day of ekoparty. More reviews are coming. We'll keep you posted!