So. Rootkit Shitstorm Kurzfassung: fronti ist schuld. Ende der Kurzfassung.
War nur Spaß - wenn es irgendwo Verantwortung gibt, dann trage ich die natürlich, aber so als Hintergrundinfo nur hier, weil ich mich jetzt lange genug in englischen Mails gebadet habe:
Irgendwann um den 19/20. Oktober 2016 herum hat fronti ein paar Penetrationstests mit dem LBC durchgeführt. Das auch vorher angekündigt, sogar nach einem development Server gefragt um den Produktivserver nicht zu zerschiessen, aber mutig wie ich bin, habe ich ihn auf dem Produktionsserver machen lassen und die Sache beobachtet.
Die PMs aus der Zeit habe ich noch, Fronti vielleicht auch.
Er ging von dem was ich auf dem Server sehen konnte recht strukturiert vor, hat den perl code analysiert, die quine entdeckt (eine Art checksum der Quelltextes) und hat eben versucht dem Server ungültige Blöcke als gültige unterzuschieben. So in etwa.
Gut, die clients von ihm sind damals in der Blacklist (IPs, Ids) gelandet, aber das konnte man ja mit Tor umgehen etc. etc.
Jedenfalls konnte LBC damals die Angriffe abwehren, aber es war klar, dass es eigentlich nur eine Frage des Aufwands (und somit der Zeit) war, bis jemand - egal welche Barrieren ihm der Client in den Weg stellte - diese prinzipiell umgehen konnte.
Es ist ähnlich wie mit dem Kopierschutz: Jede standalone Software kann prinzipiell geknackt werden. Also habe ich noch eine 3. Verteidigungslinie eingebaut: quine-check vom Server durchgeführt. Das macht man in Perl mit einem eval und das ist prinzipiell eine remote-code-execution. Da gibt es auch nichts was man auf dem client hacken könnte, denn der Code ist ja nicht da. Da flippen nun einige (muss man auch nüchtern sehen, dass es da nur einige Alarmisten gibt) aus.
Der Client kann sich vollständig selbst auto-updaten (= den kompletten Code auswechseln mit meinetwegen 100 "evals")
=> stört keinen
Hat mich gestört, also habe ich ohne Diskussion, ohne Druck ein "no_update" für die Paranoiden eingebaut.
Suma sumarum:
Ganz klar, wer Bedenken hat, soll die Software nicht einsetzen. Ansonsten Container, VM (siehe hier:
https://lbc.cryptoguru.org/man/admin#security) oder dedizierte Hardware. Wer trotzdem Bedenken hat: siehe vor-vorherigen Satz.
Gerade LBC benötigt eben zu seiner Funktion keine Wallet oder Blockchain oder sonstige BTC (oder jedwede andere Coin) Infrastruktur auf der Maschine...
Im Laufe der Diskussion sind dankenswerter Weise auch einige m.E. valide Punkte aufgetaucht (update sollte via HTTPS statt FTP erfolgen, HTTPS host name Verifikation sollte an sein, Shell execution mit Parametern sollte geschützt sein). Ja, das baue ich natürlich ein, bzw. ändere das.
Gestern habe ich noch geschaut, wie News über den LBC auf Vietnamesischen und chinesischen Seiten aufgetaucht sind, klar dass sich damit 100x mehr Leute beschäftigt haben als bisher. Ich bin durchaus für konstruktive Kritik was die Sicherheit des LBC anbelangt - mit irgendwas um die 200 clients wird das ja auch zu einer waschechten Verantwortung, aber heute ist mir der Begriff "skandalisierende Aufmerksamkeitshure" mehr als einmal in den Sinn gekommen.
Also so in etwa. Ich spiele momentan mail Ping-Pong mit ca. 100 Leuten, darunter auch einige Autoren, die neulich erst Artikel über den LBC geschrieben haben und jetzt wissen wollen was Sache ist. Wenn Fragen sind, antworte ich gerne, wenn's länger dauert: nicht weil ich mich drücke, sondern weil ich nur eine Tastatur habe.
Rico
