Ein Untersuchungsbericht über die Selbstzerstörung der Parity-MultiSig-Bibliothek

Übersetzt von Daredevil3x7 und erstellt mit Unterstützung des Kusama Treasury via WagMedia

Am Montag, den 6. November 2017, 02:33:47 PM UTC, wurde von einem anonymen Nutzer eine Schwachstelle im "Library"-Smart-Contract-Code gefunden, der als gemeinsame Komponente aller Parity Multi-Sig-Wallets eingesetzt wird, die nach dem 20. Juli 2017 eingesetzt wurden. Der Nutzer beschloss, diese Schwachstelle auszunutzen und machte sich zum "Besitzer" des Bibliotheks-Contracts. Anschließend zerstörte der Nutzer diese Komponente. Da die Multi-Signatur-Wallets von Parity von dieser Komponente abhängen, wurden durch diese Aktion Gelder in 587 Wallets mit einem Gesamtbetrag von 513.774,16 Ether sowie weitere Token gesperrt. Nach der Zerstörung der Bibliothekskomponente hat jemand (angeblich derselbe Benutzer) unter dem Benutzernamen "devops199" die Meldung #6995 gepostet, die uns zu einer Untersuchung dieser Angelegenheit veranlasste.

Alle anderen Funktionen der Parity Wallet (UI) weisen weiterhin keine bekannten Schwachstellen auf. Das gilt auch für alle Standard-Accounts ohne MultiSig.

Wir haben uns an die betroffenen Nutzer/innen gewandt und fordern alle, die wir noch nicht erreichen konnten, auf, uns zu kontaktieren: [email protected]. Wir sind uns bewusst, dass das Problem unter anderem zu Sorgen und Ängsten über die Zukunft von Projekten und Geldern in unserer Community geführt hat, und wir arbeiten hart daran, alle möglichen Lösungen zu finden.

Seit dem Exploit haben wir im Team viele Diskussionen und Analysen geführt. In diesem Beitrag möchten wir einige Faktoren beleuchten, die für das Problem relevant sind, und Antworten auf Fragen und Beschwerden geben, die nach dem Exploit aufgetaucht sind.

Wurde die Wallet-Bibliothek nicht auditiert?

Der ursprüngliche "Foundation"-MultiSig--Wallet-Code wurde vom DEV-Team der Ethereum Foundation, Parity Technologies und anderen Mitgliedern der Community entwickelt und geprüft. Viele Nutzerinnen und Nutzer verlassen sich darauf, und der Code wurde einer umfassenden Prüfung durch Fachkollegen unterzogen. In diesem Code gibt es weiterhin keine bekannten Sicherheitsprobleme. Er wurde vom Parity-Team in einen leichtgewichtigen "Stub"-Smart-Contract umstrukturiert, der jedes Mal, wenn eine Wallet erstellt wird, im Netzwerk bereitgestellt wird, sowie in einen viel schwereren "Library"-Smart-Contract, der den Großteil der Logik der Wallet enthält und nur einmal bereitgestellt wird. Obwohl es keine formelle Prüfung gab, wurde der Vertrag intern und extern im Zusammenhang mit der Analyse des Exploits vom 19. Juli und der Rückgabe der Gelder durch die White Hat Group sowohl vor als auch nach der Bereitstellung im Juli mehrfach geprüft.

Was geschah vor dem Vorfall?

Um dem ursprünglich geprüften Smart Contract so nahe wie möglich zu kommen, wurden so wenige Änderungen wie möglich vorgenommen, um den Bibliotheks-Contract abzuleiten. Das bedeutete jedoch, dass die Bibliotheks-Contracts die gleiche Funktionalität wie eine reguläre Wallet hatten und eine Initialisierung erforderten. Er enthielt daher auch noch die ursprüngliche Selbstzerstörungsfunktion, die für den Rückzug der Wallet vorgesehen ist.

Nach dem Angriff am 19. Juli 2017 haben wir den Bibliotheks-Contract am 20. Juli 2017 behoben und wieder in Betrieb genommen.

Im August schlug ein Mitwirkender auf Github namens "3esmit" eine Codeänderung vor, die besagt, dass initWallet bei der Bereitstellung aufgerufen werden sollte, was damals als praktische Verbesserung angesehen wurde. Daher haben wir diese vorgeschlagene Verbesserung in den Bibliotheks-Contract aufgenommen, der die automatische Initialisierung durch den Aufruf von initWallet bei der Erstellung vorsieht. Da die Empfehlung als Verbesserung angesehen wurde, sollte der geänderte Code zu einem späteren Zeitpunkt in einem regulären Update implementiert werden.

Am 6. November 03:25:21 PM +UTC erkannte 'devops199' den nicht initialisierten Eigentümer des im Juli eingesetzten Vertrags und entschied sich, ihn zu initialisieren und sich damit selbst zum Eigentümer zu machen. Anschließend entschied devops199, den Bibliotheks-Contract zu löschen.

Wie hätte dieser Exploit verhindert werden können?

Es gibt im Wesentlichen zwei Möglichkeiten, wie dieser Exploit hätte vermieden werden können. Wenn der Vertragscode keine Suicide- oder Kill-Funktion enthalten hätte, wäre es selbst dann, wenn jemand den Besitz übernommen hätte, nicht möglich gewesen, etwas zu unternehmen. Die Kill-Funktion war ein Rest des ursprünglich geprüften Smart Contracts. Die andere Möglichkeit wäre gewesen, dass die Wallet-Initialisierung wie von 3esmit vorgeschlagen erfolgt wäre, entweder automatisch durch die Codeänderung und die erneute Bereitstellung oder manuell bei dem im Juli veröffentlichten Vertrag.

Parity Technologies beschäftigt regelmäßig externe Prüfer für formale Audits der von uns geschriebenen Smart Contracts. Unser KYC-Service PICOPS und die Kaufverträge für ICOs, bei denen wir helfen, haben zum Beispiel strenge Audit-Anforderungen.

Wir sind jedoch der festen Überzeugung, dass nicht nur mehr Audits, sondern auch umfassendere und formalere Verfahren und Instrumente für die Einführung, Überwachung und Prüfung von Smart Contracts erforderlich sind, um Sicherheit zu erreichen. Wir sind der Meinung, dass das gesamte Ökosystem dringend solche Verfahren und Instrumente benötigt, um zu verhindern, dass sich ähnliche Probleme wiederholen, vor allem wenn die Anzahl und Komplexität der laufenden Smart Contracts zunimmt.

Was unternimmt Parity Technologies, um die betroffenen Mittel freizugeben?

Wir bedauern die Situation zutiefst und arbeiten mit Hochdruck an mehreren Ethereum-Verbesserungsvorschlägen (EIPs), die sowohl zu bereits bestehenden Vorschlägen beitragen als auch neue vorschlagen, die das Potenzial haben, Geldsperren aufzuheben. Diese Verbesserungsvorschläge werden sich auch mit allgemeinen Fällen von blockierten Geldern befassen.

Es gibt keinen Zeitplan dafür, wann ein solcher Verbesserungsvorschlag umgesetzt werden könnte; wir werden dem Willen der Community folgen und den regulären EIP-Prozess wie jede andere Protokollverbesserung durchlaufen. Parity Technologies wird einen Großteil der Entwicklungsarbeit rund um diese Vorschläge übernehmen und konstruktiv mit dem Team der Ethereum Foundation und der Community an der weiteren Entwicklung der Protokollschicht arbeiten. Wir engagieren uns für die weitere Entwicklung von Ethereum.

Welche weiteren Schritte unternimmt Parity Technologies?

• In einem ersten Schritt entfernen wir die Möglichkeit, MultiSig-Wallets einzusetzen, bis wir das Gefühl haben, dass wir die richtigen Sicherheits- und Betriebsverfahren eingerichtet haben, damit wir sicher sein können, dass so etwas nicht noch einmal passieren wird. Die Parity Wallet UI wird weiterhin Gnosis, WHG oder andere Multisig-Wallets unterstützen, die als sicher gelten. Über die Parity Wallet kannst du bereits eingerichtete Multi-Signatur-Wallets einsehen und nutzen. Wie bei allen anderen Verträge kannst du auch MultiSig-Contracts manuell einrichten, aber es wird keine MultiSig-spezifische integrierte Möglichkeit dafür geben.
• Wir werden uns auf die Infrastruktur der mittleren Ebene konzentrieren - nicht auf die Wallets, sondern auf den Chrom, in dem die Wallets liegen. In diesem Sinne werden die Wallets zur "User-Level"-Software, mit der Parity erweitert werden kann.
• Wir beauftragen ein weiteres umfassendes externes Sicherheitsaudit des gesamten bestehenden sensiblen Codes, einschließlich der Verwaltung von Geheimnissen, Schlüsselgenerierung und Passwortverwaltung, Signierung und automatischer Aktualisierung.
• Wir werden erhebliche Anstrengungen und Ressourcen in die Überprüfung unserer internen Prozesse und Verfahren stecken und haben ein Team, das sich speziell mit der betrieblichen Sicherheit beschäftigt. Dieses Team wird bei Bedarf erweitert werden und wir werden ihm Ressourcen zur Verfügung stellen. Das Team wird die Aufgabe haben, kritische Teile des Angebots von Parity Technologies zu überprüfen und zu pflegen.
• Wir werden dafür sorgen, dass alle notwendigen Contract-Deployment-Prozesse angemessen mit dem Code-Änderungs- und Überprüfungsprozess im https://github.com/paritytech/contracts Repository verknüpft werden, und wir werden die Bemühungen unterstützen, Werkzeuge dafür zu schaffen, z.B.
  • Ähnlich wie in der Luft- und Raumfahrt oder heutzutage in der Medizin sollte es für jeden Smart Contract eine Checkliste für den Einsatz geben.
  • Es sollte eine ständige Überwachung der eingesetzten Smart Contracts geben, bei der sie mit der letzten überprüften Version im Repository verglichen werden.
• Wir werden erhebliche Anstrengungen innerhalb des Unternehmens unternehmen und versuchen, externe Hilfe und Ressourcen zu finden, für:
  • Unterstützung bei der Erforschung und Entwicklung anderer Smart-Contract-Sprachen und -Werkzeuge, z. B. bei der formalen Verifizierung und der Unterstützung von Beweisen;
  • Aufbau von Beziehungen zu Forschungsteams, die sich mit der Entwicklung von Werkzeugen, der Erforschung von Sprachen und dem Testen befassen; Unterstützung beim Aufbau unabhängiger Teams, um die nächste Generation des Asset Control Managements zu entwickeln: Tresor Sichere Contracts für MultiSig-, Time Locks, Deadman Switches, um die Werkzeuge für eine sichere Speicherung und Wiederherstellung bereitzustellen;
  • Erweiterung unseres Bug Bounty-Programms und Einführung von Feature Bounties für unternehmenskritische Komponenten, sofern ausreichend Mittel zur Verfügung stehen - schließlich stellen wir unsere gesamte Software als Open Source Software-Beitrag für die Community kostenlos zur Verfügung.

Parity Technologies hat sich verpflichtet, bei der Entwicklung der Ethereum-Technologie an vorderster Front zu stehen, und wir werden unermüdlich daran arbeiten, sichere und nützliche Technologien für die Community zu entwickeln.