ISPConfig 3 Server gehackt ... "Hacked By Tunisian Fallaga Team"

#1
Leider wurde wieder einmal ein Server von uns gehackt :-/.

Diesmal haben die es geschafft über ein ungepatchtes Drupal Kundenweb nicht nur die dieses sondern auch andere Webs zu infizieren.
Dabei haben sie ihr eigenes phpMyAdmin und eine Wordpress Version mit eigenen islamistischen Inhalt plaziert.

Hat jemand erfahren welche Sicherheitslücke von diesen Leuten ausgenutzt wurde und wie diese zu schließen wäre.
ISPC3 sowie CentOS 6 sind am letzten Stand. SuEXEC ist aktiv bei allen Webs sowie Fast-CGI wobei der Kunde mit Zugriff auf die Webkonfiguration natürlich die Einstellungen verändern hätte können.

Ich bekomme langsam den Eindruck ISPC3 in der Standartinstallation ist nicht sehr sicher.
Es wäre toll wenn es eine eigene Sektion zum Sichern der Server geben würde welche in Verbindung mit ISPC3 auch Sinn macht.

Danke für eure Tipps vorab
 
#3
Im Zip die Dateien mit welchen der Hack durchgeführt wurde ...
Achtung Antivirus unter Windows schlägt natürlich an ... Clam AV nicht ;-)
Vielleicht kann sich ein Spezialist mal diese Dateien ansehen ;-)
 

Anhänge

Till

Administrator
#4
Soweit ich sehe wurde nicht ISPConfig gehacked sondern Drupal bzw. Wordpress, Dein Problem hat also nichts mit der Verwendung von ISPConfig zu tun und es wurde auch nicht der Server gehacked da ISPConfig die Webseiten durch unterschiedliche User absichert sondern es wurden nur Dateien in einer Webseite, bedingt durch eine Sicherheitslücke im jeweiligen cms bzw. geändert. Der Thread Titel ist irreführend da weder ISPConfig noch der Server gehacked wurden sondern lediglich Drupal bzw. Wordpress.

Wie sichere ich CMS Syteme auf einem Server (egal welches CP oder kein CP):

1) Immer aktuelle Updates der CMS einspielen und aller Plugins der CMS einspielen.
2) Wenn PHP Funktionen zum ausführen von scripten (exec, passthrus, popen etc.) nicht gebraucht werden, dann sollten diese für die jeweilige Website deaktiviert werden. Unter Debian und Ubuntu kann man solwas auch global für cgi und apache2 machen, centOS unterscheidet da leider nicht und daher ist eine globale Änderung unter CentOS nicht zu empfehlen da ansonsten auch shellscripte die PHP verwenden nicht mehr gehen.
3) Den Server täglich auf malware scannen, siehe auch https://www.howtoforge.de/forum/threads/wordpress-hack.9427/
4) Man kann zusätzlich auch apache Module wie mod_security installieren, da wirst Du aber anfangs eine menge fehlalarme haben die Du dann whitelisten musst.


wobei der Kunde mit Zugriff auf die Webkonfiguration natürlich die Einstellungen verändern hätte können.
Nein, das kann er nicht. Wenn eine Webseite durch den admin für den Kunden angelegt wurde dann kann ein kunde diese Einstellungen zwar sehen, er kann sie aber nicht ändern.
 

Till

Administrator
#6
In Deinen Screenshots war kein leeres Web dabei sondern 2x Wordpress. Welchem Linux User gehören die Dateien (ls -la ausgabe im web verzeichnis) die in das leere Web geschrieben wurden und welche sind das genau?
 

Till

Administrator
#9
Daher nutzen auch ale größeren Provider automoatische malware scan scripte, siehe meinen post obpen, und deaktivieren das kundenweb bei malware befall und schalten es erst wieder frei wenn der kunde die malware entfernt hat und seine seite aktualisiert.

Unmöglich, wir können nicht jeden Kunden fragen was er braucht und was nicht
Und jetzt weißt Du warum ispconfig es nicht global deaktivieren kann, wenn Du es noch nicht mal pro Webeite machen willst ;)
 

Till

Administrator
#10
Richtig, ein normler WP hack wie ers ständig irgendwo passiert wenn jemand wordpress nicht aktuell hält oder unsichere Plugins installiert. Solange Du einem Kunden zugriff auf eine webseite gibts kann sowas vorkommen, daher scanned man ja auch regelmäßig nach malware und warnt bzw. sperrt den Kunden, wenn was gefunden wurde.

Poste doch bitte mal das ls -la aus dem ehemals leeren web wo ausschließlich der hacker Dateien hoehgeladen haben soll.
 
#11
Zu Bild 1:
[root@srv05 web]# ls -la
insgesamt 244
drwx--x--- 7 web103 client32 4096 3. Jan 03:16 .
drwxr-xr-x 9 root root 4096 13. Aug 2013 ..
drwxr-xr-x 2 web103 client32 4096 13. Aug 2013 error
-rwxr-xr-- 1 web103 client32 7358 13. Aug 2013 favicon.ico
-rwxr-xr-- 1 web103 client32 62 16. Dez 12:31 .htaccess
-rw-r--r-- 1 web103 client32 27527 3. Jan 03:16 index.html
-rw-r--r-- 1 web103 client32 19930 21. Apr 2015 license.txt
-rw-r--r-- 1 web103 client32 8661 16. Dez 12:39 liesmich.html
-rw-r--r-- 1 web103 client32 7358 16. Dez 12:39 readme.html
-rwxr-xr-- 1 web103 client32 14 13. Aug 2013 robots.txt
drwxr-xr-x 2 web103 client32 4096 5. Jan 00:30 stats
-rw-r--r-- 1 web103 client32 5035 16. Dez 12:39 wp-activate.php
drwxr-xr-x 9 web103 client32 4096 13. Aug 2013 wp-admin
-rw-r--r-- 1 web103 client32 271 30. Okt 2013 wp-blog-header.php
-rw-r--r-- 1 web103 client32 1369 16. Dez 12:39 wp-comments-post.php
-rw-r--r-- 1 web103 client32 3564 13. Aug 2013 wp-config.php
-rw-r--r-- 1 web103 client32 3650 1. Nov 19:11 wp-config-sample.php
drwxr-xr-x 7 web103 client32 4096 4. Jan 08:34 wp-content
-rw-r--r-- 1 web103 client32 3286 1. Nov 19:11 wp-cron.php
drwxr-xr-x 16 web103 client32 4096 16. Dez 12:39 wp-includes
-rw-r--r-- 1 web103 client32 2380 30. Okt 2013 wp-links-opml.php
-rw-r--r-- 1 web103 client32 3316 16. Dez 12:39 wp-load.php
-rw-r--r-- 1 web103 client32 33710 16. Dez 12:39 wp-login.php
-rw-r--r-- 1 web103 client32 7887 16. Dez 12:39 wp-mail.php
-rw-r--r-- 1 web103 client32 13021 16. Dez 12:39 wp-settings.php
-rw-r--r-- 1 web103 client32 28594 16. Dez 12:39 wp-signup.php
-rw-r--r-- 1 web103 client32 4035 1. Nov 19:11 wp-trackback.php
-rw-r--r-- 1 web103 client32 3061 16. Dez 12:39 xmlrpc.php
[root@srv05 web]#
 
#12
Zu Bild 2:
[root@srv05 web]# ls -la
insgesamt 236
drwx--x--x 9 web62 client22 4096 3. Jan 03:19 .
drwxr-xr-x 9 root root 4096 20. Mär 2014 ..
drwxr-xr-x 3 web62 client22 4096 19. Mär 2012 aspnet_client
drwxr-xr-x 2 web62 client22 4096 27. Sep 2014 error
-rw-r--r-- 1 web62 client22 372 22. Sep 2014 .htaccess
-rw-r--r-- 1 web62 client22 311 22. Jul 2014 .htaccess_orig
-rw-r--r-- 1 web62 client22 27527 3. Jan 03:19 index.html
drwxr-xr-x 2 web62 client22 12288 5. Jan 00:30 stats
-rw-r--r-- 1 web62 client22 4951 8. Sep 2014 wp-activate.php
drwxr-xr-x 10 web62 client22 4096 10. Sep 2014 wp-admin
-rw-r--r-- 1 web62 client22 271 3. Jul 2014 wp-blog-header.php
-rw-r--r-- 1 web62 client22 4946 8. Sep 2014 wp-comments-post.php
-rw-r--r-- 1 web62 client22 4038 22. Sep 2014 wp-config.php
-rw-r--r-- 1 web62 client22 18969 16. Dez 03:33 wp-config-post.php
-rw-r--r-- 1 web62 client22 3396 8. Sep 2014 wp-config-sample.php
drwxr-xr-x 9 web62 client22 4096 3. Jan 03:19 wp-content
-rw-r--r-- 1 web62 client22 2956 8. Sep 2014 wp-cron.php
drwxr-xr-x 12 web62 client22 4096 19. Okt 08:00 wp-includes
-rw-r--r-- 1 web62 client22 2380 3. Jul 2014 wp-links-opml.php
-rw-r--r-- 1 web62 client22 2714 8. Sep 2014 wp-load.php
-rw-r--r-- 1 web62 client22 33043 8. Sep 2014 wp-login.php
-rw-r--r-- 1 web62 client22 8252 8. Sep 2014 wp-mail.php
-rw-r--r-- 1 web62 client22 11160 8. Sep 2014 wp-settings.php
-rw-r--r-- 1 web62 client22 26256 8. Sep 2014 wp-signup.php
-rw-r--r-- 1 web62 client22 4026 3. Jul 2014 wp-trackback.php
drwxr-xr-x 8 web62 client22 4096 3. Jul 2014 ww-phpMyAdmin-4.0.10-english
-rw-r--r-- 1 web62 client22 3032 3. Jul 2014 xmlrpc.php
[root@srv05 web]#
 

Till

Administrator
#14
Das ist ein Wordpress und kein leeres Web. Ich bezweifle stark dass ein Hacker Dir ein Wordpress installieren wird und dann noch mit dem richtigen Linux User des webs. Es gibt also 3 Möglichkeiten:

1) Der Kunde hat ein Wordpress hoch geladen und dies wurde gehacked.
2) Der Kunde hat den APS Installer in ISPConfig genutzt um ein Wordpress zu installieren und dieses wurde später gehacked.
3) Wenn Du meinst dass der Hacker wirklich ein Wordpress selbst installiert haben soll dann müsste er zumindest das FTP Passwort des Webs haben, denn die Dateien gehören dem richtigen User des Webs und nicht ISPConfig.

ISPConfig läuft unter dem user "ispconfig", der hat aber weder Schreibrechte auf das web noch gehören die von Dir gezeigten Dateien dem user ispconfig, wenn also ispconfig wie von Dir behauptet gehacked worden wäre dann würden die Dateien entweder ispconfg gehören und für den noch unwahrscheinlicheren Fall das ein Hacker tatsächlich das ispconfig Interface und den root prozess gekapert hätte dann wäre er bereits root und hätte Dich schon lange ausgesperrt, dann macht er sich mit Sicherheit nicht die Mühe irgend ein Kundenweb zu ändern und dort Wordpress zu installieren.
 

nowayback

Well-Known Member
#18
Ja, denke ich auch, nur so viele Webs gleichzeitig auf diesem Server haben mich doch etwas überrascht ;-)
wenn alle die gleiche Lücke haben, ist das nicht verwunderlich. Gerade in Bezug auf Drupal muss man sich doch nur mal die News der letzten 2-3 Wochen angucken. Da kamen doch, wenn ich mich nicht irre, 2 kritische Updates raus. Wer da nicht aktuell ist, ist eben schnell ein Opfer.
 

Werbung

Top