Bug in Ethereums Parity kostet ICO Startups 30 Millionen Dollar
Milkweed Bug. Bild von Mike Keeling via flickr.com. Lizenz: Creative Commons
Wer zu faul ist, den Code selbst zu schreiben, den beissen die Hunde: Die Multisig-Wallet, die der Ethereum Client Parity erzeugt, hatte einen Bug. Betroffen sind zunächst mehrere ICO Startups, die rund 150.000 Ether verloren haben. Eine White Hat Hackergruppe konnte schlimmeren Schaden verhindern. Dennoch stellt der rückblickend offensichtliche Bug einige Grundannahmen von Open Source in Frage.
Gavin Wood, der Chefentwickler von Parity, hat gestern einen kritischen Bug im Ethereum-Client Parity ab Version 1.5.0 vermeldet . Alle Guthaben, Ether und Token, die in einem von Parity gebildeten Multisig-Contract sind, sind absolut unsicher.
Augenblicklich betroffen waren drei Multisig-Wallets, von denen etwa 32 Millionen Dollar oder 153.000 Ether gestohlen wurden. Dies waren die Multisig-Wallets der ICOs Swarm, Edgeless und aeternity.
In einem Blogpost erklärt Matthew Carano von Swarm, was vorgefallen ist: “Um etwa 12.30 Uhr hat uns Bernd Lapp, Business Hive Leader, informiert, dass der gesamte Inhalt der Swarm City Ethereum Multisig Wallet geleert wurde … leider sind die 44.055 Ethereum, die in Swarm Citys Wallet waren, verloren.”
Carano erklärt, dass die “verbesserte” Multisig-Wallet, die Parity mit der Version 1.5 im Januar 2017 eingeführt hat, einen Bug hat. Alle anderen Wallets sowie Multisig-Contracts sind weiterhin sicher.
Auf dem Ethereum-Blockexplorer Etherscan wurde die Adresse, auf die der Hacker die Guthaben überführt hat, markiert. Offenbar hat er bereits begonnen, einen Teil der Beute auf andere Adressen zu überweisen. Ob es ihm aber jemals gelingen wird, diese beschmutzten Coins zu verkaufen, ist noch eine offene Frage. Solange Ethereum keine Zero-Knowledge-Proofs oder gut funktionierende Mixing-Contracts entwickelt, dürfte es kaum möglich sein.
Auf reddit wurde der Fehler, der zu dem Hack geführt hatte, als “School boy error” beschrieben. Man hätte dies von jedem erwartet, aber nicht von Gavin Wood. Wood hat Ethereum mitgegründet, die Smart Contracts Programmiersprache Solidity entwickelt und das Ethereum Yellow Paper geschrieben, die erste formale Spezifikation von Ethereum. Mit Parity entwickelt Wood eine Alternative zum beliebten Ethereum-Client Geth, die während der Spam-Angriffe im Herbst 2016 fast im Alleingang Ethereum am Leben gehalten hat.
Das Folgende ist schief gelaufen: Der “verbesserte” Multisig-Contract, den die Wallet Parity generiert, hat die Option eines sogenannten “Ownership-Wechsels”. Mit dieser Option kann der Besitzer des Vertrags einen neuen Besitzer definieren. Dies zwingt einen Dieb des Schlüssels dazu, den Besitzerwechsel durchzuführen, wodurch der Diebstahl, immerhin, offensichtlich und auf der Blockchain nachweisbar wird, und es eventuell möglich ist, den Contract auch dann weiter zu benutzen, wenn man einen Schlüssel verloren hat.
Nun hatte diese Ownership-Wechsel jedoch einen Fehler. Es fehlte ein “internal”. Dadurch wurde es jedem möglich, den Ownership-Wechsel durchzuführen. Der Hacker hat sich nun lediglich als neuen Besitzer des Vertrages definiert und das Geld abgezogen. Da der Fehler relativ banal war, war er auch mit wenigen Änderungen zu fixen.
Die Banalität dieses Fehlers stellt eine der großen Grundannahmen von Open Source in Frage: Wenn ein so einfacher Fehler gut ein halbes Jahr lang unbemerkt bleibt, wenn die Startups, die Millionen in diesem Contract lagern, nicht in der Lage sind, den Code zu lesen und den Fehler zu erkennen – wie viele weitere Fehler sind dann in den vielen Zeilen Code, die wir Tag für Tag benutzen? Und wie kann man das jemals erfahren?
Der Fehler erinnert aber auch daran, dass Solidity, die Sprache, in der Ethereum-Contracts gewöhnlich geschrieben sind, noch blutjung ist. Sie selbst ist noch nicht ausgereift, nur wenige Leute beherrschen sie, und es gibt auch noch nicht die Entwickler-Tools, die das Entstehen solcher Bugs im Keim ersticken. Daher kann es selbst Leuten wie Gavin Wood, die Solidity wie kein anderer beherrschen sollten, passieren, dass sich ein Fehler in den Code schleicht.
Wer nun mit Parity Geld oder Token in einem Multisig-Contract gespeichert hat, muss nicht in Panik verfallen. Ein White-Hat-Hacker-Team hat sofort begonnen, jeden verwundbaren Multisig-Contract, den sie gefunden haben, zu entleeren und die Guthaben auf eine sichere Adresse zu übertragen. Die White-Hat-Hacker haben angekündigt, die Guthaben auf dieselbe Multisig-Adresse wie zuvor zu senden, allerdings ohne den Bug. Das heißt, die Guthaben werden, falls sie auf der White-Hat-Adresse gelandet sind, über kurz oder lang wieder in der Wallet erscheinen. Wer allerdings noch ein Guthaben in einer Multisig-Adresse hat, die in Parity ab Version 1.5 erzeugt wurde, sollte diese jedoch rasch übertragen. Bevor es ein anderer macht.https://bitcoinblog.de/mein-erster-bitcoin/
Der Kurs von Ethereum reagierte auf den Bug mit einem kleinen Einbruch von etwa 10 Prozent. In den enormen Schwankungen, die Ethereum derzeit täglich durchmacht, fällt dies kaum auf. Lediglich die betroffenen Startups, etwa Swarm und Edgeless, mussten höhere Verluste hinnehmen.
Die Bitcoin-Community auf Twitter nahm den Vorfall derweil zum Anlass, eine Gelegenheit zu verpassen, sich souverän zu geben. Stattdessen frönte sie der unverhüllten Schadenfreude und spottete, dass es wie bei der DAO bestimmt bald eine Hardfork geben werde, um den Hack rückgängig zu machen. Ethereums Vitalik Buterin reagierte darauf mit der Bemerkung, dass derzeit nur Concern Trolls aus dem Bitcoin-Reich eine Hardfork für Ethereum forderten. Wie auch immer – nötig hat es die Bitcoin-Szene nicht, sich an einem Bug von Ethereum zu ergötzen.
Wer ist Bitcoin?
Do meinst bestimmt die komischen Smallblockers die sich daran ergötzen.
Richtig, das war schief ausgedrückt. Habe das korrigiert.
Ich glaube, ich habe auch manche Big Blocker gesehen, die gespottet haben. Aber offensichtlich sind die Small Blocker am lautesten, am schnellsten und am giftigsten dabei, sich an Problemen von Etheruem zu ergötzen. Weißt du, warum?
Reine Schadenfreude, hattest du das noch nie?
Doch. Aber wenn Leute 150 Mio Dollar verloren haben, verkneife ich sie mir, anstatt sie zu zelebrieren. Es wirkt für mich einfach kleingeistig und unsouverän, wenn gestandene Bitcoiner so schadenfreudig reagieren, wenn bei Ethereum was passiert. Riecht nach Angst, die Krone zu verlieren.
Warum sind es denn eher Small Blocker ?
Riecht auch nach du bist selber betroffen.
warum?
Ich bin nicht betroffen, keine Sorge.
Ich bezweifle, dass das Umtauschen in echtes Geld ein allzu großes Problem darstellt. Zum einen wird es irgendwann Mixer geben, zum anderen kann man die Ether ja einfach in eine andere Kryptowährung umtauschen. Ether -> Zcash -> Monero -> Bitcoin -> auscashen klingt doch ganz “gut”.
Ich finde es in diesem Zusammenhang viel interessanter, das Firmen, die über so viel Geld verfügen offenbar nicht die Manpower aufbringen können, die Software gegenzuprüfen. Klingt für mich schwer nach blindem Vertrauen.
Soweit ich weiß, gibt es keinen Mixer für Ethereum, und ich gehe mal auch davon aus, dass keine Wechselstelle die Coins aus dem Hack annehmen wird.
Gibt es eine offizielle Adressen-Blacklist, die Wechselstellen benutzen? Werden alle Wechselstellen diese Adressen permanent monitoren und die permanent neu generierbaren Adressen auf die von diesen Adressen überwiesen wird?
Ich denke schon, dass man die Coins irgendwie umsetzen kann.
In Etherscan sind die Hacker-Adressen öffentlich notiert. Hier sind auch öffentlich die Ethereum-Contracts von Shapeshift oder Bittrex notiert. Sobald solche Börsen die ETH des Hackers annehmen, wird dies für jeden sichtbar sein.
Nur eine Frage des Preises und der Zeit. Wenn die keiner nimmt, ich nehme sie gerne.
Imho ist es blauäugig zu glauben, dass es keine Möglichkeit zum Auscashen gibt, wenn man bedenkt, dass selbst Alphabay ETH akzeptiert hat. Die hatten zwar ihren eigenen Mixer (für BTC & ETH), aber es gibt durchaus öffentliche (keine Empfehlungen, da keine Erfahrung damit):
https://ethermixer.com/
https://bitcointalk.org/index.php?topic=1711920.0
Es gibt auch täglich neue ICOs, in die der Angreifer seine Coins stecken kann, aber womöglich ist das die beste Möglichkeit, sie nie wieder zu sehen…
Zudem ist Coin-Tainting meiner Meinung nach ein massives Problem, denn die betroffenen Adressen sind zwar markiert, aber wie soll ich als kleines Startup oder sogar Privatperson über hunderte von Hops (mit möglicherweise tausenden anderen Inputs) herausfinden, dass Coins, die ich erhalte, irgendwann mit einem Hack verbunden waren? Wenn ich das erst erfahre, wenn ich mein Geld an eine große Börse schicke und mein Account damit stillgelegt wird, hat eine dezentrale Währung verloren, denn ich müsste jedes Mal bei einer Art Schufa nachfragen, ob die Coins, die ich erhalte (nach aktuellem Stand) legitim sind.
90.000 Dollar sind schon ausgecasht über changelly:
http://www.coindesk.com/parity-wallet-hacker-cashes-90000-stolen-ether/
Bei einer Art Schufa nachfragen ist ein klasse Ansatzpunkt für die Regulierungsbehörden, um doch noch Hoheitsrechte über die Kryptowährungen zu bekommen.
Auch interessant, daß Ethereum mal wieder den Vorreiter spielt. Bevor man bei anderen Kryptowährungen auch nur auf die Idee kommt, etwas Neues auszuprobieren, haben es bei Ethereum bereits Hacker ausgenutzt. Das dürfte Ethereum zur riskantesten Kryptowährung machen, in die man zur Zeit investieren kann. Dafür sollte Ethereum dann auch bei Erfolgen ganz vorne dabei sein. Insbesondere um Swarm ist es schade. Swarm gehörte zu den frühesten Ideen für die Ethereum-Blockchain.
Am interessantesten ist aber die Frage, die im Artikel aufgeworfen und unnötigerweise auf Open-Source-Software begrenzt gesehen wird: Wieviele Fehler sind im Code und wie erfahren wir davon? Diese Frage gehört ganz offizjell zu den wenigen noch offenen Fragen, mit deren Beantwortung man sich eine Fields-Medaille verdienen kann, die unter Kennern angesehener als der Nobelpreis ist. Deshalb lautet die Antwort für alle, die nicht wenigstens Mathematikgenies vom Range eines Gödel sind: Man kann es garnicht wissen und niemals erfahren. Daher ist der Vorfwurf an die Start-ups schon sehr unfair.
Außerdem liegt das Finden von Fehlern in Computerprogrammen über Kreuz mit dem Konzept der Objektorientierten Programmierung. In kleinen Programmen dient die OOP nur als standardisierte Methode der Obfuskierung. Eine solche ist eigentlich völlig überflüssig und macht nur mehr Schreibarbeit. In größeren Projekten ermöglicht OOP unterschiedliche Programmteile unterschiedlichen Programmierern zu übertragen, ohne daß diese irgendetwas voneinander oder irgendetwas über die übrigen Programmteile wissen müssen. Genau dafür wurde die OOP entwickelt. Wenn ein Programmierer vielleicht ein Prozent des gesamten Computerprogrammes kennt und die übrigen neunundneunzig Prozent nicht, dann kann er in neunundneunzig Prozent des Computerprogrammes keine Fehler finden, weil das nur in seinem eigenem einprozentigem Teil möglich wäre. Aber gerade da wird der Programmierer einen blinden Fleck haben und keinen größeren Fehler finden (höchstens mal einen Tippfehler), weil er den sonst schließlich nicht erst gemacht hätte. Man kann aber auch nicht die Programmierer über das gesamte Programm schauen lassen oder mehrer Programmierer über jeweils einen Programmteil, weil nichtmal Microsoft solche Ressourcen hat. Nur deshalb hat man das Konzept der OOP überhaupt erst entwickelt. Das wichtigste Stichwort zur Recherche lautet Software-Krise. Schon seit den 1960ern sucht man nach Lösungen für den eklatanten Mangel an Programmierern, unter dem die gesamte IT-Branche leidet, weil es einfach nicht viele Menschen gibt, die Talent zum Programmierer haben. OOP gilt bis heute als die Lösung der Software-Krise. Auch Outsourcing wird dadurch erst auf eine sinnvolle Weise möglich. Aber weil OOP als das Nonplusultra (eigentlich nur für große Projekte) gilt, deshalb machen es viele auch dort, wo es nicht nötig ist. Schon ist das Programm obfuskiert, kein Teil braucht zu wissen, was in einem anderem vorgeht und Fehler können zur Laufzeit nicht mehr lokalisiert werden. Nur wenn man den Code Zeile für Zeile durchgeht und dabei endlich die Idee hat wie die Zeilen richtig lauten müßten, nur dann kann man einen Fehler mal zufällig finden. Aber schon ohne OOP hat man lediglich einen übersichtlicheren Code und sinnvollere Fehlermeldungen und wenn die einem nicht weiterhelfen kann man Fehler auch dann nur zufällig finden.
Ranma
Danke für den kurzen Einblick.