Als Mitglied des Security Teams habe ich Zugang zu vielen interessanten Informationen, die aber nicht veröffentlicht werden können. Und dabei rede ich nicht von neuen, noch nicht behobenen Lücken, sondern vielmehr von Dingen wie aufkommenden neuen Feature-Ideen (bzw. Diskussionen darüber), umgekehrt aber auch über meiner Meinung nach wünschenswerte Security-Zusatzeigenschaften in Frontend wie Backend, und vieles mehr.

Ein Außenstehender könnte all das viel problemloser kommentieren, ich kann es eben nicht. Was bleibt? In letzter Zeit vor allem das nachträgliche Erläutern veröffentlichter Bulletins, auch dies naturgemäß nur “an der Oberfläche”. Spannender: Sonstige Hintergründe, z.B. in Interviews mit Leuten auch außerhalb des Security Teams. Wobei dies natürlich prümär von den Interviewpartnern abhängt, und trotz viel bekundeten Interesses haben die meisten dann doch nie Zeit für sowas. Auch dies liegt sicherlich – zumindest unter anderem – an der etwas sperrigen Thematik.

Der langen Rede kurzer Sinn: Ich habe mich entschieden, diesen Blog zunächst “auf Eis zu legen”, also nicht weiter zu füttern.

“Zunächst”? Man soll ja bekanntlich nie “nie” sagen… Vielleicht ändert sich die Situation ja irgendwann dahingehend, dass das Ganze besser funkioniert.

Bis dahin: Danke für’s Vorbeischauen, und “take care”!

P.S. Direkt zu Erreichen bin ich weiterhin auch über die naw.info Website bzw. die dort angegebene Email-Adresse.
Oder natürlich per Kommentar auf dieser Seite =)

Hier die gesamte Übersicht:

• TYPO3-20080513-1 wt_gallery: XSS, Path Traversal, Information Disclosure (kritisch)
• TYPO3-20080513-2 pbsurvey: XSS (medium)
• TYPO3-20080513-3 rlmp_eventdb: XSS (medium)
• TYPO3-20080513-4 ke_stats: SQL Injection und XSS (kritisch)

Ist dies nun der Beginn von regelmäßigen “Patch Days”? Nein, allerdings wurde die Veröffentlichung bewusst gebündelt, um den betroffenen Admins das Leben wenigstens etwas zu erleichtern.

Henning Pingel, Co-Leader des Security Teams und Koordinator der Bulletins, wies zudem darauf hin, dass es sich in allen Fällen nicht um offiziellen TYPO3-Code, sondern um Dritt-Extensions handelt – und dass angesichts der weiterhin stark ansteigenden Zahl solcher Extensions auch künftig mit dem Auftreten solcher Fehler zu rechnen sein wird.

Im gleichen Zuge scheint sich momentan die Tendenz zu verstärken, dass wichtige Extensions in die offizielle Pflege durch das TYPO3-Projekt übernommen werden sollten – sicherlich eine gute Idee!

Abgesehen davon habe ich mit verschiedenen Leuten darüber diskutiert, an dieser Stelle nicht nur reaktiv zu berichten, sondern auch gelegentlich”Best Practices” zu Sicherheits-Themen darzustellen. Mit dem Ergebnis: Ja, es scheint wohl genug Interesse und auch Themen zu geben. Also geht das los!

Ebenfalls wenig aufregend zeigt sich bislang unser Honeypot. Er zieht zwar schon viele Angriffe auf sich, doch sind die bislang überhaupt nicht TYPO3-spezifisch und überhaupt unspektakulär. Im Wesentlichen sind es immer wieder Zugriffsversuche auf Lücken anderer Systeme (CMS und sonstige), meist geht es dabei übrigens weiterhin um Remote File Inclusion – Lücken.

Soviel für heute, weiterhin einen schönen Nikolaustag

Inzwischen zeigen sich vermehrt Resultate. Direkte Trafficweiterleitungen haben wir leider nicht bekommen, aber die Seite wird inzwischen auch so, also dank Google und Links, vermehrt gefunden – und zwar wie erhofft auch durch die “bösen Jungs”.

Allerdings war bisher noch nichts explizit TYPO3-orientiertes dabei… Hier die bisherigen Top-3 Systeme, auf deren Lücken gescannt wird:

• Joomla/Mambo
• dotproject
• phpbb

Interessanterweise erfolgen meist nur ein paar ausgewählte Zugriffsversuche auf verschiedene der heftigsten Lücken dieser Systeme, aber nur wenige umfangreichere Verwundbarkeits-Scans. Außerdem schön zu beobachten ist natürlich das vermehrte Auftreten von Formular-Spamming. Mal schaun wie’s weitergeht – ich denke die nächste Angriffswelle auf TYPO3 werden wir bestimmt hautnah beobachten können!

Außerdem kommt demnächst auch noch ein seperater Blogpost zum technischen Aufbau und Vorgehen für den Honeypot.

Für mich steht jetzt übrigens erstmal die TYPO3-Konferenz an – unter anderem halte ich dort einen Vortrag zu OpenID und TYPO3, außerdem freue ich mich schon auf Lars’ und Hennings spannende Live-Vorführung zum Thema “Extension Hacking”, sehr zu empfehlen! Bericht folgt natürlich hier.

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?

Wie kam es zu diesem Review?
Die Extension-Entwickler (Fa. citeq) wollten gerne das Review zur eigenen Qualitätssicherung – aber auch als Qualitätsmerkmal gegenüber ihren Kunden. Sie haben das TYPO3 Security Team angesprochen und innerhalb des Teams habe ich den Auftrag übernommen.

Wie wurde das Review durchgeführt?
Wir haben dieses “Peer-Review” zu zweit durchgeführt – Sven Gähle und ich. Dabei wurde der Code analysiert und geprüft, und die Ergebnisse als Reviewdokument mit allen Befunde an Kunden gegeben. Anschließend erfolgte die Behebung durch die Entwickler. Das Ergebnis haben wir dann nochmal intensiv gegengeprüft.

Hat sich die Arbeit im Team, also mit zwei Reviewern, bewährt?
Auf jeden Fall. Das ist auch Bedingung für die Durchführung, um wirklich exzellente Ergebnisse zu erzielen.

Wem würdest Du ein solches beauftragtes Review empfehlen?
Eigentlich ist ein externes Review sinnvoll für alle, die professionell TYPO3 Extensions entwickeln – gerade für weniger erfahrene Entwickler sowie für komplexe Erweiterungen.
Außerdem sollte das natürlich im Interesse der anwendenden Firma liegen! Diesen würde ich sogar empfehlen, solche Dinge in die Verträge aufzunehmen. Das ist sogar dann möglich, wenn die Agentur die fragliche Extension gar nicht selbst programmiert hat – schließlich kann man ja auch Dritt-Extensions reviewen lassen.

An wen sollten Interessierte sich wenden?
Immer an das TYPO3 Security Team. Selbst wenn man eine andere Firma “an der Hand hat”, die das Review durchführen soll, sollte das vom Security Team begleitet werden. Auf keinen Fall sollte die entwicklende Agentur selbst reviewen.

Und was kostet das?
Das hängt vom Einzelfall ab, das geht nicht anders – schließlich gibt es kleine und riesengroße Erweiterungen.

Fließt das Ergebnis ins öffentliche TYPO3 Extension Repository ein?
Klar.

Warum werden Extensions eigentlich nicht kostenlos vom TYPO3 Projekt gereviewed?
Wir haben tausende Extensions! Und jedes Review ist nicht unerheblicher Aufwand, wer sollte das in seiner Freizeit leisten, und mit welcher Motivation? Hier funktioniert Open Source eben anders, nämlich so, dass ernsthafte Anwender einerseits lizenzkostenfreie Software verwenden, die andere zur Verfügung gestellt haben – andererseits Ihren Teil zum Projekt beisteuern, indem sie eine externe Qualitätssicherung bezahlen. Oder eben dass eine qualitätsbewusste Agentur die externe Prüfung als Teil Ihrer Leistung begreift. Ich finde beides sehr positiv!

Ok. Was wäre sonst noch zu sagen?
Also zunächst: Dieser Weg hat sich wirklich bewährt, und dem Security Team ist daran gelegen, das weiter zu fördern. Gerade die aktuelle Vielzahl an aufgedeckten Lücken zeigt ja, wie wichtig eine Qualitätssicherung ist.

Und wie war das Feedback des Auftraggebers, der citeq?
Oh, die waren sehr angetan, wie sorgfältig der ja nicht wenig komplexe Code geprüft wurde. Und vom Ergebnis natürlich auch – ich denke, citeq würde das wieder machen. Uns selber hat die Zusammenarbeit übrigens auch Spaß gemacht. Vielen Dank nach Münster an dieser Stelle.

Ja, und danke an Dich für das erfolgreiche Review und für dieses Interview!

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…