Veja sua colocação no concurso CESPE/Câmara dos Deputados 2012

Caro Concurseiro,

Em homenagem aos milhares de brasileiros e brasileiras que estão esperando ansiosamente pelo resultado do concurso da Câmara dos Deputados, preparei essa pequena calculadora estatística que usa os dados (desvio padrão e média) do ranking SuperConcurseiros.com.br para estimar a colocação geral no concurso com base na pontuação do candidato e nos 26902 inscritos menos as prováveis abstenções.

Lembre que essa amostragem estatística do Super Concurseiros não é muito representativa, pois em geral são os melhores concurseiros que colocam suas notas nesses rankings, sem falar na falta de aleatoriedade. Portanto, não se grile muito se a sua colocação na calculadora não for boa, pois, provavelmente, a média real será mais baixa e o desvio padrão será outro fazendo sua colocação real ser bem melhor.

Se você quiser, também é possível fazer prognósticos com a calculadora, mudando-se a média, desvio padrão e o percentual de abstenção do concurso. Assim, você poderá “chutar” possíveis cenários com mais rigor estatístico,

Divirta-se e veja sua provável colocação abaixo:

Publicado em Outros | 3 Comentários

Nova Lei de Crimes Cibernéticos não puniria os transgressores do caso Carolina Dieckmann

Em maio deste ano, discutimos aqui no blog o Projeto de Lei 2793 de 2011 (PL2793/2011), conhecido como Lei de Crimes Cibernéticos. A discussão se pautou na ponderação a respeito de certas proibições trazidas pela lei que teriam impacto negativo na ciência e tecnologia nacionais. O objetivo deste artigo é continuar com  a série de críticas, desta vez questionando a urgência que tem se dado à tramitação deste projeto.

Existe em tramitação no Senado Federal o projeto do Novo Código Penal que, dentre outras inovações, cuida também de crimes cibernéticos de forma que a matéria tratada pelo PL2793 tornar-se-ía obsoleta depois de aprovado o novo código. Contudo, mesmo diante de duras críticas feitas por alguns senadores pela incomum pressa dada a tramitação do PL e por este ter matéria conicidente com a reforma do código penal, a tramitação seguiu adiante. A grande justificativa para tanto é que o novo código penal demoraria muito para ser aprovado e que a sociedade precisa com urgência de uma lei de crimes cibernéticos, tendo como caso exemplar dessa necesidade, a violação da intimidade da atriz Carolina Dieckmann. Vamos entender melhor essa urgência.

Como todos sabem, o legislativo passou mais de uma década discutindo o “Projeto de Lei Azeredo” que versava, dentre outras coisas, sobre os crimes de informátca. Contudo, essa morosidade legislativa foi trocada, como num passe de mágica,  pela pressa descabida, logo depois do início de um clamor midiático causadado pela publicação de fotos íntimas da atriz Carolina Dieckmann. Esse tema ganhou tanto destaque que até foi tratado aqui no blog e em vários outros lugares. A correlação entre o PL e o caso da atriz foi tão contundente que até chegou a ensejar o apelido “Lei Dieckmann”, que foi dado ao PL em tom humorístico. Ora, não me sinto à vontade com o fato de que uma única pessoa tenha tamanha influência sobre o Poder Legislativo de nosso país, mas se pelo menos a lei pudesse proteger as vítimas que, como a atriz, tiveram a sua intimidade violada no âmbito informático, já existiria algum ganho. Contudo, a pressa é realmente inimiga da perfeição, especialmente nesse caso.

Apesar de todos os esforços do legislativo para contemporizar com o clamor público obtido pela atriz e seu advogado, o PL2793, nova proposta de tipificação de crimes cibernéticos, sequer serviria para por na cadeia os malfeitores no caso de Carolina Dieckmann. É isso mesmo! Apesar de eu não ser jurista,  fica evidente que a conduta realizada por estes indivíduos não se enquadra no novo tipo penal definido pelo PL. Não acredita? Vejamos o trecho do PL, já com as modificações trazidas pelo senado:

Art. 154-A. Invadir dispositivo informático alheio, conectado ou não a rede de computadores, mediante violação indevida de mecanismo de segurança e com o fim de obter, adulterar ou destruir dados ou informações sem autorização expressa ou tácita do titular do dispositivo ou instalar vulnerabilidades:
Pena – detenção, de 3 (três) meses a 1 (um) ano, e multa.

Quem não lembra como se sucedeu o o caso, sugiro uma breve lida em meu artigo ‘A verdade sobre as “Técnicas de Invasão” usadas no caso Carolina Dieckmann’. Lá, descrevo que, na verdade, não houve sequer invasão nenhuma. O que realmente houve foi o envio de uma mensagem de email falsa para a atriz, alegando ser originada do provedor de internet dela. A mesagem pedia vários dados cadastrais de Carolina, inclusive a senha do correio eletrônico, sob o pretexto de melhrorar a segurança. Talvez por ingenuidade, Carolina informou todos os dados solicitados. Como a mensagem era falsa, a resposta de Carolina foi destinada ao malfeitor, que se valeu da senha da atriz para adentrar sua conta de email e copiar as fotos íntimas. Veja bem, Carolina cedeu, por vontade e consciência (ainda que mediante engodo), sua senha de email, que foi usada como deveria ser, para acessar as mensagens. Não houve servidor invadido, criptografia quebrada, tráfego interceptado, infecção por código malicioso ou nada desse tipo. Assim, não houve neste caso nenhuma “violação indevida de mecanismo de segurança” nem sequer “invasão de dispositivo informático alheio”.  O atacante apenas utilizou a senha, dada por Carolina, como de praxe.

Para compreender melhor, o direito penal brasileiro se orienta pelo princípio da estrita legalidade, o que significa que, para definirmos algo como crime, não podemos sequer fazer analogia, sendo a letra da lei definidora da conduta criminosa. Ou seja, se não está expresso claramente na lei, não é crime.  Assim, o que podemos concluir quando analisamos a conduta praticada contra Carolina frente ao tipo penal trazido pelo PL2793 é que, se dependesse apenas dele, não haveria crime nenhum nesse caso. Felizmente, a conduta em questão assemelha-se ao tipo penal de estelionato, o famoso “171” de nosso código penal, uma lei que já existe e é bem mais rigorosa que o PL de crimes cibernéticos. Veja:

Art. 171 – Obter, para si ou para outrem, vantagem ilícita, em prejuízo alheio, induzindo ou mantendo alguém em erro, mediante artifício, ardil, ou qualquer outro meio fraudulento:

Pena – reclusão, de um a cinco anos, e multa.

No caso Dieckmann, o atacante realizou o que conhecemos em segurança por phishing, que é a fraude eletrônica, geralmente feita por email, onde o fraudador se faz passar por alguma organização de conhecimento da vítima (banco, provedor, etc) com objetivo de obter indevidamente seus dados pessoais. Isso é a própria personificação do que está definido no tipo penal de estelionato já que o atacante: 1) usou de ardil (um email fraudulento) para manter em erro (Carolina pensava tratar-se do provedor) com vantagem ilícita (obtenção de dados pessoais) em prejuízo alheio (intimidade violada). Haveria ainda uma discussão de que a vantagem ilícita deveria ser de cunho patrimonial e a mera violação moral não seria suficiente para configurar o tipo, mas isso já é outra estória. A questão aqui é apenas uma: a nova lei trazida pelo PL de crimes cibernéticos não puniria ninguém no caso da Carolina Dieckmann.

Tudo isso nos leva a questionar se, de fato, o PL2793/11 merece tanta urgência assim. Principalmente porque essa urgência tem sido usada como pretexto para não envolver ativamente nas discussões do projeto, os setores da sociedade interessados, como, por exemplo, os profissionais da segurança da informação, da forma democrática que outros projetos exemplarmente fizeram (vide o Marco Civil da Internet). Qual a desculpa agora?

 

Publicado em Outros | Com a tag , , , , , , , , | 5 Comentários

Security Problem with Google’s 2-Step Authentication

Hi Folks,

A couple of months ago I tried to get one of my findings accepted to Google’s Security Reward program. This is my second try, my first one was accepted, but this time they found the report wasn’t eligible. Since the reward is off the table I am free to discuss my observations publicly and I feel more people should be aware of the issue.  So, let’s go.

Below there’s a copy of the conversation I had with Google regarding the flaw I pointed out. To sum it up, it’s about their 2-step authentication (aka OTP) scheme. They have implemented a design option that yields some security issues, some of with I have pointed out in my communications with Google.
I found out they have a time window of 10 minutes in which any of the 20 OTP passwords are valid. They do this in order to better assist users with out of sync (aka. late) watches. This means that, if you have a very precise watch, it’s likely that you will have 10 minutes before your generated OTP password gets invalidated. Also, whenever you enter a valid OTP password, the time window before it  gets invalidated altogether. This is done to avoid interception, in the sense that if you have been able to login, all past OTP passwords that were generated before the one you have just used are deemed useless in case they are intercepted by an attack. This protects you well unless the attacker can intercept OTP passwords in the future, which is impossible, or is it? As a correction, I have suggested invalidating all the time window (all the 20 OTPs), or at least they could synchronize accounts.google.com’s watch with the user’s at some point, like some banks do.

I’ve prepared a very simple PoC for Firefox to exemplify my point: http://ximen.es/gmail/

Google stated they think they have the right balance between security and usability, which I disagree. So, the PoC should be still working (since they haven’t change anything). In order to understand the PoC better, please refer to the contents of the conversation below.

Thanks,

Pablo Ximenes

 

CONVERSATION:

Vulnerability Report – Applying for Reward – 2-Step Authentication in accounts.google.com

Pablo Ximenes

Jun 5

to Google
Dear Google Security Team,I have stumbled on a vulnerability that can circumvent the Two-Way Authentication scheme used in accounts.google.com.As I am aware of, the mechanism is intended to give users the easy of mind, while authenticating themselves, that:1) If an attacker intercepts my password (using MITM, for instance) he will still be unable to login to my account, because he doesn´t own my 2-step auth token.
2) If the attacker captures my OTP, he will be unable to use it because whenever I use an OTP in asuccessfull login attempt, the OTP automatically invalidates itself (avoiding replay).
3) If an attacker pretends I entered the wrong OTP (again using MITM) and gives me an error message so I enter a second OTP so the first OTP, acquired by attacker, remains unused, I still can rely on the fact that by using the latest issued OTP,  all other issued OTPs will automatically be invalidated. This way the attacker will remain with an invalid OTP.
4) etcWell, though an informal investigation I was able to determine that your policy for timeframing the accepted OTPs is 10 minutes. This means that I issue an OTP, using a accurate watch, I have up to 10 minutes to use it before it becomes invalid. I can only imagine this policy is intended as a solution for late and advanced watches that are out of sync with precise atomic time.The problem with this policy is that by allowing the system to accept OTPs in the “future” (or in the past, depending on the reference point), the system creates an attack vector that can be used by malicious users.  Using any form of MITM, an attacker could intercept the user´s authentication request, capturing both password and OTP and issue an error mesage to the user saying the OTP is wrong. The user will enter a second attempt OTP. Instead of using the second attempt OTYP, the attacker will store the second attempt OTP and continue with user authentication through the firtly entered OTP. This will leave the attacker with an unsed OTP that is good for up to aproximately 9 minutes. This will break the premisse number 3 from the list I cited in the begining of this report and if applyied more than once in a roll, will give the attacker two valid OTPs that could be used to completely deactivate 2-Step verification in the victim´s account. I consider it severe.

I have taken the liberty of assembling a modest PoC in http://ximen.es/gmail that examplifies this problem. (please bear in mind that this example could be vastly improved if it were to be weaponized)

If the PoC isn´t clear enough, I am available for answering any questions.

A solution to this isssue would be changing the current policy for accepting OTPs. Instead of invalidating only OTPs that are timed before the one that was used, it would be a good practice to invalidade all the time frame, meaning all OTPs before + All OTPs in the next X minutes, where X would be 10 minutes for maximum security (as your timeframe is 10 minutes). X could be lower, but a save value is yet to be found. You guys could balance security and usability to find it.
Another simpler solution that would counter only the particular way to use MITM in my PoC (that uses Michal´s approache) is to extend the use of GALX cookie (together with GALX POST form variable) to https://accounts.google.com/SmsAuth as well (the page users enter their OTP).

So, I leave it to the judges to give me feedback on this. I supose this should be considered an authentication bypass vulnerability on accounts.google.com with regards to the Vulnerability Rewards Program, but I will wait for your feedback.

Thanks in advance for your consideration,

Pablo Ximenes

Google Security security@google.com

Jun 5

to me
Thanks for contacting Google’s security team. This is an automatic response to let you know that we’ve received your message. If you’ve identified a security vulnerability within any of Google’s services, systems, or networks, we’ll investigate as soon as possible and follow up with you shortly.If you aren’t reporting an application security vulnerability, you won’t receive a response and we’ll be unable to take action on your message. Here’s a few links that will hopefully help you find a solution to your issue:* For Android security issues, please contact security@android.com or visit http://developer.android.com/resources/faq/security.html#issue
* For Chrome security issues, please visit http://dev.chromium.org/Home/chromium-security/reporting-security-bugs
* For account hijackings, please go here (http://goo.gl/E3Ii3) for Youtube, and here  (http://goo.gl/Jb3at) for Google Accounts (including Gmail).
* Other problems with account security in Gmail (http://goo.gl/Jcac), Youtube (http://goo.gl/iIKAe) or Checkout (http://goo.gl/GPehn).
* Requests to remove content in Search (http://goo.gl/nhm6R), Streetview (http://goo.gl/JWwp), Maps (http://goo.gl/zys9l), Youtube (http://goo.gl/RuuQF), Orkut (http://goo.gl/YVAUU), Blogger (http://goo.gl/bBHrD), or any other product (http://www.google.com/security.html).
* Report malware (http://goo.gl/dR12) or phishing (http://goo.gl/6Q9Y) sites, or inappropriate or malicious advertisements (http://goo.gl/PKpIu).
* Scams, including fake lotteries and job offers (http://goo.gl/OhRr).
* You’ve received someone else’s email (http://goo.gl/GeCe).For anything else, please check the Google Support (http://www.google.com/support/) page.Regards,
The Google Team
Pablo Ximenes

Jun 5

to Google

I forgot to mention, the PoC was designed for firefox.

It might work on other browsers, but almost certain not chrome.

Regards,

Pablo
Em 05/06/2012 13:56, “Pablo Ximenes” <pablo@ximen.es> escreveu:

>
> Dear Google Security Team,
>
>
> I have stumbled on a vulnerability that can circumvent the Two-Way Authentication scheme used in accounts.google.com.
>
> As I am aware of, the mechanism is intended to give users the easy of mind, while authenticating themselves, that:
>
> 1) If an attacker intercepts my password (using MITM, for instance) he will still be unable to login to my account, because he doesn´t own my 2-step auth token.
> 2) If the attacker captures my OTP, he will be unable to use it because whenever I use an OTP in asuccessfull login attempt, the OTP automatically invalidates itself (avoiding replay).
> 3) If an attacker pretends I entered the wrong OTP (again using MITM) and gives me an error message so I enter a second OTP so the first OTP, acquired by attacker, remains unused, I still can rely on the fact that by using the latest issued OTP,  all other issued OTPs will automatically be invalidated. This way the attacker will remain with an invalid OTP.
> 4) etc
>
>

> Well, though an informal investigation I was able to determine that your policy for timeframing the accepted OTPs is 10 minutes. This means that if I issue an OTP, using a accurate watch, I have up to 10 minutes to use it before it becomes invalid. I can only imagine this policy is intended as a solution for late and advanced watches that are out of sync with precise atomic time.

Pablo Ximenes

Jun 6

to adammein, Google

Dear Adam,

Sorry to disturb you with this, but I haven’t heard anything as feedback to my report yet and Its been almost 24 hours (which is kindda long compared to my previois experience). Is there any problem?

I am very sorry If crossed any lines with this email.

Thanks for everything,

Pablo

Em 05/06/2012 18:53, “Pablo Ximenes” <pablo@ximen.es> escreveu:

Google Security Team security@google.com

Jun 6

to me, adammein
Hey Pablo,We got this and are looking into it! Sorry for the delay but we will get
back to you shortly!Regards,
KevinOriginal Message Follows:
————————
From: Pablo Ximenes <pablo@ximen.es>
Subject: Re: Vulnerability Report – Applying for Reward – 2-Step
Authentication in accounts.google.com
Date: Wed, 6 Jun 2012 12:36:12 -0300

Google Security Team security@google.com

Jun 7

to me, adammein
Ok Pablo,I investigated this and you are correct RE: the 10 minute window. I would
however term your attack as phishing rather them MITM as you are not
intercepting requests between the client and the legitimate server. I
would not consider this a security risk although I do appreciate you
bringing it up. It is something that we were aware of already and was a
design decision for reasons I can’t get into.

Regards,
KevinOriginal Message Follows:
————————

From: “Google Security Team” <security@google.com>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step  Authentication in accounts.google.com
Date: Wed, 06 Jun 2012 18:31:05 -0000

Pablo Ximenes

Jun 7

to Google, adammein

Thanks for replying.

Phishig was only a way I used to implement some sort of request interception (aka MITM) in order to exemplify the vector. Any form of MITM would do: malware on the victms pc, dns hijacking, etc. I myself used Michals switching example.

Any way, my point of view is that there’s a correctable flaw. Maybe you were aware.of the design, but not of the security problem it causes. Adittionally, I proposed a viable solution which is to invalidate all the 20 (10 minutes times 2) OTPs after a successful login attempt instead of invalidating only the the OTP used to authenticate and the ones timed before it. That would require little effort, Id assume. I read somewhere that if you as little as open a bug request based on anything.from the report, the.reporter is at least credited in the HoF. Since there’s no mention of that from your part I’d assume you.dont.plan to change anything with regards to my report.

Well, since the reward is off the table, can I at least blog about it?

PS: Sorry for the typos, Im using a tablet. Android. 🙂

Em 07/06/2012 18:42, “Google Security Team” <security@google.com> escreveu:

Pablo Ximenes

Jun 7

to Google, adammein

PS: BTW, The OTP scheme is known as a way to counter exactly these kind of phishing attacks you saw on my example. “Dont worry so much about phishing, cause they can get your passwotd, but they will never get a usable OTP if you were able to login to your account.”

Timing is one big problem for offline token based OTP schemes, and Google’s solution to that causes a serious security problem.

Em 07/06/2012 19:28, “Pablo Ximenes” <pablo@ximen.es> escreveu:

Google Security Team security@google.com

Jun 8

to me, adammein
Pablo,Thank you for your note, I appreciate your concerns however we feel we
have the right balance between security and usability, unfortunately this
issue is not eligible for the VRP.

Regards,
Kevin

Original Message Follows:
————————

From: Pablo Ximenes <pablo@ximen.es>

Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step
Authentication in accounts.google.com

Date: Thu, 7 Jun 2012 19:56:56 -0300

Pablo Ximenes

Jun 8

to Google

Ok, I got that. I wanna know about me.bloging about it. 🙂

Is that OK?

Em 08/06/2012 14:17, “Google Security Team” <security@google.com> escreveu:

Google Security Team security@google.com

Jun 8

to me

Sure, it’s a free world (ideally anyway) please feel free to publish
whatever you like.

Regards,
Kevin
Original Message Follows:
————————
From: Pablo Ximenes <pablo@ximen.es>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step
Authentication in accounts.google.com

Date: Fri, 8 Jun 2012 14:18:54 -0300

 

Publicado em Security | 4 Comentários

Lei de crimes cibernéticos (PL2793/2011) precisa ser melhorada sob pena de prejudicar nossa defesa nacional.

O Projeto de Lei 2793 de 2011 (PL2793/2011), conhecido como Lei de Crimes Cibernéticos (ou de forma mais jocosa, Lei Dieckmann), em seu art. 2o., especificamente na porção que institui o novo tipo penal de invasão de computadores, através da adição a nosso código penal do Art. 154A e atravé dele criminaliza também a produção, difusão, venda e criação de programas de computador usados como ferramentas de ataque cibernético.  Vejamos a íntegra do disposito para melhor compreensão:

Art. 154-A. Devassar dispositivo informático alheio, conectado ou não a rede de computadores, mediante violação indevida de mecanismo de segurança e com o fim de obter, adulterar ou destruir dados ou informações sem autorização expressa ou tácita do titular do dispositivo, instalar vulnerabilidades ou obter vantagem ilícita:
Pena – detenção, de 3 (três) meses a 1 (um) ano, e multa.
§ 1º Na mesma pena incorre quem produz, oferece, distribui, vende ou difunde programa de computador com o intuito de permitir a prática da conduta definida no caput.

Inicialmente, vamos analisar a interpretação mais abrangente, onde a lei criminalizaria o uso qualquer ferramenta informática com o mero feito de esta ser usada em um ataque cibernético de invasão de computadores.  Tal interpretação é imprópria. É o mesmo que criminalizar o a Tramontina pode ter uma de suas facas usada em um assassinato. Imaginem um ataque que se vale de Windows XP como instrumento (o terminal de ataque, por exemplo): representantes da microsoft, distribuidores de licensas, professores de cursos de informática iriam para a cadeia? Imagino que essa interpretação extrema não se sustente e sucumba ao bom senso do judiciário, contudo com bem menos espaço interpretativo as autoridades já fizeram atrocidades em nosso país fazendo parecer que nosso judiciário se preocupa mais com a legalidade do que com a justiça.

Vamos à outra interpretação, que é a mais relevante à nossa discussão e que diz respeito a ferramentas de (in)segurança, aquelas que são usadas especificamente em ações de quebra de segurança.

Em primeiro lugar, grande parte de tais ferramentas não possuem propósito único. Podem ser usadas com diversos intuitos, fato que remonta ao argumento anterior. Por exemplo, uma ferramena de análise de tráfego do tipo sniffer pode ser usada tando para diagnosticar uma rede como para capturar senhas que trafegam sem criptografia. Em segundo lugar, mesmo as ferramentas que tenham sido especificamente criadas com o intuito de quebrar a segurança não podem deixar de existir livremente em nosso meio. Elas são muito importantes para a ciência e tecnologia de um país.

É imperativo conhecer as técnicas de ataque, com exemplos, provas de conceito, implementações práticas, discussões abertas, cursos, etc, para que sejamos capazes de, no mínimo, nos defender. Isso é uma máxima comum no meio da segurança da informação. Por exemplo, vários artigos são escritos demonstrando como um determinado protocolo de criptografia (ou sua implentação) é falho, muitos deles publicam programa exemplo que demonstra a falha. Com o desenrolar desta lei, inibiremos a atividade de muitos profissionais que é vital para a segurança da informação. A principal estratégia de prova de uma fragilidade de segurança é a criação de software que demonstra a sua quebra. Difundir essas ferramentas, com demonstrações práticas é o passo inicial reforçar a segurança de muitos sistemas. Em um exemplo pessoal, cito o início de meus estudos na antiga Escola Técnica Federal do Ceara (hoje IFCE). Logo no primeiro semestre peguei emprestado da biblioteca o livro entitulado “Vírus de Computador”. Era u livro com instruções de como desenhar estes estes prograsm e incluía, dentre ostras coisas, códigos fontes de vírus em várias linguagens. Minha curiosidade me fez estudar o livro com afinco, e este estudo foi uma das bases para o que o hoje conheço de segurança da informação. Um livro como esse seria classificado, no mínimo, como “difundir” (pois passava adiante a idéia) e “distribuir” (pois o livro possuía códigos fontes) programa de computador que permite a invasão de dispositivo informático. Este livro seria literalmente censurado e eu provavelmente não teria inciado meus estudos sobre softwares maliciosos. Imagine isso amplificado para toda a sociedade e para qualquer software que verse sobre insegurança de computadores.

Permitir a livre distribuição, criação,difusão e até venda é permitir que o conhecimento nessa área se difunda, cresça e se solidifique. Naõ vejo a CENSURA AO CONHECIMENTO como mecanismo eficaz de proteção social, pelo contrário (vide a ditadura militar). Não poderíamos ter mais CURSOS de metasploit, por exemplo, pois seria difusão de ferramenta usada com intuito de devassar computadores.

E agora o ponto que quebra por completo a linha de raciocício do PL: os principais KITs de software usados por criminosos não são adquiridos no Brasil, mas no exterior, muitos deles da Rússia. Vide o mais recente deles, o RedKit, que é extremamente fácil de usar e serve para criar e gerir botnets. Ou seja, essa proibição nem de perto dificultaria os principais esquemas criminosos que se valem de tais ferramentas. Em outras palavras, não traria nenhum benefício para nossa nação, deixando a lei inóqua.

Contudo, Criar essa proibição no Brasil é dilacerar a ciência e tecnologia na área da segurança da informação. Isso nos deixará, como País, órfãos, capengas em uma área estratégica para a segurança nacional. É importante entender que CiberGuerra saiu do campo da ficção e é de fato realidade. Vide o caso americano que recentemente estampou o prestigioso New York Times, onde uma ordem secreta do presidente Barack Obama fez dos EUA o principal criador do famigerado StuxNet, malware (um tipo de vírus de computador) desenhado como arma cibernética para desativar a planta nuclear Iraniana, mas que acabou invadindo computadores civis de todo o mundo. Não podemos ficar atrás. Temos muita gente talentosa que não pode ficar refém de uma lei, que apesar de bem intencionado, trará muitos prejuízos.

Fizeram algo semelhante na alemanha, em 2007, o que foi criticado internacionalmente. E olhe que o regime jurídico alemão permite uma maior liberdade na interpretação das leis que o regime Brasileiro. Na Alemanha, o texto de justificativa dos projetos de lei é sempre levado em conta pelos juízes na hora de proferir suas sentenças. No Brasil, apesar da doutrina da “intenção do legislador”, somos muito atrelados à exclusividade do texto legal, especialmente em matérias penais.

As profissões na área da Computação não são regulamentadas e isso trouxe inúmeras vantagens para nosso país em termos de crescimento tecnológico e econômico, através da liberdade dada ao conhecimento. Querem agora regulamentar (através de uma proibição penal) todas as atividades relacionadas a um tipo específico de software, antes de sequer a profissão estar regulamentada! Como se isso fosse trazer mais segurança. Isso tratá mais INSEGURANÇA e invializará um segmento econômico fundamental para a segurança nacional.

Sou contra este dispositivo e convido todos que também o sejam a criar uma força de oposição e protesto contra ele.

Publicado em Outros | Com a tag , , , , | 5 Comentários

A verdade sobre as “Técnicas de Invasão” usadas no caso Carolina Dieckmann

Várias especulações tem sido feitas a respeito de como atuaram tecnicamente os malfeitores por detrás do vazamento de 36 fotos ímtimas da atriz Carolina Dieckmann. A maior parte delas se mostrou errada e vamos ver aqui que na verdade o que foi feito não requer nenhuma inteligẽncia acima da média nem nenhum requinte de informática.

Inicialmente, acreditava-se que os técnicos da assistência autorizada Apple, que tinham consertado o MacBook de Carolina, teriam copiado as fotos durante o procedimento. Depois de desbancar essa hipótese através de perícia na loja da autorizada, a polícia encontrou, possivelmente através de escuta telemática, uma declaração que apontava para uma possibilidade alternativa. Um dos suspeitos, Diego Fernando Cruz, teria dito em conversa com outro envolvido: “Foi apenas invasão de email, não de PC. Acho que ele pegou nos enviados dela”, referindo-se a como um de seus comparsas teria obtido as fotos. Ou seja, as fotos teriam sido copiadas não do PC, mas sim da pasta “Ítens Enviados” ca conta de email de Carolina. A partir daí, a polícia trabalhou com a hipótese da instalação de software malicioso do tipo Remote Administration Tool (RAT) que teria sido instalado no computador de Carolina quando ela, inadvertidamente, clicou em um link enviado por email. Eu mesmo bloguei a respeito de tal ferramenta, já que é comum sua utilização por pretensos falsos “hackers” que se valem da simplicidade de uso deste tipo de software para fingirem-se ser gurus da informática e de quebra conseguir vantagens fraudulentas e criminosas pela internet. Com esse software instalado, um atacante tem diversas possibilidades, podendo desde copiar arquivos até registrar tudo o que é digitado na máquina. A polĩcia trabalhou com a idéia de que a senha do email de Carolina teria sido copiado dessa forma.

Contudo, o que mais causou espanto foi o último achado da polícia, que descobriu de vez como o crime fora cometido. De acordo com as investigações mais recentes, o principal suspeito, Leonan Santos, usou o que existe de mais simples para se quebrar a segurança de uma conta de email. O que ele fez foi simplesmente enviar um email se fingindo de representante do provedor de internet usado por Carolina, prometendo mais segurança nos acessos às mensagens eletrônicas, desde que a atriz fornecesse seus dados pessoais. Carolina Dieckmann forneceu todos os dados ao preencher um formulário e acabou enviando sua senha do email para Leonan. Esses emails são conhecidos pelo jargão técnico como “Phishing”, e se tratam de imitações fraudulentas (às vezes perfeitas, às vezes muito mal feitas) de correspondências eletrônicas de fontes legítimas como bancos, provedores de internet, órgãos públicas, etc.

No final das contas Leonan Santos não usou nenhum artifício avançado de informática, nem mesmo os super simples RATs (usados até por crianças). Moral da estória: não vamos chamar de “hacker” qualquer pessoa que apenas sabe contar uma mentira e Leonan aparentemente já é conhecido por ter essa habilidade.

Publicado em Security | Com a tag , , , , , , , , | 3 Comentários

Poison Ivy Rat, exemplo de software que pode ter sido usado para furtar fotos de Carolina DieckMann

Abaixo está um video tutorial do Poison Ivy, um Remote Administration Tool, ou apenas RAT, que foi usado em 2011 para invadir uma das maiores empresas de segurança do mundo, a RSA, e pode ter sido usado pelos malfeitores no caso Carolina Dieckmann.
Note a parte final do vídeo, onde são mostradas as funcionalidades do software: gravar tudo o que é digitado, copiar arquivos, executar comandos, etc.

Veja mais sobre o assunto, amanhã à tarde no Programa Tarde Livre da TV Diário, canal 22. Lá conversarei com a querida Carla Soraya sobre toda essa confusão e sobre como devemos lidar com a privacidade na Internet.

Publicado em Security | 1 Comentário

Participo das dicussões sobre o Marco Civil da Internet no Brasil, peço sugestões

Caros Amigos,

A convite do Deputado Federal Ariosto Holanda, estamos em discussão sobre o marco civil da Internet no Brasil, projeto de Lei que visa estabelecer direitos e deveres na utilização da Internet no Brasil e que atualmente tramita na Câmara dos Deputados sob o número PL 2126/2011.

A primeira Reunião foi segunda-feira passada e continuamos com as discussões hoje a tarde na ETICE. Basicamente, o Deputado Ariosto está recebendo contribuições técnicas de diversos pesquisadores na forma de emendas que serão propostas ao PL, ou seja, está nos dando a oportuniade de contribuir diretamente com o futuro de nossa nação em uma matéria tão importante.

Gostaria de compartilhar a oportunidade que recebi do deputado com quem acompanha meu blog e pedir sugestões e comentários que possam ser acrescentados às discussões.

Abraços!

 

Publicado em Outros | 2 Comentários

Veja sua colocação no Poscomp 2011

Muitos cadidatos a pós-graduação em computação depois de receber a sua nota do POSCOMP acabam quase sempre com a mesma pergunta: “Como saber se a minha nota do POSCOMP foi boa ou ruim?”

A resposta a esta pergunta pode ser obtida através de uma composição da sua nota com os dados de média e desvio padrão que são divulgados na sua folha de resultado. Bem, eu preparei um pequeno sistema em PHP que faz o cálculo aproximado de quantos porcento de todos os candidatos de um dado POSCOMP você superou.

Entre sua pontuação e veja seu desempenho:

Obs.: Em breve atualizarei o formulário para incluir edições anteriores do POSCOMP pois ainda não consegui todas as médias e desvios.

Publicado em Outros | Com a tag , , , , , , , , , , , , | 1 Comentário

Twitter URL spoofing still exploitable (Updated)

A couple of days ago ly_gs Security Blog has published an interesting post detailing how someone can subvert Twitter’s t.co URL shortening service in order to spoof URLs in a tweet. With ly_gs technique one could post a tweet with a link that, for instance, shows as Capital One’s web page, but when clicked redirects to an attacker’s web site instead. Ly_gs blog has stated that twitter has closed the hole, but a couple of hours ago, as I played around with the ty_gs’ discovery I found out that this isn’t completely true.

Ty_gs way of exploiting this flaw might have been patched, but tweaking it just a little bit makes spoofing URLs in twitter still possible. In other words, the flaw still exists. The following tweets are examples of spoofed URLs in twitter posted after twitter has alegedely corrected the flaw:

http://twitter.com/#!/pabloximenes/status/118496446264782848

http://twitter.com/#!/pabloximenes/status/118487078941102080

The first tweet shows CapitalOne’s url, but instead takes the user to my blog. The second tweet does the same for Banco do Brasil’s web page (a Brazilian bank).

Well, the technique to do this is very close to ly_gs’ and smart people will be able to figure it out just by taking a closer look at my example tweets. Since the vulnerability is already disclosed by ly_gs’ blog, I might eventually add the full details here for the lazy (when I have the time). The only thing I really wanted to point out here is that Twitter hasn’t really corrected the flaw yet.

Enjoy!

UPDATE 1 (09/27/2011):

Twitter has aparently taken notice of this problem and has issued a complete fix this time. Kudos to their response team! They might not tackle the whole thing at one, but they sure are fast.

Now my example tweets only show the original links I have used to exploit the flaw. Let me briefly try to explain what they did. Twitter’s t.co service has an interesting beavior. Whenever you post any URL in a tweet, twitter shortens it using t.co, but also do a sort of url spoofing of their own: the show you your original link, but when you click on it you’re actually clicking the t.co link (which will take you to the orinal url anyway). If you try to copy the t.co link embedded in the tweet and post it in a different tweet (the raw t.co link), twitter will replace it with the spoffed version regardless, so it again shows your original url but beneath the actual link is t.co’s version. Using ly_gs’ discovery with this twitter own spoofing scheme, you could spoof URLs even after twitter has corrected ly_gs version of the exploit. All you needed to do is to post the two URLs (the one you want to be showed and the one you want it to be the actual link), copy the t.co’s links for both, and apply ly_gs’ exploit using the t.co’s links (just like it shows in my example tweets as of now). For reference (and a little bit of amusement) purposes, I have posted a video of the actual live exploit using one of my example tweets before twitter’s correction, which you can see below.

UPDATE 2 (09/27/2011):
Aparently, Twitter’s fix for this issue was done by disbling their own t.co url spoofing. Ususally when someone posts a link in a tweet the link remains visually like the original, but beneath it is actually using t.co. According to twitter’s help center:

How the Link Service Works

  • Links shared on Twitter.com will be shortened to a http://t.co link.
  • You’ll see the message “link will appear shortened” next to the Tweet button; however, these links will display the site that a link directs to, instead of a t.co URL.
  • All links included in Direct Message notification emails already pass through our link service and are converted to a http://t.co link.
  • Please note: t.co links are neither private nor public. Anyone with the link will be able to view the content.

So, in order to fix the problem, twitter has disabled the part that displays the original URL instead of t.co’s. What should we do if we want to have their own URL displaying in a tweet? Post just the text without a link? And in terms of security that doesn’t help either. Now a user won’t be able to distinguish one URL from another (since everyone is htp://t.co/something). OK, there is still the mouseover thing that displays the end target, but how many user do you thing actully check that before clicking on a link.

Come one, twitter, give us that service back!

UPDATE 3 (09/27/2011):

Twitter is back to normal, urls are not showing as t.co’s links anymore and the spoffing thing is fixed also. But friend @ly_gs has found some pretty neat new tricks.

Publicado em Outros | Com a tag , , , , , , | 5 Comentários

Falha de segurança grave deixa o BlackBerry Enterprise Server como presa fácil para atacantes

Sabe o BlackBerry, o celular smartphone seguro, campeão no quesito privacidade? A escolha do próprio presidente norte-americano Barack Obama? Preferido por políticos, empresários e, quem sabe, até você mesmo? Pois bem, o seu “BB” pode não estar tão seguro assim.

Ontem (12/08/2011) a RIM, fabricante do BlackBery, publicou uma nota recomendativa de segurança (security advisory), onde ela informa o público de falhas de segurança facilmente exploráveis no BlackBerry Enterprise Server (BES), software servidor instalado no provedor de serviços responsável por habilitar os recursos especiais do BlackBerry .

As falhas se encontram em dois componentes do BES, responsáveis pelo processamento para renderização no BackBerry de imagens dos tipos PNG e TIFF, a saber:

  • BlackBerry® Mobile Data System – Connection Service:  responsável por processar imagens em páginas web que são requisitadas pelo navegador do BlackBerry.
  • BlackBerry® Messaging Agent: responsável por processar imagens em mensagens de email.

As vulnerabilidades relatadas são de exploração remota e permitem a execução de código no contexto do sevidor BES, mas o que mais impressiona são os vetores de ataque. Um deles, por exemplo, permite que uma simples mensagem de email com uma imagem maliciosa em aenxo enviada para qualquer usuário de BlackBerry servido pelo BES seja o suficiente para que um atacante invada o servidor e possivelmente até a rede inteira. E nem é necessário que essa mensagem seja sequer aberta pelo destinatário.

A falha é classificada pelo Common Vulnerability Scoring System (CVSS) com nota máxima (10.0, Alta Severidade) e já possui patch de correção disponível.

Ficou com medo? Então, certifique-se já de que o administrador da rede de seu provedor já fez a atualização necessária. Do contrário, o seu BlackBerry pode estar em maus lençóis.

 

Veja aqui as versões do EBS afetadas:

  • BlackBerry® Enterprise Server da versão 5.0.1 até a 5.0.3 MR2 (para Microsoft Exchange)
  • BlackBerry® Enterprise Server da versão 5.0.1 até a 5.0.3 MR2 (para IBM Lotus Domino)
  • BlackBerry® Enterprise Server versão 4.1.7 e da versão 5.0.1 até a 5.0.1 MR3 (para Novell GroupWise)
  • BlackBerry® Enterprise Server Express version da versão 5.0.1 até a 5.0.3 (para Microsoft Exchange)
  • BlackBerry® Enterprise Server Express versões 5.0.2 e  5.0.3 (para IBM Lotus Domino)

 

 

Publicado em Security | Com a tag , , , , , | Deixe um comentário