Sicherheitslücke Joomla?

**evil_bert** · 14.05.2008 10:59

Hallo ich habe aktuell ein Sicherheitsproblem mit einer Seite.

Hier die mail, die ich an den Hoster geschickt habe:

Sehr geehrtes All-Inkl Team,

wir betreiben bei ihnen die Domain
www.bvb-fanclub-ahaus.de. Als Basis für unsere Webseite
verwenden wir Joomla 1.0.15. Eigentlich hat bisher alles soweit super
funktioniert, bis Sonntag Abend einige unserer Dateien von einem Trojaner/Virus
befallen wurden. Bzw. es wurde in viele PHP Dateien ein Iframe eingebaut der auf
einen solchen weiterleitet. Nach einiger Arbeit habe ich diesen Code jetzt
wieder aus den Dateien entfernt und es erscheint auch keine Viruswarnung mehr.

Befallen waren nur die Dateien, bei denen ich öffentliche Schreibrechte aktiviert
hatte. Dies habe ich jetzt wieder standardmäßig auf 755/644 geändert, damit ein
solcher Angriff nicht noch einmal passiert. Normalerweise setze ich die Rechte
auch nicht auf 777/666, aber damit ich unsere Joomla Installation überhaupt vom
Backend aus einstellen/ändern konnte war dies bei vielen Dateien notwendig.
Ansonsten steht im Backend von Joomla bei jeder Datei (z.B. configuration.php)
"unwritable", was nicht gerade im Sinne einer dynamischen Webseite ist, wenn
nichts geändert werden kann.

Nebenbei arbeite ich noch mit einigen weiteren Joomla Installation, bei denen
überall die Standardrechte zur Bearbeitung der Einstellungen reichen. Deswegen möchte
ich nachfragen, wie ich dies nun auch auf Ihrem Server hinbekomme, meine
Joomla-Einstellungen zu ?ern, ohne wieder durch öffenttliche Schreibrechte einen
weiteren Befall zu provozieren. Ich wäre Ihnen sehr dankbar für eine schnelle
Antwort.

MfG

Dominik Niehaus

Die Antwort:

Hallo,

dies ist etwas kompliziert. Aktuell ist so, dass alle Dateien/Verzeichnisse
welche von Joomla beschrieben werden sollen, die Rechte 666/777 haben müssen,
da php als Apache-Modul läuft und somit unter dem User wwwrun, welcher nicht
Ihrem FTP-User entspricht (deshalb die höheren Rechte).

Man kann php auch im cgi-Mode laufen lassen, dann ist der User welcher die
Dateien/Verzeichnisse beschreibt (als das Joomla) auch gleichzeitig Ihr
FTP-User und kommt mit den Rechten 644/755 aus.

Das behebt aber das Problem der Sicherheitslücke nicht, wodurch die Dateien
manipuliert wurden. Im Gegenteil nun kann der Angreifer sämtliche Dateien
beschrieben/ändern und nicht nur die, welche die Rechte 666 haben. In dem Fall
ist also mit noch größerem Schaden zu rechnen. Davon mal abgesehen ist aus
Performancegründen vom cgi-Mode abzuraten.

Da die Angriffe durch ausnutzen von Sicherheitslücken in der Software zu Stande
kommen, sollten Sie also die Einstellungen so lassen, jedoch nach
Sicherheitsupdates von Joomla und den entsprechend eingesetzten Komponenten und
Modulen ausschau halten.

Meine Frage an euch lautet jetzt, welche Maßnahmen bzw. Komponenten/Module es gibt, damit ich einen Angriff der meine PHP Dateien manipuliert zukünftig vermeiden kann. Habe bisher noch nichts gefunden.

Gruß

Dominik

**Furyk** · 14.05.2008 11:23

such hier und/oder im web mal nach den schlagworten joomla security audit. da findest du einiges zum nachlesen, verweist aber teilweise noch auf ältere joomla-versionen. mir fehlt jetzt leider die zeit zum recherchieren.

**holmi** · 14.05.2008 11:27

Ist in der Logdatei zu erkennen wir Gehackt wurde?
Welche Erweiterungen sind in welcher Version installiert?

Björn

**evil_bert** · 14.05.2008 11:37

Die Logs sind weg, da ich alles gelöscht hab und das Backup eingespielt hab. War dumm, ich weiß, aber ich wollte erstma alles löschen, da ich nich 100% wusste wie viele Dateien befallen sind.

Folgende Erweiterungen sind installiert:
extplorer RC2
Joomleague 0.92
Ponygallery 2.5.0 (war installiert zu dem Zeitpunkt)
PollXT 1.23.06
Easybook 1.1
XHTML Suite 1.5

**j!-n** · 14.05.2008 11:56

Ohne die Lücke ausfindig gemacht und beseitigt zu haben, wirst Du wieder gehackt werden, das ist nur eine Frage der Zeit. Wenn sich seit Deinem Backup nichts an der Installation geändert hat, ist die Lücke vermutlich auch im Backup vorhanden. So mir nichts Dir nichts kann man eine auf 777 gestellte index nicht manipulieren. Desweiteren sind nicht alle Vulnerables in Extensions bekannt und dokumentiert, weshalb die Listen unsicherer Extensions nicht vollständig sein können. Trotzdem findest Du ein paar grundlegende Tips in den Stickies dieses Forums. Viel Glück.

**evil_bert** · 14.05.2008 13:17

Danke schon mal für eure Antworten. Ist mir schon klar dass die Lücke auch wohl schon im Backup ist, aber besser ein Backup mit Sicherheitslücke als eine virenbefallene Seite ohne Backup. Ich werde mich dann mal weiter umschauen, wie ich sowas zukünftig vermeiden kann. Für weitere Tipps wär ich euch dennoch sehr dankbar.

**Rooney** · 14.05.2008 14:17

Zitat von evil_bert

Meine Frage an euch lautet jetzt, welche Maßnahmen bzw. Komponenten/Module es gibt, damit ich einen Angriff der meine PHP Dateien manipuliert zukünftig vermeiden kann. Habe bisher noch nichts gefunden.

Keine Kompromisse mit Hostern eingehen. wwwrun ist ein Kompromiss, der einfach nur nervt, und dann vergisst man wie Du, Rechte wieder zurückzusetzen!

Ausserdem System und Komponenten aktuell halten.

Rooney

**flotte** · 14.05.2008 15:01

Um mal was klarzustellen:
Die Dateirechte alleine sind nicht der Grund für einen erfolgreichen Hack! Der Angreifer muss schon in der Lage sein, auf dem Server Scripte auszuführen. Er benötigt also eine ganz andere Lücken, über die er zunächst einmal einbricht. Diese Lücken sind fast immer unsichere Komponenten.
Die Antwort von All-Inkl (siehe 1. Postings) ist blanker Unsinn!
Dort wird behauptet, das das Betreiben von PHP als Modul und den sich daraus resulierenen Rechten einen Zustand ergeben, der sicherer sein soll, als wenn man das PHP als CGI betreibt:

...Man kann php auch im cgi-Mode laufen lassen, dann ist der User welcher die
Dateien/Verzeichnisse beschreibt (als das Joomla) auch gleichzeitig Ihr
FTP-User und kommt mit den Rechten 644/755 aus.

Das behebt aber das Problem der Sicherheitslücke nicht, wodurch die Dateien
manipuliert wurden. Im Gegenteil nun kann der Angreifer sämtliche Dateien
beschrieben/ändern und nicht nur die, welche die Rechte 666 haben. In dem Fall
ist also mit noch größerem Schaden zu rechnen.....

Eine solche Aussage kann man nicht im Raum stehen lassen!!

Wenn ein Angreifer bereits Scripte ausfühern kann ist eh alles zu spät! Es spielt in diesem Moment nur eine untergeordnete Rolle, ob er alle oder nur einen Teil der Dateien bearbeiten kann!
Beim Setzen unsicherer Rechte und der gleichzeitigen Benutzung eines globalen Users wie "wwwrun" etc. geht man das Risiko ein auch von Angreifern manipuliert zu werden, die auf einem Nachbaraccount erfolgreich gehackt haben. Bei teilweise mehreren hundert Kunden auf einer Maschine wird schnell klar, das das daraus resultierende Risiko immens ist und (fatal!) man selbst nicht die Sicherheit anderer Auftritte beinflussen kann.
Es ist also extrem wichtig, das Kundenwebs gegeneinander abgeschottet werden. Genau das ist Aufgabe des Hosters, denn Kunden selbst haben hier quasi keine Möglichkeiten.

PHP bietet hier lediglich den open_basedir-Mechanismuss, um Kunden gegenseitig abzuschotten. Wie leicht dieser Mechanismus umgangen werden kann, möchte ich hier nicht schildern.
Mit PHP als CGI (wenn richtig konfiguriert) werden elementare Mechnismen der Schutzfunktionen der Benutzerrechte eines Linux-Betriebssystems genutzt - also PHP-unabhängig! Das zu knacken ist schon eine ganz andere Fragestellung.
Das schützt natürlich nicht vor Angreifern die unsichere Scripte ausnutzen! Aber es schützt deutlich effektiver davor, das solche Angreifer auch Nachbarwebs beschädigen.

PHP als CGI ist also quasi immer sicherer als PHP als Modul!
Nebenefffekte wie Performanceeinbussen spürt am ehesten der Hoster am Umsatz, weil er weniger Kunden je Maschine hosten kann oder er deutlich leistungsfähigere (und damit deutlich! teurere) Server braucht. Er muss also anders kalkulieren und kann nicht im Dumping-Strom mitschwimmen. Die reinen Scriptausführungszeiten sind nicht spürbar unterschiedlich.

**SirDrake** · 14.05.2008 18:06

Die Logs sind weg, da ich alles gelöscht hab

bei all-inkl hat man doch noch die Hosterlogs und die kann man nicht löschen. (bei Webspace Paketen)
Die Log-Dateien liegen im Ordner logs als zip Dateien für ftp und html

Thema: Sicherheitslücke Joomla?

LinkBack

Themen-Optionen

Thema durchsuchen

Anzeige

Sicherheitslücke Joomla?

Erhielt Danksagungen von:

Erhielt Danksagungen von:

Lesezeichen

Lesezeichen

Berechtigungen