TempleDAO StaxLPStaking Access-Lücke

Am 11. Oktober 2022 verlor TempleDAO rund 2,3 Millionen Dollar (1.831 ETH), als ein Angreifer eine fehlende Access-Control-Prüfung in der migrateStake()-Funktion des StaxLPStaking-Vertrags ausnutzte. Die Funktion sollte die eigene gestakte Position eines Nutzers in einen neuen Vertrag migrieren — aber sie verifizierte nicht, dass der Aufrufer die migrierte Position besaß.

Was geschah

TempleDAOs StaxLPStaking-Vertrag ließ Nutzer LP-Token staken. Er beinhaltete eine migrateStake(address oldStaking, uint256 amount)-Funktion, die für Nutzer gedacht war, um ihren eigenen Stake in einen aktualisierten Staking-Vertrag zu verschieben.

Der fatale Fehler: migrateStake() vertraute den vom Aufrufer gelieferten Parametern, ohne zu überprüfen, ob der Aufrufer tatsächlich den migrierten Stake besaß. Sie rief das migrateWithdraw des alten Staking-Vertrags für eine beliebige Adresse auf und schrieb das Ergebnis gut — was bedeutete, dass jeder Aufrufer die gesamte Position eines anderen Stakers zu einem von ihm kontrollierten Ziel migrieren (und damit abheben) konnte.

Der Angriff war entsprechend trivial:

1. Der Angreifer rief migrateStake() auf und gab ein von ihm kontrolliertes Ziel und den TempleDAO-Staking-Vertrag an, der alle Nutzer-Stakes hielt.
2. Die Funktion migrierte und gab die gestakten LP-Token frei an den Angreifer, da die Eigentumsprüfung fehlte.
3. Der Angreifer entpackte die LP-Position und verschwand mit ~1.831 ETH (~2,3 Mio. $).

Der gesamte Exploit war eine einzelne Transaktion, die ein einziges fehlendes require ausnutzte.

Nachwirkungen

• TempleDAO pausierte betroffene Verträge und kontaktierte den Angreifer über On-Chain-Nachrichten.
• Das Team veröffentlichte eine Post-Mortem, die die fehlende Aufrufer-Eigentums-Validierung als alleinige Wurzelursache identifizierte.
• Die gestohlenen Mittel wurden über Tornado Cash gewaschen; die Wiederherstellung war minimal.

Warum es zählt

TempleDAO ist eines der reinsten Beispiele im Katalog für die Bug-Klasse „fehlende Access-Control-Prüfung" — unterschieden von Orakel-Manipulation, Reentrancy oder ökonomischen Exploits. Es gab keinen cleveren Flash Loan, keine Preismanipulation, keinen neuen Mechanismus. Es gab eine Funktion, die hätte prüfen sollen, dass msg.sender die Position besaß, und es nicht tat.

Die strukturelle Lehre ist fast peinlich einfach, aber wiederholt sich ständig:

Jede Funktion, die Nutzer-Vermögenswerte bewegt, muss verifizieren, dass der Aufrufer autorisiert ist, jene spezifischen Vermögenswerte zu bewegen. Nicht „ist der Aufrufer ein gültiger Nutzer" — „besitzt der Aufrufer die genaue Position, die dieser Aufruf betrifft."

Das Muster wiederholt sich im Katalog: TempleDAO (migrateStake), Exactly Protocol (unvalidierter Markt), Hedgey Finance (ungeprüftes claimLockup), Seneca (Chamber-Drain). Jeder ist eine Funktion, die eine privilegierte oder mittel-bewegende Operation basierend auf vom Aufrufer gelieferten Parametern ausführt, ohne die Beziehung des Aufrufers zu den betroffenen Vermögenswerten zu validieren.

Diese Bugs werden trivial durch selbst oberflächliche Audits oder durch grundlegende Access-Control-Unit-Tests gefangen („kann Adresse B den Stake von Adresse A migrieren?"). Die Häufigkeit, mit der sie trotzdem ausgeliefert werden — besonders in Migrations- und Peripheriefunktionen, die schnell und spät geschrieben werden — ist eines der wiederkehrenden leisen Themen des Katalogs.