Incidentes e Vulnerabilidades
Roubo de NEM da Coincheck (2018) — como cerca de US$ 530 milhões foram levados e a defesa da gestão de chaves
Em janeiro de 2018, ~523 milhões de XEM (~US$ 530 mi) foram roubados da corretora japonesa Coincheck: um saldo enorme ficava em uma 'carteira quente' sem multiassinatura, então uma única chave roubada moveu quase tudo. Defenda-se mantendo as chaves a frio, exigindo múltiplas aprovações e detectando saídas anormais.
Lemos violações reais e públicas não como notícia reprisada, mas como "como você se defende disto?". Este artigo baseia-se no registro público (reguladores, comunicados oficiais, jornalismo confiável). As fontes estão listadas ao final, e nenhum passo de ataque está incluído.
- Alvo
- Ativos de clientes (XEM/NEM) mantidos na carteira quente de uma corretora
- Detectado
- 26 de janeiro de 2018 (transferências não autorizadas)
- Padrão
- Phishing direcionado / malware contra a equipe → roubo da chave privada da carteira quente → transferência única em massa
- Escala
- ~523 milhões de XEM, ~US$ 530 milhões na época (~260.000 usuários afetados)
- Causa raiz
- Grande saldo em uma carteira quente conectada à internet + sem multiassinatura (ponto único de falha) + resiliência fraca dos endpoints + detecção/contenção fraca para saídas em massa
- Correção de verdade
- Chaves a frio / em um cofre dedicado, múltiplas aprovações, minimizar o saldo quente, defesa de endpoint/e-mail, detectar saídas anormais
O que aconteceu (em termos simples)
Uma "carteira" de cripto não guarda o ativo em si — ela protege a chave privada que pode movê-lo. As chaves podem ser mantidas de duas formas: uma "carteira quente" conectada à internet e gastável na hora, ou uma "carteira fria" offline. A quente é conveniente, mas alcançável pela rede por um atacante.
Aqui, um grande saldo de XEM era mantido em uma carteira quente e sem multiassinatura. A multiassinatura exige que várias chaves concordem antes de os fundos se moverem, de modo que uma chave vazada não consegue mover nada sozinha. Sem ela, no momento em que uma única chave privada foi roubada, quase todo o saldo pôde ser movido. As informações públicas indicam que o primeiro passo foi malware entregue por phishing direcionado contra funcionários, usado para roubar essa chave.
Um saldo grande e gastável na hora é o alvo ideal de um atacante
O que os atacantes mais valorizam é um ponto único de falha que mapeia diretamente para muito valor. Um grande saldo em uma carteira quente conectada à internet, protegido por uma assinatura, é exatamente isso. Isto não é exclusivo de cripto: uma chave de API que lê o banco de dados inteiro, ou uma conta de administrador que pode fazer tudo, carrega o mesmo perigo.
A cadeia de ataque também é um mapa de defesa
Esta foi uma cadeia com um lugar para detê-la em cada passo. Leia-a como onde ela poderia ter sido quebrada, não como um passo a passo.
1. Entrada: phishing direcionado / malware contra a equipe
Um e-mail falso e pesquisado infecta um endpoint com malware.
Parada: defesa de e-mail / endpoint (EDR, cautela com anexos e macros)
2. Roubo da chave privada da carteira quente
A partir do endpoint infectado, a chave que pode mover fundos é roubada.
Parada: mantenha as chaves offline / em um HSM; exija múltiplas assinaturas
3. Transferência única em massa (~523 mi de XEM)
Uma assinatura pode movê-lo, então quase tudo sai rapidamente.
Parada: minimize o saldo quente; detecte, aprove e congele transferências grandes
4. Lavagem / dispersão
Os ativos são movidos de formas que buscam resistir ao rastreamento.
Parada: detecção e interrupção imediata; encolha o raio de impacto de antemão
Linha do tempo publicada
2018-01-26
Transferências não autorizadas detectadas; ~523 mi de XEM (~US$ 530 mi) saem. Depósitos/saques de XEM e negociação são suspensos.2018-01-27
Coletiva de imprensa pública; a empresa declara que reembolsará os usuários afetados em ienes japoneses.2018-03
A FSA do Japão emite uma ordem de melhoria de negócios sob a Lei de Serviços de Pagamento; ~¥ 46,3 bilhões reembolsados a ~260.000 usuários.2018-04
Uma aquisição pelo Monex Group é anunciada; a gestão é reformulada.2018–
O incidente impulsiona um endurecimento gradual da supervisão das corretoras de criptoativos.
A causa raiz foi camadas falhando, não um único erro
Descartar isto como "eles foram atingidos por malware" convida a uma repetição. Na realidade várias camadas falharam em sequência.
O arranjo que falhou
- Um grande saldo de XEM mantido em uma carteira quente conectada à internet
- Sem multiassinatura — uma única chave roubada podia mover tudo (ponto único de falha)
- Os endpoints da equipe não resistiram ao primeiro passo de phishing direcionado / malware
- Capacidade fraca de deter uma grande transferência anormal a tempo
O arranjo que se sustenta
- Mantenha a maioria dos ativos em armazenamento a frio (offline); mantenha o saldo quente mínimo
- Multiassinatura / múltiplas aprovações neutraliza uma única chave vazada
- Defesa de endpoint / e-mail detém o primeiro passo de phishing direcionado
- Incorpore detecção, aprovação e congelamento de saídas em massa à operação
Reembolso e regulação: a conta a posteriori é alta
A Coincheck reembolsou os usuários afetados em ienes (~260.000 usuários, ~¥ 46,3 bilhões), recebeu uma ordem de melhoria de negócios da FSA e acabou sendo reestruturada por meio de aquisição. O custo do reembolso a posteriori, da reconstrução da confiança e da resposta regulatória é muito maior do que o investimento antecipado em design. Projete a gestão de chaves à altura do valor que você protege — antes de um incidente, não depois.
Como você se defende disto
Mesmo que você não lide com cripto, se existe um único lugar onde uma chave ou uma conta move muito valor, isto é seu. Em ordem de prioridade:
Mantenha as chaves/segredos mais importantes 'a frio'
Chaves e segredos de que você não precisa constantemente pertencem ao offline ou a um cofre dedicado (HSM/KMS). Mantenha a parte alcançável pela internet (a 'quente') mínima, para que o montante em risco, se houver violação, seja pequeno.
Remova os pontos únicos de falha (múltiplas aprovações, separação de privilégios)
Evite um estado em que uma chave ou uma pessoa possa mover todos os ativos/permissões. Exija múltiplas aprovações (equivalente a multiassinatura) para ações críticas e separe os privilégios, para que um único vazamento não seja fatal.
Reforce endpoints e e-mail contra malware
O primeiro passo costuma ser phishing direcionado e malware. Detecte anomalias de endpoint com EDR e incorpore à sua rotina a cautela com anexos, macros e links suspeitos.
Detecte e detenha operações em massa anormais
Sinalize "muito movido em pouco tempo" e "destinos incomuns", e tenha a capacidade de pausar, reter para aprovação ou congelar imediatamente. Mesmo que você não consiga preveni-lo, encurtar o tempo para perceber e deter reduz a perda.
Onde isto coincide com o modo como este site é construído
No fundo, este incidente foi sobre manter um segredo (uma chave) 'quente' demais (gastável na hora), em grande volume, como um ponto único de falha. Essa é a imagem espelhada dos próprios princípios deste site — não custodiar segredos, manter apenas o mínimo alcançável e encolher o raio de impacto. Além da cripto, uma chave de API que lê o banco de dados inteiro, ou uma conta de administrador que pode fazer tudo, carrega o mesmo perigo. "Mantenha a frio, mantenha o quente mínimo, nunca deixe uma chave mover tudo" é uma defesa que qualquer um pode implementar em qualquer escala.
Fontes (registro público)
Os fatos aqui baseiam-se nas seguintes informações públicas. Nenhum passo de ataque está incluído — apenas as lições defensivas.
- Agência de Serviços Financeiros do Japão (FSA), ação administrativa referente à Coincheck (2018) — fsa.go.jp
- Comunicados oficiais da Coincheck (aviso de transferência não autorizada / política de reembolso, 2018) — coincheck.com
- Reuters, "Japan's Coincheck exchange loses $530 million in cryptocurrency heist" (2018) — reuters.com
Leia a seguir
- Termos: Phishing (direcionado) / Malware (o primeiro passo)
- Termo: EDR (detectar anomalias de endpoint)
- Prática: Checklist de baseline de segurança (proteja primeiro as chaves do reino)
FAQ
QQual foi a causa raiz do incidente da Coincheck?
Uma quantidade muito grande de XEM (NEM) era mantida em uma 'carteira quente' conectada à internet, sem multiassinatura (multisig). Nesse arranjo, roubar uma única chave privada basta para mover quase todo o saldo. As informações públicas indicam que o ponto de apoio inicial foi malware entregue por e-mails de phishing direcionado contra funcionários, usado para roubar essa chave.
QEu não tenho criptoativos — isso é relevante para mim?
Sim. A lição não é específica de criptoativos: trata-se de manter segredos valiosos (chaves, chaves de API, direitos de administrador) em um estado 'quente', gastável na hora, em grande volume, como um ponto único de falha. Mantenha os segredos importantes a frio ou em um cofre dedicado (HSM/KMS), minimize o que é alcançável a partir da internet e garanta que nenhuma chave única possa mover tudo. Isso vale para qualquer sistema.
QUm serviço pequeno pode aprender algo com isto?
Sim: (1) mantenha as chaves/segredos mais importantes offline ou em um armazenamento dedicado (HSM/KMS); (2) garanta que nenhuma chave ou pessoa única possa mover todos os ativos/permissões (múltiplas aprovações, separação de privilégios); (3) defenda os endpoints contra malware e a equipe contra phishing direcionado; (4) detecte e detenha operações em massa anormais. Tudo isso funciona em qualquer escala.