Zentrales Multisitemanagement mit dem TYPO3 CMS

Darstellung der Navigation innerhalb von TYPO3

Manchmal gibt es Anforderungen an ein Content Management System (CMS) welche lauten: Das System soll OpenSource sein, also frei von Lizenzkosten Das CMS soll in der Lage sein, mehrere eigenständige Webauftritte innerhalb einer Instanz zu verwalten Es muss möglich sein, … Weiterlesen

TYPO3 CMS: Neues in Version 6

Aufgeräumtes Benutzerbackend

Die aktuellste TYPO3 Version wurde Ende November 2012 veröffentlicht. Zeit, einen kurzen Blick auf die interessantesten Neuerungen zu werfen. Der Namen: Nach TYPO3 Version 4.7 kommt die Version 6.0? In der Tat, so ist es. Ich war ebenfalls ein wenig … Weiterlesen

TYPO3 Updates – Versicherung oder überschätztes Sicherheitsbedürfnis?

Ein wenig provozierend der Titel dieses Blogposts – natürlich mit Absicht so gewählt. Die Antwort auf die obige Frage muss lauten: Abwägen!

Pauschal kann man nicht sagen, dass jedes erschienene Update auch zwingend die eigene TYPO3 Website betrifft und eingespielt werden sollte.  Leider ist es in der Praxis häufig so, dass die Kosten und Mühen für ein Update „gespart“ oder verdrängt werden und lieber abgewartet wird. Aber warten auf was?

Das ist dann in etwa so, wie wenn man mit seinem Internetauftritt „Russisch Roulette“ spielt. Gerade bei einer Firmenwebsite ist eine solche Entscheidung aus Sicherheitsüberlegungen nicht zu empfehlen.

Bezieht man sich auf die Sicherheit eines Systems, dann lassen sich Updates in die folgenden priorisierten Kategorien einteilen:

  • Prio 1: Security Issues -> Sicherheitslücken welche entdeckt wurden
  • Prio 2: Bugfixes -> Behebung von Fehlern in der Software
  • Prio 3: Improvements -> Funktionserweiterungen

Dabei kann natürlich ein Update auch Verbesserungen in allen 3 Bereichen beinhalten. Weiterhin gilt es zu unterscheiden, ob ein Update das TYPO3 Basissystem betrifft (den sogenannten CORE) oder sich auf Erweiterungen bezieht.  Genau hier kommt der Effekt zu tragen, dass nicht jedes Security Issue die eigene Website betreffen muss, da ja auch nicht überall dieselben Erweiterungen und Versionen eingesetzt werden.

Wie geht man also am besten als IT-Verantwortlicher mit dem Thema TYPO3-Updates um?

(more…)

TYPO3 Developer Days 2012

Die TYPO3 Developer Days fanden während 4 Tagen in Unterföhring bei München statt und umfassten 47 Workshops (7 jeweils parallel) mit 280 Teilnehmern.

Keynote

Ben van’t Ende, der Community Manager von TYPO3, eröffnete die Developer Days 2012 mit der Keynote über den Stand und die Zukunft von TYPO3.
Er versuchte TYPO3 zu charakterisieren mit den Begriffen Excellence, Structure und Sharing.

Sharing
Ben van’t Ende betonte immer wieder dass die wichtigste Komponente “Sharing” ist. Möglichst viele sollen sich an TYPO3 beteiligen.
Nebst Informationen über seine Aufgaben sprach van’t Ende über

  • TYPO3 Version 4.7. welche Ende April erscheinen soll,
  • typo3.org welche vor kurzem relaunched wurden und
  • FLOW3 welches bis Ende Jahr zusammen mit TYPO3 Phoenix seine Reife erlangen soll.

Präsentationen
Die meisten Präsentationen der T3DD12 werden in ein paar Wochen auf Slideshare verfügbar sein. Eine Liste aller Slides ist verfügbar unter https://notes.typo3.org/p/t3dd12-slides .
(more…)

A Study in … Viagra

Sherlock Holmes zum Zweiten. Der Blogpost von Jürg über gehackte TYPO3-Seiten hat viel Staub aufgewirbelt worauf mehrere SOS-Rufe von betroffenen Seitenbetreibern bei uns eingetroffen sind. Das Problem war, dass einige ältere TYPO3 Betreiber plötzlich unwissentlich potenz-steigernde Pharmazeutika verkauften. Seit wir auf dieses Problem aufmerksam geworden sind, stossen wir regelmässig auf neue Opfer des “Pharmahacks”. TYPO3 ist dabei übrigens bei weitem nicht das einzige geplagte System. Perfiderweise ist der Hack auf den ersten Blick nicht sichtbar – er wird nur wirksam, wenn der Surfer via Google auf die Seite stösst. Dann wird server-seitig neuer Text in die Webseite gerendert und beim Klick auf den Link von Google aus, gelangt der Kunde nicht auf die eigentliche Seite, sondern wird auf eine (meist russische) Seite weitergeleitet. Die verkauft Viagra – oder etwas anderes blaues.
Neulich erhielten ich erneut den Auftrag, den Verkauf blauer Pillen auf der Seite eines Dritten zu unterbinden. Diesmal wurde das Problem mit “Medikamentenhack” beschrieben.

Hier folgt ein Bericht meiner Spurensuche in der Hoffnung, dass Anderen mit den selben “Krankheitssymptomen” geholfen werden kann.
Als erstes habe ich mich auf dem System, im TYPO3 Backend und auf dem Server etwas umgesehen. Dabei handelte es sich nicht um eine “verwahrloste” Webseite sondern um eine recht gut ausgebaute Plattform mit einem relativ aktuellen TYPO3 Core und einem sauberen Aufbau und umfangreicher Funktionalität. Ein eher grosser Auftritt.

Gefährliche Extensions

Auf Anhieb sind mir jedoch einige potenziell (sehr) gefährliche Extensions aufgefallen, die auf einem Live-System nichts verloren haben: “t3quixplorer” – erlaubt die Navigation auf dem Filesystem mehr oder weniger uneingeschränkt und ermöglicht das Bearbeiten von PHP-Scripts direkt über das Webinterface – der reinste Security-Alptraum. Es ist nicht auszuschliessen, dass diese Extension von einem der Angreifer installiert wurde. “devlog” ist eine Extension welche zu Entwicklungszeiten nützlich sein kann – jedoch nicht in einem Live-System. Ein anderer Kandidat, welcher jedoch nicht installiert war, ist die “phpmyadmin” Extension, welche oft aus Bequemlichkeit installiert wird. Auch diese Extension stellt ein beträchtliches Sicherheitsrisiko dar. Im übrigen beinhaltete das System einige “handgemachte” Extensions – schnell zu erkennen an fehlenden Icons und der aussagekräftigen Versionsnummer 0.0.0 – Stable? Ja genau!

Backend-User

Ich habe ausserdem alle Backend-User überprüft und mit dem Kunden zusammen sichergestellt, dass keine unbekannten Nutzer registriert waren. Sollte dies der Fall sein, würde ich empfehlen, alle User neu anzulegen und neue, sichere Passwörter zu vergeben.

Spurensuche im Dateisystem

Danach habe ich mich etwas vertieft auf die Spurensuche gemacht. Aus Erfahrung weiss ich mittlerweile, wonach ich suchen muss. Eine Suche im Filesystem nach “base64_decode(” führt meist zu verdächtigen Code-Zeilen oder Dateien:

find . -name "*.php" -print | xargs grep "eval(base64_decode("

Meist sind infizierte Dateien im Ordner typo3conf/ zu finden. Darin befinden sich die von TYPO3 auszuführenden Extensions. Der Code darin kann potenziell schädlich sein.
Auf diese Weise bin ich auf zwei verdächtige Dateien gestossen. Eine Datei war in einer nicht öffentlichen, für Kundenbedürfnisse entwickelten Extension enthalten. Die andere im ./uploads/ Ordner der bekannten Newsletter-Extension tx_directmail.

./uploads/tx_directmail/trololo.php:<?php eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2RlKCJaWFpoYkNoaV
lYTmxOalJmWkdWamIyUmxLQ0phV0Zwb1lrTm9hVmxZVG14T2FsSm1Xa2RX
YW1JeVVteExRMHBoVjBad2IxbHJUbTloVm14WlZHMTRUMkZzU20x…

In beiden Fällen war es dem Angreifer möglich, über ein ungenügend geschütztes Formular PHP-Dateien auf das System zu laden. Geschieht dies, und sind diese Dateien auch ausführbar, hat man verloren.
Bei genauerem Hinsehen habe ich in der handgestrickten Extension gleich noch mehr zerstörerische Dateien gefunden welche die unscheinbaren Namen “class.php” und “footer.php” trugen. Ich musste erst beim Dienstleister des Kunden nachfragen, um sicher zu stellen, dass es sich wirklich um bösartige Dateien handelte. In diesen Fällen hatten die Angreifer ganze Arbeit geleistet – auch das Erstelldatum war ein weit zurückliegendes. Oft kann man im System auch einfach nach Files suchen, die im Zeitraum des Hacks verändert wurden. Ich konnte diesen durch verdächtige Files auf etwa 76 Tage zurückliegend vermuten und bin mit dem Befehl

find . -iname "*.cache" -mtime -77 -mtime +75 -type f

auf weitere verdächtige Dateien gestossen. Da im Ordner typo3conf während dem Betrieb eigentlich keine Dateien geändert werden sollten, sind dies zumindest dort, nur eine Hand voll. Mein Tipp: in typo3conf/ext/ darf auf einem Live-System gar nichts geändert werden können. Dem Server (Apache) sollen also alle Schreibrechte auf typo3conf/ext/ entzogen werden. Auch localconf.php darf nie verändert werden – damit wird es für einen Angreifer sehr schwer, nachträglich Extensions zu installieren, ohne dass er Serverzugriff hat.

Bereits erwähnte class.php war mehrfach base64 encoded und nachdem ich diese mehrfach decodiert hatte wurde ihr Zweck offensichtlich. Sie leitet die Benutzer welche von viagra-verseuchten Google-Resultaten kommen auf die russischen Verkaufsseiten weiter:

Ja ist denn heut’ schon Weihnachten?

Bei der Analyse von ./uploads/tx_directmail/trololo.php wurde ich leicht überrascht. Ebenfalls nach mehrmaligem encoden kam folgendes zum Vorschein:


Ein ausgewachsenes Backdoor! Inklusive Passwortschutz. Klar russischen Ursprungs. Mit diesem Tool kann man auf einem Server so ziemlich alles machen. Dateien erstellen, löschen, bearbeiten, Rechte setzen. Damit kann man die localconf.php auslesen – dort steht (meist) der MySQL User und das Passwort im Klartext. Somit kann der Angreifer auch auf die Datenbank zugreifen. Doppelt dumm, wenn der gleiche User auf mehrere Datenbanken Zugriff hat. Wenn man localconf.php nicht schreibgeschützt hat, kann er ausserdem ein neues Install-Tool Passwort erstellen. Damit kann er sich dann einen Backend-Administrator erstellen – etwas einfacher als direkt über die DB. Netterweise nennt TYPO3 bei einer missglückten Anmeldung am Install-Tool auch gleich den dazu benötigten MD5 Hash den man dann nur noch im localconf.php eintragen braucht.
Das Backdoor in Action:

Und weiter geht’s…

Nachdem ich die Suche bereits abbrechen wollte – es war mittlerweile schon spät – bin ich im fileadmin/ in den Templates der Webseite auf eine weitere mysteriöse Datei gestossen – eine PHP Datei unter den CSS Files; en.php
Diese enthielt neben den verdächtigen base64 Codes auch noch folgenden aufschlussreichen Text:

Codz by angel(4ngel)
Make in China
Web: http://www.4ngel.net

Die Chinesen waren also auch am Werk! Nach erneut mehrmaligem Encodieren und Entfernen eines Passwortschutzes wurde offensichtlich, dass die Chinesen den Russen mittlerweile – zumindest im Design – voraus sind. Ebenfalls eine mächtige Hintertüre – einmal in schön.

Fazit, Suche, Massnahmen

Abschliessend konnten wir den Grossteil des Hacks wohl innerhalb einiger Stunden finden und entfernen. Nach dem der übliche Selbstheilungsprozess von Google eingesetzt hatte sind nun die Suchresultate wieder frei von Viagra. Für die Suche nach infizierten Files benutzen wir die Dateisystemsuche nach den Begriffen eval() und base64_decode(), Datumsangaben, verdächtige PHP-Dateien an unüblichen Orten – PHP-Files im uploads Ordner oder in andern Ordnern mit normalerweise statischen Inhalten. Auch eine Hilfe für das schnelle Finden von Schadcode kann sein, wenn die TYPO3 Temp-Files im typo3conf/ Ordner nach base64_decode durchsucht werden. Diese Dateien werden von Typo3 geladen und enthalten einen Zusammenzug vieler ausgeführter Dateien. Oft sieht man dort schnell, ob, und wo ungefähr, ein System vom “Pharmahack” befallen ist. Handgemachte Extensions die nie den Weg ins TYPO3 Repository gefunden haben sind ein erhöhtes Sicherheitsrisiko. Alle Formulare mit Upload-Funktionalität sind ein möglicher Angriffspunkt. Auch in die Datenbank sollte man einen Blick werfen. Es kann sein, dass in den Tabellen von RealURL unerwünschte Weiterleitung enthalten sind. Auch in tt_content oder in der pages Tabelle kann nach Viagra gesucht werden. Ausserdem sollte man alle Cache-Tabellen leeren.

Die befallenen Dateien und Extensions werden gesäubert oder entfernt. Nicht (mehr) benötigte Extensions sollten vom System gelöscht werden – nicht nur deaktiviert! Unnötige Backend- und Frontend-User sollten ebenfalls gelöscht und die Passwörter sicherheitshalber angepasst werden.
Alle Schreibrechte für den Server sollten auf typo3conf/ext und auf der localconf.php entfernt werden. Dies gilt selbstverständlich auch für den ganzen TYPO3-Core. Sicherheitshinweise von TYPO3 sollten ernst genommen werden:

Das Install-Tool kann auf dem Live-System entfernt werden und der Zugriff auf das Backend nur für einen bestimmten IP-Range, vielleicht über eine spezielle Sub-Domain und zusätzlich mit einem .htaccess Schutz, versehen werden. Auch HTTPS für das Backend schadet kaum.
Natürlich sollte darauf geachtet werden, dass TYPO3 und verwendete Extensions auf einem aktuellen Stand sind. TYPO3 Bug-Fix Releases sollten wenn möglich immer installiert werden da diese Security-Fixes enthalten und normalerweise problemlos zu installieren sind.

Neuer Webauftritt der Schaffhauser Kantonalbank mit TYPO3

shkb-1

Für die Schaffhauser Kantonalbank durfte Namics den Webauftritt der shkb.ch von Grund auf neu konzipieren, gestalten und entwickeln. Die SHKB setzte dabei zur Realisierung ihrer öffentlichen Webseiten auf das Open Source Content Management System TYPO3. Weiterlesen

Google-Viagra-Angriff auf Typo3

So ungern man darüber spricht, dass eigene Typo3-Installation gehackt/missbraucht wurden, so gerne möchte ich anderen Leuten helfen, die sich mit demselben Problem beschäftigen.

Was ist geschehen?

Kurz vor dem Osterwochenende (kaum ein Zufall) wurden wir darauf aufmerksam gemacht, dass eine Website von uns (auf Basis von Typo 3, Version 4.1.x) mit „Viagra-Spam” in der Google Trefferliste erscheint. Also in etwa so (Anfrage an Google „site:*DOMÄNE* viagra”).

3400-treffer-thumb-500x203-3399.png

Bei Klick auf einem der Treffer wird der Besucher über die auf der Trefferliste genannte Site mit einem serverseitigen Redirect (http 302, found) auf die Domäne http://https-checker.com/ (bei Amazon AWS gehostet) umgeleitet und von dort aus auf eine “Online-Pharmacy” in den USA oder in Kanada.

Auf Anfrage gebe ich gerne Auskunft über alle technische Details, doch hier nur das Wichtigste. Die ganze Sache wurde (aber der IP 178.122.14.205) sehr professionell ausgeführt und in unserem Fall bereits zwischen dem 20. und dem 23. Februar eigebaut. Die zwei genannten Probleme i) Ergänzung des Seiteninhaltes mit „Viagra” und co…

3403-contentergaenzung-thumb-500x366-3402.png

…und ii) Redirection auf die Kauf-Site griff nur, wenn entweder der Referrer oder der User Agent (Crawler) google beinhaltete. Zudem gab es noch eine kleine Zufallskomponente, so dass das unerwünschte Verhalten nicht immer greift.

3406-redirection-thumb-500x254-3405.png

Was tun?

Hier eine Anleitung was wir getan haben um das System (nun seit über einer Woche ohne Probleme stabil) wieder in Betrieb zu nehmen.

1) Site abstellen (resp. den User auf eine statische Information schicken). Dies haben wir getan als wir merkten, dass der Angreifer während der Reparatur Katz und Maus mit uns spielte. Anmerkung: Eine erwogene Alternative war es dem Apache über mod_header und der Direktive “header unset Location” die Redirection abzustellen, doch war uns die Präzenz des Hackers zu unangenehm.

2) Für unsere Arbeit änderten wir die Domäne vorübergehend (mit einem lokalen Hosts-Eintrag)

3) www.xxx.ch/typo3 über IP restriction und mit einem Passwort (simple authentication) sperren. Der „erste” Einstieg des Hackers erfolgte in unserem Fall hier.

4) Hier wollten wir eigentlich den Restore zurückspielen, aber da die Veränderung lange zurück lag und wir nicht soviel Content verlieren wollten, beschlossen wir das System zurück zu bauen.

5a) Die Veränderungen waren über Dutzende von Typo3-Dateien verteilt. Vereinfacht hatte es uns die Suche nach der Funktion preg_replace die genutzt wurde um die Änderungen zu verschleiern (und die sonst kaum/nicht genutzt wird). Beispiel für eine der Veränderungen ist das folgende Codefragment

3409-codefragment-thumb-500x171-3408.png

Update 5b) Im Fall einer weiteren Site in der wir Schadcode entfernt haben, wurde zur Verschleierung des Klartextes (Obfuscation) die Funktion str_rot13 genutzt. Konkret stand in localconf.php der folgende Zeilenbeginn:$a4d752de1a1e8d=str_rot13(‘tmhapbzcerff’);$a4d752de1a2…

6) Die obengenannten Fragmente haben wir vollständig entfernt. Zudem haben wir alle Extentions die nicht wirklich benötigt werden gelöscht.

7) Danach haben wir alle User deaktiviert/gelöscht, einen neuen Admin angelegt und die kritischen Dateien/Verzeichnisse akribisch geprüft (und zurückgebaut): typo3conf/, localconf.php, index.php, .htaccess und /typo3/sysext/cms/tslib/index_ts.php. Nun zeigten unsere Tests ein normales Verhalten der Site.

8) Und schlussendlich haben wir unsere T3-Security Checkliste vorgenommen und das Ding sehr restriktiv (re)konfiguriert: Installation von Extentions verbieten, keine Schreibrechte von T3 auf das Dateisystem (ausser das allernötigste) und Install-Tool entfernen.

Ich hoffe die Infos sind nützlich und wie gesagt bin ich für Fragen hier oder direkt gerne zu haben.

Update (4. Mai): Hier noch einen Post von Peter Kraume zu demselben Thema: Die eigene Webseite als Spam Schleuder: der Google Conditional Hack

Update (15. Juni): Just Pfingsten wurden wieder zahlreiche Sites “umgebaut”. Diesmal (in den mir bekannten Fällen) über Veränderungen der DB (über SQL-Injection). Dasselbe Ergebnis, aber ein anderer Angriffsvektor.

Update (30. Januar 2012): In der Zwischenzeit hatten wir über zwanzig betroffene Sites zwischen den Fingern. Noël hat unseren aktuellen Wissensstand in einem weiterenPost zusammengefasst: A Study in … Viagra

PHP, MySQL, Typo3 … —> work@namics

Wir suchen *freaks* :-).Wenn Du mindestens 4 der folgenden Begriffe kennst und auch schon öfter damit gearbeitet hast, bist du bei namics richtig: PHP, MySQL, Typo3, HTML/CSS, JavaScript, XML, XSLT, Linux, AJAX. Falls nicht, kennst du vielleicht jemanden der in diesem Umfeld arbeiten möchte :-). Hier gehts zur Bewerbung:

&lt;?php
function output($str='') {
    if (mt_rand(0,2)!=0)
        return (&quot;&lt;a href=&quot;.$_SERVER['PHP_SELF'].&quot;&gt;Du hast es fast geschafft :-)&lt;/a&gt;&quot;);
    else
        return (&quot;&lt;a href=\&quot;mailto:&quot;.base64_decode($str)
            .&quot;?subject=Stelle%20als%20OpenSource%20Entwickler%20bei%20namics\&quot;&gt;Bewerben&lt;/a&gt;&quot;);
}
echo output(&quot;Y2FyZWVyQG5hbWljcy5jb20=&quot;);
?&gt;