Além do armazenamento seguro, parte 1: projetando fluxos seguros de pagamento e assinatura

O relato preliminar da Binance sobre o incidente de 30/10/2026 descreve como um token de implantação roubado levou ao acesso ao serviço interno de assinatura e a transações fora do processo normal de saque [1]. Segundo o caminho divulgado, o invasor podia solicitar assinaturas sem antes obter acesso à chave privada da carteira.

Aqui, o alvo do invasor é a capacidade de assinatura do sistema. O armazenamento seguro, incluindo criptografia e isolamento por hardware, pode proteger a chave, mas não pode determinar se um pagamento tem autorização comercial válida. Isso levanta a questão: como uma operação não autorizada obtém uma assinatura válida?

Responder a essa pergunta exige acompanhar como uma solicitação comercial se transforma em uma transação assinada e executada. Um pagamento executado por meio de uma carteira passa por autorização comercial, construção da transação, assinatura, execução e liquidação [2, 3]. A figura mostra o uso indevido desse fluxo de trabalho ao lado de outra forma de obter capacidade de assinatura: recuperar a chave explorando falhas na implementação criptográfica.

A série Além do Armazenamento Seguro usa incidentes reais para derivar princípios de projeto e implementação que abordem esses riscos. A Parte 1, Projetando Fluxos de Trabalho Seguros para Pagamentos e Assinaturas, examina como invasores fazem uso indevido da capacidade de assinatura do sistema original sem obter suas chaves privadas. A Parte 2, Implementando a Criptografia de Carteiras com Segurança, examina falhas de implementação que permitem a invasores recuperar chaves e assinar de forma independente. Nenhum dos dois caminhos exige o roubo direto do segredo protegido.

A Seção 1 usa incidentes reais para examinar riscos e premissas negligenciadas ao longo do fluxo de trabalho de pagamentos e, em seguida, deriva verificações de projeto e implementação para abordá-los. A Seção 2 parte da hipótese de que essas verificações não impediram uma operação não autorizada e examina como limitar as perdas decorrentes. A Seção 3 explica como revisões de projeto, auditorias, testes de invasão e exercícios podem verificar tanto a prevenção quanto a contenção de perdas.

1. Projetar para Impedir Operações Não Autorizadas

O mesmo fluxo de trabalho de pagamentos pode atender a diferentes finalidades comerciais. A figura apresenta três operações representativas de custódia: depósitos estabelecem direitos sobre saldos de conta, saques atendem a instruções de clientes e transferências de tesouraria implementam decisões institucionais de movimentação de recursos.

Depósitos validados geram crédito em conta, não uma instrução automática de pagamento. Um saque exige uma solicitação e uma aprovação separadas do cliente; uma transferência de tesouraria parte de uma decisão institucional de movimentação de recursos. Ambos passam pela construção da transação, assinatura, execução e liquidação. Na custódia com ativos agrupados, o livro-razão registra os direitos dos clientes sem exigir que os ativos permaneçam em um endereço exclusivo para cada cliente.

Três operações representativas de custódia. A separação funcional, por si só, não estabelece identidades independentes nem limites de permissão.

Essas operações têm motivos diferentes para movimentar fundos. Outras operações comerciais podem seguir as mesmas etapas, mas exigir evidências ou aprovações diferentes. Em cada etapa, a questão de segurança é se a justificativa do pagamento, a transação, o uso da autoridade de assinatura e a liquidação ainda correspondem à operação pretendida.

Cada uma dessas etapas pode se tornar um ponto em que um invasor influencia o que é assinado ou executado. Uma solicitação forjada pode criar uma aparente obrigação de pagamento; a construção da transação pode substituir a operação aprovada por outra não aprovada; permissões comprometidas podem dar acesso à assinatura; e falhas na execução ou liquidação podem manter utilizável uma autoridade indesejada ou desencadear um pagamento injustificado.

A tabela abaixo relaciona os riscos às etapas do fluxo de trabalho e aos casos usados para examiná-los.

Etapa do Fluxo de Trabalho	Questão de Segurança	Caso Analisado
1,1 · Justificativa e Autorização do Pagamento	O pagamento está fundamentado em uma solicitação genuína, no direito de movimentar os fundos e em uma aprovação válida?	Solicitações de saque forjadas na Bitget [4]; comprometimento da lógica de contas e riscos na BigONE [5, 6]
1,2 · Construção e Verificação da Transação	O conteúdo completo da transação expressa a operação aprovada?	Caminho de transferência enganosa até a tomada de controle na Bybit [7, 8]; resposta de transação alterada na Kiln/SwissBorg [9, 10]
1,3 · Autorização de Assinatura e Uso da Chave	Quem pode assinar ou alterar quem tem permissão para assinar?	Tomada de controle da política de chaves na Resolv [11]; acesso ao serviço de assinatura relatado pela Binance [1]
1,4 · Execução e Liquidação	Quando a autoridade conferida por uma assinatura pode ser exercida e o que justifica o pagamento seguinte?	Execução tardia na Drift e reembolso indevido na Chainflip [12, 13, 14]

1,1 Justificativa e Autorização do Pagamento

Antes que um pagamento avance para a construção e a assinatura da transação, a instituição deve confirmar a existência de uma solicitação genuína, o direito do solicitante de movimentar os fundos e uma aprovação válida para a operação especificada. Um saldo de cliente ou uma solicitação interna autenticada, isoladamente, não comprova os três requisitos.

Casos de Falha: Justificativa de Pagamento Fabricada

No incidente de 24/09/2026 da Bitget, o invasor explorou um produto de segurança de terceiros para obter credenciais internas de alto nível. Segundo o relato oficial da Bitget, essas credenciais foram usadas para enviar comandos fraudulentos de saque ao sistema de carteiras, resultando em transferências que contornaram seus controles de risco existentes [4]. Os comandos chegaram ao processo de pagamento por meio de acesso interno, mas esse acesso não comprovava a existência de uma instrução legítima do cliente nem de uma decisão de tesouraria.

A BigONE divulgou movimentações não autorizadas de suas carteiras quentes em 16/07/2025 e afirmou que suas chaves privadas permaneceram seguras. A BigONE Eurasia atribuiu o incidente na plataforma global a alterações na lógica de contas e de controle de riscos em produção [5, 6]. Isso aponta para uma preocupação relacionada: os registros e as regras usados para justificar um pagamento também podem ser alterados. O relato público não divulga os registros detalhados das solicitações nem a API de assinatura; portanto, não demonstra que o mecanismo de ataque tenha sido o mesmo do caso da Bitget.

Esses casos expõem o risco de tratar o acesso interno ou os registros de contas como justificativa suficiente para um pagamento: um invasor pode alterar as credenciais, os registros ou as regras dos quais essa decisão depende.

Controles a Verificar

As revisões de projeto e implementação devem, portanto, verificar se cada solicitação pode ser rastreada até uma justificativa comercial genuína e se quem a apresenta também pode fabricar os registros que a sustentam ou aprová-la.

Verificar a origem, a integridade e a autorização da solicitação. Cada pagamento deve ser rastreável até uma instrução genuína do cliente, um evento comercial ou uma decisão institucional, com evidências do direito de movimentar os fundos e da aprovação. Verifique se as alterações na solicitação e nos registros que a sustentam continuam rastreáveis e se evidências fabricadas ou alteradas não podem estabelecer uma autorização apenas por virem de um serviço interno ou serem compatíveis com um saldo de conta.
Manter a validação e a aprovação independentes da criação da solicitação. Quem apresenta uma solicitação não deve também poder fabricar as evidências que a sustentam ou aprová-la. Preserve essa separação tanto nas permissões operacionais quanto nas administrativas. Verifique se alterações em registros, regras de aprovação ou atribuições de funções — incluindo exceções manuais e procedimentos de recuperação — poderiam permitir que uma única parte controlasse a solicitação e as verificações destinadas a rejeitá-la.

Uma vez estabelecida de forma independente a justificativa do pagamento, a próxima questão é se a transação expressa a operação aprovada.

1.2 Construção e Verificação da Transação

Depois que uma solicitação de pagamento é aprovada, o componente que constrói a transação a converte nos dados não assinados enviados para assinatura. O conteúdo completo da transação — incluindo destino, valor, operação e qualquer alteração no controle da carteira — deve expressar a solicitação aprovada. A aprovação de uma transferência não autoriza operações adicionais; a verificação deve examinar os dados reais a serem assinados, não apenas sua descrição em uma interface.

Casos de Falha: Operações Assinadas Divergem da Aprovação

A Bybit pretendia transferir ETH de uma carteira fria para uma carteira morna. Sua atualização oficial atribui a invasão ao comprometimento das credenciais de um desenvolvedor da Safe, que permitiu o acesso à infraestrutura da provedora e a indução dos signatários ao erro [7]. A Safe verifica assinaturas sobre campos da transação, incluindo to, value, data e operation, por meio de execTransaction [15]. Mas a interface comprometida manteve a aparência da transferência esperada enquanto substituía campos por valores maliciosos antes da assinatura. As assinaturas eram válidas para os bytes substituídos [7].

A transação resultante usou DELEGATECALL para alterar a implementação da carteira, permitindo que o invasor esvaziasse seus ativos sem nova aprovação dos proprietários originais [7, 8]. A operação comercial aprovada era uma transferência; a operação assinada alterou quem podia controlar a carteira. Conferir o destinatário exibido ou o valor imediato da transação não teria demonstrado que a operação completa correspondia à aprovação.

O incidente da Kiln/SwissBorg mostra que transações maliciosas também podem ser introduzidas pela modificação de um serviço de construção de transações em execução. A Kiln informou que um token do GitHub comprometido levou, por meio de fluxos de trabalho de CI, à obtenção de credenciais de produção. O invasor modificou um pod do Kubernetes em execução, sem alterar a imagem implantada, para retornar uma alteração da autoridade de saque junto com uma transação legítima de desativação de staking na Solana. Os signatários do serviço de custódia do cliente aprovaram a transação acrescentada; a Kiln situa a assinatura em 31 de agosto e a detecção em 08/09/2025 [9]. A SwissBorg também atribuiu a adulteração da transação à infraestrutura da provedora. As partes divergiram quanto à usabilidade e à integração das ferramentas de decodificação disponíveis na época [10].

Controles a verificar

Os casos da Bybit e da Kiln/SwissBorg mostram como uma transação pode divergir daquilo que o signatário pretendia aprovar. O projeto deve vincular a aprovação à operação completa, e a verificação deve examinar a transação real independentemente do serviço que a construiu ou exibiu.

Vincular a aprovação à operação completa. A aprovação deve abranger todos os efeitos da transação, incluindo qualquer alteração no controle dos ativos ou delegação de autoridade para executar operações [16]. Alterações fora desse escopo exigem nova aprovação. Verifique se operações substituídas ou acrescentadas não podem herdar a aprovação de um pagamento legítimo e se tentativas repetidas não podem reutilizar uma aprovação para autorizar pagamentos adicionais.
Verificar independentemente a transação e seus efeitos. Compare os dados reais enviados para assinatura com a operação comercial aprovada, abrangendo cada transação de um lote e seus efeitos sobre ativos e permissões. A verificação deve ser independente do serviço que constrói ou exibe a transação. Verifique se esse serviço pode alterar o verificador ou contornar suas verificações e se apresentações enganosas ou transações modificadas são rejeitadas.

As verificações acima tratam da correspondência entre a transação e a solicitação aprovada. A etapa de assinatura suscita outra pergunta: alguém pode usar a chave sem a autorização comercial necessária, diretamente ou alterando as permissões de acesso?

1,3 Autorização de assinatura e uso da chave

Uma transação verificada deve chegar ao serviço de assinatura por meio de um solicitante autorizado. As políticas de chaves e as funções administrativas determinam quem pode usar a chave pertinente e quem pode alterar esse acesso. A permissão para solicitar uma assinatura não autoriza todas as transações, e a permissão para administrar o serviço não deve criar uma via de assinatura sem verificações. Portanto, esta etapa abrange tanto o uso da chave para a operação aprovada quanto a autoridade sobre o acesso à chave.

Casos de falha: acesso à assinatura comprometido

O incidente da Resolv em 22/03/2026 mostra como a alteração de uma política de acesso à chave pode abrir uma via de assinatura. Seu processo de emissão exigia que um usuário depositasse garantias e que um serviço off-chain autorizado concluísse a emissão. A análise pós-incidente oficial reconstitui como o acesso ao repositório e à nuvem levou a uma função com privilégios mais elevados, que alterou a política de acesso à chave de assinatura após tentativas anteriores de acesso terem sido negadas. Essa alteração concedeu ao invasor autoridade para assinar em um serviço de gerenciamento de chaves na nuvem que exigia tanto permissões no nível da identidade quanto uma política de acesso no nível da chave [11].

Alterar quem podia assinar permitiu ao invasor autorizar a emissão fora da relação prevista com as garantias, sem convencer o signatário original. O relato estabelece o controle da autoridade para assinar, não a extração do material bruto da chave privada.

A atualização preliminar da Binance sobre seu incidente de 30/10/2026 descreve outra via para obter autoridade para assinar. Segundo a Binance, dispositivos de funcionários comprometidos e uma ferramenta interna de IA permitiram o acesso aos dispositivos de engenheiros responsáveis pelas carteiras; um token de implantação de contêiner roubado foi então usado para implantar um contêiner e executar scripts maliciosos. O invasor obteve acesso não autorizado ao serviço interno de assinatura de carteiras e iniciou transações fora do processo normal de saque [1]. Esse relato relaciona a autoridade para implantar contêineres ao acesso ao serviço de assinatura, mas não revela quais verificações internas de permissão foram contornadas. Diferentemente da alteração de política de chaves relatada pela Resolv, o ponto de entrada divulgado neste caso foi o ambiente operacional do serviço de assinatura.

Controles a verificar

Esses casos expõem o risco de obter ou usar acesso à assinatura fora do fluxo de trabalho comercial previsto. As análises devem verificar se todas as vias de assinatura exigem autorização comercial, inclusive as abertas por alterações de políticas ou privilégios de implantação.

Exigir autorização comercial em todas as vias de assinatura. A permissão para usar uma chave não estabelece autorização para uma operação específica [17, 18, 19]. Restrinja o uso da chave ao escopo comercial aprovado e verifique se solicitantes alternativos ou o acesso direto não podem contornar essa restrição. A aplicação da autorização deve permanecer independente de qualquer solicitante capaz de enviar pedidos arbitrários de assinatura. Quando uma via não puder cumprir esse requisito, registre a lacuna e avalie suas consequências conforme a Seção 2.
Controlar alterações na autoridade para assinar. Permissões administrativas e de implantação podem criar acesso à assinatura mesmo quando a identidade inicial não pode assinar [20, 21, 22]. Separe o uso da chave da autoridade para alterar políticas de assinatura, identidades ou código implantado e exija aprovação independente para essas alterações. Verifique se nenhuma parte pode usar suas permissões combinadas para conceder a si mesma acesso à assinatura ou remover as verificações comerciais que regem esse acesso.

As verificações de autorização não podem terminar quando uma assinatura é emitida: a transação ainda precisa ser executada dentro das condições aprovadas, e seu resultado deve ser conciliado corretamente.

1,4 Execução e liquidação

A autorização também precisa continuar válida após a assinatura, durante a transmissão, a execução e a liquidação dos registros comerciais e das reservas de saldo associados. Uma assinatura não é prova de que o pagamento foi concluído. A execução deve permanecer dentro do escopo e das condições de validade da autorização; a liquidação deve estabelecer qual obrigação foi cumprida e se outro pagamento é de fato devido. Uma assinatura existente ou uma transferência observada, por si só, não pode estabelecer uma nova obrigação de pagamento.

Casos de falha: uso indevido de autoridade assinada e retorno da liquidação

O caso da Drift ilustra como uma solicitação de assinatura enganosa pode deixar para trás uma autoridade utilizável posteriormente. Em seu incidente de 01/04/2026, aprovações obtidas antecipadamente foram preservadas em transações com nonces duráveis na Solana e enviadas posteriormente para assumir a autoridade administrativa [12]. Um nonce durável controla a validade da transação; ele é diferente do nonce secreto usado na assinatura criptográfica. Ele permite o envio offline ou posterior sem a expiração habitual do hash de bloco recente, embora alterações no estado da conta ou do programa ainda possam impedir a execução. Avançar o nonce invalida as transações vinculadas ao valor antigo [23].

A atualização de recuperação da Drift de 16 de abril propôs dispositivos dedicados de assinatura, verificação fora da interface principal de assinatura, períodos de espera para ações administrativas críticas e a desativação de nonces duráveis para os signatários [24]. Essas medidas tratam tanto do que os signatários aprovam quanto de quando a operação assinada pode ser executada. Elas foram anunciadas como um plano de recuperação; a atualização não estabelece que tenham sido implementadas.

Chainflip distingue swaps de clientes, saques de provedores de liquidez (LP) e operações internas de coleta de depósitos chamadas fetches [25]. Na Tron, os memos das transações podem conter instruções de swap. No relato de 15 de setembro da Chainflip sobre o incidente de 12/09/2026, um invasor enviou um fetch assinado por um validador com um memo malformado sob seu controle. A camada de observação interpretou incorretamente o contexto como um swap malsucedido e emitiu reembolsos além dos saques normais dos LPs, fazendo com que seis saques fossem pagos duas vezes [13, 14].

O erro transformou uma movimentação interna de ativos em evidência de uma nova obrigação perante um cliente. A Chainflip interpretava memos mesmo quando transferências para seu cofre estavam encapsuladas em outras chamadas de contrato. A correção restringiu a interpretação de memos de swap a transferências simples de TRX ou transferências diretas de TRC-20, excluindo chamadas encapsuladas [14]. Um fetch validamente assinado tinha sua própria finalidade; sua execução não justificava um reembolso adicional.

Controles a verificar

Transações assinadas podem permanecer executáveis por mais tempo do que o esperado, e informações sobre a execução podem ser confundidas com uma nova obrigação de pagamento. Por isso, as revisões devem verificar se as condições de execução são de fato aplicadas e se cada pagamento ou reembolso corresponde a uma obrigação genuína ainda não liquidada.

Aplicar as condições de execução aprovadas. As transações assinadas devem continuar sujeitas ao escopo, ao período de validade e às condições de cancelamento aprovados. Verifique se transações antigas ainda podem ser executadas após o vencimento, o cancelamento ou uma mudança na autorização. Vincule as condições pertinentes à operação assinada e verifique se as regras da blockchain ou a lógica de execução da carteira as aplicam; um registro apenas no sistema de negócios é insuficiente.
Liquidar apenas obrigações genuínas e pendentes. Cada pagamento ou reembolso deve corresponder a uma obrigação real que ainda não tenha sido liquidada. Preserve o vínculo entre o evento de negócio original, as tentativas de pagamento e os resultados confirmados. Verifique se novas tentativas, notificações duplicadas, resultados incertos ou transferências internas não podem gerar um pagamento injustificado e se as regras que interpretam as evidências de execução não podem ser alteradas para contornar essas verificações.

2. Projetar para limitar perdas e viabilizar a resposta a incidentes

A Seção 1 usou evidências de incidentes para identificar riscos nos fluxos de trabalho e as verificações de projeto e implementação necessárias para tratá-los. Aqui, pressupomos que essas verificações não tenham impedido uma operação não autorizada, seja por omissão, erro de implementação ou contorno dos controles. O projeto deve então limitar quanto o invasor pode movimentar, contabilizar os fundos que permanecem expostos e preservar a capacidade de detectar abusos e interromper novas saídas de fundos. Essas medidas de contenção de perdas devem ser projetadas e testadas antes de um incidente, juntamente com os controles preventivos.

A tabela resume três objetivos de projeto para limitar perdas e viabilizar a resposta a incidentes.

Objetivo de projeto	Pergunta de segurança	Foco da verificação
2,1 · Limites de gastos aplicados de forma independente	O sistema consegue limitar as saídas acumuladas de fundos quando ocorrem pagamentos não autorizados?	Aplicação independente; contabilização acumulada consistente; proteção contra alterações ou contorno dos limites
2,2 · Saldos disponíveis, reposições e transações assinadas pendentes	Quanto poderia ser perdido antes de o ataque ser contido?	Saldos acessíveis e entradas posteriores; restrições às reposições; fundos expostos a autorizações assinadas pendentes
2,3 · Monitoramento independente e resposta a incidentes	O sistema consegue detectar operações não autorizadas e interromper novas saídas de fundos?	Evidências confiáveis; alertas que permitam agir; controles de resposta eficazes e disponíveis de forma independente

2,1 Limites de gastos aplicados de forma independente

Mesmo que um pagamento não autorizado passe pelas verificações anteriores, o sistema deve limitar quanto ele e os pagamentos subsequentes podem movimentar. Isso exige um orçamento aplicado fora do controle presumido do invasor, que cubra tanto transações individuais quanto gastos acumulados. Um limite configurado não estabelece esse teto se o serviço de aprovação ou o assinador comprometido puder desativá-lo ou contorná-lo.

Aplicar limites independentemente da aprovação de pagamentos. Um pagamento que passe pelas verificações de autorização ainda deve estar sujeito a limites de gastos aplicados fora do controle presumido do invasor. Verifique se todas as rotas de assinatura e execução respeitam esses limites, inclusive rotas alternativas de execução [26, 27], e se o invasor não pode alterar ou desativar sua aplicação. Quando não for possível aplicar um limite independente, não apresente um orçamento configurado como um teto para as perdas.
Limitar os gastos acumulados, não apenas os pagamentos individuais. Defina o escopo, o período e a base de avaliação de cada orçamento, com contabilização consistente dos pagamentos concluídos e dos valores reservados. Verifique se solicitações repetidas, operações simultâneas e novas tentativas não podem, em conjunto, ultrapassá-lo nem liberar reservas prematuramente. Quando os limites dependerem dos preços dos ativos, verifique se preços manipulados, desatualizados ou indisponíveis não podem aumentar os gastos permitidos.

2,2 Saldos disponíveis, reposições e transações assinadas pendentes

A próxima questão é quais fundos permanecem em risco enquanto a instituição detecta e contém o ataque. Os saldos das carteiras, as reposições e as autorizações assinadas pendentes determinam essa exposição, inclusive no caso de fundos que chegam após o início do incidente. Avalie esses fatores em conjunto com os limites aplicáveis da Seção 2,1; o saldo atual, por si só, não é uma estimativa das perdas.

Limitar os fundos que um invasor poderia acessar. Avalie todos os ativos ao alcance da autoridade de assinatura afetada, inclusive em outras carteiras, blockchains e contratos. Inclua os saldos existentes e as entradas posteriores. A reposição de fundos deve ter autorização independente e um limite acumulado. Verifique se saídas repetidas de fundos não podem acionar reposições contínuas da tesouraria e se é possível redirecionar ou interromper novos aportes sem deixar de considerar os depósitos que ainda chegam.
Incluir os fundos expostos a autorizações assinadas pendentes. Interromper novas assinaturas não invalida necessariamente transações ou autorizações já emitidas. Identifique os fundos que elas ainda podem movimentar sem contabilizar os mesmos ativos duas vezes. Verifique se os pagamentos confirmados são registrados como gastos e se suas reservas são conciliadas, enquanto as transações não executadas mantêm suas reservas até que evidências confiáveis estabeleçam que elas não podem mais ser executadas. Um prazo de validade local ou uma solicitação de cancelamento, por si só, não deve reduzir a exposição registrada.

2,3 Monitoramento independente e resposta a incidentes

Limites e controles de financiamento restringem as perdas potenciais; o monitoramento e a resposta determinam por quanto tempo um invasor pode continuar operando. A instituição precisa de evidências que revelem abusos mesmo quando o serviço de pagamentos considera as operações válidas, além de um caminho de resposta que continue utilizável caso o ambiente operacional normal esteja indisponível ou comprometido.

O relato preliminar da Binance mostra por que apenas desligar uma aplicação pode não ser suficiente: o desligamento não eliminou uma delegação EIP-7702 existente. A revogação exigiu transações on-chain e, em sua implantação de MPC, um procedimento projetado separadamente [1]. Essa era uma restrição daquela implantação, não uma incapacidade inerente do MPC de revogar a autoridade. Portanto, a detecção e a contenção precisam ser validadas separadamente: evidências confiáveis devem levar a uma ação que efetivamente interrompa o caminho pelo qual ocorrem as perdas.

Detectar atividades não autorizadas usando evidências protegidas de forma independente. Compare as aprovações de negócio com as atividades de assinatura e os resultados de execução, e monitore alterações nas permissões e nas regras de controle. O serviço afetado não deve poder reescrever as evidências das quais o monitoramento depende. Verifique se operações aceitas pelo fluxo de trabalho ainda podem gerar alertas que permitam agir quando forem incompatíveis com a autorização de negócio, mesmo que registros locais estejam ausentes ou tenham sido manipulados.
Manter os controles de resposta disponíveis e eficazes. Mantenha autoridade independente para interromper novas assinaturas e novos aportes de fundos, bem como para invalidar transações pendentes ou revogar autorizações contínuas quando houver suporte para isso. Verifique se a resposta continua possível quando o acesso operacional habitual está indisponível ou comprometido e se as ações realmente bloqueiam novas saídas de fundos. Identifique a exposição residual e as necessidades de coordenação externa; interromper uma aplicação não revoga, por si só, autorizações assinadas, e não se pode presumir que os ativos serão recuperados.

3. Validação do projeto e da implementação

As seções anteriores perguntam se as verificações do fluxo de trabalho impedem operações não autorizadas e se as perdas podem ser limitadas quando isso não acontece. A validação deve examinar os dois objetivos no sistema implantado, inclusive a forma como os controles interagem ao longo do fluxo de fundos. Os métodos a seguir fornecem evidências complementares:

Avaliação da arquitetura e do projeto de segurança verifica se o fluxo de fundos, os limites de autoridade e as dependências entre controles sustentam os objetivos pretendidos de prevenção e limitação de perdas. Ela deve explicitar as premissas por trás da independência dos controles e dos limites de perdas.
Auditoria de código e configuração verifica se o código, a configuração e as permissões implantados implementam as verificações pretendidas, incluindo exceções e caminhos alternativos que poderiam contorná-las.
Testes de penetração examinam se vulnerabilidades em aplicações e infraestrutura podem ser combinadas para contornar controles de autorização ou de limitação de perdas. Seu escopo deve acompanhar os caminhos completos percorridos pelos fundos, sem se limitar a componentes individuais.
Exercícios de ataque e resposta verificam se o monitoramento leva a ações em tempo hábil e se limites de gastos, pausas e revogação funcionam em conjunto. Eles devem determinar quais fundos permanecem em risco e quanto tempo leva para que a contenção se torne efetiva.

Para cada cenário de validação, especifique a operação que deve ser rejeitada ou a perda que deve ser contida, juntamente com as capacidades presumidas do atacante. Registre o resultado observado, qualquer exposição remanescente e as condições das quais depende um limite de perdas alegado. Repita as verificações pertinentes após mudanças significativas no código, na configuração ou nas permissões.

Equipes ou especialistas externos em segurança podem complementar as equipes internas nessas avaliações, auditorias, testes e exercícios. A análise deles deve abranger como a lógica de pagamentos, a infraestrutura de assinatura e as permissões operacionais interagem, além de fornecer evidências das capacidades do sistema de prevenir operações não autorizadas e limitar perdas.

4. Conclusão

Os ataques examinados aqui expõem falhas de autorização desde a solicitação inicial de pagamento até a construção, assinatura, execução e liquidação da transação. Eles também mostram do que um sistema precisa para limitar perdas depois que um atacante consegue ultrapassar os controles. Os princípios de projeto resultantes abrangem prevenção, contenção e os testes necessários para avaliar ambas na prática.

A conclusão central é que proteger chaves privadas não garante, por si só, que as operações assinadas sejam autorizadas. A operação efetivamente executada deve corresponder a uma decisão de negócio genuína, e controles independentes devem limitar as consequências quando as verificações do fluxo de trabalho não conseguem impedir uma operação não autorizada. Isso exige examinar o fluxo de trabalho completo, incluindo as permissões que podem alterar suas verificações e as ferramentas necessárias para detectar e impedir perdas adicionais.

Esta análise concentrou-se no uso indevido da capacidade de assinatura do sistema original. A parte 2, Implementação segura da criptografia de carteiras, trata de uma via diferente: falhas de implementação que permitem aos atacantes prever ou recuperar chaves privadas sem roubar diretamente os segredos protegidos e, então, assinar fora do fluxo de trabalho original.