Contao gehackt: Unterschied zwischen den Versionen

Version vom 26. Dezember 2010, 19:01 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.

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, 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

…

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.
• 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.
• 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!