Mögliche Auswirkungen der log4j-Sicherheitslücke?

[rheingold]

Auf meinem Homeserver sind schon einige Angriffe in den Logs vom nginx aufgetaucht. Da nginx als reverse Proxy in einem eigenen LXC Container läuft und nichts mit Java, sollte nichts passieren. Ein mulmiges Gefühl bleibt trotzdem.

[Rikki77]

vor 4 Stunden schrieb Theseus:

Problematisch bei Log4j ist die bedenkenlose Verbreitung.

Praktisch jedes größere Projekt aus der mache der Buden, die öffentliche Aufträge bekommen, verwendet Log4j wenn es Enterprise-Java ist. Selbiges gilt auch bei fast allen mir bekannten Industrie-J2EE-Projekten.

Ich würde es nicht an der Sprache fest machen, sondern einfach mal die blinde Framework-Gläubigkeit blamen. Oft genug sind mir frische Absolventen über den Weg gelaufen, die erstmal solide Boilerplate und Abhängigkeiten angesammelt haben, bevor das Hello World auch nur begonnen wurde.

Klar kommt man da schnell zu irgendwelchen Ergebnissen, aber schön ist was anderes.

https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

[PeWi]

Der IT-Blogger fefe schreibt, dass die verrückten Preise auf Coinmarketcap gestern Nacht auf das Ausnutzen der Log4J-Lücke zurückzuführen sind. (Leider ohne Quelle, nur als Behauptung.)

https://blog.fefe.de/?ts=9f47a0f9

 

[RGarbach]

vor einer Stunde schrieb PeWi:

Der IT-Blogger fefe schreibt, dass die verrückten Preise auf Coinmarketcap gestern Nacht auf das Ausnutzen der Log4J-Lücke zurückzuführen sind. (Leider ohne Quelle, nur als Behauptung.)

https://blog.fefe.de/?ts=9f47a0f9

 

Ganz genau.. Kollege Fefe ist zwar polemisch und bekennender Cryptohasser, aber eigentlich ist er Bitcoin Maxi und hat nur den Zug verpasst

Dennoch ist er gut informiert. Ich versuche auch grad die Fäden zusammenzuführen und es sieht nicht gut aus. Heise hat einen guten Artikel, leider hinter der Paywall. 

Kommentar zu Log4j: Es funktioniert wie spezifiziert

Da kann noch so einiges auf uns zukommen. Das ERC20 Universum, DEFI sowie Exchanges, sind da ganz heiße Anwärter.

[Stone]

vor 19 Minuten schrieb RGarbach:

Da kann noch so einiges auf uns zukommen. Das ERC20 Universum, DEFI sowie Exchanges, sind da ganz heiße Anwärter.

Wo siehst du da den worst case? Habe zwar darüber gelesen aber nicht ganz verstanden😔 welche max. Auswirkungen der Bug haben könnte. Zum Jahresende habe ich zur Steueroptimierung etwas mehr auf Exchanges liegen, are funds safu?

Bearbeitet 15. Dezember 2021 von Stone

[RGarbach]

vor 18 Minuten schrieb Stone:

Wo siehst du da den worst case? Habe zwar darüber gelesen aber nicht ganz verstanden😔 welche max. Auswirkungen der Bug haben könnte.

Ich habe die Befürchtung, dass Contracts angegriffen werden. Hast du damals den DAO Hack, ich glaub 2016 war das, verfolgt? Ich hatte meine ersten Gehversuche mit ETH hinter mir und hatte gleich meinen ganzen Bestand investiert. Es war halt so visionär. Ein Angriff hat dann die Token abgezogen und es war nicht möglich etwas dagegen zu machen. Der Angreifer hat noch behauptet, es sei im Recht weil es ging. 
 

ETH war noch sehr frisch und DAO war die erste große Sache. Eben weil es so wichtig war, hat Vitalik einer Hardfork zugestimmt, damit die ETH zurückgeholt werden konnten. Die alte chain lief dann mit ETC weiter. 

Ich kann mir nicht vorstellen, dass er das heute für einen Shittoken noch einmal machen würde, die wären dann für immer weg. 

[¯\_(ツ)_/¯]

33 minutes ago, RGarbach said:

ch habe die Befürchtung, dass Contracts angegriffen werden. Hast du damals den DAO Hack,

Wie kommst du zu der Schlussfolgerung ? ERC20 Contract sind in Solidity geschrieben. Und es gibt meines Wissens nur einen Ethereum client der in Java programmiert wurde. Der aber nie zu richtiger Verbreitung geschafft hatte. Aber auch wenn zB dieser angegriffen wird , dann würde solche Manipulationen vom Netzwerk abgewiesen werden. 

Die meisten Projekte verwenden eigentlich web3js für Ihre UI's aber es gibt auch eine java Implementierung web3j um mittels Java mit Smart Contracts und Ethereum Clients zu kommunizieren. Diese wären angreifbar. Hat aber wiederum nichts mit ERC20 oder Smart Contacts selber zu tun.

Edit/Nachtrag:

- Die Java web3j https://github.com/web3j/web3j Library verwendet slf4j mit logback ist somit also nicht betroffen
- Hyperledger Besu https://github.com/hyperledger/besu ist sehr wahrscheinlich betroffen, siehe https://besu.hyperledger.org/en/stable/HowTo/Monitor/Logging/

 

Bearbeitet 15. Dezember 2021 von ¯\_(ツ)_/¯

[Arther]

1 hour ago, RGarbach said:

Dennoch ist er gut informiert. Ich versuche auch grad die Fäden zusammenzuführen und es sieht nicht gut aus.

Zur Erklärung: Der Angriff auf die Contracts war ein "Supply Chain Attack". Der "Supply" ist in diesem Fall eine von einer zentralen Instanz zur Verfügung gestellten Information, nämlich der angeblich Kurs.

[¯\_(ツ)_/¯]

1 hour ago, RGarbach said:

Das ERC20 Universum, DEFI sowie Exchanges, sind da ganz heiße Anwärter.

Noch mal dazu: Von der Liste sind nur Exchangen gefährdet sofern diese in Java implementiert sind, bzw in Java Implementierte Datenbank Produkte verwenden. (zB ElasticSearch, Cassandra, etc.) 

Ich würde mir allerdings garnicht so sehr die sorgen um den Crypto Space machen, hier kannst du zumindest deine Funds auf ne Desktop-, Paper-, Hardware Wallet ziehen und bist "sicher". 

Den grössten Spass werden grade Banke, Versicherungen und Behörden haben. Da gibt es so gut wie niemanden ,der nicht Enterprise Java (J2EE, JakartaEE) im Einsatz hat. Und selbst wenn nicht, dann haben sie zB 3rd party Produkte im Einsatz wie Atlassian Jira oder Confluence etc. Und du kannst dir garnicht vorstellen, wie oft dort zB Userdaten mit Passwörtern für irgendwelche Services drin stehen ....

Bin echt gespannt was da noch alles kommen wird 😕

Bearbeitet 15. Dezember 2021 von ¯\_(ツ)_/¯

[Stone]

vor 5 Minuten schrieb ¯\_(ツ)_/¯:

Den grössten Spass werden grade Banke, Versicherungen und Behörden haben. Da gibt es so gut wie niemanden ,der nicht Enterprise Java (J2EE, JakartaEE) im Einsatz hat. Und selbst wenn das nicht, dann haben sie zB 2rd party Produkte im Einsatz wie Atlassian Jira oder Confluence etc. Und du kannst dir garnicht vorstellen, wie oft dort zB Userdaten mit Passwörtern für irgendwelche Services drin stehen ....

Dann sollten sie jetzt schnell noch günstig BTC kaufen...

Bearbeitet 15. Dezember 2021 von Stone

[RGarbach]

vor 19 Minuten schrieb ¯\_(ツ)_/¯:

Wie kommst du zu der Schlussfolgerung ? ERC20 Contract sind in Solidity geschrieben. Und es gibt meines Wissens nur einen Ethereum client der in Java programmiert wurde. Der aber nie zu richtiger Verbreitung geschafft hatte. Aber auch wenn zB dieser angegriffen wird , dann würde solche Manipulationen vom Netzwerk abgewiesen werden. 

Die meisten Projekte verwenden eigentlich web3js für Ihre UI's aber es gibt auch eine java Implementierung web3j um mittels Java mit Smart Contracts und Ethereum Clients zu kommunizieren. Diese wären angreifbar. Hat aber wiederum nichts mit ERC20 oder Smart Contacts selber zu tun.

Edit/Nachtrag:

Die Java web3j https://github.com/web3j/web3j Library verwendet slf4j mit logback ist somit also nicht betroffen

Hey du bist hier gut im Thema, danke für deinen Kommentar. 

Versteht mich nicht falsch, es ist keine Schlussfolgerung sondern eine Befürchtung. Am Ende ist es halt egal, ob der Contract direkt angegriffen wird, oder seine Datenquelle. Darum geht es doch grade, wenn die Funds erst einmal weg sind, ist blöd. 
 

[¯\_(ツ)_/¯]

21 minutes ago, RGarbach said:

Am Ende ist es halt egal, ob der Contract direkt angegriffen wird, oder seine Datenquelle. Darum geht es doch grade, wenn die Funds erst einmal weg sind, ist blöd. 

Dafür müsstest du halt deine Private Keys bei einem "Dienstleister" liegen haben. Ohne die Privat Keys kann auch ein kompromitiertes System nichts "unerlaubtes" mit dem Smart Contract anfangen. 

[RGarbach]

vor 11 Minuten schrieb ¯\_(ツ)_/¯:

Dafür müsstest du halt deine Private Keys bei einem "Dienstleister" liegen haben. Ohne die Privat Keys kann auch ein kompromitiertes System nichts "unerlaubtes" mit dem Smart Contract anfangen. 

Ganz so einfach ist es nicht. Du hast deine Keys ja nicht auf einer Börse ala MtGox liegen. Da ist schon klar, not your keys not your coins. 

Jetzt unterstelle ich einmal, du hast WBTC in einem Konstrukt stecken. Hier besitzt du keine keys mehr. Wenn dieses Konstrukt, was immer es ist, direkt oder indirekt angegriffen wird, weil z.b. die Datenbasis kompromittiert wird, sind deine Funds ggf weg. 

[¯\_(ツ)_/¯]

22 minutes ago, RGarbach said:

Jetzt unterstelle ich einmal, du hast WBTC in einem Konstrukt stecken. Hier besitzt du keine keys mehr. Wenn dieses Konstrukt, was immer es ist, direkt oder indirekt angegriffen wird, weil z.b. die Datenbasis kompromittiert wird, sind deine Funds ggf weg. 

ja, so rum betrachtet hast du natürlich recht.Ein Angreifer muss in den Besitz der Smart Contract Admin Keys kommen. Und hier ist jetzt ein neuer Angriffsvektor dazugekommen.
Hat aber nichts mit dem Smart Contract etc zu tun. Sondern wie gut (oder eben schlecht) die Entwickler des Defi Projects (zB WBTC) Ihre Keys verwalten. 

[Arther]

23 hours ago, RGarbach said:

Am Ende ist es halt egal, ob der Contract direkt angegriffen wird, oder seine Datenquelle. Darum geht es doch grade, wenn die Funds erst einmal weg sind, ist blöd. 

Ich kann auch ein Flugzeug kaufen und dann als Wohnwagen benutzen. Wer die Ausführung von smart contracts an zentrale Datenquelle koppelt der ist selber Schuld. Das ist ja gerade immer schon das Problem gewesen, dass die schöne dezentrale Smart Contract Welt ja prinzipbedingt sehr klein ist und fast keine Informationen über die relevante Wirklichkeit enthält.