Pentest de API no caso BRB: 520 Pix em 4 horas

O sistema BRBJUS, que o BRB opera para o Tribunal de Justiça da Bahia, perdeu R$ 53,1 milhões em 520 transferências Pix que ninguém autorizou. A causa do problema está em disputa e o caso corre no Supremo Tribunal Federal. Minha tese não é sobre a causa. É esta: seja ela qual for, uma API de pagamento sem teto por janela e sem detecção de anomalia deixou um acesso indevido virar 520 operações em quatro horas.

O que você leva deste texto: por que “senha forte” não é segurança de API, e o que exigir no escopo do próximo teste para que a sua equipe não descubra isso pela imprensa.

O que aconteceu

Segundo reportagem do Bastidor publicada no Convergência Digital, as operações tiveram início por volta de 6h10 de 17 de setembro. Às 10h o banco confirmou as anomalias e, às 10h10, bloqueou o sistema, quatro horas depois do primeiro Pix. A primeira estimativa apontava R$ 43 milhões, valor que subiu para R$ 53,1 milhões. Diante do episódio, o BRB acionou o mecanismo de devolução do Pix, comunicou o Banco Central e se comprometeu a recompor o valor nas contas judiciais.

Sobre a origem, há duas versões e elas não concordam.

O TJBA enviou ofício em 19 de setembro apontando que o incidente ocorreu em ambiente de propriedade do BRB. O banco apresentou versão diferente: em ofício de 22 de setembro, afirmou que a origem do problema foi externa ao ambiente sob sua gestão. Segundo a reportagem, o banco aponta um certificado digital externo como responsável pelo desvio. Em documento de 21 de setembro, o BRB havia descrito a vinculação do certificado digital ao CPF como uma proposta. A Procuradoria-Geral do Distrito Federal juntou os documentos ao processo que corre no Supremo Tribunal Federal, e o TJBA abriu processo administrativo em 25 de setembro.

Ninguém sabe ainda se o que houve foi comprometimento de certificado, falha de integração ou outra coisa. A causa vai ser apurada. O que a fonte permite afirmar sem risco é o efeito: 520 transferências, quatro horas de janela, nenhuma trava aparente.

Recentemente o TJBA restabeleceu o sistema com limites de operação: R$ 1 milhão no período diurno, a partir das 7h, e R$ 100 mil no noturno, a partir das 18h. A instituição chamou a medida de preventiva e temporária, com o objetivo de reforçar a segurança, o monitoramento e a rastreabilidade das operações.

Dois números merecem atenção. O primeiro é que a estimativa inicial ficou mais de R$ 10 milhões abaixo do valor final, o que mostra o tamanho do erro de quem mede dano por amostragem. O segundo é que o bloqueio aconteceu quatro horas depois do início das operações.

Por que isso não é um caso de senha fraca

Existe uma classe de falha que não aparece em relatório de scan. Ela acontece quando a autenticação funciona, o usuário está identificado, e mesmo assim ele consegue fazer algo que não deveria.

Imagine o endpoint que recebe uma transferência. Ele valida: o usuário está autenticado? sim. A conta existe? sim. O valor está dentro do saldo? sim. O que ele não valida é justamente o que deveria validar primeiro: quantas vezes aquela conta pode ser debitada em uma janela de dez minutos, e se aquele destino já apareceu nas outras 519 transferências.

Nenhuma ferramenta automatizada de vulnerabilidade acha isso. Ela procura padrão de código conhecido. Aqui o código está certo. A regra de negócio é que não existe.

E é isso que o caso mostra, qualquer que seja a origem. Um certificado comprometido, um erro de integração, uma falha de processo: qualquer um desses vira dano limitado quando existe teto por operação e detecção de anomalia por volume e por destino. Sem eles, o dano escala até o sistema inteiro acordar.

Se eu fosse o CTO daquela empresa, a primeira coisa que eu pediria amanhã não seria um pentest de infraestrutura. Seria uma revisão das regras de negócio da API de transferência: teto por operação, teto agregado por janela, detecção de anomalia, idempotência e o caminho de auditoria que mostra quem pediu o quê.

O que exigir no escopo do próximo pentest

A maior parte dos escopos que eu leio testa autenticação até a exaustão e trata a API como apêndice do sistema. Isso é confortável e não encontra o que tira dinheiro.

Três coisas mudam o resultado.

Primeiro, lógica de negócio nomeada no escopo, por escrito. Sem as regras na página, o teste roda o OWASP API Top 10 e entrega um relatório bonito que não responde se alguém consegue sacar vinte vezes em um minuto.

Segundo, teste de teto por destino. Se a sua API aceita o mesmo valor para a mesma conta mil vezes em uma hora e você não tem regra contra isso, isso é achado, não discussão.

Terceiro, relatório que diz o que não foi testado. Relatório que só lista o que encontrou esconde o buraco maior, que é o que ninguém pediu para olhar.

O que fazer agora

• Peça que o escopo do teste de API liste as regras de negócio a verificar, não só o OWASP.
• Teste teto por operação e teto agregado por janela em qualquer API que movimenta dinheiro.
• Verifique se existe detecção de anomalia por volume e por destino, e quanto tempo o alerta leva para chegar a alguém.
• Peça relatório com o que não foi testado, e com retest depois da correção.
• Trate o caso do BRB pelo que ele é: um processo que percebeu o problema quatro horas depois do início das operações. A diferença entre a primeira estimativa e o valor final passou de R$ 10 milhões.

Amanhã alguém pergunta por que o banco não avisou antes. A resposta é sempre a mesma, e não muda de empresa: ninguém tinha construído o detector antes do incidente precisar dele.