Schwere Sicherheitslücke im TYPOlight-Installtool

**FloB** · 19.12.2009, 17:02

Zitat von leo.unglaub

Kleiner Tipp von jemandem der täglich mehrere GB Log Files managen muss. grep + awk

Danke … awk müsst ich mich aber einarbeiten, das geht nicht so schnell ;-).

**mv_alex** · 19.12.2009, 17:02

@Leo: Danke für die schnelle Antwort! Fremde Konten gibt es bei mir nicht, und die Passwörter funktionieren noch, wurden also nicht geändert.

Ich habe aber ein anderes Problem bemerkt, was möglicherweise auf einen Fehler in der neuen Version hindeutet.

Anmerkung von Nina: Danke für deine schnelle Reaktion, ich hab das gleich zu deinem Thread verlinkt

Edit: Danke Dir

Nachtrag: Das Problem kam nicht vom Update-Patch - falscher Alarm.

***Nina*** · 19.12.2009, 17:11

Alex, mach dafür bitte am besten ein eigenes Thread im Kernforum auf.

**stoffel** · 19.12.2009, 17:41

Es ist zwar schon ein paar mal gefragt worden, aber eine (brauchbare) Antwort hat es leider bislang noch nicht gegeben. Deshalb von mir auch noch einmal ein Versuch:

Patches sind installiert ... alles wunderbar ... nun würde ich aber gerne zusätzlich auch die beschriebene .htaccess-Datei einbinden. Das funktioniert aber leider nicht, denn der Server meldet:

500 Internal Server Error: The server encountered an internal error or misconfiguration and was unable to complete your request...

Hat jemand 'ne Idee was das Problem sein könnte. Dank an alle ...

***leo*** · 19.12.2009, 18:03

Für die Klärung dieser Frage machst Du am besten auch einen eigenen Thread auf.

**TLight** · 19.12.2009, 18:27

Von meiner Seite auch herzlichen Dank für die Warnung per E-Mail und das äußerst einfache Updaten per LiveUpdate! So etwas findet man kein zweites Mal...

Auch ich möchte gerne den zusätzlichen Schutz per .htaccess, würde aber eine noch detailliertere Beschreibung benötigen, da ich an einer so zentralen Stelle nicht einfach aufs Geratewohl herumpfuschen möchte.
Muss im Ordner /typolight/ manuell eine ._htaccess erstellt und der beschriebene Inhalt eingefügt werden? Sind weitere Anpassungen nötig? Funktioniert diese Änderung sicher auf jedem System - auch mit SMH?

Wäre toll, wenn das noch genauer beschrieben werden könnte. Soweit auf jeden Fall die Note 1 für hervorragende Arbeit!

**Andreas** · 19.12.2009, 18:36

Auf die Frage: 'Wo soll die .htpasswd liegen?'. Sie sollte nicht unbedingt im selben Ordner liegen. Bei mir liegt sie außerhalb des zugänglichen Bereichs oberhalb von html/. Sie kann auch in einem Ordner liegen, welcher mit einer anderen .htaccess für alle gesperrt ist.

Andreas

**monachus** · 19.12.2009, 19:08

@stoffel

hier im Thread gabs doch die Antwort, hat bei mir geholfen:
https://community.contao.org/de/show...9&postcount=19

**bzaiser** · 20.12.2009, 11:49

Hallo,

habe gestern auf allen meinen Sites gleich den Patch eingespielt.

Alles lief danach prima.
Heute will ich mich im Backend auf einer Seite einlogen aber mein Passwort geht nicht mehr.

Hab über phpmyadmin das Kennwort durch kopieren von einem anderen User wieder erhalten und auch geändert..

Kann es sein das jemand das DB Kennwort über die Lücke gehackt hat und meinem Adminuser ein neues Kennwort verpasst hat?

Db Kennwort hatte ich bei Strato geändert, aber das Installtool aktzeptiert immer nur das alte DB Kennwort (dauert das evetuell länger bei Strato?)

Wie kann ich herausfinden ob manipuliert wurde, in welchem Log soll ich nach was suchen?

Grüßle

Bernd

sq...... · 20.12.2009, 12:02

hi,

also ich muss schon sagen, das es mich unheimlich erstaunt, wieviele websiteadmininstratoren sich mit dem ändern der passwörter schwer tun.

es kann doch für einen administrator nicht das problem sein via FTP und einem Editor in der root/system/config/localconfig.php die beiden einträge für

Code:

$GLOBALS['TL_CONFIG']['dbPass'] = 'Mein neues Passwort';
$GLOBALS['TL_CONFIG']['ftpPass'] = 'Mein neues Passwort';

entsprechend neu zu setzen ...

**Sarvo** · 20.12.2009, 12:45

Zitat von bzaiser

Db Kennwort hatte ich bei Strato geändert, aber das Installtool aktzeptiert immer nur das alte DB Kennwort (dauert das evetuell länger bei Strato?)

Hallo Bernd,

ja das kann bei Strato manchmal etwas länger dauern. Wart einfach mal ab und probier es nochmal

Liebe Grüße

**bird** · 20.12.2009, 14:39

Hallo,

das wurde hier zwar auch schon gefragt aber bisher noch nicht beantwortet.

Unabhängig vom Überschreiben der zwei genannte Dateien kann doch statt einer Sicherung mittels .htaccess auch das Umbenennen/Löschen der Install-Dateien ein probates Mittel sein, wenn nur manuelle Updates gefahren werden?

Ich meine mich zu erinnern, dass vor einigen Monaten sogar mal darauf hingewiesen wurde, dass nach der Installation die install.php umbenannt werden sollte. Mich hat es immer schon etwas gestört, dass diese Dateien sonst "offen" rumliegen.

***leo*** · 20.12.2009, 15:13

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

1. Löschen der install.php
Nachteil: muss bei Updates manuell wieder hochgeladen werden.

2. Umbenennen der install.php
Nachteil: kann nicht mehr aufgerufen werden (Umleitungsschleife).

3. Einfügen einer exit;-Anweisung am Anfang der Datei
Nachteil: muss bei Updates manuell wieder freigegeben werden.

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

5. Passwortschutz für die install.php
Benötigt die FilesMatch-Direktive, ist aber sonst die beste Option.

6. Passwortschutz für das gesamte Backend
Sicherste Lösung, allerdings müssen sich dann auch die Redakteure doppelt anmelden.

**ChrMue** · 20.12.2009, 15:28

Vielen Dank auch von mir.
... und nun noch einen schönen 4. Advent

ChrMue

**tlightuser** · 20.12.2009, 16:54

Danke für die Informationen, sowie schneller Reaktion hinsichtlich vorübergehender Lösungsvorschläge. Ich sehe das jetzt einmal positiv. Je bekannter ein System ist, desto interessanter wird es sein, solch ein System zu hacken. Welche Neider und "DEPPEN" sind das wohl? Es wird doch nicht die OpenSource-Konkurrenz sein

.

**cgpro** · 20.12.2009, 17:44

so, knapp 30 systeme geupdatet und nichts bemerkenswertes in den logs gefunden.

bei einem system war jedoch etwas merkwürdig.

zum einen stand dies im log:
[2009-12-06 22:19] No active page for page ID "typo3conf", host "..." and langua … Löschen Anzeigen
[2009-12-06 22:19] No active page for page ID "typo", host "..." and languages " … Löschen Anzeigen
[2009-12-06 22:19] No active page for page ID "typo3", host "..." and languages … Löschen Anzeigen
[2009-12-06 22:19] No active page for page ID "tp", host "..." and languages "en …

da hat anscheinend jemand rumprobiert oder es war ein bot der sicherheitslücken systematisch an typo3 systemen ausfindig machen wollte.
Browser: Toata dragostea mea pentru diavola

zum anderen wurde auch ein fremder benutzer angelegt. (ohne ausgefüllte felder)

ob das jetzt auch andere typolightsysteme betrifft bzw. betreffen wird, keine ahnung. aber ein blick auf die logs schadet nicht wenn man das update einspielt.

**Jogibär** · 20.12.2009, 17:58

Danke dir ebenfalls, Leo,
besonders deine Mail von heute haben mir die Augen geöffnet,
dass es nicht bloß um das Löschen von Daten geht, sondern
auch um den Missbrauch des Servers bzw. des Speicherplatzes.

Gruß
Jürgen

**TheGeek** · 21.12.2009, 07:49

Also ich muss die Vorgehensweise echt mal Loben. Abgesehen davon das der Showroom vom Netz ist und die Fehlermeldung als Mail versandt wurde, werden auch möglichst wenig Infos zur Sicherheitslücke bekannt gegeben so das nur Leute die sich etwas mit der Materie befassen das Problem auch wirklich verstehen. Sehr Diskret ! ... mein erster Blick nach der Mail fiel auf diverse Exploid Seiten um raus zu bekommen ob die Meldung schon Public ist ...

**Russe** · 21.12.2009, 08:22

Zitat von squidi

Code:

$GLOBALS['TL_CONFIG']['dbDatabase'] = 'Mein neues Passwort';
$GLOBALS['TL_CONFIG']['ftpPass'] = 'Mein neues Passwort';

Du meinst sicher

Code:

$GLOBALS['TL_CONFIG']['dbPass']

**klaus_tkm** · 21.12.2009, 08:28

Zitat von cgpro

da hat anscheinend jemand rumprobiert oder es war ein bot der sicherheitslücken systematisch an typo3 systemen ausfindig machen wollte.
Browser: Toata dragostea mea pentru diavola

Auch bei mir gibt es diesen Browser im Log !

Code:

IP Adresse:	113.11.203.102
Browser:	Toata dragostea mea pentru diavola

und

Code:

67.205.89.102
Browser:	ZmEu

Gesucht wurde gezielt nach "phpmyadmin" in den verschiedensten Schreibweisen, die ich hier bewußt nicht anführe...ganze Liste von 20-25 Versuchen die Datenbank zu erreichen, von beiden IPs...

Gut, dass meine Datenbank nicht über diese Domain erreichbar ist......

lg Klaus

sq...... · 21.12.2009, 08:41

Zitat von Russe

Du meinst sicher

Code:

$GLOBALS['TL_CONFIG']['dbPass']

oups , ja natürlich du hast recht ... ich habs verbessert

**Mip** · 21.12.2009, 08:48

Zitat von cgpro

da hat anscheinend jemand rumprobiert oder es war ein bot der sicherheitslücken systematisch an typo3 systemen ausfindig machen wollte.
Browser: Toata dragostea mea pentru diavola

ist übrigens rumänisch, und heißt: "Meine ganze Liebe für die Teufelin"

Gruß, Claudiu

**andrewj** · 21.12.2009, 10:35

Hallo ich habe jetzt ein neues Problem:

Nach dem Update, das Problemlos funktionierte, kann ich leider keine Artikel mehr bearbeiten. Er löscht mir den kompletten Inhalt, wenn ich einen Artikel bearbeiten möchte!

Hat jemand einen Rat?

**ricola** · 21.12.2009, 12:12

Auch von mir ein dickes Danke für die Sicherheitswarnung. TL - absolut cool

LG. Ricola

**andrewj** · 21.12.2009, 13:18

Wenn man direkt updated ist es eventuell auch unnötig FTP Zugang etc. zu ändern, oder? Klar weiß man nicht ob nicht schon jemand dran war.

Hat jemand schon nen Hack gehabt?

Dieses Artikelproblem ist echt immernoch nervig. Ist das ein Bug, oder?

***lucina*** · 21.12.2009, 13:22

Zitat von andrewj

Dieses Artikelproblem ist echt immernoch nervig. Ist das ein Bug, oder?

Ich kann das nicht nachvollziehen - ich habe am Samstag 45 Systeme gepatched (mit TL-Versionen zwischen 2.5 und 2.75), bei keinem trat das auf.

Vielleicht schreibt Ihr mal was zu Hoster, PHP-Version, welcher Webserver, TL-Versionen etc., damit man das mal ein wenig besser eingrenzen kann.

Mit besten Grüßen,
Carolina.

**Lions_Den** · 21.12.2009, 13:41

super: die schnelle reaktion und der patch
scheisse: ich bin im urlaub

naja wird schon klappen

***Nina*** · 21.12.2009, 13:47

Zitat von andrewj

Hallo ich habe jetzt ein neues Problem:

Nach dem Update, das Problemlos funktionierte, kann ich leider keine Artikel mehr bearbeiten. Er löscht mir den kompletten Inhalt, wenn ich einen Artikel bearbeiten möchte!

Hat jemand einen Rat?

Öffne dafür bitte ein eigenes Thread im Kernforum, da das wohl nur ein Problem bei deinem Webspace ist.

**andrewj** · 21.12.2009, 13:49

Also in beiden Fällen ist DF.eu der Provider

PHP ist Version 5

Browser Firefox 3.5 unter OS X

**andrewj** · 21.12.2009, 14:15

Vorführeffekt, hat sich gerade erledigt.

Keine Ahnng warum das passiert ist, aber nu ists vorbei.

**Sebastian** · 21.12.2009, 14:48

HI

seltsam, nun ist der Montag schon halb vorbei, und bisher ist nichts wesentliches in irgendwelchen Nachrichtenportalen. Das ist doch gut, oder?

Sebastian

**cgpro** · 21.12.2009, 14:54

hm... besser ists wenns in die nachrichtenportale kommt. es liesst nicht jeder hier im forum mit oder hat die "große" email bekommen

ein imageschaden fürs system ists allemal. aber das problem haben glaub ich alle anderen auch (t3, joomla, drupal und co)

sq...... · 21.12.2009, 14:54

Zitat von Sebastian

... seltsam, nun ist der Montag schon halb vorbei, und bisher ist nichts wesentliches in irgendwelchen Nachrichtenportalen. Das ist doch gut, oder? ...

hi sebatian,

ganz so ist es nicht ... vertraulichen informationen zur folge ist das nur die ruhe vor dem sturm ... hinter den kulissen brodelt es , der plutoniumhandel ist in den letzten tagen erheblich gestiegen, man munkelt ... einige russische TL seitenbetreiber wollen zum gegenschlag ausholen ...

sq...... · 21.12.2009, 14:57

hi,

man muss auch ganz klar bedenken , das leo die sache ja selbst entdeckt hat und anscheinden niemand anderes zuvor , der diese lücke ausnutzen konnte ... es wäre bestimmt was ganz anderes , wenn sich die medien auf eine hiobsbotschaft stürzen könnten ...

**Toflar** · 21.12.2009, 15:01

Für mich ist es eher ein Imagegewinn als -schaden...

Bugs kommen vor, das ist eine Tatsache und nichts Aussergewöhnliches!

Wie hier mit dem Thema umgegangen wird spricht für TYPOlight

**madi** · 21.12.2009, 15:49

Auch von mir herzlichen Dank an Leo. Schade nur, dass es keinen Newsletter gibt, sondern nur Foren User informiert werden konnten.

**Sebastian** · 21.12.2009, 16:06

HI

man kann ja den RSS-Feed abonnieren.

@Squidi: Ich bin mit dem Plutoniumgeschäft nicht so vertraut, aber ich danke dir für den Einblick

Sicher kommt da noch was, und wenn Heise extra wartet finde ich das toll.

Und Leo hat das subjektiv genau richtig gemacht.

Sebastian

**Compadre** · 22.12.2009, 09:37

Hallo zusammen,

bin eher Designer als Programmierer, habe gepatcht und auch die .htaccess eingespielt über ftp. Wenn ich jetzt versuche, mich über die install.php anzumelden, kommt ein "500 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request..."
- Mit welchen Daten muss ich mich da einloggen? Oder wo muss ich noch zusätzliche PWs einrichten?
Wer kann helfen?

Vielen Dank,
Compadre

Zitat von hanuman

ja, da schließe ich mich an.

Danke

Schöne und schnelle Reaktion (es sei denn die Lücke ist schon ein Jahr bekannt

- geh ich aber nicht von aus)

patchen war easy ...
per .htaccess

Code:

<FilesMatch "(ftp|install)\.php$">
  AuthName "TYPOlight back end"
  AuthType Basic
  AuthUserFile .htpasswd
  require valid-user
</FilesMatch>

und

Code:

user:crypt(pass)

in der .htpasswd führte aber zu einem internal Server error NACH korrekt beantworteter Sicherheitsabfrage.
Aber egal, das patchen war easy.
entspannte Feiertage schonmal

***leo*** · 22.12.2009, 09:58

Der Fehler deutet darauf hin, dass Du die FilesMatch-Direktive nicht verwenden darfst. Dein Serveradmin sollte das umstellen können.

sq...... · 22.12.2009, 11:40

Zitat von leo

Der Fehler deutet darauf hin, dass Du die FilesMatch-Direktive nicht verwenden darfst. Dein Serveradmin sollte das umstellen können.

hallo 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 ...