#10: ThirdWeb-Vorfall: Inkompatibilität vertrauenswürdiger Module offenbart Schwachstelle

Am 5. Dezember 2023 gab die prominente Web3-Entwicklungsplattform Thirdweb signifikante Sicherheitslücken in ihren vorkompilierten Smart Contracts bekannt. Dieser kritische Fehler betraf alle ERC-20-, ERC-721- und ERC-1155-Token, die über diese spezifischen anfälligen Verträge bereitgestellt wurden. In den Tagen nach der Bekanntgabe wurden Token, die mit diesen anfälligen Verträgen bereitgestellt wurden, nach und nach in einer Reihe von Angriffen ausgenutzt, was die Schwere der zugrunde liegenden Inkompatibilität unterstreicht.

Verständnis der ThirdWeb Smart Contract Schwachstelle

Die Ursache des ThirdWeb-Vorfalls liegt in der unerwarteten Interaktion zwischen zwei grundlegenden Komponenten der Smart Contract-Entwicklung: ERC-2771 und der Multicall-Implementierung von OpenZeppelin. Um die Schwachstelle vollständig zu verstehen, ist es unerlässlich, jede Komponente einzeln zu betrachten und dann zu analysieren, wie ihre Interaktion einen ausnutzbaren Pfad geschaffen hat.

ERC-2771: Meta-Transaktionen und vertrauenswürdige Forwarder

EIP-2771 definiert ein Protokoll auf Contract-Ebene, das es Recipient-Verträgen ermöglicht, Meta-Transaktionen über vertrauenswürdige Forwarder-Verträge zu akzeptieren. Dieser Standard ist entscheidend für die Verbesserung der Benutzererfahrung, indem er es Dritten (Forwardern) ermöglicht, Gasgebühren im Namen von Benutzern zu zahlen und so die Notwendigkeit für Benutzer, native Blockchain-Token zu halten, zu abstrahieren.

In der Praxis ist OpenZeppelins ERC2771Context eine weit verbreitete Implementierung. Ihre Kernfunktionalität besteht darin, die letzten 20 Bytes des Calldata von einem vertrauenswürdigen Forwarder als effektiven _msgSender() zu behandeln. Für Entwickler, die diese Bibliothek verwenden, ist es üblich, alle direkten Verwendungen von msg.sender durch _msgSender() zu ersetzen, um die Kompatibilität mit Meta-Transaktionen zu gewährleisten. Ebenso wird _msgData() verwendet, um die ursprünglichen Transaktionsdaten abzurufen, ohne die angehängten Senderinformationen.

function _msgSender() internal view virtual override returns (address) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return address(bytes20(msg.data[calldataLength - contextSuffixLength:]));
    } else {
        return super._msgSender();
    }
}

function _msgData() internal view virtual override returns (bytes calldata) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return msg.data[:calldataLength - contextSuffixLength];
    } else {
        return super._msgData();
    }
}

Multicall: Bündeln von Transaktionen zur Effizienz

Die Multicall-Funktionalität ermöglicht es Benutzern, mehrere Funktionsaufrufe zu einer einzigen Transaktion zu bündeln, was die Gaskosten erheblich reduziert und die Transaktionseffizienz verbessert. OpenZeppelins MulticallUpgradeable ist eine beliebte Implementierung für diesen Zweck. Sie nimmt ein Array von Calldata-Bytes entgegen und führt für jeden Eintrag einen delegatecall aus, der diese im Kontext des aufrufenden Vertrags ausführt.

function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
    results = new bytes[](data.length);
    for (uint256 i = 0; i < data.length; i++) {
        results[i] = _functionDelegateCall(address(this), data[i]);
    }
    return results;
}

(Hinweis: Der hier diskutierte Fehler wurde in späteren Versionen von OpenZeppelins Multicall inzwischen behoben.)

Die Inkompatibilität: ERC-2771 und Multicall Konflikt

Der Kern der Smart Contract-Schwachstelle im ThirdWeb-Vorfall ergab sich aus einer kritischen Inkonsistenz in der Art und Weise, wie Calldata von ERC-2771 und Multicall verarbeitet wird. ERC-2771 erwartet, dass der vertrauenswürdige Forwarder die Nachrichtendaten und Senderinformationen zusammenpackt. Der Empfängervertrag verwendet dann _msgData() und _msgSender(), um diese Informationen korrekt zu entpacken.

Die Multicall-Funktion war jedoch in ihrer anfälligen Implementierung nicht darauf ausgelegt, mit der Art und Weise kompatibel zu sein, wie ERC-2771 Daten für Meta-Transaktionen packt. Insbesondere, wenn Multicall eine Charge von Aufrufen verarbeitet, hätte sie _msgSender() korrekt aus der anfänglichen Meta-Transaktion extrahieren und dann diese Senderinformationen an das Calldata jedes einzelnen Aufrufs anhängen müssen, bevor sie ausgeführt wurden. Dieser entscheidende Schritt fehlte.

Ohne dass die Senderinformationen korrekt an das Calldata innerhalb jedes von Multicall verarbeiteten Unteraufrufs angehängt wurden, versuchte der ERC-2771-Kontext innerhalb des Zielvertrags, Senderinformationen aus den letzten 20 Bytes von _msgData() des Unteraufrufs zu entpacken. Entscheidend ist, dass ein Angreifer diese letzten 20 Bytes kontrollieren konnte. Dies ermöglichte es einem böswilligen Akteur, spezifisches Calldata zu erstellen, das, wenn es von Multicall verarbeitet und dann von einem ERC-2771-aktivierten Vertrag interpretiert wurde, beliebige Logik mit einem manipulierten _msgSender()-Wert (z.B. eine vom Angreifer kontrollierte Adresse oder sogar die Pooladresse eines Protokolls) ausführen würde. Dies umging effektiv die beabsichtigten Sicherheitsprüfungen und verletzte die Erwartungen, die von beiden Spezifikationen aufgestellt wurden, was zu unbefugten Aktionen führte.

ThirdWeb Vorfall: Angriffsanalyse und Ausnutzung

Betrachten wir ein reales Beispiel der Smart Contract-Schwachstelle im ThirdWeb-Vorfall, anhand einer Angriffstransaktion, die von der Phalcon-Plattform von BlockSec analysiert wurde.

Die Strategie des Angreifers beinhaltete die Manipulation von _msgSender(), um sich als Uniswap-Pool auszugeben und dadurch dessen Token-Guthaben abzuziehen.

• Schritt 1: Anfängliche Token-Beschaffung. Der Angreifer tauschte zunächst 5 WETH gegen 3.455.399.346 TIME-Token an einer dezentralen Börse. Dies lieferte die notwendigen Token für die nachfolgende Manipulation.

• Schritt 2: Bösartige Multicall-Ausführung. Dies ist der Kern des Exploits. Der Angreifer rief einen vertrauenswürdigen Forwarder mit sorgfältig erstelltem Calldata auf, das darauf ausgelegt war, die Inkompatibilität von ERC-2771/Multicall auszunutzen. Als dieses Calldata von der Multicall-Funktion analysiert wurde, führte dies zum Aufruf der burn-Funktion des TIME-Token-Vertrags. Entscheidend war, dass aufgrund der Schwachstelle _msgSender() fälschlicherweise als Uniswap Pool-Adresse interpretiert wurde. Dies ermöglichte es dem Angreifer, einen erheblichen Teil der von Uniswap gehaltenen TIME-Token zu verbrennen, ohne tatsächliche Berechtigung. Die BlockSec Phalcon-Plattform bietet detaillierte Transaktionsverfolgung zur Visualisierung dieses Ablaufs.

  

  Das obige Bild illustriert, wie der Forwarder.execute-Aufruf des Angreifers verarbeitet wird. Die multicall-Funktion empfängt ein Byte-Array, das dann zum Aufruf der burn-Funktion mit dem manipulierten _msgSender() führt.

  

  Diese detaillierte Ansicht von Phalcon zeigt die bytes[] der Länge 1, die als Daten zum Aufrufen des Vertrags verwendet werden, was zur Ausführung der burn-Funktion unter der gefälschten _msgSender() führt.

• Schritt 3: Preismanipulation. Durch die Verbrennung einer großen Menge TIME-Token aus dem Uniswap-Pool reduzierte der Angreifer drastisch die Liquidität des Pools für TIME. Diese künstliche Verknappung führte zu einem skyrocketartigen Anstieg des TIME-Preises im Verhältnis zu WETH innerhalb des Pools.

• Schritt 4: Profitabler Arbitrage. Mit dem künstlich aufgeblähten TIME-Preis tauschte der Angreifer dann seine verbleibenden 3.455.399.346 TIME-Token zurück gegen 94 WETH und realisierte so einen erheblichen Gewinn aus dem manipulierten Preis.

Diese Abfolge von Ereignissen demonstriert einen raffinierten Angriff, der eine subtile Smart Contract-Schwachstelle ausnutzt, die aus der Modulin-Inkompatibilität resultiert.