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!


segunda-feira, 16 de setembro de 2013

O estado atual da Segurança em Aplicações - E sua empresa, como está?

Foi realizada uma pesquisa bem interessante sobre a maturidade da segurança de aplicações em organizações. Foram entrevistados 642 profissionais da área (executivos e desenvolvedores), com perguntas sobre uso de ferramentas, conhecimento sobre SDL e políticas de segurança no desenvolvimento.

Os idealizadores da pesquisa foram a empresa Security Innovation e o Instituto Ponemon. Um dos grandes pontos que chamou atenção nos resultados foi a diferença da visão real entre executivos e desenvolvedores sobre o processo atual da segurança de aplicações que a empresa se encontra.


Atualmente a camada de aplicação é responsável por 90% das vulnerabilidades de segurança, porém mais de 80% dos orçamentos são gastos na proteção na camada de rede. Aproveito o gancho aqui para uma palestra que nosso CTO Wagner Elias fará no Silver Bullet com o título "Falta Dinheiro" , onde ele focará um pouco na parte de investimentos do orçamento da empresa.

Os 7 pontos chave encontrados na pesquisa foram.
  1. Maioria das organizações não possuem um processo de desenvolvimento de software
  2. Maioria das organizações não estão fazendo testes de segurança das aplicações
  3. Políticas e requerimentos não estão integrados no SDLC
  4. Grande maioria não possui um processo formal de treinamento de segurança em aplicações
  5. Times de desenvolvimentos não são medidos por compliance com regulamentações e padrões
  6. Maioria das organizações não identificam, medem ou entendem os riscos da segurança das aplicações
  7. Grande desconexão entre executivos e desenvolvedores na situação real na maturidade no desenvolvimento seguro.
Abaixo alguns pontos importantes que valem ser destacados:

Um ponto que podemos achar básico, porém analisando a pesquisa notamos que não é tão comum, são as ferramentas automatizadas. Ficou constatado que durante o processo de desenvolvimento apenas 41% das empresas utilizam essas ferramentas e 43% após o lançamento. Esses números são extremamente baixos, visto que uma ferramenta automatizada seria a checagem mais simplificada, sem grande demanda de tempo, que uma empresa poderia adicionar.

Uma das grandes surpresas, conforme citado anteriormente no inicio do post, foi a diferença de visão da situação entre como a equipe de desenvolvimento está em relação a maturidade da segurança das aplicações. Executivos são totalmente otimistas com 67%, porém a parte técnica não está com a mesma visão, onde 73% NÃO acreditam nessa situação. Essa falta de consenso é bem crítica, pois demonstra que a empresa não está alinhada nesse processo de segurança de aplicação e investimentos podem ( e possivelmente devem) estar sendo feito em área erradas ou com menor necessidade.

Entendimento do risco e tomada de decisões baseado nas métricas demonstram o pouco uso dessa importante informação, sendo respectivamente 44% (entendimento do risco) e 42% (ações baseadas em métricas). Ter um contexto e adaptar a métrica ao seu negócio é fundamental para tomada de decisões, o que nos gerou dúvidas de como eles priorizam as correções e esforços, sem ter a métrica e entendimento adequado.


Alguns dados interessantes sobre os pesquisados, o que mostra grande valor da mesma, pois abrangeu diferentes áreas de atuação, assim como tamanho.

Tamanho das empresas


Área de atuação das empresas


Pesquisa e artigo completo podem ser encontrado em https://www.securityinnovation.com/security-lab/our-research/current-state-of-application-security.html

O Conviso Security Compliance (CSC) é a ferramenta que unifica todo o processo de desenvolvimento seguro e gestão das vulnerabilidades em uma única interface, desenvolvida pela Conviso para facilitar a priorização de ações, gerando métricas que possibilitam que a empresa tenha uma visão singular da situação atual da segurança da aplicação, tanto no lado técnico como executivo.

Requisite mais informações e uma demonstração: https://www.conviso.com.br/produtos.php

terça-feira, 10 de setembro de 2013

Conviso Security Compliance, o primeiro na América Latina compatível com o CWE

A Conviso já figura como primeira empresa da América Latina no SDL Pro Network da Microsoft, um grupo de empresas especializadas em segurança de aplicação que a Microsoft credencia, conforme podemos visualizar na imagem abaixo:


Sempre preocupada com a adequação de seus produtos aos padrões internacionais em Segurança da Informação, a Conviso agora se apresenta como a primeira empresa da América Latina a oferecer um produto 100% nacional compatível com o CWE (Common Weakness Enumeration) e listado na página do MITRE.



Isso demonstra o reconhecimento da comunidade internacional ao plano de investimentos contínuo que a empresa vem realizando em seus produtos. Ainda podemos afirmar que essa conquista é apenas o começo de muitas outras grandes novidades que ainda estão por vir.

Mas o que é o CWE ?

O CWE (Common Weakness Enumeration) é uma lista que corresponde a documentação de fragilidades em softwares criada para dar suporte ao CVE (Common Vulnerabilities and Exposures), que nos dias de hoje é uma lista global de vulnerabilidades identificadas nos mais variados tipos de software.

Essa base de conhecimento é desenvolvida e mantida pelo MITRE com o objetivo de promover colaboração entre desenvolvedores e profissionais de segurança da informação através da padronização de nomenclaturas, procedimentos de correção e prevenção, facilitando assim o processo de gestão em relação a segurança. Além do CWE o MITRE  também mantém diversos outros padrões aplicados as mais diversas áreas de pesquisa como OVAL e o CAPEC.

No Conviso Security Compliance (CSC), o cliente será informado sobre a relação com o CWE ID, facilitando assim a correção e melhorando a priorização das ações. Abaixo algumas telas do Conviso Security Compliance

Combo para pesquisa de vulnerabilidades baseada no CWE-ID


Descrição da vulnerabilidade com Sans TOP (os 25 CWE-ID mais frequentes)


Novas vulnerabilidades podem ser criadas com link para o CWE-ID correspondente


E logicamente métricas baseadas nos CWE-ID em nossos Dashboards



Ficou interessado? Não deixe de conhecer nosso produto: https://trycsc.conviso.com.br/csc/