BLOG |
Anúncios da Blink
Como um invasor aproveitou uma falha em nossas ferramentas administrativas para roubar 6,61 BTC de 24 contas, como reembolsamos cada uma delas e o que mudamos.
No sábado, 19 de setembro, às 11h39 UTC, um cliente ligou para o número de um de nossos engenheiros para informar que seu saldo no Blink havia desaparecido. Quinze minutos depois, já tínhamos desativado todo o serviço de custódia. Naquela mesma noite, a falha já havia sido corrigida. Na quinta-feira seguinte, cada cliente afetado já tinha seu saldo exato de volta, custeado pelos acionistas do Blink. Nenhum cliente sofreu qualquer perda.
Aos 22 clientes que tiveram seus bitcoins roubados e às 3.817 pessoas cujos dados de conta foram consultados: pedimos desculpas.
O que aconteceu. Um invasor abriu uma conta comum e gratuita no Blink em 17 de setembro. Dois dias depois, ele se aproveitou de uma falha na forma como nossas ferramentas administrativas verificavam as permissões para conceder a essa conta poderes de administrador. Com esses poderes, ele alterou o e-mail ou o número de telefone de 35 contas, acessou-as como se fosse o titular, aumentou os limites de saque em 14 delas e retirou bitcoins de 24 entre 09h51 e 11h54 UTC, em parte na cadeia de blocos e em parte pela Lightning Network, 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. O invasor teve como alvo 36 contas de custódia. Uma se salvou por acaso: suas tentativas de alterar o e-mail falharam e ele passou para outra. Das 35 que ele invadiu, retirou fundos de 24. Nove tinham autenticação de dois fatores e não perderam nada (veja mais abaixo), e das duas últimas ele assumiu o controle apenas alguns minutos antes de desligarmos o serviço, de modo que nada foi movimentado nelas. Vinte e duas das 24 contas esvaziadas pertenciam a clientes; duas eram de empresas do grupo Blink. Cada uma recuperou seu saldo exato anterior ao incidente em 24 de setembro, com a devolução das taxas de saque, e as contas bloqueadas foram reabertas a partir desse dia. A Blink arca com a perda.
O que não foi afetado. O dinheiro saiu da nossa carteira operacional, o saldo que mantemos para os pagamentos do dia a dia. A maior parte dos fundos dos clientes está em armazenamento frio com assinatura múltipla, o que exige várias chaves nas mãos de pessoas diferentes, e nada em nossas ferramentas administrativas tem acesso a ele. As contas não custodiais nunca estiveram em risco: não temos essas chaves, então o invasor não tinha nada para levar.
O que foi visualizado. Durante o ataque, também foram consultados dados de outras 3.817 contas. Em alguns casos, esses dados incluíam um número de telefone ou um endereço de e-mail. Não foram visualizados nomes, documentos de identidade, endereços, senhas nem frases-semente. Entramos em contato por escrito com cada titular que conseguimos localizar, informando em detalhes o que foi visualizado.
O que impediu o ataque: a autenticação de dois fatores. Nenhuma das 24 contas esvaziadas tinha essa função ativada. Nove das contas atacadas, sim. O invasor fez login nessas nove, mas cada uma de suas 18 tentativas de usá-las foi rejeitada. Nenhuma perda. 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 operação em 21 de setembro. As ferramentas administrativas não estão mais expostas à internet. As funções administrativas que alteram o e-mail ou o telefone de um cliente estão desativadas para todos enquanto as reprojetamos. Todas as chaves de API dos clientes foram revogadas. A carteira operacional agora armazena apenas uma fração do que armazenava anteriormente. A lista completa está abaixo.
Onde está o dinheiro? Uma parte ainda está nos endereços para os quais o invasor transferiu os fundos. O restante foi transferido para outras carteiras dele, de onde cerca de 5 BTC foram enviados por meio de um serviço de troca entre cadeias e uma pequena quantia chegou à Binance. Em El Salvador, foi apresentada uma queixa criminal junto à Procuradoria-Geral da República e o órgão regulador financeiro foi notificado; na Próspera ZEDE, foi apresentada uma queixa criminal junto à polícia e o órgão regulador financeiro foi notificado. Não esperamos recuperar o dinheiro; 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 de informações que você nos fornecer: até cerca de 1,65 BTC, caso tudo seja recuperado. Outros 25% de tudo o que for recuperado serão destinados ao Bitcoin Beach, ao Bitcoin Ekasi, ao Afribit Kibera e às economias circulares de Bitcoin do Sul Global que forem escolhidas em conjunto. Se as informações levarem ao congelamento de fundos, a recompensa será paga quando esses fundos retornarem a uma carteira sob nosso controle. A oferta não tem prazo de validade. Escreva para bounty@blinkbtc.com. Os termos completos, que são os que prevalecem, 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 ative-a também no seu e-mail. Se você faz login apenas com seu número de telefone, adicione um e-mail para fazer o login: um número de telefone pode ser roubado por meio de uma troca de SIM (SIM swap). Se você usa a API, crie uma chave nova. Ignore qualquer e-mail ou SMS sobre esse incidente que contenha um link: enviamos mensagens aos usuários afetados diretamente pelo aplicativo do Blink. Nunca pediremos seu PIN, sua senha, sua frase-semente ou um código de acesso, nem que você transfira seus fundos. Se entrarmos em contato com você sobre sua conta, siga as instruções dessa mensagem. Se preferir guardar suas próprias chaves, as contas sem custódia estão disponíveis no aplicativo desde junho (Configurações → Migrar para conta sem custódia).
O Blink é operado por cerca de vinte pessoas em uma dúzia de fusos horários, portanto, não existe um sábado de manhã que seja o mesmo para todos ao mesmo tempo. Às 11h39 UTC, estava anoitecendo em Hong Kong, era hora do almoço na Europa e ainda não havia amanhecido em El Salvador. O cliente que ligou havia percebido que seu saldo estava zerado e que seu e-mail havia sido alterado. Em menos de seis minutos, a equipe já estava em uma chamada, as primeiras contas foram bloqueadas manualmente pelo painel administrativo e a decisão mais importante já havia sido tomada: desligar tudo.
Às 11h54, desligamos todo o sistema de custódia. Essa decisão custou a cada usuário do Blink quase oito horas de serviço. Os saques foram suspensos no momento em que o serviço foi interrompido. Às 12h41, publicamos o primeiro comunicado: serviços em pausa, investigação em andamento. Às 16h06, publicamos o segundo: todas as contas afetadas serão totalmente reembolsadas.
Às 16h17, a primeira correção já havia sido implementada e, às 17h50, a terceira. Os fundos restantes da carteira operacional 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 corretamente. As funções administrativas que alteram dados de contato permaneceram bloqueadas como uma segunda medida de segurança; a correção foi testada no ambiente de testes naquela mesma noite e, nos dias seguintes, nós mesmos repetimos todo o ataque contra uma cópia do código anterior à correção, para garantir que o compreendêssemos, e confirmamos que cada camada agora o bloqueia.
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 podia se atribuir os poderes da nossa equipe de suporte: alterar o e-mail ou o número de telefone da conta de qualquer cliente, fazer login como esse cliente e aumentar seus limites de saque. Publicamos exatamente como isso funcionava, pois nosso código é aberto, outros serviços operam implementações baseadas nele e o erro subjacente — confiar no que um token afirma sobre si mesmo em relação ao que tem permissão para fazer — pode ocorrer em qualquer sistema construído da mesma maneira.
Nossa equipe usa uma interface administrativa para ajudar os clientes: desbloquear uma conta, corrigir um número de telefone, aumentar um limite. O acesso é feito por meio do OAuth2, o mesmo padrão que permite que você faça login em um site usando sua conta de outro serviço. Havia três problemas, e nenhum deles, por si só, chamava a atenção.
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, tal como estava, para o nosso servidor OAuth. Essa lista nunca era comparada com o que o aplicativo havia realmente solicitado. Assim, qualquer pessoa poderia adicionar ao formulário um campo oculto que dissesse “conceda-me também permissões de administrador”, e o servidor — que confiava, com razão, em sua própria página de consentimento — emitia um token perfeitamente válido que indicava “administrador”.
A API administrativa aceitava qualquer token. O controlador de acesso que estava à sua frente aceitava qualquer token válido do nosso servidor OAuth: sem exigir nenhuma permissão, sem verificar se o token era destinado à API administrativa e sem verificar quem era o cliente. Ele copiava as permissões que o token declarava ter na credencial utilizada pelo servidor administrativo.
O servidor administrativo confiava no texto das permissões. Se o texto dizia “administrador”, você era administrador. Não havia nenhuma verificação de que a pessoa por trás do token fosse um administrador conhecido.
Juntas, essas três falhas faziam com que bastassem uma conta gratuita e um navegador. Nenhuma conta ou credencial do pessoal foi utilizada, e não houve malware. Nosso próprio sistema de identidade emitiu esses tokens e, por isso mesmo, nenhum alarme foi acionado. O invasor tentou primeiro a via óbvia — adicionar permissões no pedido de autorização principal — e nossa configuração rejeitou corretamente. Em seguida, ele tentou a página de consentimento e, por lá, conseguiu passar.
Para quem for auditar uma pilha de tecnologia semelhante, o histórico é importante. A vulnerabilidade surgiu em outubro de 2023 com três pull requests consecutivas: a primeira fez com que a API administrativa aceitasse tokens OAuth, enquanto uma verificação de editor separada continuava a protegê-la; a segunda removeu essa verificação de editor; a terceira concedeu a todos os usuários acesso à tela de consentimento do OAuth. Uma atualização de segurança em maio de 2026 (PR #158) adicionou requisitos de permissões administrativas no servidor administrativo, mas lia essas permissões diretamente do próprio token, e a página de consentimento continuava permitindo que qualquer pessoa as inserisse ali. A vulnerabilidade pôde ser explorada por cerca de três anos.
As correções são públicas: a página de consentimento agora rejeita qualquer permissão que o aplicativo não tenha solicitado (PR #853); os tokens administrativos devem conter uma autorização emitida exclusivamente para a API administrativa, que os tokens dos clientes não podem obter (o mesmo PR; o PR #855 nos permitiu ativar essa verificação em produção separadamente, e o fizemos em 21 de setembro); e as funções administrativas que alteram dados de contato podem ser totalmente desativadas por meio de configuração, para todos (PR #861).
O código foi escrito em 2023, na empresa onde a plataforma Blink foi desenvolvida desde 2019, e passou a ser de nossa propriedade em outubro de 2024, quando a Blink passou por uma mudança de propriedade e se tornou uma empresa independente. Dois dos engenheiros que haviam desenvolvido a plataforma vieram conosco, mas os que haviam escrito o fluxo de autorização administrativa não, de modo que ninguém na equipe da Blink sabia por que existia uma verificação de permissões prévia. Durante 2025, a maior parte do nosso trabalho de engenharia foi dedicada a separar nossos sistemas dos daquela empresa, que, com o passar dos anos, haviam se entrelaçado: nossa própria infraestrutura, nossas próprias contas, nosso próprio nó.
Em 2026, a regulamentação mudou em muitos dos países onde atuávamos. O Google passou a exigir licenças locais para aplicativos de carteira em quinze mercados, o período de transição das regras MiCA da União Europeia terminou em 1º de julho, e muitas outras jurisdições aprovaram novas leis ou colocaram em vigor leis aprovadas em anos anteriores. Respondemos 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 guardam suas próprias chaves. Nossa publicação de junho sobre o lançamento das contas sem custódia descreve esse trabalho. Para uma equipe de cerca de vinte pessoas, isso ocupou a maior parte do ano.
O reforço do código que havíamos herdado ficou em segundo plano em relação a esses dois projetos. Esperamos demais. A primeira coisa que mudamos foi a forma como as falhas de segurança são classificadas e atribuídas.
A elevada carteira operacional faz parte da mesma história. Nós a mantínhamos em um nível aproximadamente o dobro do normal como reserva para a migração, cuja primeira onda havia terminado uma ou duas semanas antes do ataque. Ainda não a tínhamos reduzido. Por isso, a perda pôde ser tão grande. Desde então, a reduzimos a uma fração desse nível, e o saldo operacional do Lightning está diminuindo ainda mais.
O invasor comprometeu 35 contas da mesma maneira: alterou o e-mail ou o número de telefone usando as ferramentas administrativas, solicitou um código de acesso e fez login. Em 24 delas, ele retirou fundos. Em nove, ele esbarrou em uma barreira. Essas nove contas tinham a autenticação de dois fatores ativada — um aplicativo de autenticação no celular do titular — e, em uma conta protegida por 2FA, uma sessão aberta apenas com um código de acesso não permite movimentar dinheiro. Nossos registros mostram que as 18 tentativas do invasor nessas nove contas falharam exatamente nesse controle. Zero perdas em cada uma delas.
A autenticação de dois fatores (2FA) não impediu o acesso não autorizado às nossas ferramentas administrativas. Mas impediu o roubo de fundos das contas individuais. Nenhuma das 24 contas que sofreram perdas financeiras tinha essa função ativada. Deveríamos ter exigido sua ativação para saques de grande valor e para contas com saldos elevados.
Se você fizer apenas uma coisa depois de ler isto, que seja esta: Configurações → Segurança e privacidade → Autenticação de dois fatores. Em seguida, ative-a também no seu e-mail, pois é por lá que podem chegar seus códigos de acesso ao Blink.
No domingo, um dia após o ataque, já sabíamos o que havia sido roubado e de quem, até o último satoshi, de acordo com o livro-razão, a blockchain e o nó da Lightning, e o Conselho Administrativo já havia decidido como pagá-lo. Os acionistas da Blink comprometeram-se a arcar com o valor total em menos de 24 horas como um empréstimo sem juros, conforme anunciaram na quarta-feira, e a cada acionista foi oferecida a possibilidade de financiar sua parte nas mesmas condições. Na quinta-feira, 24 de setembro, repusemos cada saldo afetado e devolvemos as comissões que havíamos cobrado pelas retiradas fraudulentas. Os clientes afetados receberam uma mensagem direta nossa antes de divulgarmos qualquer outra informação publicamente, assim como as pessoas cujos dados foram consultados.
A ordem foi deliberada. Primeiro, indenizar os usuários; tudo o mais, depois. Na sexta-feira, informamos nossos acionistas sobre os mesmos fatos que você está lendo agora e retivemos esta publicação até que as autoridades recebessem nossos relatórios: uma denúncia criminal junto à Procuradoria-Geral da 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.
Há duas coisas sobre essa semana que queremos deixar registradas. No domingo, o invasor nos escreveu exigindo um pagamento, ameaçando divulgar dados dos usuários. Não pagamos e não o faremos; essa mensagem é agora prova de sua tentativa de extorsão. E, de domingo a quarta-feira, ele continuou fazendo login em quatro das contas bloqueadas cujos dados de contato ainda continham o e-mail do invasor, pois ainda não as tínhamos restabelecido. Cada pagamento que ele tentou foi rejeitado e nada aconteceu. Isso não deveria ter sido possível. Nosso procedimento de reativação agora restabelece 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 a indenizar seus usuários. Exchanges e 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 partindo do zero em 19 de setembro. A maior parte dos fundos dos clientes já estava em armazenamento frio com assinatura múltipla, distribuída por vários continentes; o serviço opera com reserva total; a autenticação de dois fatores já estava disponível e há algum tempo vínhamos incentivando os usuários a ativá-la; e os saques estavam limitados de acordo com o nível da conta. Quase tudo isso resistiu: o invasor nunca chegou ao armazenamento a frio, nunca acessou uma conta sem custódia e falhou em todas as contas que possuíam 2FA. O que falhou, especificamente, foram as verificações de autorização das ferramentas administrativas que herdamos, e um monitoramento que fiscalizava as quedas do serviço e não um administrador fazendo algo que nenhum administrador deveria fazer. O que falhou, de modo geral, foram nossas prioridades: a mudança de propriedade e, em seguida, a migração para fora da custódia ocuparam a maior parte da equipe, e o trabalho de segurança no código herdado ficou para trás.
O que fizemos nos primeiros dias:
A plataforma como um todo continua sendo reforçada.
E dois compromissos que começam hoje:
1.A recompensa por recuperação. Pagaremos 25% do valor de qualquer parte dos 6,61 BTC roubados em 19 de setembro que for recuperada como resultado direto de informações que você nos fornecer: até cerca de 1,65 BTC caso tudo seja recuperado. De tudo o que for recuperado, outros 25% serão destinados à Bitcoin Beach, à Bitcoin Ekasi, à Afribit Kibera e às economias circulares de Bitcoin do Sul Global que elas escolherem em conjunto e que possam precisar de apoio adicional. A oferta não tem prazo de validade; escreva para bounty@blinkbtc.com. A recompensa só será paga com fundos que tenham sido devolvidos a uma carteira sob nosso controle. Os fundos roubados podem ser devolvidos na cadeia de blocos para bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 ou via Lightning para o endereço Lightning bounty@blink.sv.
2.Um canal para relatar problemas de segurança, com recompensas. Escreva para bounty@blinkbtc.com. Confirmamos o recebimento de cada relato em até 72 horas, e nossa equipe de segurança se encarrega do caso até que seja resolvido. Investigações de boa-fé sobre o software do Blink são bem-vindas, e não tomaremos medidas contra ninguém que relate 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 foi criado por causa deste incidente: cada denúncia deve ser encaminhada, receber resposta e ter um responsável 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 serão destinados ao Bitcoin Beach, ao Bitcoin Ekasi, ao Afribit Kibera e às economias circulares que eles escolherem. Acreditamos que o mais provável é que os fundos estejam perdidos para sempre. Recuperar bitcoins roubados é muito difícil; portanto, para nós, qualquer quantia recuperada já é uma grande vitória, e quanto mais pessoas conseguirmos incentivar a nos ajudar a encontrar o invasor, melhor. Alguém assim não deveria se safar tão facilmente, e queremos que gastar esse dinheiro seja o mais difícil e incômodo possível para ele.
Acrescentamos os segundos 25% porque queremos lembrar ao criminoso que roubou dinheiro que nós e nossos acionistas, comprometidos com nossa missão, teríamos preferido mil vezes destinar para apoiar a adoção do Bitcoin a partir da base e para incentivar aqueles que desenvolvem projetos com Bitcoin em comunidades sem acesso a serviços bancários em todo o mundo. Ele deveria ter vergonha.
Rastreamos os fundos ininterruptamente desde 19 de setembro. Em 1º de outubro, cerca de 0,87 BTC ainda permaneciam inativos nos endereços de destino. O restante foi transferido para outras carteiras do invasor, que também contêm bitcoins que não saíram da Blink. A partir dessas carteiras, cerca de 5,05 BTC saíram por meio de um serviço de troca entre cadeias (NEAR Intents): 1 BTC em 21 de setembro e cerca de 4,05 BTC nos dias 28 e 29 de setembro. Nosso próprio pedido de preservação de dados, de 22 de setembro, ficou sem resposta, e solicitamos às autoridades que obtenham os registros desse serviço. Cerca de 0,012 BTC chegaram a uma conta na Binance, e a equipe de segurança da Binance está colaborando e bloqueando esses fundos. Como há bitcoins do próprio invasor misturados, esses valores não somam os 6,61 BTC. Os endereços na cadeia de blocos estão no anexo.
Nosso código é aberto, e serviços que não desenvolvemos operam implementações derivadas dele. O padrão vulnerável — um fluxo de consentimento que depende da lista de permissões do navegador e um controlador de acesso que aceita qualquer token válido sem verificar o público-alvo — é anterior aos repositórios atuais do Blink e está no histórico público arquivado. Notificamos em particular os operadores das implementações derivadas de que temos conhecimento; um deles aplicou a correção no mesmo dia. Nosso aviso de segurança para o código está no GitHub em github.com/blinkbitcoin/blink/security/advisories, com um identificador CVE solicitado. Se você opera algo construído com base no código do Blink e 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á-la. As correções são os três PRs (pull requests) linkados acima. Os invasores agora estão vasculhando o código público na velocidade de uma máquina. Se você opera esse código, verifique-o hoje mesmo.
O Blink surgiu 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 funcionou. Cada um deles havia nos confiado seu dinheiro, que é a única razão de ser de um custodiante.
Aos nossos clientes, pela paciência; aos pesquisadores e às plataformas de câmbio que nos ajudaram em questão de horas; aos acionistas que apoiaram a empresa sem hesitar; e à equipe que dedicou todo um sábado e não dormiu: muito obrigado. Vamos recuperar a confiança da mesma forma que a conquistamos em El Zonte: estando presentes e garantindo que os pagamentos sejam realizados, todos os dias.
Meu dinheiro esteve em risco? Se sua conta está aberta e não entramos em contato com você, não temos registro de que o invasor tenha acessado os dados da sua conta, e nada foi retirado dela. Até o momento em que a encerramos, em 19 de setembro, a falha poderia ser explorada contra qualquer conta custodial; no entanto, em uma conta com autenticação de dois fatores (2FA), não teria sido possível movimentar dinheiro. A maior parte dos fundos dos clientes está em armazenamento frio, ao qual as ferramentas administrativas não têm acesso. Se você tem uma conta não custodial, suas chaves nunca estiveram em nossos servidores e o invasor não tinha nada para roubar.
O invasor obteve meus dados? Ele consultou dados de 3.817 contas. Entramos em contato com cada titular que conseguimos localizar para informá-lo sobre o que foi constatado. Se sua conta está ativa e você não recebeu essa mensagem, ela não estava entre as afetadas. Você sempre pode nos perguntar o que foi consultado na sua conta, caso tenha havido alguma consulta: support@blink.sv.
Por que o monitoramento do Blink não detectou o ataque? Nossos alertas foram criados para detectar interrupções no serviço. Não havia nenhuma regra para o caso de um administrador realizar ações que nenhum administrador deveria realizar, e o invasor utilizou nossas próprias ferramentas com tokens que nosso próprio sistema havia emitido.
Por que havia tanto dinheiro na carteira operacional? Tínhamos praticamente dobrado nosso saldo operacional como reserva para a migração para contas sem custódia e não o reduzimos depois que a primeira onda terminou. Agora ele está em uma fração desse nível, e não vamos divulgar o valor.
A autenticação de dois fatores (2FA) teria me protegido? Neste incidente, sim. Todas as contas que contavam com ela mantiveram seu dinheiro; nenhuma das contas que perderam dinheiro a possuía. Ela não vai impedir todos os ataques, mas impediu este. Ative-a.
Devo mudar para uma conta não custodial? Se você preferir guardar suas próprias chaves, sim: é para isso que elas servem, e ninguém na Blink — nem ninguém que consiga acessar a Blink — pode movimentar os fundos que você guarda. Não é obrigatório; ainda não conta com todos os recursos e sua disponibilidade depende da sua região. Se você continuar com uma conta custodial, 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 menos de 24 horas e desembolsado em 23 de setembro. Não foram os clientes nem as reservas dos clientes. A Blink continua operando com reserva total: cada saldo é garantido na proporção de um para um.
Encontrei uma falha de segurança no Blink. O que devo fazer? Escreva para bounty@blinkbtc.com. Responderemos em até 72 horas; seu relato terá um responsável até que seja resolvido, e as descobertas críticas são recompensadas.
Aqui iremos adicionar, com a data, as novidades sobre a recuperação, a recompensa e quaisquer correções a esta publicação.
Os endereços a seguir receberam as retiradas na cadeia. Solicitamos às corretoras e aos pesquisadores que filtrem os depósitos provenientes desses endereços e que escrevam para bounty@blinkbtc.com. (O que saiu pela Lightning foi para carteiras Lightning controladas pelo invasor e é rastreado 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 as retiradas, portanto, as 14 foram realizadas em 12 transações na cadeia. Os 1,98399667 BTC restantes do total de 6,61085425 BTC foram enviados via Lightning.
Comece a receber e enviar bitcoin agora mesmo
