BLOG |
Anúncios da Blink
Como um invasor aproveitou uma falha em nossas ferramentas de administração para roubar 6,61 BTC de 24 contas, como todas foram restauradas e o que mudamos.
No sábado, 19 de setembro, às 11h39 UTC, um cliente ligou para um de nossos engenheiros para informar que seu saldo na Blink havia desaparecido. Quinze minutos depois, já tínhamos desativado todo o serviço de custódia. Naquela mesma noite, o problema foi resolvido. Na quinta-feira seguinte, todos os clientes afetados receberam de volta exatamente o valor de seus saldos, custeado pelos acionistas da Blink. Nenhum cliente sofreu qualquer prejuízo.
Aos 22 clientes cujos bitcoins foram roubados e às 3.817 pessoas cujos dados de conta foram consultados: pedimos desculpas.
O que aconteceu. Um invasor abriu uma conta gratuita comum no Blink em 17 de setembro. Dois dias depois, ele aproveitou uma falha na forma como nossas ferramentas administrativas verificavam as permissões para conceder poderes de administrador àquela conta. Com esses poderes, ele alterou o endereço de e-mail ou o número de telefone em 35 contas, acessou-as como se fosse o proprietário, aumentou os limites de saque em 14 delas e retirou bitcoins de 24 delas entre 09h51 e 11h54 UTC, em parte na cadeia de blocos e em parte pela rede Lightning, por meio do fluxo que criamos para ajudar os clientes a migrarem para a autocustódia. O invasor obteve cerca de 6,61 BTC.
De quem era o dinheiro. Eles tiveram como alvo 36 contas de custódia. Uma escapou por acaso: suas tentativas de alterar o endereço de e-mail falharam, e eles seguiram em frente. Das 35 contas que eles assumiram o controle, fizeram saques em 24. Nove delas tinham autenticação de dois fatores e não perderam nada (veja abaixo), e o invasor assumiu o controle das duas últimas contas apenas alguns minutos antes de desativarmos o serviço, de modo que nada foi movimentado nelas. 22 das 24 contas esvaziadas pertenciam a clientes; duas pertenciam a empresas do grupo Blink. Todas foram restauradas ao saldo exato que tinham antes do incidente em 24 de setembro, com as taxas de saque reembolsadas, e as contas bloqueadas foram reabertas a partir daquele dia. A Blink arca com o prejuízo.
O que não foi afetado. O dinheiro saiu da nossa carteira “quente” — o saldo operacional que mantemos para pagamentos do dia a dia. A maior parte dos fundos dos clientes fica em armazenamento “frio” com assinaturas múltiplas, que exige várias chaves mantidas por pessoas diferentes, e nada em nossas ferramentas administrativas tem acesso a ele. As contas sem custódia nunca estiveram em jogo: não mantemos essas chaves, portanto não havia nada que o invasor pudesse roubar.
O que eles viram. Durante o ataque, eles também acessaram detalhes de outras 3.817 contas. Em alguns casos, esses detalhes incluíam um número de telefone ou um endereço de e-mail. Eles não tiveram acesso a nomes, documentos de identidade, endereços, senhas ou frases-semente. Entramos em contato por escrito com todos os titulares de contas que conseguimos localizar, informando o que foi acessado.
O que os impediu? A autenticação de dois fatores. Nenhuma das 24 contas esvaziadas tinha essa função ativada. Nove das contas visadas, porém, sim. O invasor conseguiu acessar todas as nove, mas cada uma de suas 18 tentativas de usar essas contas foi recusada. Perda zero. Destacamos isso porque é uma das principais lições deste incidente: a autenticação de dois fatores funcionou, e deveríamos tê-la exigido para saques de grande valor e para contas com saldos elevados.
O que alteramos. A falha foi corrigida no mesmo dia, e uma terceira camada de proteção entrou em produção em 21 de setembro. As ferramentas de administração estão fora da internet pública. As funções de administração que alteram o e-mail ou o número de telefone de um cliente estão desativadas para todos enquanto as redesenhamos. Todas as chaves de API dos clientes foram revogadas. A carteira ativa agora contém apenas uma fração do que continha anteriormente. A lista completa está mais abaixo.
Onde está o dinheiro. Parte dele ainda está nos endereços para os quais foi transferido. O restante foi para outras carteiras, das quais cerca de 5 BTC passaram por um serviço de troca entre cadeias e uma pequena quantia chegou à Binance. Em El Salvador, foi apresentada uma queixa criminal à Fiscalía General de la República, e o órgão regulador financeiro foi notificado; na Próspera ZEDE, foi apresentada uma queixa criminal à polícia, e o órgão regulador financeiro foi notificado. Não esperamos receber o dinheiro de volta; a recompensa abaixo é para quem conseguir mudar essa situação.
Uma recompensa de 50%. Pagaremos 25% do valor de qualquer parte dos 6,61 BTC roubados em 19 de setembro que for recuperada como resultado direto das informações que você fornecer — até cerca de 1,65 BTC, caso todo o valor seja recuperado. Outros 25% de qualquer valor recuperado serão destinados à Bitcoin Beach, à Bitcoin Ekasi, à Afribit Kibera e à seleção conjunta de economias circulares de Bitcoin no Sul Global por elas indicadas. Se as informações levarem ao congelamento de fundos, a recompensa será paga assim que esses fundos forem devolvidos a uma carteira sob nosso controle. A oferta não tem prazo de validade. Escreva para bounty@blinkbtc.com. Os termos completos, que regem a oferta, estão disponíveis em blink.sv/bounty-terms.
O que você deve fazer. Ative a autenticação de dois fatores (Configurações → Segurança e Privacidade → Autenticação de dois fatores) e configure-a também na sua conta de e-mail. Adicione um login por e-mail caso tenha apenas um celular, pois um número de telefone pode ser alvo de troca de chip. Se você usa a API, gere uma nova chave. Ignore qualquer e-mail ou SMS sobre este incidente que contenha um link: entramos em contato com os usuários afetados por meio de mensagens no aplicativo Blink. Nunca pediremos seu PIN, senha, frase-semente ou código de login, nem pediremos que você transfira fundos. Se enviarmos uma mensagem sobre sua conta, siga as etapas indicadas nessa mensagem. Se preferir manter suas próprias chaves, as contas sem custódia já estão disponíveis no aplicativo desde junho (Configurações → Mudar para sem custódia).
A Blink é administrada por cerca de vinte pessoas em uma dúzia de fusos horários, então não existe algo como uma manhã de sábado para todos nós ao mesmo tempo. Às 11h39 UTC, era início da noite em Hong Kong, hora do almoço na Europa e antes do amanhecer em El Salvador. O cliente que ligou percebeu que seu saldo estava zerado e que seu endereço de e-mail havia sido alterado. Em seis minutos, a equipe já estava em uma chamada, as primeiras contas haviam sido bloqueadas manualmente pelo painel de administração e a decisão mais importante já havia sido tomada: desativar tudo.
Às 11h54, desativamos toda a infraestrutura de custódia. Essa decisão custou a todos os usuários do Blink quase oito horas de serviço. Os saques foram interrompidos no momento em que o serviço foi suspenso. Às 12h41, publicamos o primeiro comunicado: serviços suspensos, investigação em andamento. Às 16h06, publicamos o segundo: todas as contas afetadas serão integralmente reembolsadas.
Às 16h17, a primeira correção foi incorporada e, às 17h50, a terceira. Os fundos restantes da carteira ativa foram transferidos para novos endereços, de modo que qualquer pagamento já assinado para as retiradas do invasor fosse rejeitado. Às 19h34, reativamos o serviço para todos, exceto para as 36 contas que o invasor havia afetado, que permaneceram bloqueadas até que pudéssemos restaurá-las adequadamente. As funções administrativas que alteram detalhes de contato permaneceram bloqueadas como uma segunda medida de segurança; a correção foi verificada no ambiente de teste naquela noite e, nos dias seguintes, repetimos todo o ataque nós mesmos contra uma cópia do código anterior à correção, para ter certeza de que havíamos entendido o problema — e então confirmamos que cada camada agora o impede.
Todos os horários estão em UTC; El Salvador está seis horas atrás.
De outubro de 2023 até 19 de setembro de 2026, qualquer pessoa com uma conta gratuita no Blink e um navegador da web podia assumir os poderes de nossa equipe de suporte: alterar o endereço de e-mail ou o número de telefone na conta de qualquer cliente e, em seguida, fazer login como esse cliente e aumentar seus limites de saque. Estamos divulgando exatamente como isso funcionava, pois, como nosso código é de código aberto, outros serviços utilizam implementações baseadas nele, e o erro fundamental — confiar na descrição fornecida pelo próprio token sobre o que ele tem permissão para fazer — pode ocorrer em qualquer sistema construído da mesma forma.
Nossa equipe utiliza uma interface administrativa para ajudar os clientes: desbloquear uma conta, corrigir um número de telefone, aumentar um limite. O acesso a ela é feito por meio do OAuth2, o mesmo padrão que permite que você faça login em um site usando as credenciais de outro. Havia três problemas distintos, e cada um deles, por si só, não é nada fora do comum.
A tela de consentimento confiava no navegador. Quando um aplicativo solicitava permissões, nossa página de consentimento pegava a lista de permissões diretamente do formulário enviado pelo navegador e a repassava ao nosso servidor OAuth tal como estava. Ela nunca comparava essa lista com o que o aplicativo havia realmente solicitado. Assim, qualquer pessoa poderia adicionar um campo oculto ao formulário dizendo “conceda-me também permissão de administrador”, e o servidor — confiando corretamente em sua própria página de consentimento — geraria um token perfeitamente válido que indicasse “administrador”.
A API de administração aceitava qualquer token. O gatekeeper, que atuava como filtro, aceitava qualquer token ativo proveniente do nosso servidor OAuth: sem exigência de permissão, sem verificação de que o token fosse destinado à API de administração e sem verificação da identidade do cliente. Ele copiava as permissões autodeclaradas do token para a credencial utilizada pelo servidor de administração.
O servidor de administração confiava na sequência de permissões. Se a sequência indicasse “admin”, você era administrador. Não havia nenhuma verificação para confirmar se a pessoa por trás do token era um administrador conhecido.
Juntos, esses fatores significavam que bastavam uma conta gratuita e um navegador. Nenhuma conta de funcionário nem credencial de funcionário foi utilizada, e nenhum malware esteve envolvido. Nosso próprio sistema de identidade emitiu esses tokens, e foi exatamente por isso que nenhum alarme foi acionado. O invasor tentou primeiro a abordagem óbvia — adicionar permissões na solicitação de autorização principal — e nossa configuração rejeitou-a corretamente. Em seguida, tentou a página de consentimento, e ela permitiu o acesso.
Para quem estiver auditando uma pilha de sistemas semelhante, o histórico é importante. A falha surgiu em outubro de 2023 por meio de três pull requests consecutivas: a primeira permitiu que a API de administrador aceitasse tokens OAuth enquanto uma verificação separada do editor ainda a protegia; a segunda excluiu essa verificação do editor; a terceira concedeu a todos os usuários acesso à tela de consentimento do OAuth. Uma alteração de reforço de segurança em maio de 2026 (PR nº 158) adicionou requisitos de permissão de administrador no servidor de administração, mas ela lia essas permissões diretamente do próprio token, e a página de consentimento ainda permitia que qualquer pessoa as inserisse ali. A vulnerabilidade permaneceu explorável por cerca de três anos.
As correções estão disponíveis publicamente: a página de consentimento agora rejeita qualquer permissão que o aplicativo não tenha solicitado (PR #853); os tokens de administrador devem conter um público-alvo emitido exclusivamente para a API de administrador, o que os tokens de cliente não podem obter (mesmo PR; o PR #855 nos permitiu ativar essa verificação em produção separadamente, o que fizemos em 21 de setembro); e as funções de administrador que alteram detalhes de contato podem ser totalmente bloqueadas por meio de configuração, para todos (PR #861).
O código foi escrito em 2023, dentro da empresa onde a plataforma Blink foi desenvolvida a partir de 2019, e passou a ser de nossa propriedade em outubro de 2024, quando a Blink passou por uma transição de propriedade e se tornou uma empresa independente. Dois dos engenheiros que haviam desenvolvido a plataforma vieram conosco, mas os engenheiros que haviam escrito o fluxo de autorização administrativa permaneceram na empresa anterior; assim, ninguém da equipe da Blink sabia por que uma verificação de permissão anterior existia. Ao longo de 2025, a maior parte do nosso trabalho de engenharia foi dedicada a separar nossos sistemas dos daquela empresa, que haviam crescido juntos ao longo dos anos: nossa própria infraestrutura, nossas próprias contas, nosso próprio nó.
Em 2026, a regulamentação mudou em muitos dos países em que atuávamos. O Google passou a exigir licenças locais para aplicativos de carteira em quinze mercados, o período de transição para as regras MiCA da UE terminou em 1º de julho, e muitas outras jurisdições estavam aprovando novas leis ou colocando em vigor leis aprovadas em anos anteriores. Respondemos a isso mantendo menos dinheiro de nossos clientes em custódia, em vez de solicitar mais licenças: desenvolvemos e lançamos uma carteira sem custódia, retiramos o serviço de custódia de mais de quarenta jurisdições e transferimos dezenas de milhares de usuários para contas nas quais eles mesmos mantêm suas próprias chaves. Nossa publicação sobre o lançamento da carteira sem custódia, em junho, descreve esse trabalho. Para uma equipe de cerca de vinte pessoas, isso levou a maior parte do ano.
O fortalecimento do código que herdamos ficou em segundo plano em relação a esses dois projetos. Esperou por tempo demais. A primeira coisa que mudamos foi a forma como as vulnerabilidades de segurança são classificadas e atribuídas a responsáveis.
A hot wallet com saldo elevado faz parte dessa mesma história. Estávamos operando-a com um saldo de aproximadamente o dobro do normal, como uma reserva para a migração, cuja primeira fase havia terminado uma ou duas semanas antes do ataque. Ainda não tínhamos reduzido esse saldo. É por isso que a perda chegou a ser tão grande. Desde então, o saldo foi reduzido a uma fração desse nível, e o saldo operacional da Lightning está sendo reduzido ainda mais.
O invasor assumiu o controle de 35 contas da mesma maneira: alterou o endereço de e-mail ou o número de telefone por meio das ferramentas de administração, solicitou um código de login e fez o login. Em 24 delas, ele retirou fundos. Em nove delas, ele esbarrou em um obstáculo. Essas nove tinham a autenticação de dois fatores ativada — um aplicativo autenticador no celular do proprietário — e, em uma conta protegida por 2FA, uma sessão aberta apenas com um código de login não permite transferir dinheiro. Nossos registros mostram que todas as 18 tentativas do invasor nessas nove contas falharam exatamente nessa barreira. Nenhuma perda em nenhuma delas.
A autenticação de dois fatores (2FA) não impediu a invasão das nossas ferramentas administrativas. Mas impediu o roubo de contas individuais. Nenhuma das 24 contas que sofreram perdas financeiras tinha essa função ativada. Deveríamos ter exigido essa medida para saques de valores elevados e para contas com saldos elevados.
Se você for fazer apenas uma coisa depois de ler este post, que seja esta: Configurações → Segurança e Privacidade → Autenticação de dois fatores. Em seguida, ative essa função também para sua conta de e-mail, já que os códigos de login do Blink podem ser enviados para lá.
No domingo, um dia após o ataque, já sabíamos o que havia sido roubado e de quem, com precisão até o último satoshi, tendo feito a reconciliação com o livro-razão, a blockchain e o nó Lightning, e o Conselho de Administração já havia decidido como arcar com os custos. Os acionistas da Blink comprometeram-se a disponibilizar o valor total em 24 horas na forma de um empréstimo sem juros, que foi adiantado na quarta-feira, e todos os acionistas receberam a oferta de financiar sua parcela nos mesmos termos. Na quinta-feira, 24 de setembro, restauramos todos os saldos afetados e reembolsamos as taxas que havíamos cobrado sobre os saques fraudulentos. Os clientes afetados foram informados diretamente por nós antes de divulgarmos qualquer informação ao público, assim como as pessoas cujos registros haviam sido acessados.
A ordem foi deliberada. Primeiro, os usuários; tudo o mais, depois. Informamos nossos acionistas na sexta-feira com os mesmos fatos que vocês estão lendo agora e retivemos esta publicação até que as autoridades recebessem nossos relatórios: uma denúncia criminal apresentada à Fiscalía General de la República de El Salvador, notificações ao órgão regulador financeiro e à agência de segurança cibernética de El Salvador, uma denúncia criminal junto ao Departamento de Polícia da Próspera ZEDE e uma notificação ao órgão regulador financeiro da Próspera.
Duas coisas aconteceram naquela semana que queremos deixar registradas. No domingo, o invasor nos escreveu exigindo pagamento, ameaçando publicar dados dos usuários. Não pagamos e não pagaremos; a mensagem agora serve como prova de sua tentativa de extorsão. E, do domingo à quarta-feira, eles continuaram acessando — quatro das contas bloqueadas cujos dados de contato ainda exibiam o endereço de e-mail do invasor, pois ainda não as havíamos restaurado. Todas as tentativas de pagamento foram recusadas e nada mudou. Isso não deveria ter sido possível. Nosso procedimento de reativação agora restaura primeiro os dados de contato, encerra todas as sessões e só então desbloqueia a conta.
Não somos a primeira empresa a arcar com um prejuízo como esse e indenizar os usuários. As corretoras e as carteiras já fizeram isso antes de nós. O prejuízo de um custodiante é de responsabilidade do próprio custodiante.
A Blink não estava começando do zero em 19 de setembro. A maior parte dos fundos dos clientes já estava em armazenamento frio com múltiplas assinaturas, distribuída por vários continentes; o serviço opera com reserva total; a autenticação de dois fatores estava disponível e vínhamos incentivando os usuários a adotá-la; e os saques eram limitados por conta. A maior parte disso se manteve: o invasor nunca chegou ao armazenamento frio, nunca acessou uma conta sem custódia e falhou em todas as contas que possuíam autenticação de dois fatores. O que falhou especificamente foram as verificações de autorização em nossas ferramentas administrativas herdadas e o monitoramento que se concentrava em detectar interrupções de serviço, em vez de identificar se um administrador estava fazendo algo que nenhum administrador deveria fazer. O que falhou de maneira mais geral foram nossas prioridades: a transição de propriedade e, em seguida, a saída da custódia ocuparam a maior parte da equipe, e o trabalho de segurança no código que havíamos herdado ficou em segundo plano.
O que fizemos a respeito, nos primeiros dias:
Está em andamento um novo reforço em toda a plataforma.
E dois compromissos que começam hoje:
1.A recompensa pela recuperação. Pagaremos 25% do valor de qualquer parte dos 6,61 BTC roubados em 19 de setembro que for recuperada como resultado direto das informações que você fornecer — até cerca de 1,65 BTC, caso todo o valor seja recuperado. Do valor recuperado, outros 25% serão destinados ao Bitcoin Beach, ao Bitcoin Ekasi, ao Afribit Kibera e a uma seleção conjunta de economias circulares de Bitcoin no Sul Global que possam precisar de apoio adicional. A oferta não tem prazo de validade; escreva para bounty@blinkbtc.com. A recompensa será paga apenas com fundos que tenham sido devolvidos a uma carteira sob nosso controle. Os fundos roubados podem ser devolvidos a nós na cadeia de blocos no endereço bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 ou via Lightning para o endereço bounty@blink.sv.
2.Um canal de denúncias de segurança, com recompensas. Escreva para bounty@blinkbtc.com. As denúncias são confirmadas em até 72 horas e ficam a cargo de nossa equipe de segurança até que sejam resolvidas. Pesquisas de boa-fé sobre o software da Blink são bem-vindas, e não tomaremos medidas contra ninguém que denuncie uma vulnerabilidade de forma responsável. Pagamos recompensas discricionárias de até 0,1 BTC por descobertas críticas. A política completa está disponível em blink.sv/bounty-terms. Este canal existe devido a este incidente: cada denúncia deve ser encaminhada a algum lugar, ser confirmada e permanecer sob responsabilidade até que seja resolvida.
Os 50% são divididos em duas partes: 25% vão para quem fornecer informações que levem à recuperação, e outros 25% de tudo o que for recuperado vão para o Bitcoin Beach, o Bitcoin Ekasi, o Afribit Kibera e as economias circulares que eles escolherem. Acreditamos que os fundos provavelmente estejam perdidos para sempre. Bitcoins roubados são muito difíceis de recuperar; portanto, para nós, qualquer quantia recuperada já é uma grande vitória, e quanto mais pessoas pudermos incentivar a nos ajudar a encontrar o invasor, melhor. Pessoas como essa não devem escapar facilmente, e queremos tornar o uso desse dinheiro o mais difícil e incômodo possível para elas.
Acrescentamos os segundos 25% porque queremos lembrar ao invasor que ele roubou dinheiro que nós e nossos acionistas, alinhados à nossa missão, preferiríamos ter gasto apoiando a adoção popular do Bitcoin e fortalecendo os desenvolvedores do Bitcoin em comunidades excluídas do sistema bancário em todo o mundo. Que vergonha para o invasor.
Rastreamos os fundos continuamente desde 19 de setembro. Em 1º de outubro: cerca de 0,87 BTC ainda permanecia inalterado nos endereços de destino. O restante foi para outras carteiras deles, que também contêm bitcoins que não vieram da Blink. Dessas carteiras, cerca de 5,05 BTC passaram por um serviço de troca entre cadeias (NEAR Intents), 1 BTC em 21 de setembro e cerca de 4,05 BTC entre 28 e 29 de setembro; e, como nosso pedido de preservação de 22 de setembro não foi atendido, solicitamos às autoridades que obtenham os registros desse serviço; cerca de 0,012 BTC foi depositado na Binance, e a equipe de segurança da Binance já está trabalhando no caso e colocando os endereços na lista negra. Como os bitcoins do próprio invasor estão misturados, esses valores não somam os 6,61 BTC. Os endereços na cadeia de blocos estão no apêndice.
Nosso código-fonte é de código aberto, e serviços que não desenvolvemos utilizam implantações derivadas dele. O padrão vulnerável — um fluxo de consentimento que confia na lista de permissões do navegador e um gatekeeper de borda que aceita qualquer token ativo sem verificar o público-alvo — é anterior aos repositórios atuais do Blink e está no histórico público arquivado. Notificamos de forma privada os operadores das implantações derivadas de que temos conhecimento; um deles aplicou a correção no mesmo dia. Nosso aviso de segurança para a base de código será publicado no GitHub em github.com/blinkbitcoin/blink/security/advisories, com um identificador CVE solicitado. Se você executa algo desenvolvido com base no código-fonte do Blink e ainda não foi contatado por nós, escreva para bounty@blinkbtc.com; assim que confirmarmos que você opera uma implantação, compartilharemos o procedimento completo de verificação e ajudaremos você a verificá-lo. As correções são os três PRs (pull requests) linkados acima. Os invasores agora escaneiam o código público na velocidade da máquina. Se você executa esse código, verifique-o hoje mesmo.
O Blink começou como a carteira de Bitcoin para o dia a dia de uma pequena cidade litorânea, onde as pessoas precisavam de um meio de pagamento que funcionasse. Em 19 de setembro, para 22 de nossos clientes, isso não aconteceu. Todos eles haviam confiado seu dinheiro a nós, que é exatamente para isso que serve um custodiante.
Aos nossos clientes, pela paciência; aos pesquisadores e às bolsas de valores que nos ajudaram em questão de horas; aos acionistas que apoiaram a empresa sem hesitar; e à equipe que largou tudo num sábado e ficou sem dormir — muito obrigado. Vamos reconquistar a confiança da mesma forma que a conquistamos em El Zonte: estando presentes e garantindo que os pagamentos sejam processados, todos os dias.
Meu dinheiro correu risco? Se sua conta estiver aberta e não tivermos entrado em contato com você, isso significa que não temos registro de que o invasor tenha acessado os detalhes da sua conta, e nada foi retirado dela. Até o momento em que a fechamos, em 19 de setembro, a falha poderia ter sido explorada contra qualquer conta custodial; no entanto, em uma conta com autenticação de dois fatores (2FA), ela não permitiria que ninguém transferisse dinheiro. A maior parte dos fundos dos clientes fica em armazenamento frio, fora do alcance das ferramentas de administração. Se você possui uma conta sem custódia, suas chaves nunca estiveram em nossos servidores e não havia nada que o invasor pudesse roubar.
O invasor conseguiu acessar meus dados? Ele teve acesso aos detalhes de 3.817 contas. Entramos em contato por escrito com todos os titulares de contas que conseguimos localizar, informando o que foi acessado. Se sua conta está ativa e você não recebeu essa mensagem, isso significa que ela não estava entre as afetadas. Você pode sempre nos perguntar quais informações, se houver, foram acessadas em sua conta: support@blink.sv.
Por que seu sistema de monitoramento não detectou o ataque? Nossos alertas foram criados para detectar interrupções no serviço. Eles não tinham nenhuma regra para o caso de um administrador fazer algo que nenhum administrador deveria fazer, e o invasor estava usando nossas próprias ferramentas com tokens emitidos pelo nosso próprio sistema.
Por que havia tanto dinheiro na carteira quente? Tínhamos praticamente dobrado nosso saldo operacional como reserva para a migração para contas sem custódia e não havíamos reduzido esse valor após o término da primeira onda. Agora, ele representa apenas uma fração desse nível, e não estamos divulgando o valor.
A autenticação de duas etapas (2FA) teria me protegido? Nesse caso, sim. Todas as contas que tinham essa proteção mantiveram seu dinheiro; todas as contas que perderam dinheiro não tinham essa proteção. Ela não impede todos os ataques, mas impediu esse. Ative-a.
Devo mudar para uma conta sem custódia? Se você preferir manter suas próprias chaves, sim — é para isso que elas servem, e ninguém na Blink, nem mesmo quem conseguir invadir a Blink, poderá movimentar os fundos que você mesmo mantém. Isso não é obrigatório, nem todos os recursos estão disponíveis ainda, e a disponibilidade depende da sua região. Se você optar por permanecer na conta com custódia, ative a autenticação de duas etapas (2FA).
Quem pagou por isso? Os acionistas da Blink, por meio de um empréstimo sem juros concedido em 24 horas e desembolsado em 23 de setembro. Não foram os clientes, nem as reservas dos clientes. A Blink continua operando com reserva integral: cada saldo é garantido na proporção de um por um.
Encontrei um problema de segurança no Blink. O que devo fazer? Escreva para bounty@blinkbtc.com. Você receberá uma resposta em até 72 horas; seu relato terá um responsável até que seja resolvido, e descobertas críticas são recompensadas.
Atualizações com datas sobre a recuperação, a recompensa e quaisquer correções a esta postagem serão adicionadas aqui.
Os endereços a seguir receberam as retiradas na cadeia. Solicita-se às corretoras e aos pesquisadores que analisem os depósitos provenientes desses endereços e entrem em contato com bounty@blinkbtc.com. (Os recursos da Lightning-rail foram encaminhados para carteiras Lightning controladas pelos invasores e estão sendo rastreados separadamente.)
Total na cadeia: 4,62685758 BTC recebidos nesses endereços em 14 saques, sendo sete deles para o primeiro endereço. Nosso sistema de pagamentos agrupa os saques, portanto, os 14 foram enviados em 12 transações na cadeia. Os 1,98399667 BTC restantes do total de 6,61085425 BTC foram transferidos pela Lightning.
Comece a receber e enviar bitcoin agora mesmo
