Muito tempo se passou desde meu ultimo post. Após a criação do OctaneLabs, caímos de cabeça e alma no projeto MUFFIN e outros que foram surgindo. Sabem como é, projetos vêm, o tempo vai e ficou complicado postar com a frequencia que gostaria.
Vamos tentar mudar isso em 2013.
Em breve, vou comentar do OctaneLabs, dos projetos e como a Computação Forense está evoluindo nesses dias.
Vai ser muito bom voltar a escrever ;)
Até o próximo post !
sábado, 5 de janeiro de 2013
sábado, 2 de julho de 2011
O que é o Projeto MUFFIN, afinal ?
Cenário Atual
Você, CSO da empresa XYZ, está em casa. Foi dormir às duas da manhã vendo UFC, é sábado e está o maior frio lá fora. Às 3 em ponto, alguém do seu SOC liga e diz que está monitorando atividade intensa e anormal na sua rede, tem certeza absoluta que aconteceu um outbreak de malware e que provavelmente há vários servidores afetados. Vc pensa: "PUTZ, não tinha outra hora para acontecer ?". É hora de chamar o CSIRT. Todos te xingam, mas chegam à empresa conforme o marcado e a batalha começa.
Primeiro passo: Entender o que está acontecendo para planejar a CONTENÇÃO. Sua equipe precisa coletar dados voláteis de várias máquinas e analisá-los a fim de traçar estratégias. As máquinas afetadas estão ligadas e não podem ser desligadas (os dados são voláteis). O que a sua equipe tem na mão para fazer isso ? Um CD do Helix e um pendrive do CAINE, todos em várias cópias, cada um tem uma. Você orienta o time e eles partem para a batalha, iniciando pelas máquinas mais indicadas, dado o report do SOC. Nisso já são 7h e o CIO, que quase nunca apoia suas orientações, começa a ligar com o famoso "E aí ?". Sua equipe precisa coletar os dados e analisá-los o mais rapidamente.
- Em uma das máquinas, ao colocar o CD com o Helix, ela imediatamente reinicializa;
- Outra máquina tem uma versão mais antiga do SO, não roda diversos utilitários e toda a coleta fica comprometida;
- A maioria da equipe não lembra de cabeça os comandos e options necessários. Vários esquecem de capturar a memória por primeiro e muitos sequer trazem o resultado do netstat;
- Você ouve um barulho, foi um dos analistas socando a mesa porque o Antivirus não deixa de jeito nenhum ele rodar algumas ferramentas;
- Uma das máquinas tem a famosa tela azul depois da tentativa de rodar um dos programas do toolkit;
- quase todo o trabalho de coleta vai por água abaixo porque um dos pendrives retornou infectado. Como o analista estava usando Linux, não houve infecção na sua máquina, mas os resultados coletados seriam confiáveis ?
Vocês já viveram isso ??? É o que acontece na prática.
Os problemas acima acontecem, todos ou em parte, com cada um dos toolkits atualmente disponíveis como ferramenta de software livre. Dos que eu já pesquisei, o CAINE, o DEFT e o HELIX passam por essas ou outras situações onde ficam devendo. Até mesmo o COFEE, que não se encaixa na definição de software livre (apesar de ser livremente licenciado para polícias) passa por diversos problemas dos narrados acima. É exatamente nesse contexto que o projeto MUFFIN quer entrar: ser uma toolkit voltada para resposta a incidentes e que não tenha as mesmas fraquezas e os mesmos problemas desses que analisamos.
Para atingir isso, o MUFFIN será composto por 3 módulos:
- O pendrive MUFFIN, que é a toolkit propriamente dita;
- O MUFFIN Baker, uma ferramenta que permite configurar e gerar o pendrive MUFFIN;
- O MUFFIN Report, que vai acessar os dados gerados/coletados pelo pendrive MUFFIN.
O projeto já tem roadmap e escopo bem definido. Sua versão 0.1, marcada para ser apresentada no formato de procedimento, vai ao ar em breve. Em paralelo, a equipe do projeto trabalha na versão 0.2, primeira versão que vai trazer o Baker, automatizando a geração do pendrive MUFFIN.
Estamos desenvolvendo-o em Lazarus com SQLite. O Lazarus é um compilador Pascal com um ambiente muito parecido com Delphi, trazendo o beneficio de compilar o mesmo fonte em vários sistemas operacionais, incluindo Linux e o Mac OS.
Estamos precisando de colaboradores. Se você conhece de programação e pode nos ajudar, entre em contato. Se você não conhece, mas ainda assim quer ajudar no projeto, excelente. Há muito trabalho e todos são bem vindos.
Ate o proximo post !
Você, CSO da empresa XYZ, está em casa. Foi dormir às duas da manhã vendo UFC, é sábado e está o maior frio lá fora. Às 3 em ponto, alguém do seu SOC liga e diz que está monitorando atividade intensa e anormal na sua rede, tem certeza absoluta que aconteceu um outbreak de malware e que provavelmente há vários servidores afetados. Vc pensa: "PUTZ, não tinha outra hora para acontecer ?". É hora de chamar o CSIRT. Todos te xingam, mas chegam à empresa conforme o marcado e a batalha começa.
Primeiro passo: Entender o que está acontecendo para planejar a CONTENÇÃO. Sua equipe precisa coletar dados voláteis de várias máquinas e analisá-los a fim de traçar estratégias. As máquinas afetadas estão ligadas e não podem ser desligadas (os dados são voláteis). O que a sua equipe tem na mão para fazer isso ? Um CD do Helix e um pendrive do CAINE, todos em várias cópias, cada um tem uma. Você orienta o time e eles partem para a batalha, iniciando pelas máquinas mais indicadas, dado o report do SOC. Nisso já são 7h e o CIO, que quase nunca apoia suas orientações, começa a ligar com o famoso "E aí ?". Sua equipe precisa coletar os dados e analisá-los o mais rapidamente.
- Em uma das máquinas, ao colocar o CD com o Helix, ela imediatamente reinicializa;
- Outra máquina tem uma versão mais antiga do SO, não roda diversos utilitários e toda a coleta fica comprometida;
- A maioria da equipe não lembra de cabeça os comandos e options necessários. Vários esquecem de capturar a memória por primeiro e muitos sequer trazem o resultado do netstat;
- Você ouve um barulho, foi um dos analistas socando a mesa porque o Antivirus não deixa de jeito nenhum ele rodar algumas ferramentas;
- Uma das máquinas tem a famosa tela azul depois da tentativa de rodar um dos programas do toolkit;
- quase todo o trabalho de coleta vai por água abaixo porque um dos pendrives retornou infectado. Como o analista estava usando Linux, não houve infecção na sua máquina, mas os resultados coletados seriam confiáveis ?
Vocês já viveram isso ??? É o que acontece na prática.
Os problemas acima acontecem, todos ou em parte, com cada um dos toolkits atualmente disponíveis como ferramenta de software livre. Dos que eu já pesquisei, o CAINE, o DEFT e o HELIX passam por essas ou outras situações onde ficam devendo. Até mesmo o COFEE, que não se encaixa na definição de software livre (apesar de ser livremente licenciado para polícias) passa por diversos problemas dos narrados acima. É exatamente nesse contexto que o projeto MUFFIN quer entrar: ser uma toolkit voltada para resposta a incidentes e que não tenha as mesmas fraquezas e os mesmos problemas desses que analisamos.
Para atingir isso, o MUFFIN será composto por 3 módulos:
- O pendrive MUFFIN, que é a toolkit propriamente dita;
- O MUFFIN Baker, uma ferramenta que permite configurar e gerar o pendrive MUFFIN;
- O MUFFIN Report, que vai acessar os dados gerados/coletados pelo pendrive MUFFIN.
O projeto já tem roadmap e escopo bem definido. Sua versão 0.1, marcada para ser apresentada no formato de procedimento, vai ao ar em breve. Em paralelo, a equipe do projeto trabalha na versão 0.2, primeira versão que vai trazer o Baker, automatizando a geração do pendrive MUFFIN.
Estamos desenvolvendo-o em Lazarus com SQLite. O Lazarus é um compilador Pascal com um ambiente muito parecido com Delphi, trazendo o beneficio de compilar o mesmo fonte em vários sistemas operacionais, incluindo Linux e o Mac OS.
Estamos precisando de colaboradores. Se você conhece de programação e pode nos ajudar, entre em contato. Se você não conhece, mas ainda assim quer ajudar no projeto, excelente. Há muito trabalho e todos são bem vindos.
Ate o proximo post !
segunda-feira, 20 de junho de 2011
Mensagem às Futuras Gerações de CIOs, CEOs e CSOs
A onda de ataques cibernéticos que assolou o mundo recentemente, incluindo vários órgãos no Brasil, pode ser concluída em apenas uma frase: você vai ser ownado.
Ownado é um termo comum no underground de tecnologia. Quem foi ownado teve (ou ainda tem) gente com acesso aos seus dados, ao seu computador, aos seus servidores da empresa. Muitas vezes seu computador vira um escravo tecnológico, um zumbi comandado à distância para atacar e derrubar outros servidores. Mas por que você vai ser ownado ?
Entre outras coisas, porque definitivamente o ambiente digital foi reconhecido como área de guerra. Os ataques combinados dos grupos Anonymous e LulzSec sedimentaram o que já estava acontecendo em pequena escala, por um ou outro ataque em separado.
Na verdade, já tínhamos visto de tudo. Vez ou outra, tínhamos ataques derrubando grandes sites, tivemos as APTs, a operação Aurora, outras pequenas operações até que chegamos no Stuxnet e o mundo viu que o meio digital pode ser usado para sabotagem também. Esqueça tiroteios e bombas explodindo, o próximo filme do 007 vai ser filmado com um James Bond nerd não mais rodeado de mulheres maravilhosas , mas de laptops e computadores de tudo quanto é tipo, a Walther PPK dando lugar ao BackTrack ...
Depois que os militares acharam seu caminho no ciberespaço, agora foi a vez da turma que protesta. Não vou entrar no mérito da ideologia desses grupos, mas eles alegam que invadem e derrubam sites em nome da própria democracia, trazendo para o desktop e para o laptops o que antes era feito na base da gritaria e da correria. Spray de pimenta, jatos de água fria ? Nunca mais.
A questão é que, com ideologia ou não, essa turma mostrou que podem fazer estrago. Que o digam as ações da Sony, da Sega, do Citigroup ... A lista não é pequena, e vários dados roubados mostram o que é possível fazer. Eles recentemente anunciaram a paralisação do movimento, que me pareceu bastante estratégica, mas o recado foi dado. Mas por que você vai ser ownado ?
Você vai ser ownado porque a internet não é nem nunca foi a Disneylandia, embora você sempre a visse assim. Esses grupos não fizeram uma sequência de ataques, eles abriram uma nova era que não vai perdoar a forma como a Internet e a Segurança de Informações é tratada nas empresas. Esse vai ser o formato padrão de protestos daqui por diante. Se no passado o consumidor insatisfeito tinha que recorrer à Justiça, hoje ele indica o site da empresa a um grupo cracker, para que o derrubem. Políticos corruptos enfrentando jornalistas ? Coisa do passado, agora os dados deles vão parar na Web em letras grandes e em negrito. Mas por que você, logo você, vai ser ownado ?
A resposta é ainda maior do que o feito por esses grupos (não deve demorar até que sejam chamados de radicais ou recebam novos labels). Você vai ser ownado porque não consegue enxergar o que esta por trás do novo mundo digital; porque reveste seus carros com blindagens caríssimas, mas seus servidores estão completamente desprotegidos; porque você não trata os riscos mapeados, mas vive escondendo o que deveria ser feito, trocando ações reais por paleativos na única tentativa de mostrar para os agentes reguladores que você está protegendo a informação, sem mesmo sequer acreditar nem um minuto nisso.
Você vai ser ownado porque acha mais fácil enganar os auditores do que efetuar as práticas recomendadas; porque você prefere pagar alguns milhares de reais em caixinhas milagrosas para segurança a realmente implementar medidas que eduquem seus profissionais e colaboradores.
Você vai ser ownado porque sua senha, além de ridiculamente previsível, é de conhecimento de todos os que te rodeiam; porque você olha para todos os lados ao atravessar uma rua, mas não consegue perceber que o email que te mandaram está incoerente demais para ter vindo de um banco, e que você nem ao menos uma conta nesse banco tem, e nem assim você deixa de clicar no link dele; você nunca falou de sua vida para estranhos, mas põe todos os detalhes de sua vida nas redes sociais e fica postando para todo mundo ler onde você está, onde você costuma frequentar ou onde você estuda, e é por isso que você vai ser ownado.
Você vai ser ownado porque você finge que cobra o que a sua área de Segurança de Informações determina, mas você nem ao menos acredita na maioria dos controles que lá estão; porque você nunca banca atrasos no desenvolvimento dos softwares quando sua equipe o testa e comprova que a maioria dos requisitos de Segurança de Informações não foram cumpridos; Não, o prazo tem que ser cumprido e, depois, quando der, a equipe ajusta o que tiver de ser ajustado. Você lê sobre como se proteger no trânsito e envia dicas de direção segura para seus amigos, mas acha que bom senso é o único ingrediente necessário para não ter um "problema digital" e por isso mesmo as palestras de conscientização só servem para outros, nunca para você; Por isso, você será ownado.
Você vai ser ownado porque suas máquinas recebem correções de segurança completamente fora do prazo avaliado, isso quando recebem, só porque você nunca acreditou nos impactos descritos nos alertas de segurança; Você acha que antivirus e IDS são mais do que suficientes para se proteger e dorme tranquilo depois de usar seu laptop que não foi hardenizado como os demais da empresa, já que você é um executivo importante e quer fazer o que bem entende na sua máquina; não se engane, você vai ser ownado durante o seu sono tranquilo. Vai ser ownado e exposto por ter desligado a criptografia e a autenticação de sua máquina, reclamando que colocar uma senha ou carregar um token é um grande exagero e sem nenhuma necessidade "de negócio".
Essa é apenas uma pequena e modesta lista de explicações dos resultados que virão. Talvez você, CIO ou CEO, leia isso aqui e se sensibilize; provavelmente e infelizmente, isso não ocorrerá.
É fato que na nossa cultura processos só melhoram depois que problemas acontecem; providências só são tomadas depois que "o leite é derramado". Por isso, lamentavelmente o recado "não seja ownado" só valerá para as próximas gerações. A geração atual de CIOs e CEOs talvez não queira ouvir, e essa geração de CSOs, a que está aí correndo e lutando para ser ouvida, vai ser retirada de cena depois do primeiro ataque com estragos consideráveis. Os responsáveis das áreas de Segurança de Informações serão demitidos, surgirão notas dizendo que nada aconteceu, a sujeira vai aos poucos ser varrida para baixo do tapete e a nova área provavelmente ganhará, enfim, mais atenção.
Talvez então, e só então, CIOs e CEOs escutem mais e façam o que deve ser feito para não serem ownados.
Até o próximo post !
Ownado é um termo comum no underground de tecnologia. Quem foi ownado teve (ou ainda tem) gente com acesso aos seus dados, ao seu computador, aos seus servidores da empresa. Muitas vezes seu computador vira um escravo tecnológico, um zumbi comandado à distância para atacar e derrubar outros servidores. Mas por que você vai ser ownado ?
Entre outras coisas, porque definitivamente o ambiente digital foi reconhecido como área de guerra. Os ataques combinados dos grupos Anonymous e LulzSec sedimentaram o que já estava acontecendo em pequena escala, por um ou outro ataque em separado.
Na verdade, já tínhamos visto de tudo. Vez ou outra, tínhamos ataques derrubando grandes sites, tivemos as APTs, a operação Aurora, outras pequenas operações até que chegamos no Stuxnet e o mundo viu que o meio digital pode ser usado para sabotagem também. Esqueça tiroteios e bombas explodindo, o próximo filme do 007 vai ser filmado com um James Bond nerd não mais rodeado de mulheres maravilhosas , mas de laptops e computadores de tudo quanto é tipo, a Walther PPK dando lugar ao BackTrack ...
Depois que os militares acharam seu caminho no ciberespaço, agora foi a vez da turma que protesta. Não vou entrar no mérito da ideologia desses grupos, mas eles alegam que invadem e derrubam sites em nome da própria democracia, trazendo para o desktop e para o laptops o que antes era feito na base da gritaria e da correria. Spray de pimenta, jatos de água fria ? Nunca mais.
A questão é que, com ideologia ou não, essa turma mostrou que podem fazer estrago. Que o digam as ações da Sony, da Sega, do Citigroup ... A lista não é pequena, e vários dados roubados mostram o que é possível fazer. Eles recentemente anunciaram a paralisação do movimento, que me pareceu bastante estratégica, mas o recado foi dado. Mas por que você vai ser ownado ?
Você vai ser ownado porque a internet não é nem nunca foi a Disneylandia, embora você sempre a visse assim. Esses grupos não fizeram uma sequência de ataques, eles abriram uma nova era que não vai perdoar a forma como a Internet e a Segurança de Informações é tratada nas empresas. Esse vai ser o formato padrão de protestos daqui por diante. Se no passado o consumidor insatisfeito tinha que recorrer à Justiça, hoje ele indica o site da empresa a um grupo cracker, para que o derrubem. Políticos corruptos enfrentando jornalistas ? Coisa do passado, agora os dados deles vão parar na Web em letras grandes e em negrito. Mas por que você, logo você, vai ser ownado ?
A resposta é ainda maior do que o feito por esses grupos (não deve demorar até que sejam chamados de radicais ou recebam novos labels). Você vai ser ownado porque não consegue enxergar o que esta por trás do novo mundo digital; porque reveste seus carros com blindagens caríssimas, mas seus servidores estão completamente desprotegidos; porque você não trata os riscos mapeados, mas vive escondendo o que deveria ser feito, trocando ações reais por paleativos na única tentativa de mostrar para os agentes reguladores que você está protegendo a informação, sem mesmo sequer acreditar nem um minuto nisso.
Você vai ser ownado porque acha mais fácil enganar os auditores do que efetuar as práticas recomendadas; porque você prefere pagar alguns milhares de reais em caixinhas milagrosas para segurança a realmente implementar medidas que eduquem seus profissionais e colaboradores.
Você vai ser ownado porque sua senha, além de ridiculamente previsível, é de conhecimento de todos os que te rodeiam; porque você olha para todos os lados ao atravessar uma rua, mas não consegue perceber que o email que te mandaram está incoerente demais para ter vindo de um banco, e que você nem ao menos uma conta nesse banco tem, e nem assim você deixa de clicar no link dele; você nunca falou de sua vida para estranhos, mas põe todos os detalhes de sua vida nas redes sociais e fica postando para todo mundo ler onde você está, onde você costuma frequentar ou onde você estuda, e é por isso que você vai ser ownado.
Você vai ser ownado porque você finge que cobra o que a sua área de Segurança de Informações determina, mas você nem ao menos acredita na maioria dos controles que lá estão; porque você nunca banca atrasos no desenvolvimento dos softwares quando sua equipe o testa e comprova que a maioria dos requisitos de Segurança de Informações não foram cumpridos; Não, o prazo tem que ser cumprido e, depois, quando der, a equipe ajusta o que tiver de ser ajustado. Você lê sobre como se proteger no trânsito e envia dicas de direção segura para seus amigos, mas acha que bom senso é o único ingrediente necessário para não ter um "problema digital" e por isso mesmo as palestras de conscientização só servem para outros, nunca para você; Por isso, você será ownado.
Você vai ser ownado porque suas máquinas recebem correções de segurança completamente fora do prazo avaliado, isso quando recebem, só porque você nunca acreditou nos impactos descritos nos alertas de segurança; Você acha que antivirus e IDS são mais do que suficientes para se proteger e dorme tranquilo depois de usar seu laptop que não foi hardenizado como os demais da empresa, já que você é um executivo importante e quer fazer o que bem entende na sua máquina; não se engane, você vai ser ownado durante o seu sono tranquilo. Vai ser ownado e exposto por ter desligado a criptografia e a autenticação de sua máquina, reclamando que colocar uma senha ou carregar um token é um grande exagero e sem nenhuma necessidade "de negócio".
Essa é apenas uma pequena e modesta lista de explicações dos resultados que virão. Talvez você, CIO ou CEO, leia isso aqui e se sensibilize; provavelmente e infelizmente, isso não ocorrerá.
É fato que na nossa cultura processos só melhoram depois que problemas acontecem; providências só são tomadas depois que "o leite é derramado". Por isso, lamentavelmente o recado "não seja ownado" só valerá para as próximas gerações. A geração atual de CIOs e CEOs talvez não queira ouvir, e essa geração de CSOs, a que está aí correndo e lutando para ser ouvida, vai ser retirada de cena depois do primeiro ataque com estragos consideráveis. Os responsáveis das áreas de Segurança de Informações serão demitidos, surgirão notas dizendo que nada aconteceu, a sujeira vai aos poucos ser varrida para baixo do tapete e a nova área provavelmente ganhará, enfim, mais atenção.
Talvez então, e só então, CIOs e CEOs escutem mais e façam o que deve ser feito para não serem ownados.
Até o próximo post !
terça-feira, 7 de junho de 2011
Boa Notícia 2
Mais uma boa notícia: O paper sobre o MUFFIN também foi aceito na Vale Security Conference, que vai acontecer em São José dos Campos, nos dias 3 e 4 de setembro no Parque Tecnológico de SJC.
O ValeSecConf traz um grupo de palestrantes de peso para essa primeira edição (e que também é a primeira conferencia desse porte na região). Teremos InfoSec, PenTesting, Vulnerabilidades, Direito Digital e Computação Forense. O trio da Bagunça Carioca, formado pelo Fernando Mercês, Nelson Brito e eu, estará reunido lá, novamente depois de ter detonado no WebSecForum. Apareça para um refrigerante (não consumo álcool, tenho esse defeito ... ;)
Abaixo, a lista completa dos palestrantes. Inscrições estão abertas !
O ValeSecConf traz um grupo de palestrantes de peso para essa primeira edição (e que também é a primeira conferencia desse porte na região). Teremos InfoSec, PenTesting, Vulnerabilidades, Direito Digital e Computação Forense. O trio da Bagunça Carioca, formado pelo Fernando Mercês, Nelson Brito e eu, estará reunido lá, novamente depois de ter detonado no WebSecForum. Apareça para um refrigerante (não consumo álcool, tenho esse defeito ... ;)
Abaixo, a lista completa dos palestrantes. Inscrições estão abertas !
segunda-feira, 6 de junho de 2011
Boa notícia 1
Boa notícia: O paper sobre o MUFFIN foi aceito na VI SegInfo, que vai acontecer no Rio de Janeiro, nos dias 12 e 13 de agosto no prédio da Bolsa de Valores do RJ.
O VI SegInfo vai contar com palestras bastante diversificadas. Além das palestras voltadas para InfoSec, teremos Direito Digital e Computação Forense (eu e meu camarada Sandro Suffert). Ótima oportunidade de aprender mais e encontrar bons amigos, agora na Cidade Maravilhosa. Além das palestras, haverá War Games e Treinamentos.
Abaixo, a lista completa dos palestrantes. Inscrições estão abertas !
O VI SegInfo vai contar com palestras bastante diversificadas. Além das palestras voltadas para InfoSec, teremos Direito Digital e Computação Forense (eu e meu camarada Sandro Suffert). Ótima oportunidade de aprender mais e encontrar bons amigos, agora na Cidade Maravilhosa. Além das palestras, haverá War Games e Treinamentos.
Abaixo, a lista completa dos palestrantes. Inscrições estão abertas !
Mini-currículo dos palestrantes da sexta edição do Evento
| |||
| Atua na área de TI a mais de 10 anos com experiência em segurança de redes e sistemas Unix, atualmente responsável pela segurança de servidores e sites em um datacenter, professor em cursos de pós-graduação em Segurança da Informação e atuando também como consultor independente especialista em segurança de perímetro e profundidade, segurança de sistemas Web, análise de vulnerabilidade, sistemas de prevenção e detecção de intrusão. | |||
Delegada da Delegacia de Repressão a Crimes de Informática da Polícia Civil do Estado do Rio de Janeiro | |||
| Delegada da Delegacia de Repressão aos Crimes de Informática (DRCI) da Polícia Civil do Rio, é bacharel em Direito pela PUC-RJ, pós-graduada em Direito Público e Privado pela Universidade Estácio de Sá e ex-aluna da Escola da Magistratura do Rio de Janeiro. | |||
Pesquisador Independente | |||
| - Graduado em Ciências da computação; - Pós-Graduado em Gestão Estratégica de Negócios, Inovação e Empreendedorismo, e Docência; - Consultor e Pesquisador na área de Segurança da Informação; - Docente na área de Tecnologia da Informação; - Membro do Grupo do Projeto GNSS no INPE (Instituto Nacional de Pesquisas Espaciais); - Chairman do Grupo Stay Safe (Podcast e Revista); - Diretor da CSA (Cloud Security Alliance) – Chapter Brasil; - Membro da Comissão de Crimes de Alta Tecnologia da OAB – SP. - Certified Ethical Hacker - Palestrante em eventos de segurança da informação | |||
Líder do Capítulo do OWASP em Brasília | |||
| É Mestre em Ciência da Computação pela Unicamp e tem mais de 15 anos de experiência na área de segurança da informação. Com experiência tanto na área pública quanto em empresas privadas, já atuou em projetos desde segurança de redes até gestão de segurança da informação. Nos últimos anos tem se interessado por temas ligados a segurança no desenvolvimento de software, o que levou ao seu envolvimento com o projeto OWASP, uma comunidade aberta focada em aumentar a segurança no desenvolvimento de sistemas. Atualmente é líder do Capítulo do OWASP em Brasília e membro de seu comitê global de conferências. | |||
| |||
| Nelson Brito is just another Security Researcher Enthusiast, who has an addiction of playing with computer systems’ (in)security and lives in a wonderful city: Rio de Janeiro. Besides, he has been a regular security conference speaker, such as: IME Cryptology Week (2000/2001), CNASI (2000/2004/2005), CONIP (2004), SERPRO TIC (2006), ITA SSI (2006), H2HC (2006/2009/2010), FEBRABAN CIAB Workshop (2009), Web Security Forum (2011), PH-Neutral (2011), etc. By the way, Nelson Brito is the author of: | |||
Sócio-Diretor técnico do Grupo Clavis Segurança da Informação | |||
| É Diretor Técnico do Grupo Clavis Segurança da Informação, e é profissional atuante nas áreas de análise forense computacional, detecção e resposta a incidentes de segurança, testes de invasão e auditorias de rede, sistemas e aplicações. Já prestou serviços e ministrou cursos e palestras sobre segurança da informação para grandes empresas nacionais, internacionais, órgãos públicos e militares, assim como em diversos eventos, entre eles: FISL – Fórum Internacional de Software Livre, EnCSIRTs – Encontro de CSIRTs Acadêmicos, SegInfo – Workshop de Segurança da Informação, Congresso Digital, Fórum de Software Livre do Rio de Janeiro, Web Security Forum, Ultra SL – Ultra Maratona How To de Software Livre, FLISOL, entre outros. Na Academia Clavis é instrutor dos seguintes cursos: Certified Ethical Hacker (CEH), Teste de Invasão em Redes e Sistemas, Auditoria de Segurança em Aplicações Web, Análise Forense Computacional, Teste de Invasão em Redes e Sistemas EAD, Auditoria de Segurança em Aplicações Web EAD e Análise Forense Computacional EAD. Possui as certificações CEH (Certified Ethical Hacker) e SANS SSP-CNSA. Tem especial interesse nas seguintes áreas:
| |||
Diretor-geral do Departamento de Segurança da Informação e Comunicações (DSIC) do Gabinete de Segurança Institucional (GSI) da Presidência da República | |||
| Diretor-geral do Departamento de Segurança da Informação e Comunicações (DSIC) do Gabinete de Segurança Institucional (GSI) da Presidência da República. Formado em Matemática, completou sua formação com diversos cursos de especialização no Brasil e no exterior. Com mais de 30 anos de experiência ocupando diversos cargos técnicos e diretivos, Mandarino hoje comanda o órgão do Governo Federal responsável por Segurança da Informação, além de coordenar o Comitê Gestor da Segurança da Informação, órgão do Conselho de Defesa Nacional, e participar como membro do Comitê Gestor da Infra-Estrutura de Chaves Públicas do Brasil. | |||
CEO da Opice Blum Advogados Associados | |||
| - Advogado e economista; - Coordenador do curso de MBA em Direito Eletrônico da Escola Paulista de Direito; - Professor da Fundação Getúlio Vargas, USP (PECE), Universidade Presbiteriana Mackenzie; - Professor colaborador da parceria ITA-Stefanini; - Árbitro da FGV e da Câmara de Mediação e Arbitragem de São Paulo (FIESP); - Presidente do Conselho Superior de Tecnologia da Informação da Federação do Comércio/SP e do Comitê de Direito da Tecnologia da AMCHAM; - Membro da Comissão de Direito da Sociedade da Informação – OAB/SP; - Ex-Vice-Presidente do Comitê sobre Crimes Eletrônicos – OAB/SP; - Conselheiro da Comissão de Crimes de Alta Tecnologia – OAB/SP - Palestras Internacionais: Global Privacy Summit 2010 (International Association of Privacy Professionals), Washington, DC, USA; 73ª Conferência da International Law Association; ISSA International Conference 2010 – Connect & Collaborate – (Information Systems Security Association), Atlanta, GA, USA; HTCIA International Conference 2010 (High Technology Crime Investigation Association), Atlanta, GA, USA; Inter American Bar Association: Reunión del Consejo y Seminario 2010 (Contratos Modernos de Cara a las Nuevas Relaciones Comerciales), São José, Costa Rica; Participante Convidado no The Sedona Conference 2010, Washington, DC, USA - Coordenador e co-autor do livro “Manual de Direito Eletrônico e Internet”; - Sócio – CEO do Opice Blum Advogados www.opiceblum.com.br Currículo Plataforma Lattes: http://lattes.cnpq.br/0816796365650938 | |||
Director of Vulnerability & Malware Research, Qualys | |||
| Is the founder of the Dissect || PE Project, funded by Qualys. As the Chief Security Research in Check Point he founded the Vulnerability Discovery Team (VDT) and released dozens of vulnerabilities in many important software. Previous to that, he worked as Senior Vulnerability Researcher in Coseinc. He is a member of the RISE Security Group and is the organizer of Hackers to Hackers Conference (H2HC), the oldest and biggest security research conference in Latin America. | |||
CTO da Techbiz Forense Digital | |||
| - Chief Technology Officer (CTO) da Techbiz Forense Digital (3 anos) - Professor convidado do Mestrado em Informática Forense do Departamento de Engenharia Elétrica e Polícia Federal/ Universidade de Brasilia (1 ano) - Membro da ABNT, Comitê CB21/CE27 (Grupos de Trabalho de Resposta a Incidentes e Forense Computacional) (1 ano) - Membro da High Technology Crime Investigation Association – HTCIA, capítulo Mid-Atlantic/NY – (6 anos) - Consultor Externo de Segurança do Banco do Brasil S.A. (10 anos) - Blogueiro em http://blog.suffert.com (3 anos) - Ex-Coordenador do Grupo de Resposta a Incidentes de Segurança da Brasil Telecom (5 anos) - Ex-Professor do Curso de Pós-Graduação (MBA) em Crimes Digitais da Faculdade UPIS. (1 ano) | |||
| |||
| - Professor universitário na Universidade Bandeirantes – UNIBAN - Consultor em segurança da informação com palestras de conscientização e treinamentos de segurança em diversas empresas - Palestrante em diversos eventos nacionais - Membro diretor da Hackers Construindo Futuros – HCF Brasil - Membro da Cloud Computing Security Alliance – CSA Brasil - Membro da comissão de crimes digitais da OAB-SP | |||
| |||
| É um profissional certificado CISSP, CFCP, Security+, ACFCP e MCSD com mais de 20 anos de experiência em TI e 8 anos em Gestão de Segurança de Informações, tendo liderado várias investigações, perícias e pesquisas sobre Computação Forense. Tony é consultor em Segurança de Informações, membro da Comissão de Crimes de Alta Tecnologia da OAB-SP e já palestrou em importantes conferencias internacionais (YSTS, H2HC, WebSecForum, OWASP, CNASI). Criou o primeiro treinamento em Computação Forense do Rio de Janeiro, formando peritos em várias organizações incluindo Polícia e Ministério Público. Tony é autor/criador do blog http://forcomp.blogspot.com, sobre Resposta a Incidentes e Forense Computacional, e também colabora com artigos no blog de Computer Forensics da SANS. |
domingo, 29 de maio de 2011
O Stuxnet e a responsabilidade civil
Neste que é o ultimo(?) post da série Stuxnet, quero colocar algumas indagações e duvidas de ordem jurídica. Sei que alguns leitores militam no Direito e poderão contribuir.
O Stuxnet, como foi veiculado e também comentamos ao longo dos posts, causou uma serie de estragos. Observando a linha do tempo de atuação dele, podemos perceber algumas coisas críticas envolvendo o processo de infecção dele:
- Os 0-day exploits usados;
- Os exploits que já possuíam correções;
- A senha hardcoded no WinCC/Step7;
Enquanto ter uma máquina explorada por um exploits cuja vulnerabilidade já foi corrigida é falha da equipe da empresa explorada, que não atualizou a máquina devidamente, os outros dois casos tem conotação diferente.
Na questão da senha hardcoded, não tenho a menor dúvida de que isso vai contra todas as boas práticas de segurança. Não importa quais controles compensatórios estejam atuando, existem inúmeros esquemas de segurança para evitar o hardcoded, que torna rapidamente o elo mais fraco e o primeiro a ser atacado. Que o diga o Stuxnet. Isso dito, e considerando que InfoSec nao deveria ser novidade para nenhuma empresa de porte da Siemens, minha pergunta é se caberia ação de reparação contra a Siemens, por danos causados pelo Stuxnet, considerando negligência a questão do hardcode da senha.
A parte do 0-day requer uma analise sob um outro ponto. A principal técnica de propagação, baseada em arquivos .lnk craftados, era um 0-day que tinha sido usado anteriormente. Há registros sobre o uso dessa mesma técnica em novembro de 2008, com uma variante do Trojan.Zlob. Ou seja, a técnica era já conhecida "in the wild" por 2 anos !!! O outro 0-day, explorando uma vulnerabilidade do Printer Spooler, foi comentado na edição de abril de 2009 da revista Hakin9 ! Nos dois casos, o fabricante do SO pode ter deixado os usuários na mão por muito tempo, e isso implicou a viabilidade da infecção das máquinas controladoras do PLC, e com isso, os $$$$ de prejuízo. Dai vem a pergunta número 2: caberia reparação contra o fabricante de SO, considerando negligência por não ter consertado em tempo razoável falhas graves divulgadas publicamente ?
Doutores e não doutores, comentem !
Até o próximo post !
O Stuxnet, como foi veiculado e também comentamos ao longo dos posts, causou uma serie de estragos. Observando a linha do tempo de atuação dele, podemos perceber algumas coisas críticas envolvendo o processo de infecção dele:
- Os 0-day exploits usados;
- Os exploits que já possuíam correções;
- A senha hardcoded no WinCC/Step7;
Enquanto ter uma máquina explorada por um exploits cuja vulnerabilidade já foi corrigida é falha da equipe da empresa explorada, que não atualizou a máquina devidamente, os outros dois casos tem conotação diferente.
Na questão da senha hardcoded, não tenho a menor dúvida de que isso vai contra todas as boas práticas de segurança. Não importa quais controles compensatórios estejam atuando, existem inúmeros esquemas de segurança para evitar o hardcoded, que torna rapidamente o elo mais fraco e o primeiro a ser atacado. Que o diga o Stuxnet. Isso dito, e considerando que InfoSec nao deveria ser novidade para nenhuma empresa de porte da Siemens, minha pergunta é se caberia ação de reparação contra a Siemens, por danos causados pelo Stuxnet, considerando negligência a questão do hardcode da senha.
A parte do 0-day requer uma analise sob um outro ponto. A principal técnica de propagação, baseada em arquivos .lnk craftados, era um 0-day que tinha sido usado anteriormente. Há registros sobre o uso dessa mesma técnica em novembro de 2008, com uma variante do Trojan.Zlob. Ou seja, a técnica era já conhecida "in the wild" por 2 anos !!! O outro 0-day, explorando uma vulnerabilidade do Printer Spooler, foi comentado na edição de abril de 2009 da revista Hakin9 ! Nos dois casos, o fabricante do SO pode ter deixado os usuários na mão por muito tempo, e isso implicou a viabilidade da infecção das máquinas controladoras do PLC, e com isso, os $$$$ de prejuízo. Dai vem a pergunta número 2: caberia reparação contra o fabricante de SO, considerando negligência por não ter consertado em tempo razoável falhas graves divulgadas publicamente ?
Doutores e não doutores, comentem !
Até o próximo post !
sexta-feira, 27 de maio de 2011
Stuxnet e seus estragos
Ainda na nossa serie de posts sobre o Stuxnet, gostaria de comentar e lançar uma discussão sobre o impacto desse malware.
Há algumas coisas que podem ser imediatamente apontadas como tendo impacto negativo, mas outras vieram por tabela e lançam aspectos obscuros no já tenebroso mundo cibernético que estamos vivendo.
O impacto real e mais aparente é, obviamente, o principal motivo pelo qual o malware foi escrito. Ele é uma arma cibernética de sabotagem. Ponto. Os estragos foram contabilizados e há vários gráficos e estudos por aí que mostram como foi impactante nas estruturas de diversos países, mas muito mais nas plantas atômicas iranianas. Alguns gráficos mostram perceptivelmente que o impacto no Irã foi mais do que o dobro do que o segundo mais afetado; em alguns aspectos, foi mais que três vezes pior, ou maior que a soma de todos os outros afetados.
Ok, mas que outros impactos nos trouxe o Stuxnet ?
Ele mudou o cenário de malware. Ao aplicar técnicas novas, rebuscadas e sincronizadas, ele pode ter lançado novas formas e métodos de ataque que em breve estarão disseminados e serão comuns nos malwares, e sem duvida essa nova situação vai requerer mais pesquisas e praticas investigativas diferenciadas. O mecanismo de injeção de código dele, por exemplo, é engenhoso e inovador.Ele também lançou nova onda nos conceitos de guerra cibernética.
Ate onde pude colher informações, nunca tinham usado malware com objetivos de sabotagem de infra-estrutura critica. Isso também com certeza vai cair no lugar comum e vai acontecer com mais freqüência. No ultimo Hackinthebox houve uma palestra indicando como malware pode causar danos físicos ao hardware do computador, fazendo com PCs o que o Stuxnet fez com as centrifugas. A bem da verdade, isso não é nada novo. No inicio dos anos 90, a onda era criar malware que danificava a trilha 0 do disco, detonando-o. Também me lembro de algumas rotinas em assembly cujo objetivo era danificar o monitor, colocando parâmetros incompatíveis nele. Isso tinha parado, mas tudo indica que pode voltar.
Apesar de tudo, o maior impacto indireto das ações do Stuxnet não está no que comentei acima, mas no fato de que algumas das dlls do seu código estavam assinadas com certificados validos. O driver mrxnet.sys, parte do Stuxnet atuando como um rootkit, estava assinado digitalmente com um certificado válido da Realtek. Outros arquivos possuíam a mesma assinatura digital. Em meados de 2010, outros arquivos identificados como parte do código do Stuxnet estavam assinados digitalmente por um certificado válido da empresa JMicron Technology Corp. Vale notar que, fisicamente, ambas estão próximas e isso pode indicar que os certificados foram roubados por alguém com acesso físico às dependências das duas empresas. O quanto essa situação vai trazer de desconfiança nos esquemas de assinatura digital não sabemos ainda. É fato que a validade de todo o processo reside no fato de a chave privada estar muito bem guardada, e não acredito que esse tenha sido o único caso de comprometimento até hoje registrado. A famosa propriedade da assinatura digital conhecida como não-repúdio, onde o emissor não pode negar a autoria do que foi assinado, pode sair arranhada desse caso. Assim como a alegação de insanidade virou moda nos processos americanos e, nos meios digitais, o malware defense ("não fui eu quem fez isso, foi um vírus"), essa pode ser a próxima tese de defesa em documentos assinados digitalmente ("está assinado mas não fui eu, minha chave privada deve ter sido comprometida").
Pronto, mais um problema para resolver. Não devemos esquecer que já está acontecendo no Brasil o projeto da nova carteira de identidade, que já virá com chip e certificado, permitindo o uso em assinaturas digitais. Ahhh, mas tem a revogação do certificado, você pode dizer.
É verdade. O código Stuxnet com assinatura da Realtek foi identificado em 25 de Janeiro de 2010. O certificado foi revogado em 20 de julho. Tire suas conclusões ...
Comentários ?
Até o próximo post !
Há algumas coisas que podem ser imediatamente apontadas como tendo impacto negativo, mas outras vieram por tabela e lançam aspectos obscuros no já tenebroso mundo cibernético que estamos vivendo.
O impacto real e mais aparente é, obviamente, o principal motivo pelo qual o malware foi escrito. Ele é uma arma cibernética de sabotagem. Ponto. Os estragos foram contabilizados e há vários gráficos e estudos por aí que mostram como foi impactante nas estruturas de diversos países, mas muito mais nas plantas atômicas iranianas. Alguns gráficos mostram perceptivelmente que o impacto no Irã foi mais do que o dobro do que o segundo mais afetado; em alguns aspectos, foi mais que três vezes pior, ou maior que a soma de todos os outros afetados.
Ok, mas que outros impactos nos trouxe o Stuxnet ?
Ele mudou o cenário de malware. Ao aplicar técnicas novas, rebuscadas e sincronizadas, ele pode ter lançado novas formas e métodos de ataque que em breve estarão disseminados e serão comuns nos malwares, e sem duvida essa nova situação vai requerer mais pesquisas e praticas investigativas diferenciadas. O mecanismo de injeção de código dele, por exemplo, é engenhoso e inovador.Ele também lançou nova onda nos conceitos de guerra cibernética.
Ate onde pude colher informações, nunca tinham usado malware com objetivos de sabotagem de infra-estrutura critica. Isso também com certeza vai cair no lugar comum e vai acontecer com mais freqüência. No ultimo Hackinthebox houve uma palestra indicando como malware pode causar danos físicos ao hardware do computador, fazendo com PCs o que o Stuxnet fez com as centrifugas. A bem da verdade, isso não é nada novo. No inicio dos anos 90, a onda era criar malware que danificava a trilha 0 do disco, detonando-o. Também me lembro de algumas rotinas em assembly cujo objetivo era danificar o monitor, colocando parâmetros incompatíveis nele. Isso tinha parado, mas tudo indica que pode voltar.
Apesar de tudo, o maior impacto indireto das ações do Stuxnet não está no que comentei acima, mas no fato de que algumas das dlls do seu código estavam assinadas com certificados validos. O driver mrxnet.sys, parte do Stuxnet atuando como um rootkit, estava assinado digitalmente com um certificado válido da Realtek. Outros arquivos possuíam a mesma assinatura digital. Em meados de 2010, outros arquivos identificados como parte do código do Stuxnet estavam assinados digitalmente por um certificado válido da empresa JMicron Technology Corp. Vale notar que, fisicamente, ambas estão próximas e isso pode indicar que os certificados foram roubados por alguém com acesso físico às dependências das duas empresas. O quanto essa situação vai trazer de desconfiança nos esquemas de assinatura digital não sabemos ainda. É fato que a validade de todo o processo reside no fato de a chave privada estar muito bem guardada, e não acredito que esse tenha sido o único caso de comprometimento até hoje registrado. A famosa propriedade da assinatura digital conhecida como não-repúdio, onde o emissor não pode negar a autoria do que foi assinado, pode sair arranhada desse caso. Assim como a alegação de insanidade virou moda nos processos americanos e, nos meios digitais, o malware defense ("não fui eu quem fez isso, foi um vírus"), essa pode ser a próxima tese de defesa em documentos assinados digitalmente ("está assinado mas não fui eu, minha chave privada deve ter sido comprometida").
Pronto, mais um problema para resolver. Não devemos esquecer que já está acontecendo no Brasil o projeto da nova carteira de identidade, que já virá com chip e certificado, permitindo o uso em assinaturas digitais. Ahhh, mas tem a revogação do certificado, você pode dizer.
É verdade. O código Stuxnet com assinatura da Realtek foi identificado em 25 de Janeiro de 2010. O certificado foi revogado em 20 de julho. Tire suas conclusões ...
Comentários ?
Até o próximo post !
Assinar:
Postagens (Atom)