Termos mais procurados:
1 e 2) Enquanto você discute de quem é o problema, o fraudador embolsou a sua grana e do seu cliente
3) Não, MITM de anúncio assinado você pega qualquer roteador que esteja na Internet, pega os anúncios e repassa. Aí você recebe o tráfego, muda o que você quer muda, devolve o que não vai mudar. Quem foi hackeado aí foi o backbone Internet, não a AWS ou a Gerencianet.
1) Problema de quem anuncia
2) Problema de quem não verifica
3) MITM de anúncios assinados não seria literalmente a definição de hackear?
Eu sei que existe, o meu empregador que assina os RPKI brasileiros... 😉
Mas se você sabe que existe RPKI, deveria saber também que:
1) Nem todos os blocos IP já estão assinados
2) Nem todos os roteadores já verificam RPKI
3) RPKI endereça apenas hijacking com ASN origem errado, ainda é possível fazer hijack usando MITM de anúncios assinados
Existe um negócio chamado RPKI. Então acho mais fácil hackearem a Gerencianet do que a AWS.
Veja como foi este caso de IP hijacking há alguns anos atrás:
https://www.zdnet.com/article/aws-traffic-hijack-users-sent-to-phishing-site-in-two-hour-cryptocurrency-heist/
IP hijacking não precisa de comprometimento da Gerencianet. Alguém anuncia a rede do AWS onde fica a Gerencianet e desvia o tráfego para o hijack.
Como complemento, ótimo... dá para fazer estas checagens hoje no webhook:
1) O IP é o da lista da Gerencianet
2) O certificado é assinado pela CA da Gerencianet
3) O certificado tem o CN gn-webhook-pix
4) A chave Pix é uma chave para qual você registrou webhook
5) A transação é uma que você criou
mTLS também não é garantia, pq alguém pode hackear a Gerencianet, e roubar os certificados do mTLS, e sair por aí enviando webhooks fraudulentos, se for seguir por essa lógica.
Ou, você além das verificações normais no backend, simplemente coloca um firewall aceitando solicitações somente dos IPs do gateway.
Sobre pedir mTLS, há duas estratégias para garantir integridade: uma é a que você mesmo vê na API de emissões da Gerencianet, onde a notificação só avisa de mudança de estado e você precisa de requisição direta para obter a alteração. A outra é carregar informação na requisição, e aí precisa de mTLS para ter certeza de quem veio. O Banco Central escolheu a 2a., mas ambas são alternativas válidas.
Eu sou também, pq eles fizeram recursos de segurança funcionais, como por exemplo criar um token pro cartão de crédito que não fica salvo no servidor. Isso tudo em documentação oficial.
Sim, eu tenho gateways de pagamento pra cartão de crédito, e eles também não pedem mTLS, e são PCI Compliance.
O Banco Central neste caso é instituidor do arranjo. Visa e Mastercard não são estatais, e ambos especificam tanto funcionalidade quanto segurança, criaram o PCI Security Council para definir segurança. A questão não é ser estatal ou não.
Veja você mesmo a tonelada de requisitos de segurança dos arranjos de cartão:
https://www.pcisecuritystandards.org/
