Wir wollen heute mal über die schwarze Seite des Hostings sprechen, weil dies zwar nicht oft, aber immer wieder vorkommt. Der vom Kunden gemietete Webspace wird von irgendwelchen Hackern verändert und Schadsoftware wird eingespielt.

Schadsoftware verursacht dabei immer häufiger, extrem hohen wirtschaftlichen Schaden und dabei werden immer perfidere Methode eingesetzt

um diese Schadsoftware zu verstecken!

Früher waren Webspaces viel sicherer!

Früher wurden in Webspaces ausschließlich HTML-Dateien eingespielt und an Seitenabrufer ohne jegliche Auswertung und Veränderung, einfach an deren Computer übertragen und dort angezeigt. Es gab schon diverse Scriptsprachen, die auch z.B. von größeren Firmen eingesetzt wurden, wie ASP, Perl und dann später auch php. Normale Endanwender profitierten damals jedoch nicht davon, auch php-Programme laufen lassen zu können oder es war entsprechend teuer.

CMS-Systeme und Kunden können ohne Vorkenntnisse diese Systeme erweitern:

Heute wird fast jede Webpräsenz unter Verwendung von PHP-Scripten für den Abruf bereit gestellt. Die PHP-Scripte sind heute so mächtig und bieten bereits mehr Möglichkeiten, als dies in herkömmlichen Programmen, die aufwendig geschrieben und dann kompeliert werden mußten, je der Fall war. Außerdem werden immer häufiger von Kunden fertige Scripte, wie CMS-Systeme verwendet, um z.B. Webseiten einfach und schnell zu gestalten und jederzeit zu erweitern.

CMS-Systeme wie Joomla, WordPress und viele viele mehr, können dann auch noch erweitert werden, um sogenannte Plugins oder Extensions. Auch diese Erweiterungen sind wieder reine PHP-Scripte, die dann automatisiert HTML-Seiten oder Javascripte etc. erzeugen. Wird vom Seitenabrufer ein php-Script aufgerufen, meist erfolgt dies verdeckt durch rewrite-Techniken (mod_rewrite), wird dieses Script im Server des Webspaces abgearbeitet und als Ausgabe wird dann eine HTML-Seite ausgegeben. Diese Scripte können aber auch z.B. Dateien auf dem Dateisystem des Webspace schreiben, lesen, verändern oder Daten aus einer Datenbank, wie MySQL lesen und auch schreiben.

Das Schreiben von Dateien wurde bei den ersten CMS-Systemen so gut wie gar nicht eingesetzt, bis dann die Entwickler dieser CMS-Systeme alles immer einfacher gemacht haben. Heute kann ein Anwender, ohne daß er Kenntnisse von FTP (File-Transfer-Protokoll) hat, sein eingesetztes CMS-System um Plugins erweitern, wobei dann im Administrationsbereich, innerhalb des CMS-Systemes, auf einen Hinzufügen Button geklickt wird und dann das Plugin in einen Upload-Folder hochgeladen und dort vom PHP-Script automatisch ausgepackt und anschließend in das sonstige CMS-System einkopiert wird. Die Plugins werden auch immer größer und weniger kontrollierbar, was wir daran merken, daß dann Kunden darum bitten, z.B. die Upload-Grenze für Dateien von ehemals 2 MB auf 64 MB zu erhöhen und ja, sogar Anforderungen von 500 MB sind schon bei uns eingetrudelt! Wohl angemerkt, via Upload-Funktion über PHP!

Arbeitsweise des herkömmlichen FTP-Uploads zu Upload via PHP:

Das Aufspielen einer Datei via FTP ist grundsätzlich ohne Begrenzung möglich. Hierbei verbraucht der Server keinen Speicher, denn die Dateien  werden sequentiell übertragen und direkt auf die Platte geschrieben. Bei jedem Upload über PHP-Script dagegen, wird eine Datei erst einmal zum Teil im RAM gehalten und dann erst in das Filesystem geschrieben. Ferner sind der Apache-Webserver und der PHP-Parser während dieser Zeit gut ausgelastet. Entsprechend multipliziert sich diese Auslastung um alle Seitenabrufe von ALLEN Webseiten-Abrufern auf dem gesamten Server. Man darf also nicht davon ausgehen, das nur das eine Script auf dem Server etwas erledigt, sondern muß wissen, daß viele Scripte zur gleichen Zeit im Server abgearbeitet werden, daneben auch diverse Web-Seiten ausgegeben werden, Datenbankabfragen abgearbeitet werden, und Mail-Dienste gleichzeitig Mails entgegennehmen, auf Spam und Viren prüfen und in die Posteingangs-Körbe der Kunden verteilen, die dann via POP/IMAP abgerufen werden können und Ausgangs-Post an andere Server weiter versendet werden.

Auf einem Server läuft also nicht nur ein Programm, sondern extrem viele gleichzeitig, die dann auch noch gleichzeitig verschiedene Scripte abarbeiten!

Gepackte Dateien erschweren jeglichen Viren-Scan:

Dateien, die an einen Server übertragen werden, sind zum Teil gepackt (z.B. ZIP, RAR usw). Ein Virenscanner kann eine Datei nur prüfen, wenn er diese erst vollständig entpackt hat. Oft enthalten aber die gepackten Dateien wiederum gepackte Dateien, die ebenfalls wieder entpackt werden müssten, um dann vom Virenscanner überhaupt gescannt zu werden. Auf einem heimischen PC ist dies überhaupt kein Problem, da relativ wenig Anwendungen zur gleichen Zeit laufen und wenn ein User auf seinem PC eine Datei herunterlädt, kann diese ggf. cascadierte gepackte Datei vom Virenscanner ausgepackt und geprüft werden. Das benötigt natürlich Rechenkapazität und der Computer wird deutlich langsamer! Auf einem Server, wo gleichzeitig richtig viele Programme ablaufen, würde der Server während dieser Zeit ausgebremst werden, was natürlich überhaupt nicht geht! …. oder der Scan-Prozess müsste so reduziert in der Priorität laufen, daß der Anwender, der die Datei via Upload überträgt, zu lange warten müsste und ggf. wäre dies wieder mit anderen Problemen, wie Speicherplatz-Belastung, CPU-Belastung etc. verbunden.

Zeitverzögerter Scan von allen Dateien auf Viren und Schadsoftware:

Daher erfolgt auf den Webhosting-Servern von 1awww eine zeitlich verschobene Scannung aller Dateien. Im Schnitt wird Schadsoftware vom Server innerhalb von 1 Stunde nach Einspielung erkannt, wobei der Server selbst dabei knapp hunderte von Webspaces scannt und das jeweils von  mehreren Gigabytes! Diese Scannung erfolgt sinnvoll zeitgesteuert in Phasen, in denen der Server nicht hoch ausgelastet ist, um allen Kunden eine schnelle und optimale Seitenausgabe von Webseiten (ja und daß ist eigentlich nur die Hauptaufgabe eines Webservers), zu gewährleisten, denn ein Webserver sollte sich eigentlich nicht darum kümmern müssen, was auf ihm für Dateien gespeichert wurden, sondern sollte eigentlich nur extrem schnell die HTML-Dateien an die Seitenabrufer ausgeben – aber heute ist daß alles anders!

Hacker meinen es mit Webseiten-Inhabern überhaupt nicht gut:

Hacker meinen es überhaupt nicht gut mit unseren Kunden und uns, als Webhoster! Aber jeder Webhoster hat mit den gleichen Problemen zu kämpfen. Die Angriffe auf Server erfolgen dabei aus aller Welt, selbst auch von Europa aus und es werden auch immer neue Techniken verwendet, um dieses Hacking zu betreiben. Gerne erfolgen dabei Angriffswellen, die die Server so stark belasten, daß diese überlastet werden und dann nicht mehr rechtzeitig ihre Arbeit leisten können und damit abstürzen oder ggf. Angriffe durch lassen. Dabei werden gezielt Schwachstellen der Betriebssysteme, wie Unix, Linux, Windows, aber sogar MAC etc. ausgenutzt.

Hackings erfolgen heute im großen Maße auf die, von Kunden eingespielten Programme (PHP-Scripte):

Seit einigen Jahren, erfolgen die Angriffe nicht mehr nur auf das Eindringen über die normalen Transfer-Protokolle, z.B. FTP, Mail, Ping etc, also auf die Betriebssysteme, sondern auf die Anwendungen in den Webspaces, also die Scripte, die Kunden selbst in ihre Webspaces eingespielt haben und die Hersteller dieser Scripte, insbesondere CMS-Systeme begünstigen dies auch noch, indem Sie in den ausgegebenen Webseiten verraten, was für ein CMS eingesetzt wird!

Haben Sie eine Webseite? Rufen Sie diese doch mal auf und lassen Sie sich diese doch mal als HTML-Code anzeigen! Sie stellen sehr wahrscheinlich irgendwo im Kopf fest, daß da z.B. steht Joomla Version 2.8 oder ähnliches!

Hacker scannen Webseiten und suchen gezielt die Schwachstellen, um später in diese Webpräsenzen einbrechen zu können:

Hacker, die nun darauf aus sind, Schaden anzurichten, scannen und speichern dann erst mal nur ab, welches CMS-System in welcher Version für welchen betreffenden Webspace läuft. Da Bugs von allen bekannten Scripten veröffentlicht werden, um Schwachstellen aufzudecken und zu beseitigen, wird auch den Hackern bekannt, wo die Schwachstellen liegen  und dann erfolgt genau auf diese Schwachstellen der Angriff!

Wie geht der eigentliche Angriff nun von statten?

Also der Hacker oder meist sind es sogar organisierte Hacker-Banden, nutzen genau die Sicherheitslücken, indem sie ganz normale HTML-Aufrufe mit Parametern durchführen, wobei aber in den Parametern genau daß übergeben wird, was eigentlich das Script selbst abfangen sollte!

Damit daß verständlich wird, hier ein einfaches Beispiel eines normalen Seiten-Abrufes:

http://www.MeineSeite.de?funktion=anzeigen&bild=meinFoto.jpg

und hier ein simples Beispiel, wie ein Einbruch versucht wird:

http://www.MeineSeite.de?funktion=admin&subfunktion=upload&datei=schadprogramm.php

Ok, dies ist also nur eine total vereinfachte Darstellung. Die Aufrufe sind viel komplizierter gestaltet, so daß diese zu den vom Script annehmenden Parametern passt und eben möglichst so, daß dies nicht so schnell erkannt werden kann.

Ist nun das Script, daß der Kunde und Webseitenbetreiber selbst in seinen Webspace eingespielt hat, nicht korrekt programmiert, nimmt das Script via Upload z.B. die vom Angreifer gewollte zuübertragende Datei schadprogramm.php an und speichert diese im Server!

Was macht ein Hacker mit einer eingespielten Schadsoftware?

Anschließend startet der Angreifer sein von ihm, via dieser Sicherheitslücke übertragenes Script, auf dem Kundenwebspace:

Hier wieder ganz extrem vereinfacht:

http://www.MeineSeite.de?schadprogramm.php&funktion=scam&email=hansotto@seineSeite.de&text=ich+bin+ihre+bank+und+brauche+ihre+pin+nummer

Über solche Schadprogramme werden dann z.B. Kreditkarten-Daten, Pin-Codes, Zugangspasswörter von anderen Personen gescamt (eingesammelt und gespeichert) oder Angriffe auf andere Server-Systeme verursacht. Wurden vor etlichen Jahren nur Sprüche in Webseiten hinterlassen, die noch ganz witzig waren, werden heute im immer größeren Umfang, diese Schadprogramme eingesetzt, um sich zu bereichern oder jede andere denkbare Straftat, bis hin zum Terrorismus, durchzuführen!

Damit diese Schadprogramme nicht sofort erkannt werden, werden diese aber nicht im Klartext lesbar gespeichert, sondern cascadiert verschlüsselt, was den Webserver dabei auch noch entsprechend stark belastet!

Wenn Sie wissen wollen, was sich hinter cascadierter Verschlüsselung  verbirgt, klicken Sie auf den folgenden Link. Der Blog-Beitrag über cascadierte Verschlüsselung, wird in einem neuen Fenster angezeigt, so daß Sie anschließend hier weiter lesen können:

Scam im Kundenwebspace – cascadierte Scripte

Webspace mit Schadsoftware befallen, was ist zu tun?

Oft lese ich noch: Server abschalten, System scannen und dann am besten komplett sichern und neu aufsetzen!

Also wenn ein Kundenwebspace befallen ist, so hat dies normalerweise keine Auswirkung auf andere Kundenwebspaces, außer natürlich, wenn diese Schadsoftware dazu führt, daß der Server ausgelastet und ggf. auch überlastet wird. Andererseits, werden über einen Server und deren IP viele Kundenwebspaces bereit gestellt und Schadsoftware, die einen echten Schaden verursacht, kann auch dazu führen, daß die IP, der Server, der Host, das IP-Segment oder sogar das gesamte Rechenzentrum abgeschaltet wird, natürlich abhängig davon, was für Schäden verursacht werden, wie z.B. Einschleusen in andere Computer, Kreditkarten-Scam, Kinder-Pornografie, terroristische Aktionen.

Die Schäden also, die kleine Schadsoftware-Script anrichten können, kann also in die Tausende, aber auch in die Millionen gehen! Daher werden wir als Provider sofort bei Erkennung von Schadsoftware, den entsprechenden Webspace erst einmal sperren, um Folgeschäden grundsätzlich zu vermeiden und darüber den Kunden informieren!

Schadsoftware entfernt – alles nun gut?

Immer wieder sind Kunden der Meinung, es würde reichen, nur die erkannte und befallene Datei, die das Schadsoftware-Script enthält, zu löschen und dann gegen das Original zu tauschen! Aus Erfahrung wissen wir aber, daß dies ganz und gar nicht reicht, weil oft und unerkennbar, diverse andere Dateien verändert oder eingeschleust wurden, die ebenfalls Programm-Code enthalten, die einem Angreifer sofort wieder Tor und Tür öffnen und so dauert es dann auch aus der Erfahrung heraus, nicht lange und wieder ist der gleiche Webspace mit Schadsoftware befallen!

Und selbst wenn alle Dateien gelöscht wurden und ein ganz anderes CMS installiert wurde, erfolgt erneut ein Eindringen und wie ist daß denn überhaupt möglich? Ich will Ihnen das gerne aufzeigen:

Einbruch in ein Webspace und ausgelesene Kennwörter (Passwörter) öffnen viele andere Türen:

Wie ich oben schon beschrieben habe, kann ein Script auf dem Webspace alle Dateien lesen! Und es gibt Software wie CMS-Systeme, die ein auslesen aller Kennwörter auch noch begünstigen, wie z.B. Joomla! In der configuration.php im Hauptverzeichnis des CMS, kann eine Schadsoftware alle Einstellungen auslesen, wie z.B. FTP-User und Passwort, Datenbankuser und Passwort und auch Mail-Postfach-User und Passwort!

Die Schadsoftware hat also mit ziemlicher Sicherheit auch gleich dem Hacker diese Daten bereits angezeigt und/oder übermittelt!

Durch ein Löschen aller Dateien und einem nicht veränderten FTP-Passwort, spielt sich der Hacker ein Script ein oder mehrere, dies ist problemlos möglich, denn er hat ja die Zugangsdaten!

Die Hintertür, ein Script in der Datenbank, wird meist übersehen:

Anderes Scenario:
Alles wurde geändert, aber die Datenbank, die blieb unverändert!
Joomla speichert seine Artikel in der Datenbank und gibt diese auch für die Seitenabrufer aus der Datenbank aus. Es werden natürlich dabei auch Cache-Dateien erzeugt, die einen schnelleren Zugriff ermöglichen, aber grundsätzlich sind die Artikel in der Datenbank gespeichert. Und in einem Artikel wiederum, kann Programmcode eingebaut werden, wie Javascript oder auch PHP-Code!

Ein kleines Script im Artikel, wenn auch das entsprechende Plugin installiert ist, kein Problem, wie z.B. (nachfolgendes Script, wobei ich einige Zeichen anpassen mußte, damit das Miniscript hier im Blog-Artikel angezeigt und nicht ausgeführt wird:

php
+file = ‚bilder_anzeigen.php‘;
+current = file_get_contents(+file);
+current .= „neuer Schadcode“;
+file_put_contents(+file, +current);
endephp

Vor der Reinigung des Webspace, die richtigen Schritte überlegen:

a) Welcher externe Schaden, wurde bereits durch den Einbruch verursacht?
b) Welcher Gesamt-Schaden ist mir als Seitenbetreiber, durch das Hacking, wie z.B. Ausfall der Webseite, Reparaturmaßnahmen etc. entstanden?
c) Wenn dieser Schaden hoch genug war, ist hier eine Strafanzeige sinnvoll?
d) Wenn Strafanzeige, dann müssen Protokolle gefertigt werden. Diese Protokolle bereit zu stellen, kostet Aufwand beim Hosting-Provider (in der Regel 1-4 Stunden) und muß durch Auftrag erteilt werden! Diese Entscheidung muß sofort nach Kenntnis getroffen werden, um ggf. auch einen kompletten Server-Abzug „einzufrieren“
e) Erst wenn diese Überlegungen abgeschlossen sind, sollte mit der Reinigung begonnen werden, weil dadurch Einbruchsspuren beseitigt werden!

Überlegung vor der Reinigung, was die Software anbetrifft:

a) Welche Software soll laufen und in welcher Version – am besten, die neuste Version, bei der alle bekannten Sicherheitslücken geschlossen sind
b) Jedes Plugin prüfen, ob es wirklich benötigt wird und wenn, dann in der neuesten Version
c) die einzusetzenden Scripte (Software) daraufhin prüfen, ob diese nicht evtl. im Index der gefährlichen Produkte gelistet sind. Hier eine Adresse, um dies prüfen zu können: CVE-Details

Die Vorgehensweise, der Reinigung des Webspaces:

a) Komplette Kopie des Webspaces inklusive Dateisystem, Datenbanken, Mail-Postfächer
b) Komplettlöschung des Dateisystemes des Webspaces durch den Support – es darf nicht eine alte Datei erhalten bleiben, die womöglichen Schadcode enthält, der ggf. noch nicht entdeckt wurde!
c) Änderung aller Passwörter des Webspaces inklusive der Administrations-Oberfläche z.B. Confixx, cPanel, Plesk, dann aller Datenbanken und aller Mail-Postfächer
d) Prüfung der Mail-Postfächer, für die der Einbrecher Zugang erhalten haben könnte, ob sich hier Mails befinden, die wiederum Zugangsdaten enthalten. Wenn ja, von allen Systemen, in denen die Zugangsdaten ausgelesen werden konnten oder auch noch können, ebenfalls alle Passwörter ändern! Denn der Angreifer nimmt sich die Mails vielleicht erst in einem halben Jahr vor und bricht in ein anderes System ein, um Ihnen erneut einen Schaden zuzufügen!

Beispiel: In der Joomla-Konfigurationsdatei, waren die Zugangsdaten des Mail-Accounts enthalten und in diesem Mail-Account befindet sich eine Mail mit Zugangsdaten zu einem anderen System. Wenn dort das Passwort nicht geändert wurde, kann der Hacker diesen Zugang verwenden, um hier anderen Schaden durchzuführen!

e) Die Datenbanken prüfen, ob hier ebenfalls schadhafter Programmcode in Artikeln versteckt wurde! Ggf. jeden Artikel in der Datenbank kontrollieren! f) Prüfung, ob sich in der Datenbank-Tabelle für User, neue User eingeschlichen haben, die Administrations-Zugang erhalten haben!
g) Prüfung in Ihrem Webspace-Interface, ob hier Subuser zugefügt wurden, die Administrations- oder FTP-Zugang erhalten haben (Confixx z.B. zusätzliche FTP-USer)
f) Einspielung der Original-Software und NICHT Dateien Ihres durchgeführten Backups, in den leeren Webspace. Einzelne Dateien, die Ihnen fehlen, müssen dann nach kopiert werden, wobei JEWEILS vorher die Datei zu prüfen ist! WARNUNG: Ein Virusscanner wird hier oft nichts finden, weil das Script immer unterschiedlichen Code haben kann, ggf. auch noch cascadiert verschlüsselt!
g) Administrationsverzeichnisse zusätzlich durch einen Passwortschutz aus dem Administrationsinterface, wie confixx, cPanel, Plesk absichern. Um dann in den Administrationsbereich z.B. von Joomla zu gelangen, muß man sich einmal via .htaccess-Passwortschutz authentifizieren und dann für Joomla selbst ein zweites mal. Dabei am besten komplett abweichende User und Passwörter verwenden!

Besser sich schützen, bevor es zu einem Schaden kommt:

a) grundsätzlich nur das an Software einspielen, was Sie wirklich benötigen
b) grundsätzlich die Software auf dem neuesten Stand halten (Updates durchführen)
c) nicht scheinheiligen Viren/Schadprogramm-Scannern für Ihr Produkt (CMS) vertrauen, die bringen oft nur mehr Unsicherheit in Ihren CMS, weil diese Zugangsdaten von Ihnen benötigen!
d) nicht scheinheiligen Backup-Programmen für Filesystem/Datenbank vertrauen, die bringen oft nur mehr Unsicherheit in Ihren CMS, weil diese ebenfalls Zugangsdaten benötigen
e) Backups regelmäßig über das Administrations-Interface für Ihren Webspace durchführen, wie Confixx, cPanel, Plesk und diese Backup-Kopie auch auf den lokalen Computer übertragen!