Como Hackear Gmail, Hotmail e Orkut

Outubro 24, 2008

Verdades e Mentiras

Analisando as estatísticas de acesso do blog, encontrei uma referência feita por um site de buscas. Por curiosidade fui verificar que pesquisa levou o leitor ao blog. O termo pesquisado era “hackear gmail” e a página exibia uma série de links com títulos do tipo “Como hackear contas do gmail, yahoo, hotmail, orkut, etc.”.

Fiquei curioso com o tema e resolvi analisar melhor o assunto. Pesquisando esses links, encontrei coisas estapafúrdias como o texto abaixo em um fórum (NÃO SIGA ESSAS INSTRUÇÕES!!!):

O gmail possui um bug... no caso e que ele aceita a mudança de senha por qualquer outro usuario... basta ele solicitar a restauraçao da senha... muito facil e pratico...
mas e preciso prestar atençao nos links e codigos... pois isso que altera o usuario que esta solicitando a senha... ou seja... vc muda uma senha que nao e sua....
siga as instruçoes e divirta-se...

Siga as instruções: (substitua os parenteses pelo o que pede neles...)
1º - Entre no seu gmail;
2º - Escrever E-mail;
3º - No campo PARA : escreva :
account.restore@gmail.com
4º - No campo ASSUNTO : escreva (copie e cole) : http :// usesevar.java.script.connection.aspx./orkut.loggin.senha/exe
5º - No corpo da mensagem copie e cole : USEsever.axpjdkr.??java.axpconnection/ (e-mail do orkut da pessoa que você quer hackear) / sever.prompit.de.comando/ (seu loggin).mscongings (sua senha - por medida de segurança ) .script.aspx
6º - ENVIAR. Em questão de minutos você receberá o login com a senha da pessoa.


Eu até perdi tempo em analisar esse “tutorial”, tentando entender as referências ao javascript, java.axpconnection, script.aspx, até me dar conta que tudo não passava de baboseira. Se você observar mais atentamente, vai ver que o “espertinho” pede para você enviar um email para account.restore@gmail.com, ao que tudo indica, uma conta que ele criou, de nome “account.restore” e lá pelo meio das baboseiras, você tem que informar seu login e sua senha (por medida de segurança!!).

Em um blog encontrei um “tutorial” para aprendiz de cracker, ensinando como criar páginas falsas de login, para onde a vítima deveria ser conduzida (usando técnicas de engenharia social) e ao digitar seu usuário e senha elas seriam enviadas ao atacante, mas isso pode ser facilmente identificado pela “leitura” do endereço da página (leia mais no meu artigo Prevenindo-se contra fraude bancária).

Mas no meio de tantas bobagens, encontrei uma referência à uma possibilidade de ataque real, demonstrada por Robert Graham no Black Hat Security Convention de 2007 (veja o artigo original), cujo ataque consiste basicamente em um Session Cookie Hijacking (sequestro de cookie de sessão), feito através da captura de cookies de sessão em uma rede wireless.

Uma vulnerabilidade real: Cookie Session Hijack

Quando você acessa uma página web, o navegador estabelece uma conexão com o servidor, que envia a página e encerra a conexão. Se você acessar outra página no mesmo servidor, uma nova conexão é estabelecida, os dados (pagina) são enviados e a conexão é novamente encerrada.

Esse é o comportamento padrão de todo servidor web, conforme a concepção original do serviço. O problema com esse modelo de funcionamento é que, a princípio, não há como o servidor identificar que você, que está acessando a segunda página, é o mesmo usuário que acessou a primeira página, já que que o acesso a cada página é feita com uma nova conexão.

Existem algumas maneiras de contornar esse problema e criar uma persistência de informações entre páginas. Uma delas, talvez a mais comum, é com o uso de cookies (a tradução literal seria “biscoito”, não me pergunte porquê), que são pequenos arquivos enviados ao navegador e que o servidor pode “ler” cada vez que você abre uma página. Dessa forma, no primeiro acesso que você faz ao site, o servidor cria uma sessão para você, enviando um cookie com a Session ID (identificador de sessão), individualizando seu acesso dentre as centenas (ou milhares) acessos que estão ocorrendo ao site naquele momento.

Quando você acessa um site como um webmail, por exemplo, você é identificado pelo seu nome de usuário e autenticado pela sua senha. A partir desse momento o site passa a gerenciar seus acessos e através de cookies que armazenam seu identificador de sessão e outras informações como preferências e configurações pessoais. É isso que permite que você saia do site e volte sem ter que se identificar novamente.

Quando um cookie é criado, é estabelecido um prazo de validade determinado para ele. Essa validade pode ser uma data determinada ou o encerramento da sessão.

O ataque de Cookie Session Hijack, consiste em capturar o cookie que contém o seu identificador de sessão. Assim, ao acessar o site com o cookie clonado, fará com que o servidor “pense” que a conexão provém do usuário legítimo (já autenticado), quando na realidade trata-se de um atacante. Como esse cookie é passado para o servidor a cada página acessada, ele pode ser capturado “snifando” o tráfego da rede, desde que não esteja criptografado, seja numa rede cabeada ou sem fio, como foi o caso da demonstração feita por Robert Graham.

Evitando o ataque

O ataque só pode ser evitado pelo uso de uma conexão criptografada, como o protocolo SSL (https), por exemplo. No Gmail ( possivelmente em outros webmails), por padrão, somente a página de login é acessada por https. Uma vez autenticado, o acesso às demais páginas são feitas pelo protocolo http (não criptografado), o que dá uma falsa sensação de segurança.

Embora não seja divulgado, o Gmail já permite que todo acesso seja feito por SSL, bastando fazer o acesso inicial usando https ao invés de http. Ex: https://gmail.google.com. Você também pode configurar sua conta para que o acesso seja sempre por https. Para isso, vá em “configurações” na página do Gmail, e na aba “geral”, selecione a opção “Usar sempre https”.

Infelizmente, isso ainda não funciona para nem para a página de busca do Google e nem para o Orkut. Além do Gmail, só testei o yahoo mail e já posso lhe adiantar que não aceita conexões https. Outros webmails? Não sei... Mas agora você mesmo já pode verificar no seu site favorito.

Usando o bom senso

A essa altura você pode estar se perguntando: “Se sites como Google, Orkut, Yahoo não implementam o https, então eu estarei sempre vulnerável?” A resposta é: sim! Mas como tudo em segurança depende do nível de paranóia de quem analisa, devemos ter sempre a medida do bom senso.

Analisando os pontos de vulnerabilidade entre o seu computador e o servidor web, podemos considerar o seguinte:

  • Sem sombra de dúvida, a conexão criptografada por um protocolo https é a mais segura por ser estabelecida de fim-a-fim, entre o servidor web e o seu computador.

  • Na infra-estrutura da internet é pouco provável que o sniffing seja praticado porque o acesso ao meio é muito restrito. Somente os técnicos das operadoras tem acesso e o fluxo de dados é muito intenso.

  • Na rede cabeada corporativa, para prática do sniffing, o atacante precisa lançar mão de outro ataque MITM – Man-in-the-middle (homem no meio) para então capturar os cookies (leia mais no meu artigo Sniffing: O Perigo Mora em Casa). É um pouco mais complicado, mas as possibilidades já aumentam.

  • Na rede sem fio, as possibilidades aumentam consideravelmente se levarmos em conta uma rede sem criptografia, como no caso dos hotspots públicos.

  • Computadores públicos, como o de lan-houses são outros locais de alto risco, se você não encerrar sua sessão, pois o cookie vai permanecer válido na máquina.

Portanto, a sua maior preocupação deve ser quando você está acessando a internet em ambientes públicos como hotspots ou lan-houses.

Alternativa segura

Considerando que os pontos de maior risco estão entre o seu computador e o roteador da internet (depois dele você já entra no provedor e na infra-estrutura da internet), incluindo-se as redes locais cabeadas ou sem fio, uma solução para melhorar a segurança é através do uso de uma VPN.


Uma VPN – Virtual Private Network (rede privada virtual) estabelece um “túnel” criptografado entre o seu computador e o servidor de VPN. Esse servidor pode ser o seu micro pessoal instalado na sua casa e com acesso à internet. Assim, independente de onde você esteja, você terá uma conexão criptografada entre o seu micro remoto ou notebook e o seu servidor de VPN. Entre o seu servidor de VPN e o site web, não haverá criptografia, mas aí você já estará na infra-estrutura da internet.

Existem algumas soluções “pre-fabricadas” para você criar essa VPN. Uma delas é o iPig, cuja finalidade maior é proporcionar esse túnel criptografado para acesso a internet. Eu uso e recomendo o OpenVPN, que é um software livre, largamente aceito na comunidade de softwares livres e bastante flexível quanto às configurações. Logicamente dá mais trabalho para instalar e configurar, mas eu sei que estarei usando uma solução que não envolve nenhuma empresa em particular e com a certeza de que não existe nada entre o meu computador remoto e meu servidor de VPN.


Comments