ich bin recht neu in dem ganzen Bitcoin Thema und hab folgendes (sehr) theoretisches Szenario im Kopf und wäre es damit möglich eine Wallet zu kompromitieren?
Folgendes:
Theoretisch ist es ja möglich Text in der Blockchain zu hinterlegen, soweit mir bekannt.
Damit ist doch auch die Möglichkeit gegeben einzelne Codeschnipsel in verschiedenen Blöcken zu hinterlegen.
Nur um Sie über einen weiteren Codeschnipsel in einem openSource Wallet Client abzurufen, zusammen zu setzen und eine Maleware zu starten, die z.B. Tastatureingaben oder Screenshots aufnimmt und an einen CC Server zu senden.
Da wir genau ca. 144 Blöcke pro Tag möglich haben, haben wir auch die Option die Codeschnipsel sehr sehr klein und über einen großen Zeitraum zu verteilen.
Mal davon abgesehen das man sich die Mühe machen müsste, jeden Codeschnipsel einem Block zu zuweisen um das im nachgang wieder abrufen zu können.
Man müsste dafür auch einen Wallet Client kompromitieren können.
Aber sagen wir mal Zeit/Geld/Aufwand spielt hier eine eher untergeordnete Rolle.
Könnte man dieses Szenario nicht auch verwenden um den Bitcoin Source Code zu „verseuchen“?
Da ja hier kein direkt sichtbarer schädlicher Code im Source Code versteckt sondern der Abruf und der zusammenbau des Maleware Codes im Source Code enthalten sein muss und man den auch über mehrere Klassen / Funktionen/etc. verteilen könnte.
Bitte präzise Sprache verwenden, sonst müsste man fragen, was du unter „Bitcoin Source Code“ verstehst. Ich interpretiere das jetzt mal so, daß du den Code von Bitcoin Core meinst.
Du wirst in Bitcoin Core keinen Code reinbekommen, dessen Funktion nicht mehrere Augenpaare der Core Devs vollständig verstanden und getestet haben und dessen Funktion klar umrissen ist. Punkt.
Dein Angriffsvektor könnte funktionieren, sehr wahrscheinlich aber nur mit einer Closed-Source-Wallet, aber dann kannst du dir den Klimbim mit Code-Schnipseln in OP_RETURN Daten sparen, die du jeder deiner Transaktionen hinzufügen dürftest, also auch mehrere pro Block. (Solche Zusatzdaten kannst du in der Coinbase-Transaktion oder in OP_RETURN Daten in einer oder mehreren Transaktionen eines Blockes unterbringen.) Mit Closed-Source kannst du ja machen, was dir gefällt, das fällt nur dann auf, wenn jemand den Code deiner Wallet reverse engineered oder der Schmuh durch entsprechende Transaktionen deiner Wallet auffällig wird.
Bei Open-source wird es eine Weile dauern, aber irgendwann fällt krauser Code einfach auf, besonders wenn es danach aussieht, daß man da etwas zu verschleiern versucht. Du wirst z.B. Code brauchen, der die Blockchain nach deinen Malware-Code-Krümeln absucht.
Ich würde keine Wallet auch nur entfernt anfassen, deren Source-Code den leisesten Verdacht von Verschleierung oder umständlichster Programmierung macht. Selbst wenn das keine bösen Absichten hat, ist es eine Fehlerquelle und potentielles Sicherheitsrisiko. Das darf bei einer Wallet-Software nicht sein.
Interessant und theoretisch möglich. Es kommt darauf an, was das Wallet mit den OP_RETURN Daten macht. Die meisten Wallets sind keine Blockexplorer und aus Nutzersicht (use case: wallet) sind die Daten aus OP_RETURN vollkommen uninteressant. Da die Wallets ohnehin thin clients sind, die i.d.R. selbst gar keine Blöcke validieren, sondern sich mit einer Full Node verbinden, würde ich davon ausgehen, dass der potentielle Schadcode aus OP_RETURN gar nicht erst über die Leitung geht.
Wonach man suchen könnte, wenn man diesen Exploit bauen will:
Eine Wallet, die OP_RETURN anzeigt oder eine Wallet, die selbst Transaktionen validiert
Möglichkeit eine Situation zu provozieren, bei dem die Daten aus OP_RETURN im Fehlerlog (Konsole) ausgegeben werden. Das könnte z.B. sowas sein wie: „App im Entwicklermodus starten“
Eine Wallet, die versucht die Privatnachricht aus OP_RETURN zu interpretieren, z.B. eine Sprache zu erkennen
Wenn man dem Opfer dann eine Transaktion mit Schadcode in OP_RETURN sendet, könnte man so (theoretisch) das Wallet kompromittieren. Sehr spannende Idee.
Ich glaube auch das der Code durch viele Augen verifiziert und getestet wird.
Es gibt ja Anwendungen, wo man Code zur späteren verwendung vorbereitet und implementiert und auskommentiert (macht noch nix, aber kann ich ja brauchen).
Ist kein guter Stil, das würde man dann wohl eher in ein extra File auslagern und ggf. durch den import der Klasse dann abrufen, oder ähnliches, aber → rein theoretisch.
Ich würde an der Stelle auch mehrere Angriffsvektoren miteinander kombinieren um auf jeden Fall sicherzustellen das der Code erst mal unentdeckt bleibt.
Daher auch der Ansatz, den eigentlichen Malewarecode, den ich ja schon vorher in der Blockchain verteilt hab, abzurufen.
Der darf sich schon nicht direkt nach dem compilen und ausführen aktivieren. Sondern auf ein Signal oder Zeit hin (was wieder schwer zu verstecken sein wird).
Und nehmen wir nur ganz hypotethisch an das einer oder viele der CoreDevs viele Cookies bekommen hat/haben und zur Dark Side übergelaufen ist/sind (ideologie lässt sich ja überschreiben und kompromitieren).
Denk bitte dran, das es sich bei dem Szenario um ein reines Gedankenspiel handelt und keine tatsächliche Möglichkeit darstellen muss. Dafür sind es zu viele Faktoren die einfach stimmen müssen.
Mit Wasabi und dem Coinjoin gibt es ja schon die Möglichkeit das „ungezielt“ zu tun.
Der macht das ja schon und zieht sich einzelne Blöcke aus der Blockchain, soweit ich das mitbekommen habe (korrigier mich, wenn ich mich irre)
Da müsste man doch nur noch die Blöcke präzisieren und die Maleware zusammen bauen lassen.
Keine Ahnung wie so ein Block on detail aussieht, deswegen sagt mir der OP_RETURN nichts.
Aber ein Feld aus einer Datenmenge, die ich ja eh bekommen, heraus zu ziehn und auszuwerten, ist ja nicht so die herausforderung.
Der Zusammenbau und Ausführung der Maleware (deswegen lässt man seine Services nicht als root laufen ) ist da das spannendere Unterfangen.
Ich sehe in die andere Richtung (also Wallet veröffentlicht Informationen nach außen) viel größeres Angriffspotential. Vor allem auch bei Hardware Wallets.
Eine Hardware Wallet kann noch so open-source und transparent sein, am Ende des Tages kann ich nicht verifizieren welcher Maschinencode tatsächlich auf der Hardware ausgeführt wird. Eigentlich ist für diesen Nachteil der Host zuständig: Er überprüft das Gerät auf Echtheit und kontrolliert die Kommunikation nach außen.
Bei der nonce covert channel attack haben Hardware Wallets aber potentiell einen Angriffsvektor, indem sie Informationen über die Nonce der Signatur veröffentlichen. So kann über mehrere Transaktionen hinweg z.B. der Seed veröffentlicht werden und der Angreifer (z.B. der Hersteller der Hardware Wallet) kann ihn einfach mit on-chain Daten rekonstruieren.
Der Host Software wird dies ohne weiteres nicht auffallen, da sie die Nonce nicht auf mögliche Angriffe kontrollieren kann, sie kennt die sicherheitskritischen Daten der Wallet schließlich nicht.
Die BitBox02 löst dieses Problem indem die BitBoxApp verifizierbaren (aber nur teilweisen) Einfluss auf die Nonce nimmt. Ist soweit ich weiß auch die einzige Hardware Wallet die hier ansetzt. Klingt fast schon wie Werbung, aber es ist halt so…
inb4: „Aber wenn der Hersteller sowieso kompromittiert ist, wie kann ich der Host Software vertrauen?“
Die Software auf dem Rechner ist zwar potentiell „unsicher“ aber dafür viel besser überprüfbar – sie läuft schließlich auf meinem System. Ich kann einfacher nachvollziehen ob wirklich der open-source Quellcode auch in meiner Applikation steckt. Der Angreifer müsste meinen Rechner über die Wallet Software hinaus kompromittieren (und natürlich die Hardware Wallet), und da sind wir auf einem Niveau gegen das man sich sowieso nicht mehr wirklich schützen kann…
Mehr zu dem Thema:
Natürlich ist so ein Angriff so oder so sehr unwahrscheinlich. Eigentlich haben nur die Hersteller der Hardware Wallets hier eine realistische Chance einen Angriff zu realisieren.
Eine Hardware Wallet kann noch so open-source und transparent sein, am Ende des Tages kann ich nicht verifizieren welcher Maschinencode tatsächlich auf der Hardware ausgeführt wird. Eigentlich ist für diesen Nachteil der Host zuständig: Er überprüft das Gerät auf Echtheit und kontrolliert die Kommunikation nach außen
da hast du vollkommen recht. Es kann ja auch sein, das ein Chip auf der Wallet is der eben nicht Dokumentiert ist und wenn man die Wallet noch gegen Physischen Zugriff geschützt hat, ist die Information auf den Chips auch wieder hin.
Selbst wenn das also an der Stelle dann wieder einer Spitz kriegt, kann man behaupten, das es eine noch nicht dokumentierte Hardwarerevision 2 ist und auch da kann man rein schreiben was man will.
(special encrypted storage for internal code signing certificates) so als Beispiel, würde wahrscheinilich noch nicht mal wer hinterfragen, da Code Signing ja an sich was gutes ist
Man will ja seine Hardwar ggf. auch Updaten um gefundene Sicherheitslücken effektiv zu schließen, sofern sie per Update zu schließen sind.
Ab einem gewissen Punkt, muss man also wieder Vertrauen vorschießen.
Hat sich eigentlich schon einer an Side Channel Attacks bei der BitBox versucht?
Also Kommunikation über Chips in der BitBox mitzuschneiden und ggf. zu manipulieren, die dafür eigentlich nicht in Frage kämen?
Du hast ja mehrere Signalwege in so einem elektrischem Schaltkreis und ggf. kannst du über einen ungesicherten was abgreifen, was du nich abgreifen können solltest?
Wäre nicht das erste mal das so was geht (unabhängig von der Wallet Thematik).
Dein einwurf über die BitBox02 hab ich als Ansporn genutzt und mich über die BitBox etwas beleseb. Liest sich recht gut.
Sicherheit fängt halt schon am Schlüssel an und nicht erst am Schloss.
Wie denkst du darüber, ob man mit der von mir beschriebenen Methode es schaffen könnte den Bitcoin_Core Code oder eine schon weit verbreitete Software Wallet zu kompromitieren (reines Gedankenspiel)?
Ich mein, jeder fängt mal klein an und testet bissl rum. Da macht ja auch Kleinvieh schon Mist als potenzielles Target. 100$ x 10T is halt auch schon ein Sümmchen
) ist da das spannendere Unterfangen.
