Ataques de Business Logic em Fintechs: Quando a Vulnerabilidade Está no Processo

Você acabou de assinar um cheque de R$ 2 milhões para licenciar o WAF mais avançado do mercado. Sua equipe de AppSec roda pipelines de CI/CD impecáveis, e os relatórios do SonarQube mostram zero vulnerabilidades críticas. Seu CISO dorme tranquilo. Três dias depois, sua fintech perde R$ 15 milhões em 48 horas. Nenhum alarme soou. Nenhum SQL Injection foi tentado. Nenhum malware foi instalado.

O que aconteceu? Um garoto de 19 anos descobriu que, se ele agendasse um Pix e cancelasse a transação no exato milissegundo em que o sistema de liquidação consultava o saldo, o dinheiro saía da conta, mas o saldo não era debitado. Ele repetiu o processo 400 vezes.

Bem-vindo ao submundo dos ataques de Business Logic (lógica de negócio). Nós acompanhamos o mercado financeiro brasileiro há mais de 15 anos e podemos afirmar: a maior ameaça silenciosa para Nubank, Stone, PagSeguro e centenas de SCDs (Sociedades de Crédito Direto) não é o hacker russo buscando quebrar a criptografia. É o fraudador local que entende as regras de negócio da sua plataforma melhor que os seus próprios desenvolvedores.

O Ponto Cego das Ferramentas de Segurança

Ferramentas de SAST (Static Application Security Testing) e DAST (Dynamic Application Security Testing) são brilhantes para encontrar erros de sintaxe. Elas sabem identificar um Cross-Site Scripting (XSS) ou um Buffer Overflow. Elas varrem o código em busca de bibliotecas desatualizadas mapeadas em bancos de dados de CVEs (Common Vulnerabilities and Exposures).

O problema? Essas ferramentas não fazem a menor ideia de como um banco funciona.

Um scanner não sabe que um usuário com perfil "Cliente Varejo" não deveria conseguir aprovar o próprio limite de crédito. O scanner vê uma requisição HTTP perfeitamente formatada, com um token JWT válido, chamando uma API de limite de crédito. A sintaxe está correta. A autorização técnica (o token) existe. O WAF deixa passar.

A vulnerabilidade não está no código escrito; está no design do processo. O ataque de lógica de negócio usa a aplicação exatamente como ela foi projetada para ser usada, mas manipula o fluxo para obter uma vantagem indevida. É o equivalente digital a entrar em um restaurante, pedir um prato de R$ 100, usar um cupom de R$ 50, pedir para cancelar metade do prato e receber R$ 50 de troco em dinheiro vivo. A caixa registradora permite a operação matemática, mas o dono do restaurante acaba de ser roubado.

Conversamos frequentemente com auditores do Banco Central e diretores de segurança cibernética. A estimativa não oficial é assustadora: falhas lógicas respondem por mais de 70% das fraudes transacionais complexas no ecossistema Pix e Open Finance hoje.

Casos Reais: A Anatomia do Prejuízo no Brasil

Para entender a gravidade do problema, precisamos olhar para as trincheiras. Selecionamos três vetores de ataque clássicos que causaram estragos reais no mercado brasileiro recente. Os nomes das instituições foram omitidos por questões de confidencialidade, mas as mecânicas são exatas.

A Ilusão do Limite Duplicado via Boleto

Uma fintech de cartões de crédito queria oferecer a melhor experiência do usuário (UX) possível. A regra de negócio era clara: quando o cliente paga a fatura, o limite do cartão deve ser restabelecido instantaneamente.

Como o Brasil ainda usa o sistema de boletos e a compensação pela Nuclea (antiga CIP) leva até D+1, a fintech implementou uma regra de confiança. Se o cliente gerasse o boleto no aplicativo da fintech e informasse "já paguei", ou se o sistema detectasse a entrada do código de barras na rede bancária, o limite era liberado na hora, antes da liquidação financeira (o dinheiro real bater na conta da fintech).

O ataque de business logic explorou exatamente essa ansiedade por UX. Quadrilhas começaram a gerar boletos de pagamento da fatura (ex: R$ 10.000). Eles agendavam o pagamento do boleto em um bancão tradicional para o mesmo dia. A rede bancária registrava a intenção. A fintech lia o registro e liberava os R$ 10.000 de limite instantaneamente.

Imediatamente, os fraudadores faziam compras de alto valor ou transferiam o dinheiro via Pix usando o limite de crédito recém-liberado. Horas depois, eles cancelavam o agendamento do boleto no bancão. O dinheiro nunca chegava à fintech, mas o limite já havia sido gasto. Prejuízo direto no balanço.

O Loop Infinito de Cashback

A guerra pelas maquininhas e contas digitais criou programas de incentivo agressivos. Uma carteira digital brasileira lançou uma promoção: 10% de cashback para compras feitas em estabelecimentos parceiros, com limite de R$ 500 de cashback por transação.

O erro de design? A plataforma permitia que um mesmo CPF tivesse uma conta de pessoa física (pagadora) e uma conta de microempreendedor - MEI (recebedora), operando na mesma infraestrutura de pagamentos.

O fraudador criava as duas contas. Usava o cartão de crédito da conta PF para "comprar" R$ 5.000 na própria conta MEI. A transação gerava R$ 500 de cashback instantâneo na conta PF. A taxa de antecipação e processamento que a plataforma cobrava do MEI era de 4% (R$ 200).

Lucro líquido do fraudador por transação: R$ 300. Eles automatizaram isso usando scripts simples (bots) que faziam a compra, recebiam o cashback, transferiam o dinheiro de volta e repetiam a operação centenas de vezes de madrugada. A aplicação funcionou perfeitamente segundo o código. O processo, no entanto, foi desenhado sem prever o risco de auto-financiamento circular.

Race Conditions no Saque de Criptoativos

Exchanges de criptomoedas no Brasil sofrem com isso há anos. A Race Condition (condição de corrida) é um ataque onde o invasor envia múltiplas requisições simultâneas para o servidor em um intervalo de milissegundos.

Imagine que o usuário tem 1 BTC na conta. Ele clica em "Sacar 1 BTC". A aplicação verifica o saldo (Sim, ele tem 1 BTC). A aplicação processa a transferência na blockchain. A aplicação atualiza o saldo para 0 BTC.

Se o invasor envia 10 requisições de saque exatamente ao mesmo tempo, o sistema pode verificar o saldo para todas as 10 requisições antes que o banco de dados tenha tempo de aplicar o "lock" e atualizar o saldo para zero. O resultado? O sistema autoriza 10 saques de 1 BTC, embora o usuário só tivesse 1 BTC. A exchange assume o rombo de 9 BTC.

O Peso da Regulação: BACEN e CVM Não Aceitam Desculpas

Se você opera no mercado regulado, o problema ganha uma camada jurídica pesada. O Banco Central do Brasil, através de resoluções como a 4.893 (e a mais recente Resolução Conjunta nº 6 de Cybersecurity), exige que as instituições implementem controles contínuos de segurança e testes de invasão.

O BACEN não se importa se a invasão ocorreu por um 0-day no Windows ou por uma falha de lógica no seu sistema de liquidação do SPI (Sistema de Pagamentos Instantâneos). O regulador avalia o risco sistêmico e a proteção do consumidor. Se um ataque de business logic permitir que um usuário acesse dados de terceiros ou desvie fundos, sua instituição enfrentará multas severas, exigência de provisionamento extra de capital e, no limite, a suspensão da autorização de funcionamento.

Além disso, o COAF (Conselho de Controle de Atividades Financeiras) entra no jogo se a falha lógica for usada para lavagem de dinheiro. Vemos rotineiramente criminosos explorando falhas de arredondamento em sistemas de câmbio ou cripto para "limpar" pequenos valores em altíssima frequência (smurfing), passando abaixo dos radares de monitoramento padrão.

Como Blindar a Operação Financeira

Delegar a segurança de negócio para o time de infraestrutura é assinar um atestado de incompetência gerencial. A defesa contra falhas de business logic exige uma mudança radical na forma como os produtos financeiros são concebidos.

1. Modelagem de Ameaças (Threat Modeling) no Dia Zero

A segurança precisa sentar na mesa de produto. Antes de escrever a primeira linha de código da nova funcionalidade de Pix Garantido, o time de segurança deve perguntar: "Como eu posso abusar disso para ganhar dinheiro?".

O Product Manager (PM) foca no "caminho feliz" — o usuário clica aqui, paga ali, recebe o recibo. O profissional de AppSec precisa mapear o "caminho do caos" — o usuário clica aqui, desliga a internet, altera o payload da requisição para um valor negativo e envia.

2. Pentests Manuais e Especializados

Testes de intrusão genéricos não servem. Contratar uma consultoria de segurança que vai rodar o Burp Suite no modo automático e entregar um PDF de 200 páginas com falsos positivos de cabeçalhos HTTP é jogar dinheiro fora.

Você precisa de Red Teams especializados em mercado financeiro. Pessoas que entendem como funciona a mensageria ISO 20022, que sabem a diferença entre saldo contábil e saldo disponível, e que vão testar ativamente a lógica de liquidação, estorno e conciliação da sua plataforma.

3. Controle Estrito de Estado e Máquinas de Estado

A grande maioria das falhas de lógica ocorre porque o sistema perde a rastreabilidade do estado de uma transação. A transação está "pendente", "processando" ou "concluída"?

Implemente bloqueios rigorosos de banco de dados (pessimistic locking) para operações financeiras. Nunca confie no input do cliente. Se o cliente diz que o preço do produto no carrinho é R$ 10, o backend deve recalcular o preço consultando o banco de dados interno antes de fechar a compra.

4. Monitoramento Comportamental (Anti-Fraude vs Segurança)

A linha entre fraude e ataque de segurança desaparece na lógica de negócio. Seu sistema de monitoramento não deve olhar apenas para IPs maliciosos. Ele deve olhar para anomalias financeiras. Uma conta que recebe 50 estornos no mesmo dia não está sofrendo um bug; está explorando o sistema. A integração entre a área de Prevenção a Fraude e o Centro de Operações de Segurança (SOC) é inegociável.

O Preço da Complexidade

O mercado financeiro brasileiro é um dos mais sofisticados e rápidos do mundo. O Pix mudou a velocidade do dinheiro de dias para segundos. Essa velocidade trouxe uma inovação absurda, mas reduziu a janela de tempo que as instituições têm para identificar e bloquear um comportamento anômalo.

Cada nova funcionalidade — Open Finance, Drex (Real Digital, com seus smart contracts que são, por definição, pura lógica de negócio), iniciação de pagamentos — multiplica exponencialmente a superfície de ataque lógico.

A tecnologia de defesa continuará evoluindo. Inteligência artificial já começa a ser treinada para entender fluxos de negócio e apontar anomalias de design. Até que isso seja perfeito, a responsabilidade recai sobre a arquitetura humana. Produtos financeiros seguros não nascem de ferramentas caras, nascem de processos paranoicos e times que pensam como fraudadores antes de escreverem como desenvolvedores.