Com o advento dos cartões de crédito e da Internet, as compras se tornaram muito mais fáceis e, como dizem, mais seguras. Apenas alguns cliques e o produto que você precisa já está a caminho de sua casa. No entanto, nem todos os sistemas são ideais, ou melhor, não existem. Você sempre pode encontrar algum tipo de erro, uma lacuna que permite que os atacantes façam suas ações sujas. Hoje, gostaria de chamar sua atenção para o estudo de um programador muito talentoso, Yohanes Nugroho, que falou sobre vulnerabilidades no sistema MIGS.
Este texto é uma tradução das palavras do próprio pesquisador de vulnerabilidades Yohanes Nugroho. Tenha um bom tempo.
Vulnerabilidade no algoritmo de hash MIGSNo ano passado, descobri um erro no algoritmo de hash baseado em MD5 usado pelo MIGS (Mastercard Internet Gateway Service). Isso permitiu que você fizesse alterações no tamanho da transação. A empresa me recompensou por descobrir esse problema. No mesmo ano, o MIGS passou a usar o HMAC-SHA256, mas havia algumas vulnerabilidades.
O que é o MIGS?Quando você paga em um site, seus proprietários geralmente conectam seu sistema a um gateway de pagamento intermediário (há uma transição para outra página). Esse gateway de pagamento é então conectado a vários sistemas de pagamento disponíveis em um país específico. Para cartões de crédito, muitos gateways se conectam a outros gateways (um dos quais é o MIGS), que trabalham com muitos bancos para fornecer o 3DSecure.
Como isso funciona?A sequência de pagamento, se você usar o MIGS, geralmente fica assim:
- Você seleciona um produto no site.
- Digite o número do seu cartão de crédito.
- O número do cartão, o tamanho do pagamento e outros parâmetros são assinados e retornados ao navegador, o que gera automaticamente uma solicitação POST para o gateway de pagamento intermediário.
- Esse gateway converte informações em um formato suportado pelo MIGS, assina com uma chave MIGS e as retorna ao navegador. Após o qual o navegador gera outra solicitação POST para o próprio servidor MIGS.
- Se o 3DSecure não estiver ativado, esta etapa será ignorada. Caso contrário, o MIGS transferirá a solicitação para o banco que emitiu o cartão. O banco solicita OTP e gera HTML, o que gera uma solicitação POST para o servidor MIGS.
- O MIGS retorna os dados assinados para o navegador e cria uma solicitação POST para o gateway de pagamento intermediário.
- Validação de dados e assinatura por um gateway de pagamento intermediário. Se os dados estiverem incorretos, uma página de erro será gerada.
- Com base na resposta do MIGS, o gateway de pagamento transmite o status do pagamento ao vendedor.
Vulnerabilidade no algoritmo de hash MD5Este erro é muito simples. O método hash usa a seguinte fórmula:
MD5 (Segredo + Dados)Mas não há vulnerabilidade à extensão de hash (algumas verificações foram realizadas para evitar isso). Os dados são formados desta maneira: todos os parâmetros de solicitação que começam com vpc_ são classificados, após o qual os valores são conectados sem separação. Por exemplo, temos os seguintes dados:
Nome: Joe
Valor: 10000
Cartão: 1234567890123456
vpc_Name = Joe e Vpc_Amount = 10000 & vpc_Card = 1234567890123456
Aplicar classificação:
vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe
Nós conectamos os valores:
100001234567890123456
Observe se eu altero os parâmetros:
vpc_Name = Joe e Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000
Aplicar classificação:
vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe
Nós conectamos os valores:
100001234567890123456
Esse valor MD5 será o mesmo. Ou seja, quando os dados são transferidos para o MIGS, podemos adicionar um parâmetro adicional após o tamanho do pagamento para remover o último dígito ou antes dele - para remover o primeiro. E você pode pagar US $ 2 em vez de 2000 por um MacBook.
Gateways e comerciantes intermediários podem evitar essa vulnerabilidade, sempre verificando se o valor do pagamento retornado pelo MIGS corresponde ao solicitado.
A MasterCard me recompensou por identificar esse erro com um prêmio de US $ 8500.
Vulnerabilidade de hash HMAC-SHA256O novo HMAC-SHA256 possui uma vulnerabilidade que pode ser explorada se injetarmos valores incorretos no gateway de pagamento intermediário. Eu verifiquei esse erro em um dos gateways de pagamento (Fusion Payments). Eles me pagaram um bônus de $ 500 por isso. Essa vulnerabilidade também pode afetar outros gateways de pagamento conectados ao MIGS.
Na nova versão, delimitadores (&) entre campos, nomes de campos (não apenas valores) foram adicionados e, é claro, HMAC-SHA256. Para os mesmos dados de antes, a linha de hash é assim:
Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe
Não podemos mover nada, tudo neste plano está em ordem. Mas e se o valor contiver os caracteres & ou = ou algum outro?
Depois de ler o documento de referência de integração do cliente de pagamento virtual do MiGS, descobri:
"Observação: o valor em todos os pares nome / valor, para fins de hash, NÃO deve conter caracteres de URL"Eu me concentro em
NÃO . Isso significa que se tivermos os seguintes campos:
Valor = 100
Cartão = 1234
CVV = 555
O hash será assim: HMAC (Montante = 100 & Card = 1234 & CVV = 555)
E se os campos forem assim (usando & e =):
Valor = 100 & Cartão = 1234
CVV = 555
Esse hash é assim: HMAC (Valor = 100 & Card = 1234 & CVV = 555)
Da mesma maneira. Mas até agora, não é um problema.
Obviamente, pensei que poderia haver um problema na documentação oficial, talvez caracteres de URL ainda devam ser usados. Mas verifiquei o comportamento do servidor MIGS, tudo estava como no documento. Talvez eles não desejem trabalhar com uma codificação diferente (como + em vez de% 20).
Parece que não deve haver problemas, os valores incorretos serão verificados pela MIGS e cometerão um erro (por exemplo, o tamanho do pagamento incorreto será rejeitado).
Mas notei que em alguns gateways de pagamento, em vez de verificar os dados inseridos no servidor, eles simplesmente assinam e redirecionam tudo para o MIGS. É muito mais fácil testar JavaScript no lado do cliente, assinar os dados no servidor e deixar a MIGS decidir se o número do cartão está correto, se o CVV deve consistir em 3 ou 4 dígitos, se o cartão expira corretamente etc. A lógica é a seguinte: o MIGS verificará novamente os dados e os tornará melhores.
No Fusion Payments, descobri que é isso que acontece: eles permitem que você insira qualquer tamanho de código CVV (a verificação ocorre apenas em JavaScript), assine a solicitação e envie para a MIGS.
ExplorarPara explorar essa vulnerabilidade, precisamos criar uma sequência que seja a solicitação correta e obtenha a resposta correta do servidor MIGS. Não precisamos nos comunicar com o servidor MIGS, apenas fazemos o cliente assinar os dados corretos.
Pedido básico:
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999 & vpc_OrderInfo = vdchecececurur
E a resposta básica do servidor será assim:
vpc_Message = Aprovado & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_Secure25Spe25
No caso do Fusion Payment, a exploração é implementada implementando vpc_CardSecurityCode (CVV)
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3dA & vpc_OrderInfo = Orderinfo & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256
O cliente / gateway de pagamento gera o hash correto para esta linha.
Agora podemos inserir esses dados no próprio cliente (sem interagir com o servidor MIGS de forma alguma), mas vamos alterá-los um pouco para que o cliente reconheça as variáveis necessárias (a maioria dos clientes apenas verifica vpc_TxnResponseCode e vpc_TransactionNo):
vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 & vpc_Message = Aprovado & vpc_OrderInfo = Orderinfo & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256
Nota:
O hash será o mesmo que com os dados anteriores.
O cliente ignorará vpc_AccessCode e seu valor.
O cliente manipulará vpc_TxnResponseCode etc., assumindo que a transação esteja correta.
Pode-se dizer que este é um erro do cliente MIGS, mas o método de hash usado pelo MasterCard permite que esse erro exista. Se os valores fossem codificados, essa vulnerabilidade não existiria.
Resposta da MIGSA MasterCard não respondeu a esse erro no HMAC-SHA256. Entrei em contato com várias pessoas que já havia contatado anteriormente sobre uma vulnerabilidade anterior. Não há resposta. Mesmo cancelando a inscrição no estilo de "testamos". Eles têm meu Facebook se quiserem entrar em contato comigo (desde a correspondência sobre o MD5).
Alguns aparentemente fingem que não viram meu relatório, mas coloquei uma senha na carta. Havia pelo menos três visualizações do endereço IP da MasterCard. Ao mesmo tempo, não são cliques aleatórios sem leitura, pois é necessário inserir conscientemente a senha. Eu escrevo para eles toda semana.
Minha expectativa era que eles avisassem a todos que se conectassem ao seu sistema para verificar e filtrar os dados incorporados.
Lacunas nos gateways de pagamentoAlém disso, quero dizer: apesar de os gateways de pagamento lidarem com dinheiro, eles não são tão seguros quanto parece. Durante meus pentests (testes de penetração), descobri várias vulnerabilidades nos protocolos de pagamento em vários gateways intermediários. Infelizmente, não posso contar os detalhes (se eu disser "pentest", isso é algo que se enquadra no contrato de não divulgação).
Eu também encontrei erros de implementação. Por exemplo, ataques de extensão hash, XML, erros de verificação de assinatura etc. Um dos erros mais fáceis que encontrei no Fusion Payments. O primeiro bug que encontrei foi: eles nem sequer verificam assinaturas do MIGS. Isso significa que podemos simplesmente modificar os dados retornados pelo MIGS e marcar a transação como bem-sucedida. Isso significa apenas alterar um caractere: de F (sem êxito) para 0 (com êxito).
Ou seja, podemos inserir qualquer número de cartão, receber uma resposta incorreta da MIGS, alterá-lo e, de repente, o pagamento se torna bem-sucedido. Esta é uma empresa com um orçamento de 20 milhões e recebi 400 dólares deles. Este não é o único gateway de pagamento com essa vulnerabilidade, durante o meu teste, encontrei isso em outros gateways. Apesar da pequena recompensa, o Fusion Payments é atualmente o único gateway de pagamento que entrei em contato, o que é muito claro em seu programa de recompensa por bugs encontrados. Eles responderam muito rapidamente às minhas mensagens e rapidamente corrigiram seus erros.
ConclusãoOs gateways de pagamento não são tão seguros quanto você pensa. Com essas recompensas baixas (e, em alguns casos, recebi US $ 0), imagino quantas pessoas já exploraram essas vulnerabilidades nos gateways de pagamento.
Comentário do tradutorQuero acrescentar algumas palavras às conclusões do autor do estudo. Antes de tudo, este estudo é um aviso e um alerta para os vendedores, pois as vulnerabilidades encontradas os tornam vítimas de invasores. Mas existem muitos outros bugs que podem ser prejudiciais aos clientes (portadores de cartão, usuários de sistemas de pagamento etc.). Tenha cuidado ao inserir suas informações pessoais de cobrança em um site não verificado. Melhor ainda, tenha à sua disposição um cartão bancário separado, no qual haverá exatamente o valor necessário para fazer uma compra na Internet.
Você encontrou algum erro nos sistemas de pagamento ou talvez tenha sido vítima de tais erros? Compartilhe suas experiências, opiniões e dicas sobre como se proteger nos comentários. Tenha um bom dia e faça compras com segurança.
Como um anúncio. Promoção! Agora, obtenha apenas
4 meses de uso gratuito de VPS (KVM) com unidades dedicadas na Holanda e nos EUA (configurações de VPS (KVM) - E5-2650v4 (6 núcleos) / 10GB DDR4 / 240GB SSD ou 4TB HDD / 1Gbps 10TB - US $ 29 / mês e acima, estão disponíveis opções com RAID1 e RAID10) , um análogo completo de servidores dedicados. Ao fazer o pedido por um período de 1 a 12 meses, os
termos da ação estão aqui, os assinantes existentes podem receber 2 meses como bônus!
Como construir a infraestrutura do edifício. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?