Internet MyBB-Downloads waren infiziert

Die Download-Pakete von MyBB 1.6.4 waren auf dem Server kompromittiert, bestätigen die Entwickler in einem Blog-Posting. Unbekannten Angreifern war es über eine Schwachstelle des Content Management Systems (CMS) für die MyBB-Homepage gelungen, PHP-Code einzuschleusen und auszuführen.
Damit stellten sie offenbar eine trojanisierte Version der MyBB-Software auf den Server, die eine Hintertür enthielt. Wann das genau geschah, ist nicht klar. Somit sind potentiell alle 1.6.4er-Versionen betroffen, die vor dem 6. Oktober heruntergeladen wurden. Jeder Betreiber eines MyBB-Systems sollte deshalb unverzüglich seine installierte Version checken. Zur schnellen Säuberung empfehlen die Entwickler, die Datei /index.php durch eine aus einem sauberen Download zu ersetzen und das Verzeichnis /install/ zu löschen.
Die MyBB-Entwickler diskutieren derzeit, welche Konsequenzen sie aus dem Einbruch ziehen müssen. Sie wollen unter anderem "Prüfsummen" veröffentlichen, mit denen man die Echtheit der Downloads testen kann. Das ist allerdings nicht sonderlich effizient, wenn die Angreifer den Server kontrollieren, auf dem auch die Prüfsummen hinterlegt sind. Besser geeignet wären digitale Signaturen, die sich ohne den geheimen Schlüssel nicht fälschen lassen. Der Nachteil: Digitale Signaturen für Software-Pakete prüft kaum jemand, solange es nicht ein Update-Mechanismus automatisch erledigt. (ju)

Quelle:
heise online - MyBB-Downloads waren infiziert

Was denkt Ihr darüber? Ich finde es schon erschreckend das die Entwickler wohl kein Augenmark auf dne Sicherheitsaspekt des eigenen Servers gelegt haben. Man stelle sich vor sowas würde bei vbulettin phpbb etc passieren.
 
Es ist kein Einzelfall (wobei ich die Säuberungstipps der Entwickler in diesem Fall etwas ... dürftig finde :rolleyes: ) und auf jeden Fall nichts neues:

~/Blog: Linux .. Infected
(oder etwas seriöser:
IRC-Server seit Monaten mit Backdoor [Update] | heise Security )
'Allegations regarding OpenBSD IPSEC' - MARC

Thwarted Linux backdoor hints at smarter hacks
Interessant ist in dem Zusammenhang
The Underhanded C Contest
Es geht darum, ein "sinnvolles" Programm zu schreiben, welches versteckte, böse Funktionen enthält UND einer Codereview standhält. Der "Gewinner":
Not A Number - Underhanded C: The Leaky Redaction

Opensource ist kein Allheilmittel gegen Sicherheitslücken.
Besonders bei größeren Projekten (auch wenn die Entwickler selbst keine "bösen" Absichten haben) kann jemand z.B paar hundert oder tausend Zeilen Code beitragen und irgendwo mit wenigen Zeilen seine backdoor Funktion verstecken.

Man könnte jetzt auch schreiben: C und PHP sind böse, weil diese zu viele Freiheiten bieten. Das würden auch einige als Grund zu einem Flamewar sehen ;). Aber was wären richtig praktikabele Lösungen? Theoretisch könnte man formelle Softwareprüfung nehmen (Isabelle, B/EventB etc), Code größtenteils nur generieren lassen und allgemein eine sichere Sprache "erfinden"/nutzen. Rein praktisch wäre der Aufwand sogar für kleinere Projekte immens. Alleine Umsetzung/Übersetzung in ein Modell, Beweis der Korrektheit des Modells, der Refinements bis hin zum Code, der Korrektheit des Compilers (Grüße an C und vor allem C++ Anhänger - gibt es schon einen Compiler, der wenigstens c99 Standard komplett unterstützt? ;) ).
Irgendwas ist halt immer.
 
Man könnte jetzt auch schreiben: C und PHP sind böse, weil diese zu viele Freiheiten bieten.
Das analysierst du falsch.
1. PHP ist an sich ne reine Backdoor.
2. Es liegt nicht an C, sondern an OpenSource. Ich mein, was kann C dafür, dass diese langhaarigen Typen mit Piguinfetisch diese schöne Sprache dermaßen missbrauchen ;)
 
Nein du siehst dies falsch.
PHP wurde hauptsächlich dazu entwickelt um Informationen, die auf einem entfernten
Rechner gespeichert sind dynamisch aufzubereiten und abrufen zu können.
Dies ist kein "Backdoor", das ist die "Frontdoor". :wink:

Auch bei c sind es nicht die Pinguinfetischsten gewesen, sondern die Anzugträger aus der MS-Ecke
die aus dem Internet einen Marktplatz gemacht haben, auf dem sich jetzt die Taschendiebe
und Halsabschneider breit gemacht haben. :p

Gruss :D
 
Linux: Kernel "Back Door" Attempt | KernelTrap
Code:
+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+                       retval = -EINVAL;
Der Unterschied ist also nur ein "=".
Und hier kann man die Absicht sehr glaubhaft abstreiten,
da es ein verbreitetes Typo sein sollte ;).

Ich denke auch an solche lustigen Sachen wie
Code:
 *(data_ptr + i) vs (*data_ptr + i)
bzw. noch subtiler (data is vom Typ void*, i ist ein int)
(*(unsigned char*)data+i)) vs *((unsigned char*)data+i))

Und sowas passiert, wenn Leute ohne spezifische Kenntnisse am Code arbeiten:
Es war (angeblich ;) ) auch keine Absicht:
[pkg-openssl] Diff of /openssl/trunk/rand/md_rand.c
Das Ergebniss - 2 Jahre lang schwache SSH/VPN usw. Keys: Schwache Krypto-Schlüssel unter Debian, Ubuntu und Co. | heise Security
 
Es gab in Linux auch mal eine Backdoor, die über Jahre hinweg eingeschleust wurde. Das Zusammenspiel vieler kleiner Code-Fragmente, die in durchaus sinnvollem Code eingebettet wurden, ergab die eigentliche Backdoor. Man sieht also, dass selbst Code-Analysen nichts bringen, wenn nicht vor jedem Build der komplette Code analysiert wird. Und wer will sowas bei einem riesigen Projekt wie einem Kernel schon tun und gewährleisten?
 
selbst das bringt nichts ... man kann sich nicht dagegen schützen, dass ein stück code, von dem man annimmt, dass es ein problem löst, ein ganz anderes problem löst ...

gezielt platzierte funktionalitäten, liegen nicht immer auf code ebene vor ...

im zweifel bringt dir selbst ein komplettes code review nichts ... The Underhanded C Contest
 
Zurück
Oben