Conviso: Patrocínios, apoio, palestrantes e treinamentos

Nos dias 14 e 15 de setembro, na UNIVAP - Universidade Vale do Paraíba – Urbanova,  irá acontecer a Vale Security Conference (ValeSec) e a Conviso Application Security ® é uma das patrocinadoras do evento. De acordo com o site do evento:

“A Vale Security Conference é uma iniciativa inovadora composta por pesquisadores e profissionais de segurança da informação que visa trazer ao Vale do Paraíba conhecimentos relevantes sobre os problemas relacionados ao uso das tecnologias, sua segurança, bem como o desenvolvimento de ações preventivas, sejam estas para o mundo corporativo, acadêmico ou para a sociedade em geral.” [1]

O Rodrigo Montoro, nosso Gerente de Produtos irá palestrar sobre o Snort com o título: “Snort - Muito além do make install” [2], segue abaixo a descrição da palestra:

“Detecção de Intrusos está muito além de uma simples ferramenta ou instalação da mesma. Muito vemos no dia a dia, empresas prestando serviços ou até mesmo consultores instalando poderosas ferramentas, mas praticamente com suas configurações padrões, gerando milhares de falsos-positivos e sem contexto algum com a rede e/ou negócio da empresa. Nessa palestra discutiremos o processo completo para implementação de um Sistema de Detecção de Intrusos de acordo com a necessidade da empresa, diferente tipos de ferramentas e nomenclatures (com foco no Snort), configurações avançandas que são ignoradas em mais de 90% das instalações, assim como a parte mais importante e produto final desse processo, a Gestão do Alerta. A ferramenta é apenas reflexo do nosso conhecimento sobre o assunto e necessidade, muitas vezes com pleno conhecimento, uma ferramenta mais simples poderá ter resultados extraordinários e melhores que produtos milionários, caso o profissional que a instala/configura entenda o contexto que esta sendo exposto.”

Além da palestra a Conviso estará presente no evento com 3 treinamentos. Um deles será ministrado pelo nosso CTO, Wagner Elias e terá como tema “Segurança em Desenvolvimento de Software segundo o OpenSAMM”. O workshop tem como objetivo apresentar as práticas do OWASP OpenSAMM [3]. Outro treinamento será ministrado por um dos nossos consultores, o Roberto Soares. O título do treinamento será Ruby for Pentesters [4].

“O treinamento introduz uma abordagem prática na criação de ferramentas utilizando a linguagem Ruby e mostrando as vantagens em utilizar esta linguagem. Testes totalmente hands-on, assim os participantes conseguem assimilar as técnicas apresentadas. Será utilizada como alvo uma rede virtual próxima ao real e também será disponibilizado as ferramentas e arquivos criados utilizados na oficina para os participantes também realizarem os testes posteriormente.”

Para completar teremos também o treinamento do Rodrigo Montoro sobre o os conceitos básicos do Snort [5]. Abordando desde a instalação, como funciona, testes básicos, regras, etc.

Nos dias 05 e 06 de Outubro, no Novotel Morumbi em São Paulo, acontence a Hackers to Hackers Conference (H2HC) [6], conhecida como a maior conferência de Segurança da Informação do Brasil. A conferência visa mostrar ao público como os sistemas são atacados, exibindo novas técnicas de ataque, ferramentas e pontos de insegurança de sistemas para que os responsáveis pela segurança saibam também como se defender e prevenir ataques. Dentre os keynotes speakers está Charlie Miller, antigo funcionário da NSA e escritor de vários exploits para produtos da Apple, que irá demonstrar técnicas de car hacking, isto é, diversas técnicas utilizadas para hackear carros, os quais hoje em dia possuem diversos componentes eletrônios e automatizados.

A Conviso Application Security também irá apoiar e ter seu representante no evento em que mais abrange cidades brasileiras na área de segurança em informação, o RoadSec[7]. Um novo evento de Segurança da Informação com um conceito diferente, por ser um evento itinerante e que acontece em várias cidades do país dando assim a oportunidade de conhecermos diversos profissionais de Segurança em diferentes regiões. O evento em Curitiba acontecerá no dia 21 de Setembro, na Universidade Positivo. O nosso CTO, Wagner Elias[8] irá palestrar sobre “Um pouco sobre segurança em desenvolvimento de software” e terá como objetivo mostrar um planejamento baseado no OWASP OpenSAMM para implementar a iniciativa nas organizações.

Wagner Elias, também apresentará a palestra “falta dinheiro” no Silver Bullet 2013, em São Paulo nos dias 27 e 28 de setembro, o qual irá discutir sobre o investimento em segurança da informação, como deve ser feito esse investimento para aumentar o nível de segurança e atender aos interesses da empresa.

Acompanhe todos os eventos que a Conviso Application Security patrocina e apóia em:  https://www.conviso.com.br/eventos.php

[1] http://www.valesecconf.com.br/

[2] http://www.valesecconf.com.br/palestrantes.html#spooker

[3] http://www.valesecconf.com.br/treinamentos.html#welias

[4] http://www.valesecconf.com.br/treinamentos.html#espreto

[5] http://www.valesecconf.com.br/treinamentos.html#spooker

[6] http://h2hc.org.br/h2hc/pt/

[7] http://roadsec.com.br/

[8] http://roadsec.com.br/wagner-elias

[9] http://sbconference.com.br

Segurança além da aplicação - Baselines, Hardening e o novo Projeto SANS SCORE

Introdução

Atualmente, os ataques cibernéticos vem crescendo exponencialmente em todo mundo. O Brasil não fica fora dessa estatística, de fato ele é um dos países mais afetados. A Akamai[1], uma empresa especializada em computação em nuvem e content delivery, disponibiliza um aplicativo em seu site onde é possível acompanhar os ataques em tempo real, como pode ser visto na Figura 1 abaixo.

Figura 1 - Ataques cibernéticos acontecem em tempo real. - Imagem feita às 15:16 do dia 20/08/2013

Um exemplo bem comum dos ataques realizados é o Local File Inclusion (LFI). Este ataque possibilita acesso aos arquivos locais no servidor, como por exemplo arquivos sensíveis, arquivos de configuração e arquivos de logs. Em alguns casos esse ataque permite a execução remota de código malicioso. Na Figura 2, é possível ver um exemplo de como este ataque é executado visando acesso não autorizado a um arquivo de log.

Figura 2 - Exemplo de LFI acessando o arquivo /var/log/auth.log do sistema - Fonte: http://lanmaster53.com/images/posts/lfi_rce_orig_auth.png

No exemplo citado, além da falha na aplicação, existe um problema de permissão, pois o servidor web não deveria ter acesso aos arquivos de log, ou seja, além de corrigir a falha é necessário ajustar as permissões do usuário do servidor web para que assim seja possível diminuir a possibilidade de ataque. Isto é o chamado Princípio do Menor Privilégio (ou Least Privilege Principle, em inglês), que diz que cada aplicação, usuário, plugin ou módulo, deve acessar apenas as informações necessárias para o seu funcionamento legítimo.

Como podemos diminuir essa superfície de ataque e aumentar a segurança? 

Nosso dia a dia é cercado de regras, e para isso existem leis e pessoas encarregadas de assegurar que tais regras seja seguidas e que existam punições caso contrário. Assim como as leis, os baselines são os requisitos mínimos de configurações e boas práticas que o sistema deve possuir antes de entrar em produção. 

Sabemos que para uma Lei funcionar, é necessário que tenha alguém monitorando e garantindo sua aplicação. O hardening é o responsável por isso, monitorando se os baselines estão sendo seguidos ou gerando alertas caso contrário.

No exemplo de LFI apresentado no começo, se o servidor seguisse algum Baseline e fosse aplicado o hardening, a possibilidade de sucesso em um ataque seria reduzida, pois provavelmente o acesso aos arquivos de logs não estaria disponível (a não ser por alguma necessidade especifica), fazendo com quem uma falta de validação dos parâmetros de entrada da aplicação não fosse o único fator determinante para o sucesso na exploração da vulnerabilidade.

Existem diversos Guias com sugestões de configurações de baselines, dentre os quais podemos citar:

• NIST - http://www.nist.org
• CIS Bench - http://cisecurity.org

Nesse post comentaremos sobre o CIS Bench e a iniciativa do SANS, chamada de SCORE.

O que é o tal do CIS Bench?

Center for Internet Security (CIS)[2] é uma organização sem fins lucrativos que ajuda as empresas a melhorar sua postura de segurança em relação a proteção de suas aplicações na web, o SCORE(Security Consensus Operational Readiness Evaluation)[3] é mais um dos vários recursos de melhoria de segurança que o CIS oferece como ajuda às empresas e governos. Como falado anteriormente, o CIS possui vários outros recursos que podem ser encontrados nesse link: Resources Publications.

Figura 3 - Checklist do CIS - Fonte:

http://benchmarks.cisecurity.org/images/screenshot_CIS-CAT_checklist.png

E qual a finalidade do SCORE?

O SCORE foi elaborado a partir do consenso de diversos profissionais gabaritados do mercado de segurança com o intuito de definir melhores padrões mínimos e gerar informações sobre melhores práticas de segurança. Ele também debate sobre técnicas já existentes, assim melhorando as mesmas e servindo como mecanismo de melhoria do CIS Bench.

O objetivo geral é demonstrar a importância do hardening tanto para empresas quanto para governos, criando e promovendo listas de discussões, debatendo e melhorando o processo todo, de forma contínua.

Alguns papers do SCORE já foram publicados como exemplo de “Descobrindo intrusos ” tanto para Windows[4] e Linux[5]. O projeto também disponibiliza um guia de estudos e uma serie de livros [6].

Conclusão

Problemas e falhas existem em qualquer aplicação. Como profissionais de segurança da informação é nosso dever diminuir essa exposição reduzindo a superfície do ataque e corrigindo falhas, com o objetivo de dificultar uma possível invasão. O trabalho de segurança em uma Aplicação Web ou qualquer outro software está relacionado à segurança da infraestrutura que o suporta, não limitando-se somente à blindagem da aplicação.

Na Conviso possuímos o Armature. Essa extensão do Conviso Security Compliance[7] possibilita a empresa a utilização de Baselines e Aplicação / Monitoramento do hardening. A solução é totalmente flexível, sendo que a empresa poderá utilizar Baselines desenvolvidos pelo Conviso Intelligence ou a criação seus próprios, que serão convertidos em regras para o monitoramento dos agentes em tempo real. Com essa extensão é adicionado mais contexto as falhas, possibilitando priorizar melhor as ações da Gestão de Vulnerabilidades, pois a empresa não só terá a criticidade da falha da aplicação, mas também da infraestrutura que suporta a mesma, correlacionando e gerando métricas com a real criticidade.

Peça uma demonstração https://www.conviso.com.br/contato.php caso tenha interesse.

[1] - http://www.akamai.com

[2] - http://www.cisecurity.org

[3] - http://www.sans.org/score
[4] - http://www.sans.org/score/checklists/ID_Windows.pdf

[5] - http://www.sans.org/score/checklists/ID_Linux.pdf

[6] - http://www.sans.org/score/studyguides.php

[7] - https://www.conviso.com.br/produtos.php

Entendendo e explorando o CVE-2012-4576 para o Kernel do FreeBSD

Introdução

Dando continuidade a exploração de vulnerabilidades em kernel-land [1], neste artigo serão analisados os detalhes da vulnerabilidade registrada no CVE-2012-4576 e como podemos utilizá-la para obter execução de código no kernel do FreeBSD.

Esta vulnerabilidade foi reportada por Mateusz Guzik e o advisory [2] oficial do time de segurança do FreeBSD foi publicado no dia 22 de Novembro de 2012.

A falha ocorre devido a falta de validação em uma chamada de sistema. Como resultado, regiões de memória podem ser sobrescritas. A vulnerabilidade existe no módulo que adiciona a compatibilidade de execução de arquivos binários nativos do Linux no FreeBSD, então apenas sistemas que usam este recurso podem estar vulneráveis.

Todos os experimentos neste artigo foram realizados no sistema operacional FreeBSD 7.0, 8.2 e 9.0 arquitetura 32 bits (i386).

A vulnerabilidade

De acordo com o patch [3] disponibilizado pelo time de segurança oficial do FreeBSD, percebe-se que o código vulnerável se encontra no arquivo “sys/compat/linux/linux_ioctl.c” na função “linux_ifconf()”.

Arquivo: /usr/src/sys/compat/linux/linux_ioctl.c
---
2134  /*
2135   * Implement the SIOCGIFCONF ioctl
2136   */
2137 
2138  static int
2139  linux_ifconf(struct thread *td, struct ifconf *uifc)
2140  {
2141  #ifdef COMPAT_LINUX32
2142  struct l_ifconf ifc;
2143  #else
2144          struct ifconf ifc;
2145  #endif
...
2149          struct sbuf *sb;
...
2152          error = copyin(uifc, &ifc, sizeof(ifc));
2153          if (error != 0)
2154                  return (error);
...
2236         ifc.ifc_len = valid_len;
2237         sbuf_finish(sb);
2238         memcpy(PTRIN(ifc.ifc_buf), sbuf_data(sb), ifc.ifc_len);
2239         error = copyout(&ifc, uifc, sizeof(ifc));
2240         sbuf_delete(sb);
2241         CURVNET_RESTORE();
2242 
2243         return (error);
2244  }
---

Na linha 2139 vemos que a função recebe dois argumentos, sendo o primeiro o endereço para uma estrutura do tipo “thread” e o segundo o endereço para uma estrutura “ifconf”. Por acreditar ser desnecessário, o trecho de código que faz a chamada a função “linux_ifconf()” foi omitido, mas a única informação relevante para o correto entendimento desse artigo é que o segundo argumento passado é o endereço de memória que foi utilizado como argumento na chamada ioctl, portanto, o conteúdo da variável “uifc” é controlado pelo usuário. Exemplo da utilização da ioctl SIOCGIFCONF pode ser vista em [4].

Como podemos ver na linha 2152, o conteúdo da variável “uifc” é copiado para a variável “ifc” utilizando a função “copyin()” [5], a partir deste ponto a estrutura “ifc” também será controlada pelo usuário. Para quem não conhece, as funções “copyin()” e “copyout()” [6] são utilizadas para transferir dados do espaço de endereçamento do usuário para o kernel e vice-versa. Após isso, na linha 2238, o valor controlado pelo usuário é utilizado como primeiro argumento na chamada a função “memcpy()” [7]. Um detalhe relevante é que ao realizar a chamada ioctl podemos informar a quantidade de bytes que o endereço que passamos comporta, desta forma a função “linux_ifconf()” poderá calcular se irá ocorrer overflow ou não ao copiar os dados, durante esse cálculo o valor “ifc.ifc_len” é alterado e não é totalmente controlado pelo usuário.

O valor retornado pela chamada a função “sbuf_data(sb)” na linha 2238 são as configurações das interfaces disponíveis na máquina.

Exploração

Como mencionado anteriormente, o módulo que adiciona compatibilidade binária Linux ao FreeBSD, falha em validar um endereço passado como argumento na chamada a ioctl SIOCGIFCONF, permitindo que seja passado qualquer endereço de memória que terá seu conteúdo sobrescrito pelas configurações das interfaces da máquina. Para quem já tem alguma experiência com exploração de vulnerabilidades, inclusive no kernel, sabe que este tipo de falha em determinadas situações pode ser facilmente exploradas, em [8] você encontrará uma vulnerabilidade similar no kernel do linux encontrada pelo pesquisador Dan Rosenberg.

Existem estruturas importantes para o correto funcionamento do kernel que podem ser utilizadas como alvo e ter seus valores sobrescritos, o que permite redirecionar o fluxo de execução do kernel para um desejável por um atacante. Para realizar a exploração dessa vulnerabilidade foi selecionada a entrada número 3 da Interrupt Descriptor Table (IDT) [9] para ser sobrescrita pelos 16 bits mais significativos do nome da interface retornada. Os valores da entrada da IDT que serão sobrescritos são apenas os bits mais significativos do endereço de uma função. Como podem haver vários nomes para interfaces (“em”, “eth”, “lo”, “usbus”, etc), o exploit que foi escrito para essa vulnerabilidade obtêm esse valor em tempo de execução e ajusta o exploit de acordo com o nome da interface do ambiente. Este comportamento que permitiu o exploit funcionar tanto na versão 8 quanto na versão 9 do FreeBSD onde no mais recente a chamada a ioctl retorna “usbus0” e na versão 8 retorna “eth0”.

O endereço da função que irá gerenciar determinada interrupção fica dividido pela metade na IDT, os bits menos significativos armazenados no começo da entrada e os mais significativos no final da entrada, sendo que cada entrada tem o tamanho de 8 bytes. Assim, como falado anteriormente, somente os bits mais significativos serão sobrescritos, desta forma o novo endereço da função terá os bits mais significativos (os dois primeiros bytes) retornados pelo nome da interface e os bits menos significativos continuarão com os valores da função original. Antes de sobrescrever, será necessário mapear o novo endereço gerado e inserir o código que deseja ser executado quando uma nova interrupção da entrada sobrescrita for gerada, no caso do exploit escrito, essa interrupção é gerada usando a instrução chamada int3.

Partindo da premissa que os nomes das interfaces sejam caracteres ascii, não precisamos checar se o endereço gerado após a sobrescrita está dentro dos limites do espaço de endereçamento do usuário. Considerando que o nome da interface seja composto por letra e números, o maior valor em ascii é o caracter ‘z’ que tem o valor ‘7f’ em hexadecimal. Então considerando que a interface retornada seja ‘zz0’ e o endereço original da função na IDT seja 0xc0d33d08, após a sobrescrita o endereço será ‘0x7f7f3d08’, limite dentro do espaço de endereçamento do usuário.

Neste ponto já é possível obter execução de código, o próximo passo agora é reparar o estrago que foi feito na IDT com as outras informações da interface. Como as informações de cada interface são armazenadas em uma estrutura chamada “ifreq” e seu tamanho é 32 bytes, esse é o tamanho mínimo que conseguimos sobrescrever da IDT. Quanto menos valores conseguirmos sobrescrever, menor o estrago a ser reparado. No exploit liberado anteriormente não utilizava esse recurso e sobrescrevia muito mais que 32 bytes da IDT no caso do FreeBSD 8. Depois de consertar a IDT única coisa que resta é elevar os privilégios e retornar para userland, no exploit utilizamos a técnica “iret” [10] para esse propósito.

Através do método explicado acima foi possível escrever um exploit que funcionasse tanto na versão 7, 8 e 9 do FreeBSD sem precisar usar endereços fixos no código para cada versão. Não foi realizado nenhum teste em outras versões, mas é possível que o exploit também funcione normalmente desde que seja versão i386 do sistema operacional.

Outro fator importante é que, teoricamente, sobrescrever a IDT não é uma boa escolha devido ao motivo que o processo pode ser interrompido pelo scheduler logo após a sobrescrita e o novo processo acionar a interrupção da entrada sobrescrita ao invés do processo do exploit. Como o endereço que foi sobrescrito não é mapeado no novo processo, possivelmente um kernel panic irá ocorrer. Apesar disto, o exploit disponibilizado aqui foi executado e em nenhum momento aconteceu algo inesperado.

Conclusão

A correção feita pela equipe de segurança foi substituir a função “memcpy()” pela função “copyout()". Esta função automaticamente valida se os endereços passados como argumento pertencem ao seus devidos espaço de memória, evitando que seja feito a cópia de dados kernel <-> kernel e/ou user-land <-> user-land.

O exploit está disponível em [11], para utilizá-lo é necessário que seja compilado em um ambiente Linux e com a biblioteca structs.h [12] no mesmo diretório onde encontra-se o arquivo CVE-2012-4576-linux.c, após isso o binário gerado pode ser executado normalmente em uma versão vulnerável do FreeBSD. Não é necessário especificar nenhum parâmetro adicional ao compilador mas se o ambiente Linux estiver faltando alguma biblioteca necessária, recomenda-se utilizar a flag “-static” para o gcc. O ambiente Linux utilizado foi Ubuntu versão 12.04 instalado em uma máquina virtual VMWARE.

O vídeo abaixo demonstra a exploração da falha nos sistemas FreeBSD 7, 8.2 e 9.

Referências

[1] - http://blog.conviso.com.br/2012/12/uma-analise-do-cve-2012-0217.html
[2] - http://www.freebsd.org/security/advisories/FreeBSD-SA-12:08.linux.asc
[3] - http://security.FreeBSD.org/patches/SA-12:08/linux.patch
[4] - http://www.techpulp.com/blog/2008/10/get-list-of-interfaces-using-siocgifconf-ioctl/
[5] - http://www.unix.com/man-page/FreeBSD/9/copyin/
[6] - http://www.unix.com/man-page/FreeBSD/9/copyout/
[7] - http://linux.die.net/man/3/memcpy
[8] - http://www.vsecurity.com/download/tools/linux-rds-exploit.c
[9] - https://en.wikipedia.org/wiki/Interrupt_descriptor_table
[10] - https://www.blackhat.com/presentations/bh-usa-03/bh-us-03-cesare.pdf
[11] - https://github.com/andersonc0d3/exploits/blob/master/CVE-2012-4576-linux/CVE-2012-4576-linux.c
[12] - https://github.com/andersonc0d3/exploits/blob/master/exploits/CVE-2012-4576-linux/structs.h

BlackHat, DEF CON e BSidesLV

Recentemente, aconteceu uma das maiores conferências focadas na área de TI e segurança da informação, a BlackHat[1]. O evento ocorreu dos dias 27 de julho a 1 de agosto, com dezenas de palestras e atividades que ao decorrer das edições vem surpreendendo cada vez mais. Por exemplo, nesta ultima edição durante a conferência pesquisadores demonstraram como interceptar ligações em celulares, podendo espionar as conversas telefônicas, mensagens de texto ou até mesmo fotos enviadas e recebidas pelo usuário, utilizando a mesma tecnologia pelas empresas para aumentar a cobertura de telefonia celular[2]. Outra apresentação que chamou a atenção, foi a de Kevin McNamee, que mostrou como transformar um smartphone Android em uma máquina espiã (SpyPhone), podendo monitorar quase tudo que o telefone faz[3].

Uma grande perda para a comunidade de Segurança foi a morte de um lendário pesquisador e profissional de segurança, o Barnaby Jack, conhecido principalmente por ter feito dois caixas eletrônicos jogarem dinheiro em pleno palco durante uma apresentação anterior no evento. Dias antes de sua palestra na BlackHat sobre “Como invadir dispositivos médicos: Atacando pessoas que usam próteses eletrônicas”, o hacker foi encontrado morto em seu apartamento, não se sabe ao certo o motivo da morte, mas a hipótese de crime foi descartada pela polícia. [4]

Falando de grandes conferências, torna-se impossível não citar a DEF CON[5], um evento que já está em sua 21ª edição, e é uma das mais antigas conferências voltada à área de segurança da informação, que aconteceu nos dias 1 a 4 de Agosto este ano. A DEF CON tem a grande preferência do público, pois ela é mais técnica e menos formal, o que caracteriza a sensação de estar numa verdadeira conferência hacker. A DEF CON disponibilizou um documentário mostrando como é o evento[6], vale a pena assistir.

Outro evento que vem ganhando grande espaço no mundo da segurança da informação, são os eventos BSides. Estes geralmente acontecem dias antes ou depois de um grande evento nacional ou internacional. O BSides LasVegas[7] é uma ótima alternativa para quem gostaria de participar de eventos como a DEF CON ou a BlackHat, porém não tenha condições de pagar por eles. O BSidesLV chama a atenção por ser um evento de alta qualidade, a custo zero, que conta com a ajuda de patrocinadores e voluntários, e também, principalmente, por estar entre uma das maiores conferências na área de segurança em informação. No Brasil, temos a BSidesSP que acontece sempre antes ou depois do You Shot The Sheriff (YSTS) em maio e da Hackers to Hackers Conference (H2HC) em outubro.

[1] BlackHat - http://www.blackhat.com/

[2] Black Hat: pesquisadores mostram como interceptar ligações em celulares - http://idgnow.uol.com.br/mobilidade/2013/08/01/black-hat-pesquisadores-mostram-como-interceptar-ligacoes-em-celulares/

[3] Hackers podem transformar seu Android em um SpyPhone -

http://tecnologia.terra.com.br/hardware-e-software/hackers-podem-transformar-seu-android-em-um-spyphone,efff31272ea30410VgnVCM4000009bcceb0aRCRD.html

[4] Hacker lendário, Barnaby Jack morre às vésperas da Black Hat - http://info.abril.com.br/noticias/seguranca/2013/07/hacker-lendario-barnaby-jack-morre-as-vesperas-da-black-hat-1.shtml

[5] DEF CON - https://www.defcon.org/

[6] DEFCON: The Documentary - http://vimeo.com/69695831

[7] BSides Las Vegas - http://www.bsideslv.org/

UbiCrypt Summer School - Bochum 2013

A Conviso marcou presença esse ano na escola de verão em engenharia reversa na Universidade de Ruhr, Bochum [1]. Quem atua em pesquisa com foco na área de análise de Malware e código sabe que Ruhr representa um centro de excelência e concentração de bons pesquisadores na Europa (e me arriscaria a dizer no mundo).

Como de costume, a organização germânica não deixou nada a dever. Desde a infra-estrutura para acolher alunos das mais diferentes nacionalidades até a forma como o processo foi executado. Para se inscrever no curso foi necessário resolver um desafio descrito na página do evento [2] e escrever um parágrafo explicando o que lhe motiva a participar do curso. Isso, de certa forma, já tornava o processo de participação minimamente meritocrático e filtrou quem não possui uma base técnica mínima necessária para acompanhar o curso.

O evento em si, foi composto por duas vertentes: (i) a primeira formal e voltada para pesquisa e (ii) a segunda aplicação do conhecimento. Ao decorrer de cinco dias de curso com uma turma composta por 70 alunos trabalhando em tópicos como: Deobfuscation, Unpacking, Windows Internals, Binary Instrumentation, Dynamic Taint Analysis, Engenharia Reversa em código C++ e uma aula mais específica sobre Malwares para dispositivos móveis com foco em Android. Na Quarta-feira ocorreu uma pausa nas aulas e foi realizado um mini seminário com apresentações dos top-artigos de 2012 em Malware Analysis na Europa.  

Foram 3 horas de aulas por dia (das 9 às 12) e um laboratório com desafios práticos na parte da tarde (auxiliado por monitores). Recomendo fortemente à quem decidir participar desse evento nos próximos anos já possuir uma fluência em Python e ser usuário de médio/avançado do IDApro [3] (além de dominar a API do IDAPython [4]).  Todas as aulas são ministradas em Inglês, isso significa que é necessário se comunicar nesse idioma. Por ser uma cidade estudantil (por volta de 40 mil estudantes no Campus de Bochum), os custos com acomodação são relativamente baixos (dois hostels na cidade e o hotel Ibis fica por volta de 30 euros a diária).

Resumo da obra: o evento é para aqueles de coração forte. Para aqueles que gostam de algo mais técnico e específico e uma ótima oportunidade para "o além do networking", que infelizmente representa o objetivo maior de boa parte dos eventos em segurança da informação hoje em dia. Aprender algo de forma estruturada realmente palpável na área. Recomendo fortemente.