Zurück zum Blog

Der CashioApp-Sicherheitsvorfall erneut betrachtet

Code Auditing
16. Mai 2022
5 Min. Lesezeit

Ab 23.03.2022 16:20:08 UTC+8 wurde CashioApp ausgenutzt, um das Konto mit den als Sicherheit hinterlegten Token zu leeren. Der Verlust belief sich auf etwa 52 Millionen. Möglich wurde der Angriff durch eine unzureichende Prüfung der Eingabekonten, die es dem Angreifer erlaubte, 20 Milliarden $CASH-Token ohne jegliche Einzahlung zu prägen. Im Folgenden erläutern wir die technischen Details.

Zusammenfassung

Der Vorfall war auf einen Fehler im Brrr-Programm zurückzuführen, das für das Prägen und Verbrennen von $CASH-Token gegen Saber LP Arrows als Sicherheit ausgelegt ist. Konkret können Nutzer durch die Einzahlung von Arrow-LP-Token $CASH ausgeben, also $CASH prägen. Zu beachten ist, dass den Arrow-LP-Token Saber-LP-Token zugrunde liegen. Die Anweisung print_cash, mit der $CASH geprägt werden können, erhält eine Liste von Konten, darunter das Bank-Konto und das Collateral-Konto. Sie dienen dazu, die als Sicherheit hinterlegten Token (d. h. Arrow-LP-Token), die zum Prägen von $CASH verwendet werden dürfen, zu erfassen und nachzuverfolgen. Vorgesehen ist, dass diese beiden Konten nur vom Administrator initialisiert und autorisiert werden. Das Programm prüft jedoch die Gültigkeit des Bank-Kontos nicht. Dadurch kann der Angreifer eine Reihe gefälschter Konten (einschließlich des Bank-Kontos) erstellen, sie der Anweisung print_cash übergeben und $CASH nahezu kostenlos ausgeben (es fallen lediglich Transaktionsgebühren an).

Details

Beginnen wir die Analyse mit den Konten, die von der nachstehenden Anweisung print_cash verwendet werden.

Das Attribut common (Zeile 75) ist eine Struktur des Typs BrrrCommon im Programm. In BrrrCommon werden das bank-Konto und das collateral-Konto vom Administrator initialisiert und autorisiert. crate_token ist das Konto des $CASH-Tokens. Es speichert Informationen über $CASH, etwa den öffentlichen Schlüssel von crate_mint (Zeile 107), die öffentlichen Schlüssel der Administratorrollen und weitere Angaben. crate_collateral_tokens ist ein Tresorkonto, das die von Nutzern übertragenen, als Sicherheit hinterlegten Token hält. Da es sich bei den als Sicherheit hinterlegten Token um Arrow-LP-Token handeln soll, denen die LP-Token von Saber zugrunde liegen, müssen Nutzer die zugehörigen Konten von saber_swap angeben. Die letzten beiden Attribute der Struktur BrrrCommon sind Programm-IDs der in der Anweisung verwendeten Zielprogramme. Zu beachten ist, dass die letzten vier Attribute der Struktur PrintCash das Systemkonto des Nutzers (das zugleich die Transaktion signiert), das Sicherheitenkonto des Nutzers, das $CASH-Token-Konto des Nutzers, das die geprägten $CASH empfängt, sowie der öffentliche Schlüssel des Kontos sind, das zum Prägen der $CASH berechtigt ist.

Die Angriffstransaktion

Nachdem wir die Funktion der genannten Konten erläutert haben, analysieren wir nun die Angriffstransaktion: 0x4fgL…z2K5. Dieser Angriff wird von der Angreiferadresse (unter 0x6D7f) aus initiiert. Die Liste der Eingabekonten für die Anweisung PrintCash ist nachstehend dargestellt.

Das oben gezeigte Account #1 (0x5aha) entspricht dem Bank-Konto. Wir stellten fest, dass es sich von der Adresse auf der offiziellen Website von CashioApp (0xEm1P) unterscheidet. Das bedeutet, dass die Validierung des Bank-Kontos unzureichend ist!

Validierung

Sehen wir uns die Validierung der Struktur BrrrCommon im Code genauer an, um zu verstehen, wie die Prüfung umgangen wird.

Die einzige Prüfung des als Eingabe übergebenen Bank-Kontos stellt sicher, dass das übergebene Collateral-Konto mit dem Bank-Konto verknüpft ist (Zeile 12). Sie lässt sich jedoch leicht umgehen, indem auch ein gefälschtes Collateral-Konto angegeben wird. Um keine echten Vermögenswerte als Sicherheit hinterlegen zu müssen, gab der Angreifer außerdem gefälschte saber_swap-Konten an. Der Angreifer will wertlose Vermögenswerte als Sicherheit einzahlen, um wertvolle $CASH-Token auszugeben. Daher müssen die vom Angreifer angegebenen Adressen für crate_token und crate_mint echt sein. Anders ausgedrückt: Die unzureichende Prüfung des Bank-Kontos ermöglicht es dem Angreifer, eine Reihe gefälschter Konten zu erstellen und damit $CASH gegen wertlose Sicherheiten auszugeben.

Die Behebung

Zur Behebung wird die Anweisung assert_keys_eq!(self.bank.crate_mint, self.crate_mint) hinzugefügt. Diese Anweisung stellt sicher, dass das Feld crate_mint des Bank-Kontos den korrekten Wert crate_mint für $CASH enthält. Doch wie stellt das sicher, dass das Bank-Konto gültig ist? Sehen wir uns die Struktur NewBank (im Programm bankman) und die Struktur NewCrate (im Programm crate_token) an, um die Antwort zu finden.

Das Bank-Konto ist tatsächlich eine PDA, deren Seeds die Adresse von crate_token enthalten. Zugleich ist crate_token ebenfalls eine PDA, deren Seeds die Adresse von crate_mint enthalten. Dadurch wird sichergestellt, dass das Bank-Konto gültig ist, wenn das als Eingabe übergebene crate_mint gültig ist. Ohne ein korrektes crate_mint können Angreifer $CASH nicht prägen und die Angriffe nicht durchführen.

Über BlockSec

BlockSec ist ein wegweisendes Unternehmen für Blockchain-Sicherheit, das im Jahr 2021 von einer Gruppe weltweit anerkannter Sicherheitsexperten gegründet wurde. Das Unternehmen setzt sich dafür ein, die Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt zu verbessern und so ihre breite Akzeptanz zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Chains, die Plattform Phalcon Security für Sicherheitsentwicklung und die proaktive Abwehr von Bedrohungen, die Plattform MetaSleuth zur Nachverfolgung und Untersuchung von Mittelflüssen sowie die Erweiterung MetaSuites an, mit der Web3-Entwickler sich effizient in der Kryptowelt bewegen können.

Bislang hat das Unternehmen mehr als 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden mehrere zehn Millionen US-Dollar von namhaften Investoren erhalten, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital.

Offizielle Website: https://blocksec.com/

Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

Für die neuesten Informationen anmelden
Über die sichere Speicherung hinaus, Teil 2: Wallet-Kryptografie sicher implementieren
Security Insights

Über die sichere Speicherung hinaus, Teil 2: Wallet-Kryptografie sicher implementieren

Kann ein Angreifer einen privaten Schlüssel rekonstruieren, ohne dessen geschützte Kopie auszulesen? Teil 2 von Beyond Secure Storage untersucht sechs Vorfälle, bei denen schwache Zufallszahlen, Entropieverlust oder Fehler bei Signatur-Nonces Schlüssel vorhersagbar oder rekonstruierbar machten. Daraus leitet er Anforderungen an die Implementierung der Schlüsselerzeugung und des Signierens ab und erläutert anschließend, wie Zahlungsinstitute deren Einhaltung durch Code-Reviews und Tests des produktiv eingesetzten Systems überprüfen können.

Über sichere Speicherung hinaus, Teil 1: Sichere Zahlungs- und Signaturabläufe gestalten
Security Insights

Über sichere Speicherung hinaus, Teil 1: Sichere Zahlungs- und Signaturabläufe gestalten

Wie kann ein nicht autorisierter Vorgang eine gültige Signatur erhalten, ohne dass der Angreifer den privaten Schlüssel stiehlt? Teil 1 von Beyond Secure Storage untersucht anhand von Vorfällen bei Bitget, Bybit und Binance Autorisierungsfehler bei Zahlungsanforderungen, der Erstellung, Signierung und Ausführung von Transaktionen sowie bei deren Abwicklung. Daraus leitet er Gestaltungsprinzipien ab, um nicht autorisierte Vorgänge zu verhindern und Verluste zu begrenzen. Anschließend erläutert er, wie Überprüfungen, Audits, Penetrationstests und Übungen diese Schutzmaßnahmen verifizieren können.

NEAR-Intents-Exploit: Fehler bei der Rückerstattung und Lehren für die Sicherheit
Security Insights

NEAR-Intents-Exploit: Fehler bei der Rückerstattung und Lehren für die Sicherheit

Beim Exploit von NEAR Intents wurden überdimensionierte Rückerstattungsereignisse genutzt, um interne Guthaben zu erhalten, nachdem die eingezahlten Vermögenswerte zurückgegeben worden waren. Diese Analyse rekonstruiert den Ablauf der Receipts und sieben Auszahlungen auf der BNB Chain in Höhe von insgesamt 3.865.021 USDT. Sie unterscheidet diese Mittelabflüsse von der vom Projekt gemeldeten vollständigen Rückgewinnung der Mittel und erläutert Sicherheitsaspekte bei der Entwicklung und Prüfung von NEAR-Smart-Contracts.

Der beste Sicherheitsauditor für Web3

Lassen Sie Design, Code und Geschäftslogik vor dem Launch prüfen. Nach den höchsten Sicherheitsstandards der Branche.

BlockSec-Audit
Der CashioApp-Sicherheitsvorfall erneut betrachtet