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’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:

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.


Pablo Ximenes



Vulnerability Report – Applying for Reward – 2-Step Authentication in

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 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 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 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 with regards to the Vulnerability Rewards Program, but I will wait for your feedback.

Thanks in advance for your consideration,

Pablo Ximenes

Google Security

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 or visit
* For Chrome security issues, please visit
* For account hijackings, please go here ( for Youtube, and here  ( for Google Accounts (including Gmail).
* Other problems with account security in Gmail (, Youtube ( or Checkout (
* Requests to remove content in Search (, Streetview (, Maps (, Youtube (, Orkut (, Blogger (, or any other product (
* Report malware ( or phishing ( sites, or inappropriate or malicious advertisements (
* Scams, including fake lotteries and job offers (
* You’ve received someone else’s email ( anything else, please check the Google 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.


Em 05/06/2012 13:56, “Pablo Ximenes” <> escreveu:

> Dear Google Security Team,
> I have stumbled on a vulnerability that can circumvent the Two-Way Authentication scheme used in
> 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,


Em 05/06/2012 18:53, “Pablo Ximenes” <> escreveu:

Google Security Team

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 <>
Subject: Re: Vulnerability Report – Applying for Reward – 2-Step
Authentication in
Date: Wed, 6 Jun 2012 12:36:12 -0300

Google Security Team

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.

KevinOriginal Message Follows:

From: “Google Security Team” <>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step  Authentication in
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” <> 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” <> escreveu:

Google Security Team

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.


Original Message Follows:

From: Pablo Ximenes <>

Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
Authentication in

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” <> escreveu:

Google Security Team

Jun 8

to me

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

Original Message Follows:
From: Pablo Ximenes <>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
Authentication in

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 , , , , | 4 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.



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 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:!/pabloximenes/status/118496446264782848!/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.


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 service has an interesting beavior. Whenever you post any URL in a tweet, twitter shortens it using, 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 link (which will take you to the orinal url anyway). If you try to copy the link embedded in the tweet and post it in a different tweet (the raw link), twitter will replace it with the spoffed version regardless, so it again shows your original url but beneath the actual link is’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’s links for both, and apply ly_gs’ exploit using the’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 url spoofing. Ususally when someone posts a link in a tweet the link remains visually like the original, but beneath it is actually using According to twitter’s help center:

How the Link Service Works

  • Links shared on will be shortened to a 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 URL.
  • All links included in Direct Message notification emails already pass through our link service and are converted to a link.
  • Please note: 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’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:// 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’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 , , , , , | Deixar um comentário

Notícia Crime contra a Google impetrada no Ministério Público de MG

Este post veio da necessidade de dar seguimento a algumas notícias que estão aparecendo sobre nossa iniciativa de tornar pública a interceptação telemática ilegal realizada pela Google, no último ano, no Brasil. Uma delas foi publicada pela Folha de São Paulo, em seu blog de tecnologia. Como é dito na notícia, no último dia 26 de abril, tivemos a oportunidade de apresentar nosso artigo “Os impactos de privacidade em redes wifi e implicações penais no Brasil do caso Google Street View” no IV Congresso Tecnológico da InfoBrasil, em Fortaleza. Apesar de ser uma iniciativa acadêmica, o artigo é parte de nossa investida em exigir que o poder público investigue adeguadamente a conduta da Google no Brasil, da mesma forma que foi feita em outros países do mundo. Dando seguimento a esse processo, encaminhamos uma notícia crime ao Ministério Público de Minas Gerais, com a Manifestação no. 24571052011-7, impetrada na Promotoria Estadual de Combate aos Crimes Cibernéticos. Atualmente nossa denúncia encontra-se em análise. Aproveito aqui para elogiar o MP de MG por seus sistemas, que muito facilitaram nosso contato. Ainda estamos tentando fazer o mesmo para os MPs de SP e do RJ. Embora estejamos impetrando as denúncias nos MPs estaduais, acreditamos que esse assunto é de interesse nacional (e por conseguinte da União), pois as comunicações interceptadas, embora tenham sido originadas nesses três estados, podem ter sido destinadas a qualquer canto do Brasil e do mundo.

Por fim, esperamos que, com essa nossa iniciativa, o Brasil não fique atrás de outros países quando o assunto é proteção à privacidade e que nossas leis não fiquem restritas ao papel.

ATUALIZAÇÂO: Veja também a matéria publicada na InfoExame.

Publicado em Outros | 2 comentários

McAfee has its own website vulnerable to attacks

Today, as every ordinary Monday, I went to my e-mail box and checked messages from the security community in Full-Disclosure. As usual I came across an advisory pointing out some web security vulnerabilities that differently from usual certainly had my attention. I could say the post called my attention for its organization (not so common among web vuln disclosers), or because it included not only one but a myriad of different vulnerabilities, or maybe because these vulnerabilities included some unusual (and potentially dangerous) stuff like server side source code disclosure, or even because these vulnerabilities were not patched by the vendor even after 15 full days it was informed about them. But no, those were not the reasons I had my eyes rolling. The thing that really got me is that all of this is not about any vendor, it is about Mcafee, a vendor well known by its anti-virus software but also by its web security service McAfee Secure. This service provides customers with the label “Verified by McAfee Secure” so they can put in their website as a mark of safety. According to McAfee: “The McAfee SECURE™ trustmark only appears when the website has passed our intensive, daily security scan. We test for possible personal information access, links to dangerous sites, phishing, and other online dangers.” In other words, the presence of this label means that the website is not vulnerable to the exact same vulnerabilities McAfee currently has.

Don’t get me wrong, I have no interest in damaging McAfee’s image, I even own a company that sells McAfee products, but this is a serious lack of diligence with costumers and resellers that must not go unnoticed. Having that in mind, let’s discuss those vulnerabilities a bit. Have in mind that this post is written for those non tech savvy enough to need it. So, go light on the criticism. 🙂

0) First of all credits to where they belong. This find was brought to light by the YGN Ethical Hacker Group and the original post can be found here. They have contacted McAfee 15 days ago and today have decided enough is enough.

1) First vulnerability: Cross Site Scripting.

This is the first bulnerability YGN found in McAfee’s website. In order not to waste any time, let me paste wikipedia’s definition here: “Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site’s owner.”

In the case of McAfee, the vulnerable portion of the site is this:

Basically, whatever javascript code you put after that address is going to be executed in the client’s browser like it came directly from McAfee’s own page having access to all cookies and privileges bound to the domain. An example would be:‘’)

2) Second Vulnerability: Information Disclosure > Internal Hostname

This javascript reveals McAfee’s internal hostname. I supose the check done by the script should be done server side, so this information doesn’t get disclosed. But, hack, it seems for McAfee it’s no big deal to have it this way.

3) Third Vulnerability: Information Disclosure > Source Code Disclosure

This one is serious. Usually, sever side scripts have their source hidden in the server. They stay in the sever, run in the server, and their output is supposed to be the result of their execution and not their source. With this premise, programmers generally add stuff in the sever side script code that should not see the light of day in the hopes it really won’t. This is why this vulnerability is potentially dangerous. In McAfee’s case they have the following server side scripts fully open with their source code available to the world:

As a potential solution to these problems, YGN has acidly recommended McAfee to make better use of their own technicians and engineers, or in their own words “Fully utilize Mcafee FoundStone Experts”. In fact, this problem leaves McAfee wide open to sarcasm and the jokes have already started in Full-Disclosure. Let’s hope that after this McAfee will honor their clients and fix things at home as a priority.

Well, one can only conclude one thing about all of this: “The shoemaker’s son always goes barefoot”.

Publicado em Security | Com a tag , , , , , , , | 12 comentários