Batori Blog

O Gmail possui uma vulnerabilidade que permite explorar ataque de XSRF na sua página de troca de senha.

O que é XSRF?

XSRF é a sigla para Cross Site Request Forgery. Esta técnica pode ser usada de várias formas e a vítima tem que estar autenticada na aplicação vulnerável.

Quando um usuário se autentica em uma aplicação web existe uma relação de confiança entre o usuário e a aplicação durante o período de tempo em que a sessão autenticada permanece ativa. Neste período a aplicação não solicita uma nova autenticação (usuário e senha) a cada função que o usuário acessa da aplicação. Existe aplicações que solicitam novamente a senha em algumas funções críticas, como é o caso de pagamentos de contas em aplicações de home banking. Mas a maioria das aplicações web autenticam o usuário apenas uma vez e confiam nesta autenticação até o fechamento do navegador ou a sessão cair por tempo de inatividade.

Para fazer um ataque de XSRF, o atacante tem que conhecer a aplicação alvo e identificar a url ou o formulário que realiza a função crítica, como por exemplo, aprovação de processo, enviar mensagem, confirmar uma pendencia importante, etc. O atacante estuda a função crítica, identifica o enderço das páginas e os parâmetros que são enviados. De posse destas informações, o atacante monta um link ou um código HTML que irá executar a função crítica estudada. Por exemplo, pode existir uma aplicação financeira que quando um usuário legítimo aprova um pagamento através de um botão, o botão na verdade ativa o endereço http://aplicacao/aprova_pagamento?id_conta=10.

Conhecendo o endereço, os parâmetros e a forma com uma função crítica é chamada, o atacante tem que fazer a vítima clicar no link enquanto ela está autenticada na aplicação. Existem várias formas de se conseguir isso:

* Gravar um script ou html numa aplicação vulnerável a Cross Site Scripting. Quando o usuário autenticado acessar o script ou html gravado irá processar e executar a função da aplicação sem saber;
* Se aplicação permitir a edição de figuras, o atacante poderá incluir uma figura que execute uma url;
* Colocar um link em outra aplicação e solicitar para um usuário autenticado clicar no link ou acessar uma página que tenha o script ou o link montado especialmente para o XSRF.

Quando o usuário estiver autenticado na aplicação e clicar em um link ou acessar um página que tenha o script ou html com ataque de XSRF irá executar a função até mesmo sem saber. No nosso exemplo a vítima poderá aprovar um pagamento sem intenção através da chamada a url http://aplicacao/aprova_pagamento?id_conta=10.

Qual o perigo?

Existe um risco muito grande principalmente em aplicações que usam o conceito web 2.0. Essas aplicações possuem conteúdo montado por usuários, compartilhamento de informações e grande interatividade com usuários. Aplicações corporativas com funções críticas também são alvos deste tipo de ataque.

Como se proteger?

Se proteger deste tipo de ataque não é tarefa fácil.

A aplicação pode usar controles de token temporários que ajudam a evitar este tipo de ataque. O token temporário seria gerado em uma página anterior e seria validado na página crítica. O token dificulta, mas não evita 100%. O atacante teria que automatizar o ataque desde o momento da geração do token, o que dificulta bastante, mas não é garatia total.

Outro controle a ser aplicado é o uso de captcha em funções críticas. Captcha são aquelas figuras que temos que ler e digitar para confirmar alguma página. O captcha além de dificultar o usa da página por robôs e programas, dificultaria o ataque de XSRF. Mais uma vez apenas dificulta, pois o atacante pode usar recursos de OCR para ler o captcha.

A redigitação da senha também pode ser usado para evitar o XSRF. Além de proteger a aplicação por descuito do usuário que deixa a sessão aberta e se ausenta da frente do computador, a redigitação da senha evita o XSRF pois não é possível automatizar o ataque sem conhecer a senha do usuário. O ponto negativo é que se existir a redigitação da senha em muitas funções de uma aplicação, isto pode torná-lo pouco funcional e produtiva para o usuário final.

O Caso do Gmail

No caso do Gmail, qualquer usuário que esteja autenticado e executar a url abaixo irá trocar a senha sem passar por captcha ou controle de token.

https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=senha_antiga&Passwd=123&PasswdAgain=123&p=&save=Save

O atacante poderia montar uma página autenticacao_falsa.html que solicite a senha antiga e troque a senha do Gmail da vítima. Como o Gmail não implemente nenhum token ou outro tipo de controle entre páginas, se ele estiver autenticado e abrir página_falsa, a senha poderá ser trocada indevidamente.

Referência: http://seclists.org/fulldisclosure/2009/Mar/0029.html

Ricardo Kiyoshi Batori

Fazendo uma rápida busca na internet sobre este assunto é possível ver que não existem grandes saídas para efetuar o bloqueio de dispositivos removíveis. No Windows Vista, é possível verificar que já existe de forma nativa, uma GPO de restrição a discos removíveis. No Win2003 Server, existe uma GPO para bloquear unidades A, B, C e D, porém, não funcionariam no caso de um pen-drive inserido numa máquina. Se fizessemos o bloqueio total destas unidades, dispositivos como teclados e mouses USB poderiam não funcionariam, o que é inviável ultimamente.

Efetuando testes, foi possível alterar o código-fonte destas GPO´s, afim de, certa forma “expandir” o número de unidades a serem bloqueadas. É necessário acessar o arquivo “system.adm“, que fica na pasta C:\Windows\inf do AD. Procure o seguinte trecho do código.

Abaixo, o código-fonte modificado:

NoDrives
#if version >= 4
SUPPORTED !!SUPPORTED_Win2k
#endif

EXPLAIN !!NoViewOnDrive_Help
PART !!NoDrivesDropdown DROPDOWNLIST NOSORT REQUIRED
VALUENAME “NoViewOnDrive”
ITEMLIST
NAME !!ABOnly VALUE NUMERIC 3
NAME !!COnly VALUE NUMERIC 4
NAME !!DOnly VALUE NUMERIC 8
NAME !!ABConly VALUE NUMERIC 7
NAME !!ABCDOnly VALUE NUMERIC 67108851
NAME !!ALLDrives VALUE NUMERIC 67108863 DEFAULT
; low 26 bits on (1 bit per drive)
NAME !!RestNoDrives VALUE NUMERIC 0
END ITEMLIST
END PART
END POLICY

Pegando como exemplo a linha NAME !!ABCDOnly VALUE NUMERIC 67108851 .
“67108851″ significa o bloqueio de todas as unidades necessárias . É possível ir alterando este número. Cada unidade equivale a um número. Por exemplo, a unidade “A:\” equivale ao número 1, a unidade “B:\” equivale ao número 2, a unidade “C:\” equivale ao número 4, e assim por diante, sempre dobrando o número da unidade anterior. O número 67108851 significa a soma de todas as unidades de discos de A a Z, menos “12” (C:\=4 + D:\8).

É possível tambem alterar a string das duas GPO´s utilizadas, para melhor visualização na seguinte linha:
[strings]
ABCDOnly=”Restringir todas as unidades, menos C:\ e D:\”
Depois da edição, salve o arquivo.

Lembrando que é necessário depois ativar as GPO´s:

“Hide these specified drives im My Computer”;
“Prevent access to drives from My Computer”.

O uso do e-mail está mais do que disseminado. Trocam-se e-mails entre amigos para enviar um anexo com aquela piada imperdível, para convite de aniversário, para a receita de um remédio milagroso, para falar de amenidades etc.etc. E, muito mais preocupante, profissionais e empresários trocam muitas dezenas de e-mails, diariamente, para atualização de quase todas as tarefas e rotinas pertinentes ao dia-a-dia de empresas de todos os portes e tamanhos.
No mundo corporativo, raras são as companhias preocupadas com a inviolabilidade dos seus e-mails. Informações confidenciais tais como projetos, propostas, relatórios, memorandos etc. circulam livremente através de e-mails. Sejam eles internos ou, pior ainda, externos. E sem qualquer padrão ou preocupação mínimos de segurança.
A utilização do e-mail é tão simples e banal, que em praticamente todas as empresas ele já acabou gerando, paradoxalmente, um grave problema de comunicação interna: o da falta de interação pessoal. Funcionários quase não se comunicam mais pessoalmente, só mesmo através do maravilhoso e-mail. Nem mesmo quando os assuntos possam ser de vital importância para a empresa. E nem mesmo quando estão sentados lado a lado, na mesma seção.
Poucos dirigentes sabem, mas rastrear e abrir um e-mail desprotegido é uma tarefa simples. Qualquer administrador da rede corporativa, do servidor de e-mail, do sistema de backup, etc., pode “enxergar” tudo o que trafega na empresa que esteja desprotegido. Aquele e-mail confidencial do diretor para o presidente, por exemplo, pode ser lido com facilidade.
Para complicar ainda mais essa quase “promiscuidade” na ida e vinda de e-mails sem respeito a qualquer norma de segurança, as redes sem fio também estão se espalhando rapidamente em lugares públicos, facilitando ainda mais a quebra do sigilo no tráfego de informações. Hotéis e aeroportos são locais perfeitos para sniffers (farejadores) com más intenções. A espionagem industrial está aí, mais do que presente. Ela não é obra apenas de ficção, e está sendo incrivelmente facilitada pelo uso indiscriminado e irresponsável do e-mail.
Existem três “Contramedidas de Segurança” eficazes no uso do e-mail: a certificação digital, a criptografia por gateway e a classificação da informação e conscientização do usuário.
Certificação Digital
A confidencialidade e a integridade na troca de e-mails pode ser assegurada através de uma criptografia assimétrica. Isso não é assim tão trabalhoso. Basta que as empresas – e os usuários em geral – se habituem a trafegar seus e-mails criptografados. A utilização de identificações digitais permite o tráfego seguro de mensagens, inclusive a sua criptografia. Uma identificação digital é composta de uma chave pública, de uma chave particular e de uma assinatura digital. Ao assinar digitalmente as mensagens, o usuário estará adicionando sua assinatura digital e uma chave pública à mensagem. A combinação da assinatura digital e da chave pública é a chamada certificação digital.
Existem inúmeras entidades certificadoras que podem fornecer essas chaves de segurança. No próprio correio eletrônico do Windows Outlook ou do Outlook Express, por exemplo, há explicações detalhadas sobre como proceder para a obtenção dessas chaves, que resultarão no envio e recebimento de mensagens de e-mail seguras, autênticas e invioláveis. Esses procedimentos podem demandar algum tempo, mas, com certeza, eles são de grande valia. Em especial no mundo empresarial é inconcebível que os e-mails continuem trafegando livremente sem qualquer proteção.
Criptografia por Gateway
Esta é uma solução mais corporativa, onde a política de criptografia no envio de e-mail é aplicada na solução de proteção do serviço de e-mail. De acordo com uma política pré-estabelecida, o e-mail é criptografado na saída da mensagem. Esta solução torna a adoção de criptografia transparente para o usuário final e agrega um controle adicional de segurança nas mensagens confidenciais.
Classificação da Informação e Conscientização do Usuário
Não podemos nos esquecer do fator mais importante que envolve a segurança da informação de uma organização: o ser humano. Dispor de uma política de segurança da informação implantada e manter os usuários conscientes da classificação da informação e das normas de segurança é fundamental. Existem técnicas como a AVS (Análise de Vulnerabilidade Social) que ajudam as empresas a medir e melhorar o seu nível de conscientização de segurança.

Ricardo Kiyoshi é diretor da Batori www.batori.com.br – empresa que presta serviços de inteligência em segurança da informação e difunde a cultura de segurança, contribuindo para a excelência nos negócios das corporações.