Einführung
Ein $6 Millionen Exploit in einem nicht identifizierten Base Vault hat laut dem Sicherheitschef von Immunefi eine erhebliche Lücke in der Schwachstellenberichterstattung aufgedeckt. Zum Zeitpunkt des Vorfalls befanden sich noch etwa $31,7 Millionen im Vault.
Details des Vorfalls
Gonçalo Magalhães, Sicherheitschef bei Immunefi, erklärte gegenüber crypto.news, dass die nicht identifizierten Betreiber des Vaults einem Whitehat-Forscher nur wenige Optionen ließen, um die Schwäche der Whitelist zu beheben, ohne rechtliche Probleme zu riskieren. In dem begleitenden Vorfallbericht wurde die Schwäche bereits in der Vorwoche identifiziert, jedoch hatte der Forscher keinen klaren Offenlegungskanal.
„Da jede genehmigte Adresse das aBaswstETH des Vaults ohne benötigte Sicherheiten entnehmen konnte, stellt dies tatsächlich eine große Schwachstelle dar“, erklärte er.
Mehr als 24 Stunden nach dem Angriff berichtete der Bericht, dass kein Team den Vault öffentlich beansprucht, den Verlust anerkannt oder eine Behebung angekündigt hatte. TokenPost berichtete, dass der Angreifer eine Safe-Multisignatur-Wallet verwendet hatte, um einen bösartigen Vertrag zur Lending-Whitelist des Vaults hinzuzufügen. Laut dem Bericht zog der Vertrag dann 1.783 aBaswstETH ab und tauschte die Token über Aave V3 gegen etwa 1.783 wstETH ein.
Schwachstellenanalyse
Magalhães stellte fest, dass die Einschränkung des Zugangs zu genehmigten Adressen den Anschein von Schutz erweckte, da Angreifer normalerweise Schwierigkeiten haben, in die Whitelist zu gelangen. Sobald jedoch eine Adresse genehmigt wurde, erlaubte der Vault, dass diese Vermögenswerte ohne Bereitstellung von Sicherheiten entnommen werden konnten. Der Sicherheitschef beschrieb die Whitelist selbst als unzureichenden Schutz gegen diese Abhebungsmöglichkeit.
Vor dem Exploit hatte der Vault laut TokenPost 25 Tage lang keine Safe-Transaktion ausgeführt. Die Publikation erwähnte Social Engineering und Kollusion als mögliche Erklärungen für die Zugangsänderung, stellte jedoch fest, dass keines von beiden nachgewiesen wurde.
Forderungen und Empfehlungen
Mit sieben noch nicht identifizierten Safe-Signern im Vorfallbericht forderte Magalhães die Personen, die die Wallet kontrollieren, auf, sich zu identifizieren und zu reagieren. Er betonte, dass ihr anhaltendes Schweigen Verdacht erwecke, ohne diese Besorgnis als Beweis für eine Beteiligung am Diebstahl zu präsentieren.
„Da dies ein nicht identifizierter Vault ist, kann ein Whitehat kaum eine Handlung mit der Garantie durchführen, dass er nicht in rechtliche Schwierigkeiten gerät.“
In seinen Kommentaren beschränkte sich das Problem nicht nur auf das Finden eines technischen Fehlers. Magalhães stellte auch das unbekannte Eigentum des Vaults und die Genehmigung in Frage, die einem Bedrohungsakteur den Zugang zur Whitelist ermöglichte, und sagte, beide Aspekte weckten Verdacht auf die Schöpfer.
Öffentliche Offenlegung und Belohnungsprogramme
Am 21. September sprach Immunefi-CEO Mitchell Amador über private Offenlegung und Genehmigung nach dem Liquid Network Exploit. Amador betonte, dass Forscher Schwächen privat melden sollten, vorzugsweise über ein definiertes Belohnungsprogramm, anstatt Benutzerfonds zu bewegen und danach über die Zahlung zu verhandeln.
In diesem Vorfall gaben nicht identifizierte Akteure 3.400 BTC zurück, behielten jedoch 598,5 BTC, so der Bericht. Blockstream wies ihren Anspruch auf verantwortungsvolle Offenlegung zurück und lehnte ihre Forderung nach einer 10%-Belohnung ab.
Schlussfolgerung
Magalhães erklärte, dass ein Bug-Bounty diesen Angriff wahrscheinlich gestoppt hätte, da die Sicherheitsgemeinschaft das Abhebungsproblem des Vertrags durch ein Programm identifiziert hätte. In einem Bericht vom 10. August über die Ergebnisse des Bug Bounty im Juli gab Immunefi bekannt, dass Forscher im Monat $2,32 Millionen für bestätigte Schwachstellen erhielten. Die Anzahl der bestätigten und bezahlten Berichte stieg um 18% im Vergleich zu Juni, während das Unternehmen angab, dass seine Programme 374 Bedrohungen verhinderten.
Der Bericht wies auch darauf hin, dass Sicherheitsprüfungen zusätzliche Zugangswege zu Benutzerfonds abdecken müssen, um zukünftige Exploits zu verhindern.
