Kronos Research API-Key-Diebstahl

Am 19. November 2023 legte das Taipei-basierte Handelsunternehmen Kronos Research öffentlich offen, dass 26 Millionen $ durch einen Cyberangriff auf die API-Infrastruktur der Firma gestohlen worden waren. Entscheidend: Die Angreifer stahlen keine Private Keys — sie stahlen API-Keys, die programmatische Withdraw-Autorität über Kronos' Wallets kontrollierten. Die Kompromittierung zwang WOO Network, eine große Börse, die Kronos als ihren primären Market Maker nutzte, den Handel auszusetzen.

Was geschah

Kronos Research operierte als High-Frequency-Market-Maker und ließ automatisierten Handel und Rebalancing über mehrere Börsen und DeFi-Protokolle laufen. Die Automatisierung der Firma stützte sich auf API-Keys — Service-Account-Credentials, die programmatische Aktionen einschließlich Wallet-Withdrawals innerhalb vorkonfigurierter Limits autorisierten.

Die Angreifer kompromittierten diese API-Keys auf eine Weise, die Kronos öffentlich nicht detaillierte. Mit den Keys in der Hand konnten sie:

1. Withdrawals einleiten aus Kronos' Wallets über dieselben programmatischen Pfade, die Kronos selbst nutzte.
2. Rund 26 Mio. $ in gemischten Assets drainen, bevor die Firma die unautorisierte Aktivität entdeckte und Credentials rotierte.

Die Withdraw-Limit-Konfigurationen der API-Keys fingen die Aktivität nicht rechtzeitig ab — entweder weil der Angreifer pro Aktion innerhalb der konfigurierten Limits blieb und viele Aktionen machte, oder weil die Limits für operative Bequemlichkeit großzügig gesetzt waren.

Folgen

• Kronos stoppte alle Handelsoperationen, um eine gründliche Untersuchung durchzuführen.
• WOO Network, abhängig von Kronos für Market-Making-Liquidität, pausierte den Handel komplett, bis alternative Arrangements getroffen werden konnten.
• Kronos bestätigte, der Verlust werde intern absorbiert, ohne Partner oder Gegenparteien zu betreffen.
• Gestohlene Gelder wurden gewaschen; keine öffentliche Wiederherstellung.

Warum es wichtig ist

Der Kronos-Research-Vorfall ist der kanonische Fall dafür, warum API-Key-Sicherheit ein Custody-Anliegen ist, nicht nur ein Operations-Anliegen. Viele Firmen — Börsen, Market Maker, Payment-Processors — betreiben große Teile ihres Geschäfts über API-Keys mit effektiver Signing-Autorität über Wallets. Das Trust-Modell lautet „der API-Key ist an ein spezifisches Service-Account mit konfiguriertem Permission-Scope gebunden" — in der Praxis aber:

• API-Keys werden auf operativen Servern mit breiterer Angriffsfläche als HSM-isolierte Signing-Keys gespeichert.
• Ihre Permission-Scopes sind meist für den typischen Fall konfiguriert, nicht für das Worst-Case-Angreifer-Szenario.
• Sie sind routinemäßig einer breiteren Population von Mitarbeitern ausgesetzt (Operations, DevOps, Engineering) als die Private Keys selbst.

Moderne Best Practices seit dem Kronos-Vorfall umfassen:

• Engere Per-Key-Withdrawal-Velocity-Limits mit Auto-Suspendierung bei Anomalien.
• Erforderliche Out-of-Band-Bestätigung für Withdrawals an externe Adressen.
• HSM-gestützte API-Keys, die nicht vom Host exfiltriert werden können, selbst wenn der Server kompromittiert ist.
• Whitelisted Ziel-Adressen für jede programmatische Withdraw-Autorität.

Die Lektion, bei Kronos bezahlt: Ein Private Key in einem Hardware Security Module unterscheidet sich bedeutend von einem Private Key in einer Software-Wallet, und ein API-Key, der autorisiert ist, auf einen von beiden zu wirken, ist seine eigene Asset-Klasse mit seinem eigenen Threat-Modell.