SafeMoon Public-Burn-Drain

Am 28. März 2023 verlor der von Jake Paul beworbene Memecoin SafeMoon etwa 8,9 Millionen $ aus seinem WBNB-Liquiditätspool, als ein Angreifer eine öffentliche burn()-Funktion ausnutzte, die versehentlich in einem kürzlichen Vertrags-Upgrade exponiert worden war. Die Funktion erlaubte es jedem Nutzer, Tokens von jeder anderen Adresse zu verbrennen — einschließlich des SafeMoon-WBNB-Liquiditätspools selbst. Nach Verhandlungen gab der Angreifer 7 Mio. $ (80 %) zurück.

Was geschah

Ein SafeMoon-Vertrags-Upgrade führte eine burn()-Funktion mit öffentlichen Zugriffsberechtigungen ein — fast sicher eine unbeabsichtigte Folge eines Refactors, der die Funktion als interne Admin-Operation belassen sollte. Die Funktion ließ jeden Aufrufer eine beliebige Adresse angeben und SFM-Tokens vom Saldo dieser Adresse verbrennen, ohne Autorisierungsprüfung.

PeckShields Analyse stellte das Upgrade-Muster fest und charakterisierte den Bug als wahrscheinlich mit einem Admin-Schlüssel-Leak verbunden — jemand mit der Upgrade-Autorität scheint die Public-Burn-Version des Vertrags ausgeliefert zu haben, entweder durch Kompromiss oder durch einen Entwicklerfehler, der nicht in der Überprüfung gefangen wurde.

Der Angriff:

1. Identifizierte die öffentliche burn()-Funktion im neuen Vertrag.
2. Verbrannte eine Mehrheit der SFM-Tokens, die der WBNB/SFM-Liquiditätspool hielt — was das SFM-Angebot im Pool drastisch reduzierte, während das WBNB unverändert blieb.
3. Der automatische Preisermittlungsmechanismus des Pools interpretierte die Angebotsreduzierung als enormen Preisanstieg in SFM — weil dasselbe WBNB nun gegen ein winziges SFM-Angebot bepreist werden musste.
4. Verkaufte eine kleine Menge SFM in den Pool zum künstlich aufgeblähten Preis und zog die Mehrheit der WBNB des Pools im Austausch ab.
5. Ging mit etwa 8,9 Mio. $ in WBNB davon.

Folgen

• Das SafeMoon-Team alarmierte die Community innerhalb von Stunden und engagierte den Angreifer über On-Chain-Nachrichten.
• Der Angreifer gab 7 Mio. $ zurück (80 % der gestohlenen Mittel) nach Verhandlung und behielt 2 Mio. $ als effektive "Belohnung".
• SafeMoon pausierte betroffene Verträge und lieferte einen neu gestalteten Token mit ordnungsgemäßen Zugriffskontrollen aus.
• Die Episode trug zur breiteren Auflösung des SafeMoon-Projekts bei, das bereits SEC-Durchsetzungsmaßnahmen wegen Betrugsvorwürfen gegen seine Gründer gegenübergestanden hatte.

Warum es wichtig ist

SafeMoon ist ein eindrucksvoller Fall dafür, wie eine einzige versehentlich öffentliche Funktion das gesamte wirtschaftliche Modell eines Vertrags kompromittieren kann. Die fragliche burn()-Funktion war in ihrer beabsichtigten Form eine routinemäßige administrative Operation. Sie ohne Zugriffskontrolle zu exponieren, verwandelte sie in einen universellen Pool-Drainer für jeden Liquiditätspool, der SFM hält.

Die strukturellen Lehren:

1. Access-Modifier auf jeder externen Funktion müssen Zeile für Zeile überprüft werden, besonders während Upgrades. Der Standard für jede privilegierte Operation sollte onlyOwner oder Äquivalent sein; die Beweislast liegt beim Entwickler, jede Funktion, die public oder external ohne Einschränkungen ist, zu rechtfertigen.
2. Funktions-Berechtigungen sollten explizit getestet werden — jedes Audit sollte einen "jeder kann das aufrufen"-Test für jeden privilegierten Pfad enthalten, nicht nur funktionale Tests des beabsichtigten Nutzer-Flows.
3. Kürzliche Upgrades sind hochriskant für die ersten 48-72 Stunden nach Deployment. Viele Protokolle planen jetzt unabhängige Post-Upgrade-Audits oder Community-Bug-Bounties mit erhöhten Auszahlungen während des unmittelbaren Post-Upgrade-Fensters.

SafeMoons breitere Auflösung — die Kombination des Hacks mit SEC-Durchsetzung und der zugrundeliegenden Tokenomics, die weit als räuberisch angesehen wurde — ist auch ein wiederkehrendes Memecoin-Muster: Technische Sicherheitsversäumnisse, regulatorischer Druck und Design-Skepsis konvergieren oft auf denselben Projekten innerhalb von Monaten voneinander.