BLOG |

Blink-Ankündigungen

Der Angriff vom 19. September – Die Fakten, die ganze Geschichte und die Ankündigung einer Belohnung von 50 % (bis zu 3,3 Bitcoin)

Wie ein Angreifer eine Schwachstelle in unseren Admin-Tools ausnutzte, um 6,61 BTC von 24 Konten zu entwenden, wie alle Konten wiederhergestellt wurden und welche Änderungen wir vorgenommen haben.

Der Angriff vom 19. September – Die Fakten, die ganze Geschichte und die Ankündigung einer Belohnung von 50 % (bis zu 3,3 Bitcoin)
3. Oktober 2026
Blink-Team

Am Samstag, dem 19. September, um 11:39 Uhr UTC rief ein Kunde einen unserer Techniker an und teilte ihm mit, dass sein Guthaben auf Blink verschwunden sei. Fünfzehn Minuten später hatten wir den gesamten Verwahrungsdienst abgeschaltet. Am selben Abend war die Lücke geschlossen. Bis zum folgenden Donnerstag hatten alle betroffenen Kunden ihr Guthaben in voller Höhe zurückerhalten, finanziert durch die Aktionäre von Blink. Kein Kunde hat einen Verlust erlitten.

An die 22 Kunden, deren Bitcoin entwendet wurde, und an die 3.817 Personen, deren Kontodaten abgerufen wurden: Es tut uns leid.

‍

Die Fakten

Was ist passiert? Ein Angreifer eröffnete am 17. September ein gewöhnliches kostenloses Konto bei Blink . Zwei Tage später nutzte er eine Schwachstelle in der Berechtigungsprüfung unserer Verwaltungstools aus, um diesem Konto Administratorrechte zu verleihen. Mit diesen Berechtigungen änderte er die E-Mail-Adresse oder Telefonnummer bei 35 Konten, meldete sich bei diesen Konten an, als wäre er der Inhaber, erhöhte bei 14 davon die Auszahlungslimits und zog zwischen 09:51 und 11:54 UTC Bitcoin von 24 Konten ab – teils auf der Blockchain, teils über Lightning mithilfe des Prozesses, den wir entwickelt haben, um Kunden beim Übergang zur Selbstverwahrung zu unterstützen. Der Angreifer erbeutete etwa 6,61 BTC.

Wem das Geld gehörte. Sie hatten es auf 36 Treuhandkonten abgesehen. Eines entging ihnen durch Zufall: Ihre Versuche, dessen E-Mail-Adresse zu ändern, schlugen fehl, und sie wandten sich anderen zu. Von den 35 Konten, die sie übernommen hatten, hoben sie von 24 Geld ab. Neun Konten verfügten über eine Zwei-Faktor-Authentifizierung und erlitten keinen Verlust (siehe unten), und die letzten beiden Konten wurden von den Angreifern erst wenige Minuten vor der Abschaltung des Dienstes übernommen, sodass von diesen Konten nichts abgehoben wurde. 22 der 24 leergeräumten Konten gehörten Kunden; zwei gehörten Unternehmen der „ Blink “-Gruppe. Jedes Konto wurde am 24. September auf genau den Stand vor dem Vorfall zurückgesetzt, wobei die Abhebungsgebühren erstattet wurden, und die gesperrten Konten wurden ab diesem Tag wieder freigeschaltet. Blink trägt den Verlust.

Was nicht betroffen war: Das Geld stammte aus unserer „Hot Wallet“ – dem Betriebsguthaben, das wir für alltägliche Zahlungen vorhalten. Der Großteil der Kundengelder befindet sich in einem „Cold Storage“ mit Mehrfachsignatur, für den mehrere Schlüssel erforderlich sind, die sich im Besitz verschiedener Personen befinden, und auf den unsere Verwaltungstools keinen Zugriff haben. Nicht-verwahrende Konten spielten dabei keine Rolle: Da wir diese Schlüssel nicht besitzen, gab es für den Angreifer nichts zu stehlen.

Was sie gesehen haben. Während des Angriffs haben sie zudem Details von 3.817 weiteren Konten eingesehen. Bei einigen davon handelte es sich um eine Telefonnummer oder eine E-Mail-Adresse. Namen, Ausweisdokumente, Adressen, Passwörter oder Seed-Phrasen waren nicht zu sehen. Wir haben jeden Kontoinhaber, den wir erreichen konnten, schriftlich darüber informiert, welche Daten eingesehen wurden.

Was sie aufgehalten hat? Die Zwei-Faktor-Authentifizierung. Bei keinem der 24 leergeräumten Konten war sie aktiviert. Bei neun der von ihnen ins Visier genommenen Konten war dies jedoch der Fall. Der Angreifer loggte sich bei allen neun Konten ein, doch jeder seiner 18 Versuche, diese Konten zu nutzen, wurde abgelehnt. Kein Verlust. Wir weisen darauf hin, weil dies eine der wichtigsten Lehren aus diesem Vorfall ist: Die Zwei-Faktor-Authentifizierung hat funktioniert, und wir hätten sie für große Abhebungen und für Konten mit hohen Guthaben vorschreiben sollen.

Was wir geändert haben. Die Sicherheitslücke wurde noch am selben Tag geschlossen, und am 21. September wurde eine dritte Schutzebene in die Produktion übernommen. Die Admin-Tools sind nicht mehr über das öffentliche Internet erreichbar. Die Admin-Funktionen, mit denen die E-Mail-Adresse oder die Telefonnummer eines Kunden geändert werden können, sind für alle deaktiviert, während wir sie neu gestalten. Alle API-Schlüssel der Kunden wurden widerrufen. Die Hot Wallet enthält nun nur noch einen Bruchteil des früheren Bestands. Eine vollständige Liste finden Sie weiter unten.

Wo das Geld ist. Ein Teil davon befindet sich noch immer auf den Adressen, auf die es überwiesen wurde. Der Rest floss in ihre anderen Wallets, von denen etwa 5 BTC über einen kettenübergreifenden Swap-Dienst transferiert wurden und ein kleiner Betrag bei Binance einging. In El Salvador wurde bei der Fiscalía General de la República Strafanzeige erstattet und die Finanzaufsichtsbehörde benachrichtigt; in Próspera ZEDE wurde bei der Polizei Strafanzeige erstattet und die Finanzaufsichtsbehörde benachrichtigt. Wir rechnen nicht damit, das Geld zurückzubekommen; die unten angegebene Belohnung ist für jeden, der das ändern kann.

Eine Prämie von 50 %. Wir zahlen 25 % des Wertes jedes Teils der am 19. September gestohlenen 6,61 BTC, der als direkte Folge der von Ihnen bereitgestellten Informationen wiederbeschafft wird – bis zu etwa 1,65 BTC, falls der gesamte Betrag wiederbeschafft würde. Weitere 25 % aller wiedererlangten Beträge gehen an Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera und die von ihnen gemeinsam ausgewählten Bitcoin-Kreislaufwirtschaften im Globalen Süden. Wenn Informationen dazu führen, dass Gelder eingefroren werden, wird die Prämie ausgezahlt, sobald diese Gelder an eine von uns kontrollierte Wallet zurückgeführt wurden. Das Angebot ist zeitlich unbegrenzt. Schreiben Sie an bounty@blinkbtc.com. Die vollständigen, maßgeblichen Bedingungen finden Sie unter blink.sv/bounty-terms.

Was Sie tun sollten: Aktivieren Sie die Zwei-Faktor-Authentifizierung (Einstellungen → Sicherheit und Datenschutz → Zwei-Faktor-Authentifizierung) und richten Sie diese auch für Ihr E-Mail-Konto ein. Fügen Sie eine E-Mail-Anmeldung hinzu, falls Sie nur ein Smartphone besitzen, da eine Telefonnummer durch einen SIM-Swap kompromittiert werden kann. Wenn Sie die API nutzen, erstellen Sie einen neuen Schlüssel. Ignorieren Sie alle E-Mails oder SMS zu diesem Vorfall, die einen Link enthalten: Wir haben betroffene Nutzer über Nachrichten in der „ Blink “-App kontaktiert. Wir werden Sie niemals nach Ihrer PIN, Ihrem Passwort, Ihrer Seed-Phrase oder einem Anmeldecode fragen oder Sie auffordern, Guthaben zu überweisen. Falls wir Ihnen eine Nachricht bezüglich Ihres Kontos geschickt haben, befolgen Sie bitte die darin beschriebenen Schritte. Wenn Sie Ihre Schlüssel lieber selbst verwahren möchten, stehen Ihnen seit Juni nicht-verwahrende Konten in der App zur Verfügung (Einstellungen → Zu nicht-verwahrendem Konto wechseln).

‍

Die ganze Geschichte

Samstag

Blink wird von etwa zwanzig Mitarbeitern in einem Dutzend Zeitzonen betrieben, daher gibt es keinen Samstagvormittag, der für uns alle gleichzeitig stattfindet. Um 11:39 Uhr UTC war es in Hongkong früher Abend, in Europa Mittagszeit und in El Salvador noch vor Sonnenaufgang. Der Kunde, der angerufen hatte, hatte bemerkt, dass sein Guthaben bei null stand und seine E-Mail-Adresse geändert worden war. Innerhalb von sechs Minuten war das Team in einer Telefonkonferenz, die ersten Konten waren manuell über das Admin-Panel gesperrt worden, und die entscheidende Entscheidung war gefallen: alles abschalten.

Um 11:54 Uhr haben wir das gesamte Backend für die Verwahrung offline genommen. Diese Entscheidung kostete jeden Nutzer von Blink fast acht Stunden Ausfallzeit. Die Auszahlungen wurden in dem Moment eingestellt, als der Dienst ausfiel. Um 12:41 Uhr veröffentlichten wir die erste öffentliche Mitteilung: Dienst unterbrochen, Untersuchung läuft. Um 16:06 Uhr veröffentlichten wir die zweite: Jedes betroffene Konto wird vollständig entschädigt.

Um 16:17 Uhr wurde der erste Fix integriert und um 17:50 Uhr der dritte. Die verbleibenden Guthaben in den Hot Wallets wurden auf neue Adressen übertragen, sodass alle bereits signierten Auszahlungen für die Abhebungen des Angreifers zurückgewiesen wurden. Um 19:34 Uhr schalteten wir den Dienst für alle wieder frei, mit Ausnahme der 36 Konten, auf die der Angreifer zugegriffen hatte; diese blieben gesperrt, bis wir sie ordnungsgemäß wiederherstellen konnten. Die Admin-Funktionen zur Änderung von Kontaktdaten blieben als zweite Sicherheitsmaßnahme gesperrt. Die Korrektur wurde noch am selben Abend auf der Staging-Umgebung verifiziert, und in den folgenden Tagen führten wir den gesamten Angriff selbst noch einmal anhand einer Kopie des Codes vor der Korrektur durch, um sicherzustellen, dass wir ihn verstanden hatten – und bestätigten anschließend, dass jede Ebene den Angriff nun verhindert.

Die Zeitleiste

Alle Zeiten sind in UTC angegeben; in El Salvador liegt die Uhrzeit sechs Stunden zurück.

Zeit (UTC) · Was ist passiert?
17. September, abends
Der Angreifer erstellt ein gewöhnliches Konto unter Blink .
18.–19. September
Der Angreifer sondiert unsere Systeme über dieses Konto; das Hinzufügen von Administratorrechten zur Hauptautorisierungsanfrage wird aufgrund unserer Konfiguration abgelehnt.
19. September, 04:36 Uhr
Das Hinzufügen auf der Einwilligungsseite gelingt; es folgen die ersten Admin-Abfragen des Angreifers.
19. September, 09:30–11:54 Uhr
Etwa 4.650 Abfragen durch Administratoren anhand des Benutzernamens, während die Übernahmen laufen.
19. September, 09:37–11:51 Uhr
Bei 35 Konten wurden die Kontaktdaten geändert; bei 14 Konten wurden die Auszahlungslimits angehoben.
19. September, 09:51–11:54 Uhr
Abhebungen von 24 Konten, on-chain und über Lightning.
19. September, 11:39 Uhr
Ein Kunde ruft an und meldet, dass sein Konto leergeräumt wurde. Unser Überwachungssystem hatte den Angriff nicht erkannt.
19. September, 11:43–11:45 Uhr: Telefonat mit dem „
“-Team; erste Konten wurden über das Admin-Panel gesperrt; Entscheidung zur Schließung.
19. September, ca. 11:54 Uhr
Die Verwahrungsdienste wurden offline geschaltet; die Auszahlungen wurden eingestellt.
19. September, 12:41 Uhr
Erste öffentliche Bekanntmachung: Dienstleistungen ausgesetzt.
19. September, 16:06 Uhr
Öffentliche Zusage, dass alle betroffenen Konten wieder vollständig ausgeglichen werden.
19. September, 16:17–17:50 Uhr
Die drei Pull-Requests zur Fehlerbehebung wurden zusammengeführt; die verbleibenden Guthaben im Hot-Wallet wurden auf neue Adressen übertragen, sodass alle noch ausstehenden, bereits signierten Auszahlungen ungültig wurden.
19. September, 19:34 Uhr
Der Dienst wurde für alle anderen Konten wiederhergestellt, wobei die Funktionen zur Änderung der Administratorkontakte gesperrt sind; die 36 betroffenen Konten bleiben gesperrt.
19. September, abends
Öffentliche Bekanntmachung, dass der Dienst wieder verfügbar ist und eine umfassende Nachanalyse folgen wird; die Behebung wurde auf der Staging-Umgebung überprüft; das Konto und die Sitzungen des Angreifers wurden gesperrt.
19.–20. September
: Die Adressen der Angreifer wurden identifiziert und an die Börsen weitergeleitet; der Abgleich der Ledger wurde abgeschlossen.
20.–23. September
Der Angreifer meldet sich erneut bei vier der gesperrten Konten an, deren Kontaktdaten noch immer die E-Mail-Adresse des Angreifers enthielten; jeder Zahlungsversuch wird abgelehnt, und es geschieht nichts. Am 23. September werden alle Sitzungen auf den betroffenen Konten beendet und die Kontaktdaten wiederhergestellt.
21. September
: Die Adressen des Angreifers wurden in unsere Sperrliste für Auszahlungen aufgenommen; Börsen beginnen mit der Sperrung. Die Überprüfung der Berechtigungen für Admin-Token geht in der Produktionsumgebung live. Etwa 1 BTC wird aus den Wallets des Angreifers in einen kettenübergreifenden Swap-Dienst übertragen.
23. September
Die Aktionäre stellen die Mittel bereit.
24. September
Alle betroffenen Guthaben wurden vollständig wiederhergestellt und die gesperrten Konten wieder freigeschaltet; öffentliche Bekanntmachung, dass alle betroffenen Konten wieder vollständig ausgeglichen wurden. Die Admin-API und das Admin-Panel wurden aus dem öffentlichen Internet entfernt (nur noch über VPN zugänglich).
24. September–1. Oktober
Interne Benachrichtigungen an die Betreiber der uns bekannten abgeleiteten Bereitstellungen.
28.–29. September
Etwa 4,05 BTC werden aus den Wallets des Angreifers an einen kettenübergreifenden Swap-Dienst überwiesen.
30. September
Die Finanzaufsichtsbehörde von El Salvador (Superintendencia del Sistema Financiero) und die Behörde für Cybersicherheit (Agencia de Ciberseguridad del Estado) wurden benachrichtigt; bei der Polizeidienststelle von Próspera ZEDE wurde Strafanzeige erstattet.
1. Oktober
Strafanzeige bei der Generalstaatsanwaltschaft der Republik El Salvador (Fiscalía General de la República) eingereicht; die Finanzaufsichtsbehörde von Roatán (Próspera ZEDE) wurde benachrichtigt.
2. Oktober
Nach einer erneuten Überprüfung unserer Protokolle werden 331 weitere Kontoinhaber, deren Daten eingesehen wurden, in der App benachrichtigt; die aktualisierten Zahlen werden an die Behörden übermittelt.

‍

So lief der Angriff ab

Vom Oktober 2023 bis zum 19. September 2026 konnte sich jeder, der über ein kostenloses Konto bei Blink und einen Webbrowser verfügte, die Befugnisse unseres Support-Teams aneignen: die E-Mail-Adresse oder Telefonnummer im Konto eines beliebigen Kunden ändern, sich anschließend als dieser Kunde anmelden und dessen Auszahlungslimits erhöhen. Wir veröffentlichen genau, wie das funktioniert, da unser Code Open Source ist, andere Dienste darauf aufbauende Implementierungen betreiben und der zugrunde liegende Fehler – nämlich darauf zu vertrauen, dass ein Token selbst beschreibt, was es tun darf – in jedem System auftreten kann, das auf die gleiche Weise aufgebaut ist.

Unsere Mitarbeiter nutzen eine Administrationsoberfläche, um Kunden dabei zu helfen, ein Konto zu entsperren, eine Telefonnummer zu korrigieren oder ein Limit zu erhöhen. Der Zugriff darauf erfolgt über OAuth2, denselben Standard, mit dem man sich über eine Website bei einer anderen anmelden kann. Es gab drei verschiedene Fehler, von denen jeder für sich genommen nichts Besonderes ist.

Der Einwilligungsbildschirm vertraute dem Browser. Wenn eine App um Berechtigungen bat, übernahm unsere Einwilligungsseite die Liste der Berechtigungen direkt aus dem vom Browser übermittelten Formular und leitete sie unverändert an unseren OAuth-Server weiter. Diese Liste wurde niemals mit den tatsächlich von der App angeforderten Berechtigungen abgeglichen. So hätte jeder ein verstecktes Feld mit dem Text „Gib mir auch Admin-Rechte“ zum Formular hinzufügen können, und der Server – der zu Recht seiner eigenen Einwilligungsseite vertraute – hätte ein vollkommen gültiges Token generiert, das „Admin“ enthielt.

Die Admin-API vertraute jedem Token. Der davor geschaltete Gatekeeper akzeptierte jedes aktive Token von unserem OAuth-Server: Es wurden weder Berechtigungen abgefragt, noch wurde überprüft, ob das Token für die Admin-API bestimmt war, noch wurde geprüft, um welchen Client es sich handelte. Er kopierte die vom Token selbst angegebenen Berechtigungen in die Anmeldedaten, die der Admin-Server verwendet.

Der Admin-Server vertraute der Berechtigungszeichenfolge. Wenn in der Zeichenfolge „admin“ stand, war man Administrator. Es wurde nicht überprüft, ob die Person hinter dem Token ein bekannter Administrator war.

Beides zusammen führte dazu, dass ein kostenloses Konto und ein Browser ausreichten. Es wurden weder ein Mitarbeiterkonto noch Anmeldedaten von Mitarbeitern verwendet, und es war keine Malware im Spiel. Unser eigenes Identitätssystem hat diese Tokens ausgestellt, weshalb auch kein Alarm ausgelöst wurde. Der Angreifer versuchte es zunächst auf dem naheliegenden Weg – indem er Berechtigungen zur Hauptautorisierungsanfrage hinzufügte –, und unsere Konfiguration wies dies korrekt zurück. Dann versuchte er es über die Einwilligungsseite, und diese ließ ihn durch.

Für jeden, der einen ähnlichen Stack überprüft, ist der Verlauf von Bedeutung. Die Sicherheitslücke entstand im Oktober 2023 durch drei aufeinanderfolgende Pull-Requests: Der erste sorgte dafür, dass die Admin-API OAuth-Token akzeptierte, während eine separate Editor-Prüfung dies weiterhin sicherte; der zweite entfernte diese Editor-Prüfung; der dritte gewährte jedem Nutzer Zugriff auf den OAuth-Einwilligungsbildschirm. Eine Sicherheitsverbesserung im Mai 2026 (PR #158) fügte Anforderungen an die Administratorberechtigungen auf dem Admin-Server hinzu, doch diese Berechtigungen wurden aus dem Token selbst ausgelesen, und die Einwilligungsseite erlaubte es weiterhin jedem, sie dort einzutragen. Die Schwachstelle war rund drei Jahre lang ausnutzbar.

Die Korrekturen sind öffentlich: Die Einwilligungsseite lehnt nun jede Berechtigung ab, um die die App nicht gebeten hat (PR #853); Admin-Token müssen eine Zielgruppe enthalten, die ausschließlich für die Admin-API ausgestellt wurde und die Kundentoken nicht erhalten können (derselbe PR; PR #855 ermöglichte es uns, diese Überprüfung in der Produktionsumgebung separat zu aktivieren, was wir am 21. September getan haben); und die Admin-Funktionen, die Kontaktdaten ändern, können per Konfiguration für alle Nutzer vollständig deaktiviert werden (PR #861).

‍

Wie es drei Jahre überstanden hat

Der Code wurde im Jahr 2023 in dem Unternehmen geschrieben, in dem die Plattform „ Blink “ seit 2019 entwickelt wurde, und ging im Oktober 2024 in unseren Besitz über, als „ Blink “ einen Eigentümerwechsel durchlief und zu einem eigenständigen Unternehmen wurde. Zwei der Ingenieure, die die Plattform entwickelt hatten, kamen zu uns, doch die Ingenieure, die den Autorisierungsablauf für Administratoren programmiert hatten, blieben zurück, sodass niemand im Team von Blink wusste, warum es dort eine frühere Berechtigungsprüfung gegeben hatte. Im Laufe des Jahres 2025 floss der Großteil unserer technischen Arbeit in die Trennung unserer Systeme von denen des anderen Unternehmens, die im Laufe der Jahre miteinander verwachsen waren: unsere eigene Infrastruktur, unsere eigenen Konten, unser eigener Knoten.

Im Jahr 2026 änderten sich die gesetzlichen Rahmenbedingungen in vielen der Länder, in denen wir tätig waren. Google führte in fünfzehn Märkten die Verpflichtung zur Einholung lokaler Lizenzen für Wallet-Apps ein, die Übergangsfrist für die MiCA-Vorschriften der EU endete am 1. Juli, und viele andere Länder verabschiedeten neue Gesetze oder setzten bereits in früheren Jahren verabschiedete Gesetze in Kraft. Wir reagierten darauf, indem wir weniger Geld unserer Kunden verwahrten, anstatt weitere Lizenzen zu beantragen: Wir entwickelten und führten eine nicht-custodial wallet ein, stellten den Verwahrungsdienst in mehr als vierzig Rechtsordnungen ein und führten Zehntausende von Nutzern auf Konten um, bei denen sie ihre eigenen Schlüssel verwahren. Unser Beitrag zur Einführung der nicht-custodial Lösung im Juni beschreibt diese Arbeit. Für ein Team von etwa zwanzig Mitarbeitern nahm dies fast das gesamte Jahr in Anspruch.

Hinter diesen beiden Projekten stand die Aufgabe, den Code, den wir übernommen hatten, sicherer zu machen. Das hat zu lange auf sich warten lassen. Als Erstes haben wir geändert, wie Sicherheitsbefunde priorisiert und zugeordnet werden.

Die erhöhte Hot-Wallet-Kapazität ist Teil derselben Geschichte. Wir hatten sie als Puffer für die Migration auf etwa das Doppelte des normalen Niveaus hochgefahren, wobei die erste Welle der Migration ein oder zwei Wochen vor dem Angriff abgeschlossen worden war. Wir hatten sie noch nicht wieder auf das normale Niveau zurückgeführt. Deshalb konnte der Verlust so hoch ausfallen. Inzwischen wurde sie auf einen Bruchteil dieses Niveaus reduziert, und der Betriebssaldo von „ Lightning “ wird weiter abgebaut.

‍

Was die 2FA bewirkt hat

Der Angreifer übernahm 35 Konten auf dieselbe Weise: Er änderte die E-Mail-Adresse oder Telefonnummer über die Admin-Tools, forderte einen Anmeldecode an und meldete sich an. Bei 24 davon hob er anschließend Geld ab. Bei neun stieß er auf eine Hürde. Bei diesen neun war die Zwei-Faktor-Authentifizierung aktiviert – eine Authentifizierungs-App auf dem Smartphone des Kontoinhabers – und bei einem durch 2FA geschützten Konto kann eine Sitzung, die man nur mit einem Anmeldecode eröffnet hat, kein Geld überweisen. Unsere Protokolle zeigen, dass alle 18 Versuche des Angreifers bei diesen neun Konten genau an dieser Hürde scheiterten. Bei keinem einzigen entstand ein Verlust.

Die Zwei-Faktor-Authentifizierung (2FA) konnte die Übernahme unserer Admin-Tools zwar nicht verhindern, hat aber den Diebstahl aus einzelnen Konten verhindert. Keines der 24 Konten, von denen Geld abgezogen wurde, hatte diese Funktion aktiviert. Wir hätten sie für große Abhebungen und für Konten mit hohen Guthaben vorschreiben sollen.

Wenn Sie nur eine Maßnahme aus diesem Beitrag umsetzen, dann sollte es diese sein: Einstellungen → Sicherheit und Datenschutz → Zwei-Faktor-Authentifizierung. Aktivieren Sie diese Funktion anschließend auch für Ihr E-Mail-Konto, da Ihre Anmeldecodes für Blink dorthin gesendet werden können.

‍

In der Woche danach

Am Sonntag, dem Tag nach dem Angriff, wussten wir bereits, wem was entwendet worden war – bis auf den letzten Satoshi –, hatten die Beträge mit dem Hauptbuch, der Blockchain und dem Knoten „ Lightning “ abgeglichen, und der Vorstand hatte entschieden, wie die Kosten gedeckt werden sollten. Die Aktionäre von Blink stellten den gesamten Betrag innerhalb von 24 Stunden als zinsloses Darlehen zur Verfügung, zahlten ihn am Mittwoch aus, und jedem Aktionär wurde die Möglichkeit geboten, seinen Anteil zu denselben Konditionen zu finanzieren. Am Donnerstag, dem 24. September, haben wir alle betroffenen Guthaben wiederhergestellt und die Gebühren zurückerstattet, die wir für die betrügerischen Abhebungen erhoben hatten. Die betroffenen Kunden wurden direkt von uns informiert, bevor wir weitere öffentliche Erklärungen abgaben, ebenso wie die Personen, deren Daten eingesehen worden waren.

Die Reihenfolge war bewusst gewählt. Zuerst die Nutzer, alles andere kommt später. Wir haben unsere Aktionäre am Freitag mit denselben Fakten informiert, die Sie gerade lesen, und diesen Beitrag zurückgehalten, bis die Behörden unsere Meldungen erhalten hatten: eine Strafanzeige bei der Fiscalía General de la República von El Salvador, Meldungen an die Finanzaufsichtsbehörde und die Cybersicherheitsbehörde von El Salvador, eine Strafanzeige bei der Polizeibehörde von Próspera ZEDE sowie eine Meldung an die Finanzaufsichtsbehörde von Próspera.

In dieser Woche ereigneten sich zwei Dinge, die wir zu Protokoll geben möchten. Am Sonntag schrieb uns der Angreifer und forderte eine Zahlung, wobei er damit drohte, Nutzerdaten zu veröffentlichen. Wir haben nicht gezahlt und werden es auch nicht tun; die Nachricht dient nun als Beweis für seinen Erpressungsversuch. Und vom Sonntag bis zum Mittwoch loggte er sich immer wieder ein – bei vier der gesperrten Konten, deren Kontaktdaten noch die E-Mail-Adresse des Angreifers enthielten, da wir diese noch nicht wiederhergestellt hatten. Jeder Zahlungsversuch wurde abgelehnt, und es passierte nichts. Das hätte eigentlich nicht möglich sein dürfen. Unser Reaktivierungsverfahren stellt nun zuerst die Kontaktdaten wieder her, beendet jede Sitzung und entsperrt erst danach das Konto.

Wir sind nicht das erste Unternehmen, das einen solchen Verlust übernimmt und die Nutzer entschädigt. Börsen und Wallets haben dies bereits vor uns getan. Der Verlust eines Verwahrers geht zu Lasten des Verwahrers.

‍

Was wir geändert haben

Blink Am 19. September fingen wir nicht bei Null an. Der Großteil der Kundengelder befand sich bereits in einem über mehrere Kontinente verteilten Cold Storage mit Mehrfachsignatur; der Dienst arbeitet mit Vollreserve; die Zwei-Faktor-Authentifizierung war verfügbar, und wir hatten die Nutzer dazu angehalten, diese zu nutzen; außerdem waren Auszahlungen auf Kontoebene begrenzt. Das meiste davon hielt stand: Der Angreifer gelangte nie an den Cold Storage heran, griff nie auf ein nicht-verwahrendes Konto zu und scheiterte bei jedem Konto, das über 2FA verfügte. Was konkret versagte, waren die Autorisierungsprüfungen in unseren übernommenen Admin-Tools sowie die Überwachung, die eher auf Ausfälle abstellte als darauf, dass ein Administrator etwas tat, was kein Administrator tun sollte. Was ganz allgemein versagte, waren unsere Prioritäten: Der Eigentümerwechsel und anschließend die Abkehr von der Verwahrung beanspruchten den Großteil des Teams, und die Sicherheitsarbeit am Code, den wir übernommen hatten, musste zurückstehen.

Was wir in den ersten Tagen dagegen unternommen haben:

  • Die Sicherheitslücke wurde am 19. September durch den „Consent Fix“ geschlossen, wobei die Admin-Funktionen zur Änderung von Kontaktdaten als zweite Sicherheitsmaßnahme gesperrt wurden; der Dienst wurde noch am selben Abend wieder in Betrieb genommen, und die Korrektur wurde noch am selben Abend in der Staging-Umgebung überprüft. Die dritte Schutzebene, die Zielgruppenprüfung für Admin-Token, wurde am 21. September in die Produktionsumgebung übernommen.
  • Die Admin-Oberfläche akzeptiert nur Zugangsdaten, die speziell dafür ausgestellt wurden, und die Admin-API sowie das Admin-Panel wurden am 24. September aus dem öffentlichen Internet entfernt; Zugriff nur über VPN.
  • Die Admin-Funktionen, mit denen die E-Mail-Adresse oder die Telefonnummer eines Kunden geändert werden können, wurden für alle Anrufer deaktiviert, während wir einen schrittweisen Ablauf entwerfen.
  • Alle Sitzungen des Angreifers und alle OAuth-Berechtigungen wurden widerrufen – die letzte davon am 23. September – und alle API-Schlüssel der Kunden wurden vorsorglich widerrufen.
  • Auszahlungen an die Adressen des Angreifers wurden blockiert; die Adressen wurden unten veröffentlicht, damit andere sie überprüfen können.
  • Die Betriebsguthaben wurden auf einen Bruchteil ihres früheren Umfangs reduziert und auf einem niedrigen Niveau gehalten.
  • Sicherheitskorrekturen werden nun in einem privaten Mirror entwickelt und erst nach der Bereitstellung in das öffentliche Repository übertragen, sodass eine Korrektur nicht öffentlich diskutiert wird, solange die Sicherheitslücke noch besteht. Der Code bleibt Open Source.

Auf der gesamten Plattform finden derzeit weitere Sicherheitsmaßnahmen statt.

Und zwei Verpflichtungen, die heute in Kraft treten:

1.Die Belohnung für die Wiederbeschaffung. Wir zahlen 25 % des Wertes jedes Teils der am 19. September gestohlenen 6,61 BTC, der als direkte Folge der von Ihnen bereitgestellten Informationen wiedergefunden wird – bis zu etwa 1,65 BTC, falls der gesamte Betrag wiedergefunden würde. Von allem, was wiedergefunden wird, gehen weitere 25 % an Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera und deren gemeinsam ausgewählte Bitcoin-Kreislaufwirtschaftsprojekte im Globalen Süden, die zusätzliche Unterstützung gebrauchen könnten. Das Angebot ist zeitlich unbegrenzt; schreiben Sie an bounty@blinkbtc.com. Die Prämie wird ausschließlich aus Mitteln gezahlt, die in eine von uns kontrollierte Wallet zurückgeführt wurden. Gestohlene Gelder können on-chain an bc1q5vek5m04l6v277t6exhrurylqsmtvg2l30pt99 oder über Lightning an die Adresse Lightning bounty@blink.sv zurückgegeben werden.

2.Ein Kanal zur Meldung von Sicherheitslücken mit Belohnungen. Schreiben Sie an bounty@blinkbtc.com. Meldungen werden innerhalb von 72 Stunden bestätigt und von unserem Sicherheitsteam bearbeitet, bis sie geklärt sind. In gutem Glauben durchgeführte Untersuchungen zur Software von Blink sind willkommen, und wir werden niemanden verfolgen, der eine Schwachstelle verantwortungsbewusst meldet. Für kritische Befunde zahlen wir nach eigenem Ermessen Belohnungen von bis zu 0,1 BTC. Die vollständigen Richtlinien finden Sie unter blink.sv/bounty-terms. Dieser Kanal wurde aufgrund dieses Vorfalls eingerichtet: Jede Meldung muss irgendwo eingehen, bestätigt werden und so lange in Bearbeitung bleiben, bis sie geklärt ist.

‍

Warum ist das Kopfgeld so hoch?

Die 50 % werden in zwei Teile aufgeteilt: 25 % gehen an denjenigen, dessen Hinweise zur Wiederbeschaffung führen, und weitere 25 % der wiederbeschafften Summe gehen an Bitcoin Beach, Bitcoin Ekasi, Afribit Kibera und die von ihnen ausgewählten Kreislaufwirtschaftsprojekte. Wir gehen davon aus, dass die Gelder höchstwahrscheinlich für immer verloren sind. Gestohlene Bitcoins lassen sich nur sehr schwer wiederbeschaffen, daher ist für uns jeder wiederbeschaffte Betrag ein großer Erfolg – und je mehr Menschen wir dazu bewegen können, uns bei der Suche nach dem Angreifer zu helfen, desto besser. Solche Leute sollten nicht ungestraft davonkommen, und wir wollen es ihnen so schwer und unangenehm wie möglich machen, das Geld auszugeben.

Wir haben die zweiten 25 % hinzugefügt, weil wir den Angreifer daran erinnern möchten, dass er Geld gestohlen hat, das wir und unsere mit unserer Mission verbündeten Aktionäre viel lieber dafür ausgegeben hätten, die Bitcoin-Akzeptanz an der Basis zu fördern und Bitcoin-Entwickler in Gemeinden weltweit zu unterstützen, denen der Zugang zu Bankdienstleistungen verwehrt ist. Schande über den Angreifer.

‍

Wo das Geld steckt

Wir haben die Geldflüsse seit dem 19. September kontinuierlich verfolgt. Stand 1. Oktober: Etwa 0,87 BTC befanden sich noch unberührt auf den Empfängeradressen. Der Rest floss in andere Wallets der Betroffenen, die ebenfalls Bitcoin enthalten, die nicht von Blink stammen. Von diesen Wallets wurden etwa 5,05 BTC über einen kettenübergreifenden Swap-Dienst (NEAR Intents) transferiert, 1 BTC am 21. September und etwa 4,05 BTC am 28.–29. September; nachdem unser eigener Antrag auf Sicherstellung vom 22. September unbeantwortet blieb, haben wir die Behörden gebeten, die Aufzeichnungen dieses Dienstes einzuholen; etwa 0,012 BTC flossen in eine Binance-Einzahlung, und das Sicherheitsteam von Binance ist bereits eingeschaltet und führt eine Sperrliste ein. Da die eigenen Bitcoins des Angreifers daruntergemischt sind, ergeben diese Zahlen zusammen nicht die 6,61 BTC. Die On-Chain-Adressen finden Sie im Anhang.

‍

Wenn Sie unseren Code ausführen

Unsere Codebasis ist Open Source, und Dienste, die nicht von uns entwickelt wurden, nutzen darauf basierende Implementierungen. Das anfällige Muster – ein Einwilligungsablauf, der der Berechtigungsliste des Browsers vertraut, und ein Edge-Gatekeeper, der jedes aktive Token ohne Zielgruppenprüfung akzeptiert – stammt aus der Zeit vor den aktuellen Repositorys unter Blink und ist im archivierten öffentlichen Verlauf zu finden. Wir haben die Betreiber der uns bekannten abgeleiteten Implementierungen vertraulich informiert; einer hat noch am selben Tag einen Patch installiert. Unser Sicherheitshinweis für die Codebasis wird auf GitHub unter github.com/blinkbitcoin/blink/security/advisories veröffentlicht, wobei eine CVE-Kennung beantragt wurde. Wenn Sie eine auf der Codebasis von Blink basierende Anwendung betreiben und noch nichts von uns gehört haben, schreiben Sie bitte an bounty@blinkbtc.com; sobald wir bestätigt haben, dass Sie eine solche Bereitstellung betreiben, teilen wir Ihnen das vollständige Prüfverfahren mit und helfen Ihnen bei der Überprüfung. Die Korrekturen sind die drei oben verlinkten PRs. Angreifer scannen öffentlichen Code mittlerweile mit Maschinen-Geschwindigkeit. Wenn Sie diesen Code ausführen, überprüfen Sie ihn noch heute.

‍

Abschließendes Wort

Blink Es begann als alltägliche Bitcoin-Wallet für eine kleine Küstenstadt, in der die Menschen Geld brauchten, das funktionierte. Am 19. September war dies für 22 unserer Kunden nicht der Fall. Jeder einzelne von ihnen hatte uns sein Geld anvertraut – und genau dafür ist ein Verwahrer da.

An unsere Kunden für ihre Geduld; an die Forscher und Börsen, die innerhalb weniger Stunden geholfen haben; an die Aktionäre, die ohne zu zögern hinter dem Unternehmen standen; und an das Team, das an einem Samstag alles stehen und liegen ließ und die ganze Nacht durcharbeitete – vielen Dank. Wir werden das Vertrauen wieder zurückgewinnen, so wie wir es uns in El Zonte erarbeitet haben: indem wir vor Ort sind und dafür sorgen, dass Zahlungen jeden Tag reibungslos abgewickelt werden.

‍

Häufig gestellte Fragen

War mein Geld in Gefahr? Wenn Ihr Konto noch offen ist und wir Ihnen noch nicht geschrieben haben, liegen uns keine Hinweise darauf vor, dass der Angreifer Ihre Kontodaten eingesehen hat, und es wurde nichts von Ihrem Konto entwendet. Bis zur Schließung des Kontos am 19. September hätte die Sicherheitslücke bei jedem Verwahrungskonto ausgenutzt werden können, allerdings hätte es bei einem Konto mit 2FA niemandem möglich gewesen, Geld zu überweisen. Der Großteil der Kundengelder befindet sich in einem „Cold Storage“, auf den die Verwaltungstools keinen Zugriff haben. Wenn Sie ein nicht-verwahrtes Konto haben, befanden sich Ihre Schlüssel zu keinem Zeitpunkt auf unseren Servern, und es gab für den Angreifer nichts zu entwenden.

Hat der Angreifer meine Daten abgegriffen? Es wurden Daten von 3.817 Konten eingesehen. Wir haben jeden Kontoinhaber, den wir erreichen konnten, schriftlich darüber informiert, welche Daten eingesehen wurden. Wenn Ihr Konto noch aktiv ist und Sie keine solche Nachricht erhalten haben, gehörte es nicht zu den betroffenen Konten. Sie können jederzeit bei uns nachfragen, ob und welche Daten zu Ihrem Konto eingesehen wurden: support@blink.sv.

Warum hat Ihre Überwachung den Angriff nicht erkannt? Unsere Warnmeldungen waren darauf ausgelegt, Ausfälle zu erkennen. Es gab keine Regel für den Fall, dass ein Administrator Dinge tut, die kein Administrator tun sollte, und der Angreifer nutzte unsere eigenen Tools mit Tokens, die unser eigenes System ausgestellt hatte.

Warum befand sich so viel in der Hot Wallet? Wir hatten unseren Betriebsbestand als Puffer für die Umstellung auf nicht-verwahrende Konten in etwa verdoppelt und ihn nach dem Ende der ersten Welle nicht wieder reduziert. Der Betrag beträgt nun nur noch einen Bruchteil dieses Niveaus, und wir veröffentlichen die Zahl nicht.

Hätte mich die Zwei-Faktor-Authentifizierung (2FA) retten können? In diesem Fall ja. Alle Konten, bei denen sie aktiviert war, blieben unversehrt; alle Konten, bei denen Geld verloren ging, hatten sie nicht aktiviert. Sie kann zwar nicht jeden Angriff abwehren, aber diesen hier hat sie verhindert. Aktivieren Sie sie.

Sollte ich zu einem Konto ohne Verwahrung wechseln? Wenn Sie Ihre Schlüssel lieber selbst verwahren möchten, ja – dafür sind sie ja da, und niemand bei Blink noch jemand, der sich Zugang zu Blink verschafft, kann Gelder bewegen, die Sie selbst verwahren. Es ist nicht zwingend erforderlich, noch sind nicht alle Funktionen verfügbar, und die Verfügbarkeit hängt von Ihrer Region ab. Wenn Sie bei der Verwahrung bleiben, aktivieren Sie die 2FA.

Wer hat das bezahlt? Die Aktionäre von „ Blink “ – in Form eines zinslosen Darlehens, das innerhalb von 24 Stunden zugesagt und am 23. September ausgezahlt wurde. Nicht die Kunden und auch nicht die Kundenrücklagen. „ Blink “ arbeitet weiterhin mit Vollreserve: Jedes Guthaben ist eins zu eins gedeckt.

Ich habe ein Sicherheitsproblem unter Blink entdeckt. Was soll ich tun? Schreiben Sie an bounty@blinkbtc.com. Sie erhalten innerhalb von 72 Stunden eine Antwort, Ihr Bericht wird bis zur Behebung von einem Verantwortlichen betreut, und für kritische Befunde gibt es eine Belohnung.

‍

Aktualisierungen

Aktuelle Informationen zum Stand der Wiederherstellung, zur Belohnung sowie etwaige Korrekturen zu diesem Beitrag werden hier hinzugefügt.

‍

Anhang: On-Chain-Adressen

Die folgenden Adressen haben die On-Chain-Auszahlungen erhalten. Börsen und Forscher werden gebeten, Einzahlungen, die von diesen Adressen stammen, zu überprüfen und sich an bounty@blinkbtc.com zu wenden. (Die Erlöse ausLightning-rail flossen in vom Angreifer kontrollierte Lightning -Wallets und werden separat zurückverfolgt.)

Gesamtbetrag auf der Blockchain: 4,62685758 BTC gingen bei diesen Adressen in 14 Auszahlungen ein, davon sieben an die erste Adresse. Da unser Auszahlungssystem Auszahlungen bündelt, wurden die 14 Auszahlungen in 12 Transaktionen auf der Blockchain abgewickelt. Die verbleibenden 1,98399667 BTC der insgesamt 6,61085425 BTC befinden sich noch auf Lightning.

Fanden Sie dies nützlich? Geben Sie dem Autor einen Tipp!

Fanden Sie dies nützlich? Geben Sie dem Autor einen Tipp!

Social-Share-Komponente

Blink herunterladen

Empfangen und senden Sie jetzt Bitcoin

Community