Contao gehackt: Unterschied zwischen den Versionen

Version vom 25. August 2012, 21:38 Uhr

Unvollständiger Artikel: dieser Artikel ist noch nicht sauber bearbeitet. Bitte erweitere ihn und entferne erst anschliessend diesen Hinweis.

Seit der Veröffentlichung von Contao sind nur sehr wenige Sicherheitslücken bekannt geworden (die Zahl der kritischen kann man an einer Hand abzählen), was vor allem der Sicherheitsarchitektur des Frameworks geschuldet ist (v. a. werden standardmäßig alle Nutzereingaben gefiltert). Dennoch kann es vorkommen, dass eine Contao-Installation kompromittiert wird. Dies geschieht aber meist durch Versäumnisse der Seitenbetreiber oder Hoster, oftmals auch unabsichtlich und ohne Wissen derer.

Seite auf der schwarzen Liste

Reagiert man nicht schnell genug, und Google bekommt das mit, wird die Seite auf die scharze Liste gesetzt. Browser wie Firefox nutzen diese um vor dem Zugriff darauf zu warnen. Das sieht dann so aus:

Und im Google wieder zu überzeugen, man hat aufgeräumt, siehe diese Google Support Seite dazu.

Mögliche Angriffsvektoren

Eine Contao-Installation kann über verschiedene Wege infiziert werden, insbesondere über

• direkten Dateisystemzugriff, v. a. durch schlecht gesicherte FTP-Zugänge oder abgegriffene Passwörter über Trojaner oder ungesicherte Verbindungen zum Internet (z. B. öffentliches WLAN),
• direkten Datenbankzugriff, v. a. durch schlecht gesicherte Datenbankadministrations-Zugänge oder abgegriffene Passwörter
• indirekten Dateisystemzugriff, z. B. über Viren auf dem Server, die z. B. über Zugänge anderer Kunden auf dem Server eingeschleust wurden, meist durch wenig bis nicht getrennte Kundenbereiche auf einem Server oder Serversystemen,
• indirekten Datenbankzugriff, insbesondere durch Accounts mit mehr Zugriffsrechten als nötig,
• Viren auf Client-Computern (z. B. bei Administratoren und Kunden), die Dateien auf den Quellcomputern infizieren (und somit werden bereits infizierte Dateien auf den Server übertragen),
• Sicherheitslücken in auf dem Client verwendeter Software (z. B. gab es mal eine Sicherheitslücke in einer Version von FileZilla – die womöglich am häufigsten auftretende Ursache für Dateisystem-Angriffe),
• verseuchte Backups (die Infektion kann länger zurückliegen, als man denkt!),
• Sicherheitslücken in auf dem Server verwendeter Software (Betriebssystem, Datenübertragungsprogramme, Administrationstools (z. B. Plesk), Datenbankverwaltungssysteme, CMS, Scripts aller Art, …) – denn kein System ist vollkommen fehlerfrei und 100%ige Sicherheit gibt es nicht!
• Die allgemein wohl häufigste Ursache für Infektionen sind Fehler in der Konfiguration – Standard-Benutzer besitzen mehr Rechte als nötig, nicht benötigte Funktionen, die Angriffsvektoren öffnen, werden nicht abgeschaltet, fehlerhafte Anfragen werden nicht aussortiert, …

Gegenmaßnahmen / Reinigung eines kompromittierten Systems

• Beweise sichern.
  • Hinzugefügte Dateien bzw. kompromittierte Dateien sichern.
  • Dabei möglichts Dateidatum/Uhrzeit nicht verändern zur Sicherung des Zeitpunktes.
• Kompromittierte Dateien entfernen / ersetzen
• Webhoster Bescheid geben und nach Logs bitten, wann die Datei von wem hochgeladen wurde
  • (Datum/Uhrzeit, Remote IP, lokaler FTP username)
• Passwort des entsprechenden FTP Benutzers ändern
  • Jedoch nicht(!) von dem Rechner aus, von welchem vermutlich das Passwort entwendet wurde
  • (lässt sich evtl. anhand obiger Angaben erraten, von einem bislang gänzlich unbeteiligten Rechner aus ist hingegen von Vorteil).
• entsprechenden FTP User deaktivieren und dessen Nutzer(n) Bescheid geben, dass sein Rechner vermutlich kompromittiert/infiziert wurde.
• Bis zur Sicherstellung dass der Rechner nicht mit Schadsoftware infiziert ist auf keinen Fall das neue Passwort auf diesem Rechner eingeben (Stichwort Keylogger).
• Einen Systemcheck kann man z.B. mit einer kostenlosen Virenscanner Disk durchführen, welche nahezu jeder nahmhafte Hersteller (u.a. die mit dem roten Regenschirm) anbietet. Eine separate CD daher, damit eine etwaige Schadsoftware nicht schon beim booten den Scanner lahmlegt.

Prophylaxe

Auch wenn nicht alle Maßnahmen mit vertretbarem Aufwand durchgeführt werden können: Jedes bisschen Mehraufwand zahlt sich aus.

• Script- und Template-Dateien regelmäßig auf Schadcode überprüfen (ersteres geht schnell und einfach über den Contao System Check) sowie unerwartete zusätzliche Dateien prüfen und ggf. löschen.

Damit eine Installation nicht infiziert wird, gilt generell immer:

• ALLE verwendete Software, ob auf Client oder Server, ob für die Serververwaltung verwendet oder nicht, MUSS immer AKTUELL sein, regelmäßig und häufig muss auf Aktualität aller installierten Software geprüft werden.
• Software auf Relevanz überprüfen – brauche ich wirklich installiertes Programm X auf Server/Client? Solch eine Bestandsaufnahme am besten regelmäßig (z. B. alle 3-6 Monate) durchführen.
• Insbesondere Virenscanner müssen stets aktuell gehalten werden, damit man gegen die neusten Viren geschützt ist (dennoch: Die allerneusten Viren können sich immer frei entfalten, bis ein Anti-Virus-Hersteller einen solchen entdeckt, analysiert und Erkennungsmerkmale identifiziert hat, dass Anti-Virus-Software ebendiese erkennen kann – dabei vergeht viel Zeit!).
• Desweiteren MÜSSEN Passwörter insbesondere für sicherheitskritische Bereiche ausreichend stark sein (lang, mit Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen) und sie DÜRFEN NICHT für andere passwortgeschützten Bereiche verwendet werden! Insbesondere gilt dies für weniger kritische Bereiche mit hoher Reichweite (z. B. social networks, Foren, Chat-Programme) versus Administrationsoberflächen (generell: je mehr ein Nutzer darf, desto komplizierter und besser geschützt muss das Passwort sein!).
• Passwörter SOLLEN regelmäßig und häufig geändert werden!
• NIEMALS über unverschlüsselte Verbindungen Passwörter versenden, das gilt insbesondere an öffentlichen (und auch heimischen) WLANs (auch scheinbar verschlüsselte Verbindungen könnten nur über eine schwache Verschlüsselung verfügen – bei WLAN ist WPA2 mit langem Passwort Pflicht!) und öffentlichen Computern. Statt FTP ist SFTP/SCP vorzuziehen, mindestens jedoch FTPS (FTP over SSL). Außerdem sollten kritische Weboberflächen (z. B. Datenbankadministration, CMS-Administration) nur über HTTPS (SSL/TLS) erreichbar sein. Generell schützt ein zusätzlicher SSH-Tunnel/VPN zum Server, falls vorhanden, vor bösen Überraschungen.
• Auch im Zeitalter des Internets und der Computer gilt: Passwörter NICHT einfach so irgendwo aufschreiben, nicht auf Zettel und auch nicht auf "digitale Notizblöcke". Wer sich ein Passwort nicht merken kann, sollte Passwortmanager benutzen, die über ein Master-Passwort geschützt sind und auf die möglichst wenige Personen Zugriff haben, und/oder die Passwörter in Sätze verpacken, die nur vom "Passwort-Eigentümer" dechiffriert werden können ("jeder x-te Buchstabe eines Wortes ist ein Teil des Passworts" ist dabei nur eine schwache Verschlüsselung, es sei den der Text selber ist nicht auffällig (bspw. ein längeres Gedicht).
• Wichtig ist auch die ständige Kontrolle von Protokollen, v. a. auf dem Server – außergewöhnliche Anfragen und Protokolleinträge müssen genauer untersucht werden, ebenso sollten stichprobenartig normal aussehende Einträge kontrolliert werden.
  Eine Hilfe dabei könnte diese Erweiterung sein: Integrity_Check
• Wenn möglich, Brute Forcing erschweren: Wiederholversuche bei falschen Passworteingaben runterschrauben, Warteintervalle bei zu häufiger Fehleingabe erhöhen, keine Standard-Benutzernamen verwenden (z. B. "root", "admin"!), v. a. lange und komplizierte Passwörter verwenden, …
• Immer misstrauisch sein!