Hackerangriff

Artikel:

cache.php.suspected_

Um Angriffe auf den eigenen Server zu erkennen bzw. um als Hoster Angriffe auf Webseiten und Server der Kunden rechtzeitig zu erkennen werden u.a. regelmäßig Scans auf verdächtige Dateien durchgeführt. Diese erhalten, je nach Programm eine "potientell gefährlich"-Endung angehängt, u.a. wird suspected_ verwendet.

Soweit so gut, das zusätzliche Plus an Sicherheit ist aber schnell vertan, wenn man sich alleine auf den Scan verläßt. Je nach Anbieter gibt es auch Servicleistungen zu kaufen, bei denen im Falle eines Verdachtes weitere Prüfungen erfolgen und die Gefahr durch den Service behoben wird. Diese zusätzliche Sicherheit hat aber auch ihren Preis.

Wer seinen Server selbst administriert sollte bei jeden Verdacht sofort handeln.

Dass es keine gute Idee ist solche provisorisch geschützten Dateien auf dem Server zu lassen, habe ich festgestellt, als ich in den Serverlogs zahlreiche Versuche gefunden habe, eben solche Dateien aufzurufen.

Dateien mit der Endung "suspected_" werden von PHP nicht ausgeführt, sondern im Klartext angezeigt. Dies bedeutet allerdings, dass PHP-Dateien, die Zugangsdaten enthalten im Falle eines Falles ebenso im Klartext angezeigt würden!

weiterlesen ...

Artikel:

configuration.php.swp

Einige Editoren erstellen BackUp-Dateien von den PHP-Dateien, wenn diese geändert werden. Dabei wird an die PHP-Datei die "BackUp"-Endung angehängt.

Dies ist eine feine Sache, wenn man sich total vertan hat. Aber eine echte Versionsverwaltung durch das Betriebsystem wäre schön gewesen, aber der Versuch das beste aus den Betriebsystemen VMS, Unix und Windows im Betriebssystem WindowsNT zu vereinen ist leider gescheitert. In VMS war die Versionsverwaltung im Betriebsystem integriert und hat super funktioniert. Mit dem Befehl Purge konnte alle alten Versionen gelöscht werden. Dabei war auch die Vorgabe von Parametern, wie letzte 5 Versionen behalten und die Vorgabe von Dateien, Verzeichnissen oder Mustern möglich. Okay, die Chance wurde vertan.

Wenn nun der Editor solche Sicherungskopien anlegt, dann sollte bei der anschließenden Synchronisation mit dem Webspace auf jeden Fall vermieden werden, dass diese Dateien auf den Server gelangen.

Eine Datei: configuration.php.swp wird nämlich im Klartext angezeigt. Da diese Datei wichtige Daten und Passwörter enthält ist dies eine gefährliche Sicherheitslücke!

Die Gefahr ist auch tatsächlich vorhanden. Obwohl ich keine solche Dateien auf dem Server habe, wurde gerade versucht eben diese configuration.php.swp aufzurufen.

Die Datei ist nicht vorhanden, es wird ein 404er Fehler ausgegeben. Alles gut, sollte man meinen. Aber nein, der Versuch Sicherungsdateien auszuspähen bezieht sich nicht nur auf Sicherungskopien von Editoren.

weiterlesen ...

Artikel:

Hackerangriff auf Kunena

Kunena ist eine gute und beliebte Forum-Erweiterung für Joomla.

Im Juni 2014 wurde leider eine Sicherheitslücke entdeckt, die aber sehr schnell über das zur Verfügung gestellte Sicherheits-Update (v. 3.0.6) geschlossen werden konnte.

Obwohl dies nun schon 3 Jahre her ist, wird immer noch versucht diese Sicherheitslücke auszunutzen. Vor dem Update gab es 2 Schwachstellen: XSS und SQL-Injection.

z.B.
/?beforeafter=before&catids=4&change_css=green&childforums=1
&exactname=1&func=1&itemid=55&lang=en&limit=5
&option=com_kunena&order=inc&q=1
&searchdate=lastvisit&searchuser=wxhoktyl&sortby=title

Gefunden wurde der Angriff in den Server-Logs der Matheburg. Eine Homepage in Joomla, auf der nie ein Forum installiert war! Damit führt der Aufruf nur zu einem 404er Fehler. Bei einer vergessenen Seite oder Testseite ohne Verzeichnisschutz, auf der noch ein altes Forum vor sich hindümpelt ...

Bei der Analyse gehackter Server taucht immer wieder die Frage auf, wie konnte das passieren? Bei allen mir bekannten Fälle bei denen eine Webseite mit Joomla gehackt wurde, waren Sicherheitsupdates nur sporadisch oder gar nicht installiert worden.

weiterlesen ...

^