Schwere Sicherheitslücke im TYPOlight-Installtool

[ATLAS]

Nur ein kleiner Hinweis. Wer mit Plesk arbeitet bekommt schon mal solche Probleme. Einen Verzeichnisschutz sollte man in solch einem Fall über das Backend von Plesk einrichten.

[leo]

wir hatten das schonmal bei den tickets ... FileMatch wird schon vom core für das comprimieren von css und js verwendet, also müsste es den fehler schon geben soweit im root die htaccess für das umschreiben der url verwendet wird ...

Nein, dieser Fall liegt anders. Die .htaccess im Root ist optional und muss gesondert aktiviert werden, daher ist es gut möglich, dass das FileMatch-Problem bisher unerkannt blieb.

[Andreas]

Nur ein kleiner Hinweis. Wer mit Plesk arbeitet bekommt schon mal solche Probleme. Einen Verzeichnisschutz sollte man in solch einem Fall über das Backend von Plesk einrichten.

Auch darauf achten, dass das Einrichten des Verzeichnisschutzes mit Confixx eine vorhandene .htaccess überschreibt. Also am besten temporär für irgendeinen leeren Ordner einrichten, nachsehen was in den Dateien .htaccess und .htpasswd steht und übernehmen. Der temporäre Passwortschutz kann dann mit Confixx wieder entfernt werden.

Andreas

[Pixelpirat]

In der Tat hatte auch ich ein Problem mit dem Installationspasswort. Erst nachdem ich

Es gibt verschiedene Möglichkeiten, das Installtool bzw. eine Installation abzusichern.

4. Zugriff mittels deny from all generell blockieren
Nachteil: auch der Administrator kann nicht mehr zugreifen.

Was ist mit deny from all und allow from FesteIP?
Ich habe eine Feste IP zudem noch shell Zugänge bei diversen Servern.

Damit sollte es doch sehr sicher sein. Oder?

Gruß
Pixelpirat

[leo]

Das geht natürlich auch. Habe ich nur nicht erwähnt, weil der Normalbenutzer mit Alice/Telekom-DSL in der Regel keine feste IP-Adresse hat. Es gäbe darüber hinaus auch noch die Möglichkeit, ein Client-Zertifikat für den Zugriff vorauszusetzen.

[Harry]

Hallo zusammen,

erst einmal auch von meiner Seite: "Respekt Leo, für Deine umsichtige Handhabung der Sicherheitslücke". Ich bin jetzt auch durch mit der Aktualisierung der Installationen meiner Kunden, bei der das Live Update tatsächlich eine echte Hilfe war. Dennoch hat's gedauert. Von ein paar Stunden kann, zumindest in meinem Fall, nicht die Rede sein, wenn man die Sache ernst nimmt.

Nehmen wir einmal an, man ist Dienstleister und betreut etwa 50 Kunden. In einigen der erstellten Seiten stecken Monate Aufwand für Absprachen und Umsetzung. Das will man nicht auf's Spiel setzen. Nehmen wir weiter an, der schlimmste Fall ist eingetreten und jemand hat die Sicherheitslücke bereits genutzt und ist im Besitz der Datenbankzugangsdaten eines komplexen Projekts. Dann bleibt nur der Weg, den Leo bereits empfohlen hat, mit folgenden Nebenerscheinungen:

1. Das Datenbankpasswort ändern: Sofern im laufenden Betrieb, am Besten die localconfig.php mit FTP-fähigem Editor öffnen, neues Passwort eintragen und die Datenbankeinstellungen im Admintool des Providers öffnen. Dann Beides möglichst zeitnah sichern. Anschließend das neue Passwort lokal dokumentieren. Falls das Admintool Confixx ist, muss man weitere Systeme im Account anpassen, da in Confixx nur ein zentrales Passwort für alle Datenbanken verwaltbar ist. Kunden, die administrativ arbeiten, müssen über die Änderung informiert werden.
2. Den Patch aufspielen, alternativ das Update auf 2.7.6. Falls das System länger nicht mehr aktualisiert wurde (kleiner als 2.7.0), sind Anpassungen notwendig, siehe Änderungen in der bevorstehenden Version 2.7.
3. Die Benutzer prüfen: Ein möglicher Eindringling könnte sich einen Adminzugang angelegt haben. Den kann man löschen (und weiß dann auch, dass es ich gelohnt hat). Es könnte aber auch das Passwort eines existierenden Adminaccounts überschrieben worden sein. Sicherheitshalber sollte man daher die Passwörter aller Backend-Admins überschreiben und den Admins das neue Passwort zukommen lassen, mit dem Hinweis, dass sie ihr bisheriges Passort wieder eintragen können, da die Passwörter ja verschlüsselt gespeichert werden.

Und das mal fünfzig! Nein, ich will mich nicht beschweren. Es ist die erste Sicherheitslücke in TYPOlight seit Bestehen. Im Vergleich zu anderen Systemen ein guter Schnitt. Wenn man als Dienstleister seine Installationen sauber verwaltet, kann man alles nacheinander abarbeiten. Nur nicht, wie gesagt, in zwei Stunden.

Liebe Grüße

Harry

[xtra]

Ein möglicher Eindringling könnte sich einen Adminzugang angelegt haben. Den kann man löschen (und weiß dann auch, dass es ich gelohnt hat). Es könnte aber auch das Passwort eines existierenden Adminaccounts überschrieben worden sein. Sicherheitshalber sollte man daher die Passwörter aller Backend-Admins überschreiben und den Admins das neue Passwort zukommen lassen, mit dem Hinweis, dass sie ihr bisheriges Passort wieder eintragen können, da die Passwörter ja verschlüsselt gespeichert werden.

Spaetestens in einem solchen Falle MUSST du die Seite meiner Meinung nach erstmal vom Netz nehmen bzw. mindestens die Passes aller User aendern, nicht nur admins.

Weiterhin musst du die komplette Seite herunterladen und mit den offiziellen Sourcen vergleichen (diffen) sowohl des Core als auch Extensions.
Wenn ein Adminuser angelegt worden ist, so kam dieser auch an die FTP login Daten (sofern SMH aktiv) oder aber konnte durch installieren eigener Extensions (umbiegen des ER auf einen eigenen SOAP Server und installation von dort) die Dateien deiner Installation manipulieren. Somit ist der Installation nicht mehr zu trauen und man muss auf Nummer sicher gehen, dass kein malicious code eingeschleust wurde.

Je mehr ich darueber nachdenke, desto mehr Gefallen finde ich an der Idee ein tripwire fuer TYPOlight zu programmieren um solchen Manipulationen entgegen zu wirken.

Gruss
Chris (der paranoid denkt)

[sq......]

hallo,

sei mir nicht böse .... aber ... das ist kurz vorm eigenen bunker im keller ... aber trotzdem könnte man wenn man wollte den faden auch noch weiter spinnen ...

am besten den anbieter wechseln und dann am besten zu so einem der noch nie etwas von typolight gehört hat und auch kein ftp verwendet, am besten keine kunden hat und auch keine accounts auf seinen nicht vorhandenen server anbietet ...

grund ? ganz einfach 99 % der hostingprovider nutzen für kundenlogin und ftp-zugang die gleichen daten - zumindest für den erstzugang - weitere ca. 60 % verwalten über einen kundenaccount mehrere angebote ... wo man dann natürlich auch entsprechende änderungen vornehmen könnte ...

sicher kann man für die zukunft über entsprechende maßnahmen nachdenken ... aber momentan gibt es nicht eine meldung über einen angriff über genau diese sicherheitslücke ... ganz im gegenteil sind bisher mehr fehlermeldungen gekommen bei bereinigen dieser ... und da widerum zu 70% aus administrativer unkenntnis ...

die sicherheitslücke wurde von leo selbst entdeckt und nicht aufgrund bereits erfolgreicher angriffe auf das system ... also bitte keine panikmache ...

[xtra]

sei mir nicht böse .... aber ... das ist kurz vorm eigenen bunker im keller ...

Das gebe ich hiermit an dich zurueck. Siehe Ausfuehrungen unten.

am besten den anbieter wechseln und dann am besten zu so einem der noch nie etwas von typolight gehört hat und auch kein ftp verwendet, am besten keine kunden hat und auch keine accounts auf seinen nicht vorhandenen server anbietet ...

Quatsch. Warum sollte man dies?

grund ? ganz einfach 99 % der hostingprovider nutzen für kundenlogin und ftp-zugang die gleichen daten - zumindest für den erstzugang - weitere ca. 60 % verwalten über einen kundenaccount mehrere angebote ... wo man dann natürlich auch entsprechende änderungen vornehmen könnte ...

Das mit den gleichen Passwoertern trifft nur solange zu wenn man keine FTP accounts anlegt, welche einen eigenen "chroot" und daher ein eigenes Heimatverzeichnis aus welchem sie nicht entkommen koennen, was meines Wissens nach die 99% der Provider die du ansprichst gestatten und meist sogar raten.

sicher kann man für die zukunft über entsprechende maßnahmen nachdenken ... aber momentan gibt es nicht eine meldung über einen angriff über genau diese sicherheitslücke ... ganz im gegenteil sind bisher mehr fehlermeldungen gekommen bei bereinigen dieser ... und da widerum zu 70% aus administrativer unkenntnis ...

Ich wollte nicht andeuten, dass Angriffe stattgefunden haben und habe dies meines Wissens auch nirgendwo getan. Ich habe lediglich beschrieben, wie man bei einem kompromittierten System vorgehen sollte.
Dass die Fehlermeldungen durch den Patch groesstenteils aus administrativer Unkenntnis entstanden sind, brauchst du mir nicht zu sagen. Ich weiss ganz genau was die Luecke war, weiss genau wie ich sie exploiten koennte und weiss ganz genau, dass die Behebung derselbigen einen Nebeneffekt wie in den Meldungen beschrieben in keinster Weise hervorrufen kann.

die sicherheitslücke wurde von leo selbst entdeckt und nicht aufgrund bereits erfolgreicher angriffe auf das system ... also bitte keine panikmache ...

Wo genau habe ich bitte Panikmache betrieben?

Ich schrieb lediglich dass man einem, als kompromittiert erkannten, System nicht vertrauen darf, da jegliche Aenderung vorgenommen worden sein koennte.
Dies nun als Panikmache abzutun finde ich erlich gesagt auf's Groebste ungerecht und obendrein auch noch grob Fahrlaessig. Schliesslich impliziert es, dass man in einem solchen Falle nur den Backend User, welchen man nicht kennt, loeschen soll und dann passt alles.
Schoene heile Welt durch loeschen eines Datenbankeintrags.
Wenn du die E-Mail von Leo gelesen hast, dann wird dir sicher auch aufgefallen sein, dass er genau das von mir beschriebene Angriffsszenario auch dort geschildert hat (Stichwort: Template Editor).
Ich bin hier einen Schritt weiter gegangen und habe beschrieben wie man von einem solchen Angriff recovern sollte.

[EDITH meint]
nur um noch den letzten Zweiflen und Trollen den Wind aus den Segeln zu nehmen. Ich begruesse die Umgangsweise mit der Lycke und empfinde sie als vollkommen korrekt. Ebenso halten wir uns alle daran, die Details wie man es exploiten koennte nicht zu veroeffentlichen. Leo hat auch, da bin ich mir sicher, von uns allen Ryckendeckung in dieser Vorgehensweise. Ebenso bin ich sehr erfreut dass der Patch fyr alle Versionen bereit gestellt wurde und der Hinweis prominent an die ganze user community ging.
Jedoch geht mir der Hut hoch, wenn jemand wie du oben dann durch seine Aussagen impliziert dass es reicht wenn man ein kompromittiertes System patcht. Man kann einfach nicht wissen was alles modifiziert wurde.
[/EDITH]

morgendliche Grysse
Der boese Panikmacher aus dem OpenSource Lager [/SARCASM].

[matze]

Kurzer Einschub: Was meinst du mit TripWire?

[xtra]

Kurzer Einschub: Was meinst du mit TripWire?

Etwas in der Art von: http://sourceforge.net/projects/tripwire/
SunBlack geht mit seinem taic schon in die richtige Richtung. Jedoch muss man die Liste von einem vertrauenswuerdigen Server bekommen um sicher zu sein.
Genaue Gedanken habe ich mir hierzu noch nicht gemacht wie das genau aussehen soll, aber im Hinterkopf habe ich es auf jeden Fall.

[Thomas]

Zunächst erstmal danke für den Hinweis und den Patch!

Aber dennoch macht man aus einer Mücke gerade einen Elefanten.
Ohne das Risiko der Lücke mindern zu wollen.

Das man ohne Live Update bei vielen Projekten etwas mehr Arbeit bekommt steht auch ausser Frage.

Aber mal ganz ehrlich!?
Mit so etwas war doch zu rechnen, schon alleine aus dem Grund, dass nichts 100% sicher sein kann.

Man könnte jetzt von Pech oder Glück reden, dass TL noch nicht so weit verbreitet ist. In solchen Fällen wohl eher Glück, aber nichts desdo trotz werden in absehbarer Zeit sicherlich mehr Lücken aufkommen.

Und wenn Leo die ebenso schnell und mit Weitsicht fixed, sollte man kaum etwas befürchten.

Es ruft auch jeden Webmaster auf den Plan, der eher in seinem Interesse dafür sorgen sollte, z.B. Anbieter zu wählen die allen Features von TL zugänglich sind und man nicht mit technischen Tricks, Hacks oder anderen Ausweichmöglichkeiten hantieren muß.

Auch wird es mit der Erstellung von Modulen, Plugins und Sonstigem, Lücken geben. Die größten Beispiele für sowas sind ja Systeme wie Joomla, Typo3 und wie sie auch alle heißen und heißen werden.

Gibt es eigentlich Jemanden, der sowas kontrolliert, bevor es im Repository aufgenommen wird?

Um gewisse Sicherheitsfeatures zu integrieren, zu verbessern oder zu generieren, kann man ja gerne Vorschläge machen. Das aber konstruktiv und an richtiger Stelle.

Es bringt wohl kaum etwas, sich wegen geschriebener Wörter, die Niemand wirklich beurteilen kann, wie sie wirklich gemeint sind (nicht Jeder nutzt Smileys ) , an den Hals zu gehen.

In diesem Sinne, wünsche ich Euch geruhsame Weihnachten mit Euren Familien und laßt Euch den Weihnachtsbraten oder die Bockwurst schmecken.

[lucina]

Aloha,

Aber dennoch macht man aus einer Mücke gerade einen Elefanten.

Eben nicht. Das war keine Mücke, das war nahe am GAU. Mich erschüttert allerdings, wie gering bei manchen das Bewusstsein dafür ist.

Mit so etwas war doch zu rechnen, schon alleine aus dem Grund, dass nichts 100% sicher sein kann.

Es geht nicht darum, ob etwas 100% sicher sein kann - es geht darum, eine Architektur zu haben, die das abfängt, wenn was schiefgeht. Ich traue Leo da im Allgemeinen doch sehr über den Weg, was seine Fähigkeiten angeht - aber Jedem rutscht mal was durch, Serverkonfigurationen haben Fehler, MySQL ist nicht perfekt, und PHP-Updates sind buggy.

Ich muss das in meine Überlegungen und Planungen mit einbeziehen, wenn ich mit einem System auf einem exponierten Server arbeite - und Webserver sind das eben qua definitionem. Ich muss Vorkehrungen treffen, um nichts anderes geht es hier und bei Leos Frage, ob das Installtool umbenannt gehört oder nicht ('security by obscurity' geht für mich gar nicht - frag mal jemand bei Diebold an, was die davon halten ...).

Man könnte jetzt von Pech oder Glück reden, dass TL noch nicht so weit verbreitet ist. In solchen Fällen wohl eher Glück, aber nichts desdo trotz werden in absehbarer Zeit sicherlich mehr Lücken aufkommen.

Wohl wahr, mit Glück hat das allerdings wenig zu tun. Ich schaue gerne über den Tellerrand, ich schaue mir gerne auch mal detailliert an, was sich so auf meinen Servern tummelt. Einen Vorteil, den ich bei TL sehe ist die klare Struktur, die (bei verständiger Herangehensweise) die Zahl der Einfallstore auf ein Minimum beschränkt.

Und wenn Leo die ebenso schnell und mit Weitsicht fixed, sollte man kaum etwas befürchten.

Darauf konntest Du Dich in der Vergangenheit quasi verlassen - möchtest Du das auch in jeder möglichen Zukunft tun? Nix gegen Leo, aber ich möchte das nicht.

Es hat ja hier nun auch eine Reihe sehr konstruktiver Vorschläge gegeben, das System vom Design her sicherer zu machen.

Die Verlagerung des Datenbank-Updates in die Systemwartung, die Andreas vorgeschlagen hat, bietet da ein paar Ansätze - wobei ich es ehrlich gesagt noch nie verstanden habe, weshalb die Wartungsfunktionen, Installationsfunktionen und die eigentliche Anwendung nicht vollständig voneinander getrennt sind. Diese 'install.php' mitten im TL-Verzeichnis war mir ein steter Dorn im Auge.

Zertifikatssicherheit ist nett, secureFTP nutze ich, wo immer ich kann - und das gehört in TL vollständig integriert, in den Core als Feature.

Tripwire ist ein feiner Ansatz, da gebe ich Xtra recht.

Install-Tool löschen wäre auch eine Möglichkeit, ja. Umbenennen ist nur die halbe Miete.

Grundsätzlich würde ich es begrüßen, wenn die in der localconfig abgelegten Daten außerhalb des TL-Zugriffes ständen. eGroupware macht das aus meiner Sicht schn relativ richtig, da wird eine header.php mit den Settings und Daten inkludiert, so sie denn bestimmte Voraussetzungen hat (nur Lesezugriff, außerhalb des eigentlichen Verzeichnisses, nur mit einem separatem Tool zu bearbeiten, mit einem Hash gesichert, der in der systemeigenen Datenbank steht und verglichen wird - schlägt die Prüfung fehl, dann ist das System für jedwede Änderungen blockiert).

Es ruft auch jeden Webmaster auf den Plan, der eher in seinem Interesse dafür sorgen sollte, z.B. Anbieter zu wählen die allen Features von TL zugänglich sind und man nicht mit technischen Tricks, Hacks oder anderen Ausweichmöglichkeiten hantieren muß.

Leider eben nicht.

Auch wird es mit der Erstellung von Modulen, Plugins und Sonstigem, Lücken geben. Die größten Beispiele für sowas sind ja Systeme wie Joomla, Typo3 und wie sie auch alle heißen und heißen werden.Gibt es eigentlich Jemanden, der sowas kontrolliert, bevor es im Repository aufgenommen wird?

Das stände an, ja. Ich habe das aber hier (bzw. im alten und im sehr alten Forum schon erlebt, dass da ErstellerInnen von Extensions so richtig angemacht worden sind, weil sie mal eben aus einem Modual heraus und am Core vorbei ein paar PHP-Funktionen aufgerufen haben ... Allerdings sieht Qualitätssicheruung gewiss anders aus. Hier braucht es welche, die sich das systematisch anschauen.

In diesem Sinne, wünsche ich Euch geruhsame Weihnachten mit Euren Familien und laßt Euch den Weihnachtsbraten oder die Bockwurst schmecken.

Ich wünsche Dir & Euch dasselbe!
Mit besten Grüßen,
Carolina.

[lindesbs]

Aus aktuellem Anlass moechte ich dann doch noch meinen Senf dazu geben :
So wie lucina eben auch schon schrieb, das war /ist keine Muecke.

Ein Betreiber einer Webseite (egal ob privat oder als Firma) ist fuer den Inhalt SELBST verantwortlich. Wenn nicht er, dann die Person im Impressum. Letztlich der Admin-C, der Verantwortliche fuer die Domain.
Wenn es nun jemanden gelingt, sich in das/ein System einzuhacken, kann eer dort versteckt fuer jedermann Code hinterlassen.
Er kann die Webseite kompromittieren, mittels neuem Text, aber er kann auch iFrames hinterlassen, die schadhafte Dinge machen. Und wenn jemand ueber die Webseite auf das System kommt, und SpamMails oder Viren weiterverbreitet, ist der BETREIBER der Seite dafuer verantwortlich.

Und eben sowas ging mit dem Bug. Man hatte ZUGRIFF auf das System. Es wird nicht heruntergespielt, oder Muecken gemacht, oder Boesewichte definiert.
Es geht hier nicht nur um Leo und sein TL System. Er hat richtigerweise den Fehler in allen Versionen gefixt, Patches hingestellt, aber mehr kann er nicht machen.
Jeder Betreiber einer Installation ist SELBST fuer den Inhalt verantwortlich. Und das muss klar werden.
Ich will hier niemanden seine TL Kenntnisse oder ISP Kenntnisse aberkennen, so wie es mir per PN schon angedeutet wurde. Aber eine Installation ist nur so gut, wie der Betreuer sie pflegt, und da reicht es eben manchmal nicht nur zwei Dateien hochzuladen und gut ist. Man muss eben auch kontrollieren, was passeirt sein kann. Passwoerter aendern bringt auch nichts, wenn JEMAND in einem Artikel etwas kompromitierendes angepasst hat.

Somit ist jeder selbst verantwortlich und aufgerufen, seine Installationen z uueberpruefen und zu kontrollieren. Das kann Leo ihm leider nicht abnehmen. Das Framework ist gut, aber eine gewisse Art von Selbstkontrolle und Verantwortung muss einfach da sein.

Man darf ja Auto auch nur mit Berechtigung fahren. Manchmal waere sowas auch fuer andere Dinge sinnvoll...

Soviel dazu.

Stefan aka lindesbs