0
0
Uma vulnerabilidade grave no webmail da UOL foi reportada por Gabriel Pato. Uma vulnerabilidade que permite ganhar acesso ao e-mail da vítima simplesmente por ela ler um e-mail.
A falha continua existindo. A plataforma continua vulnerável, pondo em risco os dados e as contas dos usuários que utilizam esses serviços. Continue lendo e saiba todos os detalhes sobre a falha no webmail da UOL.
Webmail da UOL: falha grave encontrada
Gabriel Pato, youtuber de hacking e tecnologia, reportou uma vulnerabilidade gravíssima para a UOL que que acontece no webmail deles.
Esse sistema de webmail é usado tanto pelos e-mails @uol.com.br quanto por alguns outros serviços da empresa. Essa falha põe em risco toda a conta de e-mail da vítima, porque o hacker poderia ganhar acesso a tudo o que ela tem lá, ler todos os e-mails, interagir usando a conta, etc. Realmente ganha acesso total a conta da vítima.
Como dito anteriormente, tudo o que o hacker precisa fazer é enviar um e-mail para a vítima e esse e-mail não precisa ter nenhum anexo. A vítima só precisa abrir esse e-mail no webmail dela e pronto! O hacker já poderia ganhar acesso a toda a conta dela.
E nenhuma solução de segurança que a vítima estivesse usando, como um antivírus, por exemplo, conseguiria parar esse ataque. Outro detalhe alarmante é que a falha é extremamente simples.
Hacker ético: expor a falha ao público
Quando um hacker ético reporta uma vulnerabilidade para uma empresa, a única coisa que ele espera é que esta falha seja corrigida. Esse é sempre o objetivo. Mas se a empresa não corrige o problema, mas também não fala o que está acontecendo para quem relatou essa falha, o que muitos hackers éticos fazem nesta situação é divulgar a falha para o público. Dessa forma, pelo menos os usuários desse serviço que está vulnerável vão estar cientes do risco que eles estão correndo. Essa é uma prática comum no mundo inteiro. Quer ver um exemplo disso?
O Google, internamente, tem um time fantástico de segurança de pesquisadores que buscam falhas em programas populares por meio de um projeto que eles chamam de Project Zero. Este time do Google identificou uma falha no navegador Edge da Microsoft em fevereiro de 2018 e reportou tudo para a Microsoft. Eles deram 90 dias para a Microsoft corrigir essa vulnerabilidade que eles estavam reportando. No entanto, e a Microsoft não conseguiu cumprir este prazo e o Google divulgou os detalhes da falha para o público.
O time do Google achou que 90 dias era mais do que suficiente para a Microsoft desenvolver a correção no Edge, testar esse update em várias máquinas, para daí, então, usar o Windows Update para distribuir esse update para todos os seus clientes, para todos que tem o Windows e que tem o Edge instalado.
Passou 1 ano e 7 meses desde que o youtuber reportou essa falha à UOL. E corrigir essa falha é muito mais simples do que todo esse processo que a Microsoft teve que passar para atualizar o Edge. Portanto, ele decidiu expor a falha tomando o papel de alertar os usuários desses serviços os riscos que eles estão correndo.
Como a falha no webmail da UOL foi descoberta
Em outubro de 2018, Gabriel Pato foi convidado para palestrar na Roadsec, o maior festival hacker da América Latina. Nele acontecem várias palestras simultaneamente e a palestra dele seria na trilha de palestras técnicas sobre segurança ofensiva.
Então, ele resolveu fazer uma palestra para incentivar as pessoas que buscam vulnerabilidades em aplicações web a serem mais criativas ao realizar buscas de vulnerabilidade do tipo Cross-site Scripting.
Ele deu o nome da palestra de “Cross-site Scripting continua sexy”, porque muita gente acha que é uma falha do passado e que já não acontece mais com tanta frequência. Por isso, na palestra, Pato mostrou casos criativos e diferentes de Cross-site Scripting por aí.
Tratamento de e-mails
Uma das coisas que ele menciona na palestra é que se deve ficar de olho em recursos dos sites que permitem os usuários inserirem elementos dinâmicos nas páginas. Como, por exemplo, formatação de texto, inserção de imagens, etc. Gabriel tinha o interesse de incentivar a sempre explorar o algoritmo que interpreta esses elementos que o usuário insere e transforma isso em um HTML que vai aparecer na página no fim das contas.
Além disso, um dos cenários que usa isso há muito tempo são os webmails.
Tenho certeza que todo mundo aí já deve ter usado alguma formatação de texto ou inserção de elementos, como uma imagem, no corpo de um e-mail que estava escrevendo. Desde o mais básico, negrito, até essa inserção de imagens no corpo do e-mail, tudo é transformado em HTML. Os e-mails sempre suportaram o formato text/HTML.
No entanto, no momento de exibir esse e-mail recebido para o usuário que está acessando o webmail, esse conteúdo tem que ser tratado. Não é permitido exibir todas as regras de HTML por aí. Isso porque existem sérios riscos de segurança nisso.
O tratamento de e-mails é um ponto que o youtuber queria martelar bastante na palestra: prestar atenção nas transformações que acontecem, porque é possível conseguir usar isso a favor dos hackers éticos. Além de conseguirem escrever códigos maliciosos devido às transformações que acontecem. Será que vão conseguir passar as remoções de segurança que uma aplicação está fazendo? Usar uma transformação para resultar em um código que acabe sendo malicioso?
Tag script no e-mail
Imagine se a aplicação de e-mail permita usar a tag <script>, que é a tag usada para escrever códigos javascript que vão ser executados na página. Se o webmail permitisse essa tag, seria possível enviar um e-mail para alguém e quando essa pessoa abrisse esse e-mail, poderia executar códigos na sessão logada dessa pessoa. Nesse momento, criara-se um script que poderia interagir com qualquer coisa do e-mail dela, inclusive ler e-mails, mexer nas configurações do e-mail ou até mandar a sessão logada dessa vítima para o hacker. Ou seja, obviamente os webmails têm que remover essa tag se ela fizer parte de um conteúdo recebido dentro de um e-mail.
Por exemplo, como será que os webmails interpretam essa situação aqui: <scr<script>ipt>?
Sabemos que removem a tag script, mas será que nesse caso eles removeriam só o script que está dentro? E se eles removessem esse script que está completinho, não resultaria em um outro script também completo? Ou será que ele vai rodar várias vezes e perceber todas essas camadas e removendo, removendo? Curioso, não é? Esse é o exemplo mais básico. Seria possível testar várias outras formas. Por isso, Pato queria compartilhar esses insights dando o exemplo dos e-mails na palestra.
Código de teste no e-mail
Então, o youtuber resolver realizar um teste básico nos e-mails UOL.
Ele mandou o seguinte HTML: <vídeo><source onerror=alert(1)>. Uma tag de vídeo, com um source de vídeo, com um tratador de evento on error, fazendo disparar um alerta quando acontecesse um erro. Esse erro sempre vai acontecer porque não tem nenhum vídeo a ser tocado no código em questão, então apenas um alerta seria executado.
Coisas simples são um ponto de partida básico para testar um Cross-site Scripting.
Nenhum e-mail permite um vídeo no corpo do e-mail, então provavelmente os webmails vão remover essas tags, não é? Era isso ele pensou que iria acontecer também. Mas, no e-mail da UOL, essa tag foi carregada. O webmail da UOL não mudou nada nessa tag e o código de script foi executado.
Quando ele abriu o e-mail no e-mail de teste, o alerta estava lá, confirmando que qualquer um tem o poder executar um código de script. Temos aqui, então, um Cross-site Scripting gravíssima. Nem mesmo preciso ficar tentando entender como eles removem tags ou manipulam tags. Eles, simplesmente, não removiam quase nada.
A tag script removiam. No entanto, existem várias outras formas de executar um script como, por exemplo, os tratadores de eventos. Aliás, também foi testado os aplicativos deles para mobile, pelo menos na versão de iOS, e pode confirmar que acontecia a mesma coisa.
Impacto do Cross-site Scripting no e-mail
Gabriel Pato realizou um experimento de que quando a vítima abrisse o e-mail, ela não iria perceber, mas o código ia ativar o redirecionamento de e-mails do e-mail dela. Então, a partir daquele momento, todos os e-mails que a vítima recebesse, não apareceria mais para ela, mas seria encaminhado para um e-mail no controle do hacker.
Imagina você fazendo isso com uma vítima e depois pedindo uma recuperação de senhas em várias contas que ela tenha usando esse e-mail, como, por exemplo, nas redes sociais. Situação muito séria!
Exemplo do impacto do Cross-site Scripting
Foi enviado um e-mail para a vítima com o título HTML. Nele, foi colocado a tag vídeo e a tag source com o atributo on error executando um.
No momento em que o e-mail é enviado, já aprece lá no inbox da vítima. E quando clica para ler esse e-mail em questão, a caixa de alerta aparece, mostrando que o código javascript rodou na sessão da vítima e foi realizado um Cross-site Scripting.
Ataque no redirecionamento de e-mail
Primeiro, vamos ver como funciona esse recurso de redirecionamento. Entra na página de configuração do webmail e localiza essa funcionalidade. Aqui, se percebe que o formulário onde digita o e-mail e as configurações de redirecionamento, são, na verdade, uma página que fica em um outro host. Descobre-se que é um iframe e o outro host é o config.uol.com.br. Ele recebe da url um parâmetro token, que é o que autentica esse usuário nesse webmail nessa outra aplicação do config.uol.com.br.
O ataque precisa capturar esse valor do token da vítima, porque tendo esse valor em mãos, o hacker poderia acessar diretamente essa url do config.uol, passando o token da vítima e ativando o redirecionamento do e-mail dela para o endereço que ele quiser.
Detalhes do ataque
Usando uma proxy, identifica de onde esse token está vindo. Logo, percebe-se que ele faz parte de um json de configurações que o webmail carrega assim que o usuário faz o login. Há várias propriedades que são carregadas aqui, mas a que se precisa é a configredirurl. Essas configurações são todas carregadas pelo angular, então, quando um e-mail malicioso for aberto pela vítima vão estar carregadas na aplicação.
O valor foi acessado por meio de um caminho. Em seguida, precisa fazer um código que envie essa informação para algum servidor de controle do hacker. Pode-se realizar isso ao fazer a aplicação carregar uma imagem que fica localizada em um servidor do hacker. No endereço dessa imagem, passa o valor que se quer capturar da vítima, no caso, aquele token do config.uol. Essa imagem, na verdade, não existe no servidor. Esse código é usado apenas para fazer o servidor dela carregar um link de controle do hacker no servidor dele loga essa tentativa de carregamento. Em seguida, no endereço desse carregamento, vai estar o dado capturado.
Então, envia esse novo ataque para a vítima. Ela recebe, clica no e-mail e não vê nada. Enquanto isso, no servidor do hacker já tem um lobby de captura. Obtém-se, então, url com o token para acessar a página que configura o redirecionamento de e-mails dessa vítima. É só abrir essa url que foi capturada no navegador. Tem-se a opção de preencher qual e-mail vai usar como destino do redirecionamento de e-mails da conta da vítima. Envia o formulário e, a partir desse momento, a vítima para de receber qualquer e-mail e todos os e-mails que iriam para ela, vão agora para o e-mail do hacker.
Report da vulnerabilidade para a UOL
Uma vez claro como essa vulnerabilidade era crítica e urgente, Pato se apressou para reportar essa vulnerabilidade para a UOL.
Encontrar uma maneira de falar com alguém da UOL foi um desafio. Não há nada no site nem no Google, alguma página que tivesse algum formulário de contato ou endereços de e-mail. Não tem nenhuma página explicando nada. Além disso, não há nenhuma instrução deles para enviar report de vulnerabilidade ou sequer de um contato simples direto com alguém da equipe de segurança ou de TI.
Contato direto com colaborador da UOL
Então, o youtuber pediu ajuda para um amigo que é organizador de eventos de segurança da informação pelo Brasil todo. E, por sorte, ele conhecia uma pessoa da equipe de segurança da informação da UOL. Não foi divulgado nem nome dessa pessoa, nem o cargo dela, para não comprometer o profissional.
Gabriel Pato entrou em contato com essa pessoa e reportou a falha no dia 24 de outubro de 2018. Nesse report, foi incluídas sugestões de como eles podiam corrigir essa vulnerabilidade. Uma das sugestões era ativar o atributo sandbox no iframe que eles usam para visualizar os e-mails no webmail. Simplesmente escrevendo sandbox ali já iria inviabilizar o ataque demonstrado.
Nesse mesmo dia, a pessoa respondeu confirmando que recebeu o report. Sete dias depois, enviou um novo e-mail para essa pessoa, perguntando como é que estavam as coisas e se colocando à disposição para ajudar, caso estivessem tendo alguma dificuldade ou alguma dúvida no processo. No mesmo dia, no dia 31 de outubro, a pessoa respondeu que um time de desenvolvimento da UOL já estava tratando do caso, mas que ele ainda não tinha as relações das ações que foram tomadas iria verificar. Desde então, não recebeu nenhuma mensagem deles.
Gabriel Pato imaginou que eventualmente eles iam acabar resolvendo a falha.
No entanto, semana passada, ele lembrou do report realizado. Além disso, ficou muito curioso para ver qual foi a correção deles e se tinham adotado as sugestões. Então, resolveu testar de novo a falha. Porém, 1 ano e 7 meses depois, a falha continua lá, funcionando, com nada corrigido.
Relevância da falha no sistema da UOL
Muitos podem imaginar que a falha no sistema da UOL é irrelevante. No entanto, é importante reforçar que a UOL teve extrema importância na história da internet no Brasil. Eles dominavam a internet brasileira nos anos 90 e no começo dos anos 2000. E muita gente teve a UOL como o seu primeiro e-mail na internet e mantém esse e-mail até hoje. Aliás, se for olhar o ranking dos sites mais acessados por brasileiros hoje (31/05/20) a UOL está em sexto lugar:
- google.com
- youtube.com
- gooogle.com.br
- facebook.com
- globo.com
- uol.com.br
Outra razão para essa falha ser ainda mais relevante é que o sistema de webmail do UOL não é usado somente nos e-mails. Então, onde ele for usado, essa falha pode existir. E ao olhar os javascripts, dá para verificar várias menções de outros webmails que, na verdade, são o mesmo produto.
Vemos menções do BOL (bol.com.br), que foi confirmado que, de fato, é vulnerável. Há menções ao zipmail, que se acredita que não dá para fazer cadastros nele, então não pode testar. Também temos menção ao webmail da folha, que cai na mesma situação. Agora, o mais crítico, há menções ao webmail oferecido como produto do UOL host.
UOL host
A UOL tem o UOL host, uma divisão de serviços de tecnologia da informação, com data centers próprios, serviços de hospedagem no site, servidores etc. Eles são superfortes nesse segmento. Oferecem o serviço de hospedagem de e-mails para você ter o seu e-mail com seu domínio personalizado. O serviço não foi contratado para fazer o teste, mas tudo indica que, de fato, seja o mesmo webmail. Portanto, há muitas chances de quem utiliza esses serviços do UOL host, estar usando um sistema vulnerável e passando por esse risco.
Inclusive, se você conferir a screenshot do webmail host dá para notar que é muito similar ao e-mail da UOL. Tudo indica ser o mesmo produto, então, ele estaria também vulnerável.
Recado muito importante: se você utiliza algum desses serviços, a sugestão é que você não utilize o webmail e passe ter acesso ao seu e-mail utilizando algum programa, como Outlook para Windows, configurando o seu e-mail via IMAP ou Pop3/SMTP. Assim, você consegue acessar o seu e-mail usando um outro programa sem depender do seu webmail que pode estar vulnerável. Assim, você consegue continuar usando o seu e-mail sem correr risco.
FONTE: WINDOWS TEAM