Zum Inhalt springen

Wiederholte Attacken auf Typo3-Seite

Erstellt am 16. Mai 2007 · 65 Antworten · letzte Antwort am 5. September 2007 · Seite 1 von 4

Tags: Sicherheit, Frage

nickno ·

Hallo,

ich hatte das Problem die Tage auch, als ich zufällig auf einer Kunden-Seite war. Konnte aber ebenfalls keinen Fehler in T3 ausmachen. Hast du/habt ihr eine Lösung (Hack) dafür gefunden? Wenn dem so ist, dann würde ich mich über eine kurze PM freuen.

Wenn nicht, dann würde ich dich/euch bitten, die Infos für euch zu behalten, damit die Info nicht zu weit rumgeht... Dann macht es nämlich keinen Sinn, die Schwachstelle rumzuschicken - ausser an das Security Team.

Danke&Gruß,
Tim

//edit: Rechtschraibfeder

iHunte ·

Einige von unseren Seiten sind auch von dem Code verdreckt worden.

So wie es aussieht ist es kein Sicherheitsproblem von TYPO3 da der
"Bot" (Ich gehe jetzt mal sehr stark davon aus das ein Bot die Seiten
infiziert) bei uns auch statische Seiten infiziert hat. Dazu zählen
z.b. auch andere CMS.

Es scheint so als sei der Fehler direkt im System bzw. in einer
Systemweiten Software.

Benutzen hier alle UNIX oder gibt es hier auch jemanden der das
Problem in einer Windows Server Umgebung hat?

nickno ·

Da ich den Weg gefunden habe, WIE in das System eingebrochen wurde und es noch keinen Fix dafür gibt, möchte ich das noch nicht öffentlich machen.
Ich schreibe ein Privatnachricht, in der ich darauf näher eingehe.

Anscheinend liegt es aber doch an Typo3... 😉

iHunte ·
nickno schrieb

Da ich den Weg gefunden habe, WIE in das System eingebrochen wurde und es noch keinen Fix dafür gibt, möchte ich das noch nicht öffentlich machen.
Ich schreibe ein Privatnachricht, in der ich darauf näher eingehe.

Anscheinend liegt es aber doch an Typo3... 😉

Wieso bist Du dir da so sicher?

Ich denke aus seinem Posting geht nicht hervor welche Methode genutzt wurde um den code einzufügen. Wie ich bereits geschrieben habe sind auch statische nicht-TYPO3 Seiten davon betroffen die in keinem Zusammenhang mit den TYPO3 Systemen stehen.

jan.​radecker ·
iHunte schrieb

Ich denke aus seinem Posting geht nicht hervor welche Methode genutzt wurde um den code einzufügen. Wie ich bereits geschrieben habe sind auch statische nicht-TYPO3 Seiten davon betroffen die in keinem Zusammenhang mit den TYPO3 Systemen stehen.

Nunja, der Einbruch erfolgte bei mir mittels einer Schwachstelle in einer TYPO3-Extension.
Der Schadcode selbst wurde aber an unterschiedlichen Stellen angebracht.
Mal ware er direkt in der index.php an erster Stelle drin,
dann im Seitentitel (in der DB) mit eingebaut,
dann in einer Javascript-Datei als "verschlüsselter" Code, der per DocumentWrite in die Seite geschrieben wurde.
Der Angreifer war da sehr Ideenreich.

Daher kann das schon sein, dass über die TYPO3-Schwachstelle der Einbruch erfolgte, und dann auch statische Dateien manipuliert wurden.

just2b ·
jan.radecker schrieb

Nunja, der Einbruch erfolgte bei mir mittels einer Schwachstelle in einer TYPO3-Extension.

und zwar welcher?
georg

jan.​radecker ·
nickno schrieb

Wenn nicht, dann würde ich dich/euch bitten, die Infos für euch zu behalten, damit die Info nicht zu weit rumgeht... Dann macht es nämlich keinen Sinn, die Schwachstelle rumzuschicken - ausser an das Security Team.

Genau deshalb gebe ich mich (auch in der PM) sehr bedeckt.

Da alles auf gegenseitigem Vertrauen basiert - und ich dieses generell erst mal nicht habe - bin ich lieber zu verschwiegen und trete dabei dem einen oder anderen auf die Füße, als mir den Vorwurf machen zu lassen, ich hätte den Exploit rumposaunt.

jan.​radecker ·
just2b schrieb

und zwar welcher?
georg

Hast 'ne PM.

Was mir noch auffällt:
zwei Wochen bleibt der Originalbeitrag unbeantwortet, aber kaum nachdem ich verkündet habe, ich wüsste, wie es geht, haben plötzlich alle das Problem.... #paralyzed#

nickno ·
just2b schrieb
jan.radecker schrieb

Nunja, der Einbruch erfolgte bei mir mittels einer Schwachstelle in einer TYPO3-Extension.

und zwar welcher?
georg

Bitte nicht posten. Da der Jan den Fehler schnell gefunden hat, wird diese sicher recht trivial sein!

humpun ·
nickno schrieb
just2b schrieb
jan.radecker schrieb

Nunja, der Einbruch erfolgte bei mir mittels einer Schwachstelle in einer TYPO3-Extension.

und zwar welcher?
georg

Bitte nicht posten. Da der Jan den Fehler schnell gefunden hat, wird diese sicher recht trivial sein!

Schwachsinn. Der Exploit ist schon mit einem Bot unterwegs und es sollte eigentlich so schnell wie möglich mal ein Patch erscheinen. Infiziert sind schon eh die meisten.

nickno ·
jan.radecker schrieb
just2b schrieb

und zwar welcher?
georg

Hast 'ne PM.

Fühl mich benachteiligt... 😉

Was mir noch auffällt:
zwei Wochen bleibt der Originalbeitrag unbeantwortet, aber kaum nachdem ich verkündet habe, ich wüsste, wie es geht, haben plötzlich alle das Problem.... #paralyzed#

Nein, ich dachte der Fehler sei lokal auf dem Computer und hab nicht den Quelltext nach Fehlern durchsucht. Stattdessen hab ich mir diesen (komischen) Spybot installiert, der widerum nichts finden konnte. Nachdem Java aus war, hatte ich auch erstmal Ruhe.

nickno ·
humpun schrieb

Schwachsinn. Der Exploit ist schon mit einem Bot unterwegs und es sollte eigentlich so schnell wie möglich mal ein Patch erscheinen. Infiziert sind schon eh die meisten.

Woher bist dir so sicher, dass das nen Bot ist. Vielleicht ist es auch einfach nur wieder ein dummer Schüler, der Langeweile hat. Wie ich das sehe sind momentan etwa eine Handvoll Seiten hier im Forum betroffen. Also wird es sich um <50 Seiten handeln. Wenn man den Exploit kennt, kann man sowas am Nachmittag verbreiten.

just2b ·

Meine güte..

als ob das spekulieren was bringt....
Jan hats dem Security-Team gemeldet und gibt auch per PM den ext-key nicht raus (auch nicht an mich [@nickno]).

also einfach warten oder auf die gnade von jan hoffen, per PM informiert zu werden 😉

georg

nickno ·

[OFFTOPIC]

just2b schrieb

Meine güte..
(auch nicht an mich [@nickno]).

Sorry, kam wohl etwas zu ernst rüber... :o

also einfach warten oder auf die gnade von jan hoffen, per PM informiert zu werden 😉

In diesem Forem fehlt der BB-Smily, der um Gnade bettelt o.O

[/OFFTOPIC]

jan.​radecker ·
humpun schrieb

Schwachsinn. Der Exploit ist schon mit einem Bot unterwegs und es sollte eigentlich so schnell wie möglich mal ein Patch erscheinen. Infiziert sind schon eh die meisten.

Die Zugriffsmuster in meinen Protokollen sehen aber mehr nach "Handarbeit" aus...
Alleine des zeitlichen Verlaufs wegen.

iHunte ·

Hm, bei uns sind auf verschiedenen chroot Verzeichnissen fast gleichzeitig zugriffe. Die timestamps der bearbeitung liegen alle nur einige Sekunden
auseinander (darum gehen von einem Bot aus).

Naja spekulation.

Mir ist noch aufgefallen das alle Dateien in denen das wort "index" auftauchte
mit diesem Code infiziert waren. Ganz egal in welchem Verzeichnis.

nickno ·

Mich wundern nur die Berichte, wonach auch statische Dateien manipuliert worden sind?

Ein großes Danke jedenfalls an die Personen, die zur Lösung beigetragen haben!!

jan.​radecker ·
nickno schrieb

Mich wundern nur die Berichte, wonach auch statische Dateien manipuliert worden sind?

Na, dann will ich mal Butter bei die Fische geben:

Die SQL-Injection-Schwachstelle ermöglichte es per Brute-Force und ein wenig SQL-Magie z.B. aus der Tabelle be_users einen Admin-User samt MD5-Passwort auszulesen.
Mit diesen Daten und einem manipulierten POST-Datenstrom* auf der TYPO3-Backend-Loginseite konnte sich der Angreifer als Admin ganz regulär anmelden. Dann kann der Angreifer ja prinzipiell alles tun, was dem Admin eben erlaubt ist, insbesondere (eigene Hacker-) Extensions installieren oder Dateien im Fileadmin bearbeiten.

In meinem Fall hat sich der Angreifer verschiedene (russische) Webshells und SQL-Shells installiert, über die er dann mit den Rechten des Webspaceusers alle ihm zugänglichen Dateien (eben auch statische HTML-Seiten) manipulieren konnte.
Hier zeigt sich dann wieder, wie wichtig eine Rechte- und Betriebssystem-technische Abschottung der Webspaces untereinander ist. Ist das System der Abschottung nicht 100%ig dicht, kann der Anwender z.B. die localconf von anderen Webspaces auslesen und so mit der SQL-Shell auch dort pages manipulieren oder die Passworte auslesen.

*)
Der Angreifer errechnet den an den Server zu sendenden verschlüsselten Anmeldestring selbst aus Username, MD5-Passwort und Challenge als MD5 über den entsprechend zusammengesetzten String.

P.S.
Ich wollte mit meiner verschlossenen Art und Weise nur sicherstellen, dass VOR einem offiziellen Fix so wenig Leute wie möglich die Schwachstelle kennen und eventuell in schlechter Absicht missbrauchen.
Da der Fehler im Quellcode recht offensichtlich ist, reicht einem erfahrenen Angreifer wahrscheinlich in der Regel schon der Hinweis, in WELCHER Extension eine Lücke ist, um sie zu finden.