Wednesday, March 10, 2010

Site de teste da Ajato (TVA) revela informações do usuário

Tagged with:
Thursday, December 3, 2009, 3:20
This news item was posted in Segurança em Aplicações Web category and has 9 Comments so far.

ajato Um “cross-site scripting” e uma série de informações desnecessárias sendo exibidas ao usuário.  Esses foram os dois fatores necessários que fizeram do site de Teste de Velocidade da provedora Ajato\TVA (http://testevelocidade.ajato.com.br), uma ameaça a seus próprios usuários.  Em forma de video-post, mostrei que de forma muito simples, é possível extrair informações como o IP interno e MAC do modem, velocidade do plano de internet e nível de sinal, com pouquissimas linhas de código e sem exigir qualquer interação da vítima, graças ao script do teste de velocidade da Ajato, que expõe sem a menor necessidade tais informações. Confesso que quando as vi pela primeira vez, custei a acreditar.

Se quiser ir direto ao site da prova de conceito (PoC), veja clicando aqui (Obviamente, apenas para usuários Ajato).

Dê seu Feedback via comentários ou tweets! Colabore com a divulgação clicando no botão de RT ;)

Qualquer dúvida, é só gritar.

Até a próxima, pessoal!

You can leave a response, or trackback from your own site.

9 Responses to “Site de teste da Ajato (TVA) revela informações do usuário”

  1. Raul said on Thursday, December 3, 2009, 13:16

    parabens ai por mais um video, e nao me arrependi nada de ter gasto meus preciosos 20 e pocos minutos assistindo…

    vlw msmo… deu pra aproveitar varias outras coisas…

    e o ajato vacilou legal com seus clientes…
    acho eu que qualquer 1 devia somente mostrar as informações que o cliente ou usuario do site solicita-se. Ele solicitou a velocidade? Só mostra a velocidade…

    Deve ser alguém que pensou assim: “Eu sei como pegar varias informações do cara então vou mostrar que sei.”.
     

  2. Wellington said on Saturday, December 5, 2009, 15:03

    Parabéns pelo vídeo, muito bom .

    Agora entendi o que é um ataque XSS e uma ideia do que pode ser feito :D

  3. Neres said on Tuesday, January 19, 2010, 15:16

    Agora sim tores entenderes tudo!

    Parabens pelo site!

  4. Adilson said on Friday, February 19, 2010, 14:15

    Boa Tarde amigo,

    Curti muito o seu tutorial, só fiquei com a seguinte dúvida:

    “Se os dados passados pela URL não estão sendo gravados, como esse XSS pegaria os dados de outra pessoa, a não ser os dela mesma”?

    Grato

  5. Gabriel Coutinho de Lima said on Friday, February 19, 2010, 16:57

    Adilson,
    Por ser um xss refletido, seria necessário ter um código como um iframe em uma página, e a vítima deveria acessar esta página. O exemplo está no link da PoC: http://www.falandodeseguranca.com/exemplo/ajato.html . Com o código que esta nesse html, já seria possível um script php oculto gravar todas as informações da ajato DA VÍTIMA QUE ENTROU NO LINK. Onde for possível adicionar html (para o iframe), seria possível obter esses dados dos usuarios, de forma oculta.
    Lembre-se, não é um SQL Injection ou qualquer outra técnica que esteja expondo informações do banco de dados de clientes, mas sim um XSS refletido, que, com o código do exploit, nos dá as informações especificas da vitima que acessou.

  6. Phil said on Friday, February 19, 2010, 18:08

    Olá, passei por acaso nesse post logo depois de fazer o test de velocidade! Fiquei preocupado lógico, e me perguntando se vocês costumam informar os fornecedores de acessos desse tipo de falhas ou deixam a iniciativa para os leitores e clientes revoltados desses FA.

  7. Adilson said on Monday, February 22, 2010, 13:07

    Boa Tarde Gabriel,

    Acho que não estou entendo bem XSS, teria algum link para me recomendar?

    Pois estou com dificuldade em entender como um iframe embutido no site te traria informações de outras pessoas. Já que se você desse um “Atualizar” na página, seu iframe ja não estaria mais la. A não ser que tenha algum cache por parte do servidor, ou algo assim.

    Grato

  8. Gabriel Coutinho de Lima said on Monday, February 22, 2010, 21:49

    Adilson,
    É como comentei acima. Trata-se de um XSS refletido, por tanto, precisa de um fator que ative-o, seja passando um link alterado à vitima, ou mantendo o código que ativa o link com o exploit em algum website que a vitima deve acessar.
    XSS que são mantidos em sites são os permanentes\armazenados. Esses sim, bastaria o usuário normalmente acessar a página em que o código foi “injetado”, mas não é o caso.

  9. Adilson said on Tuesday, February 23, 2010, 9:09

    Bom dia Gabriel,

    Agora entendi, não havia pensado nos links maliciosos.

    Parabéns pelo site e sempre estarei vendo aqui para ver sobre novidades de segurança.

    Grato

Leave a Reply

Powered by WP Hashcash