Seite gehackt trotz Contenido 4.6.4

risibility · Beitrag von **risibility** » Mi 21. Dez 2005, 15:02

Also ich weiß nicht mehr weiter...

Ich habe am Dienstag (13.12.05) das Contenido 4.6.4 neu auf den Server gespielt (war auch genug Platz nachdem mir die Hacker den ganzen Server leer geräumt haben) und angefangen die Seite neu aufzubauen. Jetzt war ich heute endlich soweit, dass die Seite sogut wie wieder steht und machte ein Backup via FTP und eines der DB. Zu meinem erstaunen musste ich feststellen, das ich eine Reihe von Hackertools auf dem Server hatte.

Vor der Contenido installation hatte ich nichts auf dem Server, also kann es vorher nicht dort gewesen sein. Passwörter sind seit dem besagten Tag scon 3 mal geändert worden.

Ohne jemanden zu nahe treten zu wollen, aber das kann nur vom Contenido her kommen! Was soll ich nun tun?

Beitrag von **emergence** » Mi 21. Dez 2005, 15:11

check die server logs... wenn der angriff wirklich über contenido stattgefunden hat, muss dort der einstiegspunkt ersichtlich sein...

risibility · Beitrag von **risibility** » Mi 21. Dez 2005, 15:41

Wenn ich wüßte wie ich die finde? Ich habe da nur so eine statistik, kann aber nichts über einstigspunkte finden...

risibility · Beitrag von **risibility** » Mi 21. Dez 2005, 15:41

Der Server steht bei 1und1 und mit denen habe ich gerade telefoniert. Die sagten das es an einem php-script liegen würde?!?

Beitrag von **Halchteranerin** » Mi 21. Dez 2005, 15:45

risibility hat geschrieben:Der Server steht bei 1und1 und mit denen habe ich gerade telefoniert. Die sagten das es an einem php-script liegen würde?!?

Haben sie auch gesagt, an welchem? Contenido besteht ja praktisch nur aus PHP-Dateien.

risibility · Beitrag von **risibility** » Mi 21. Dez 2005, 15:47

das hab ich die auch gefragt, aber darauf gab es leider keine Antwort...

Ich habe in den Logs die ich habe einen anonymen FTP Zugriff. Aber ich habe garkein anonymen FTP zugang auf meinem server... das war diesen Montag.

risibility · Beitrag von **risibility** » Mi 21. Dez 2005, 15:49

die IP ist aus Tokyo...
...wahrscheinlich nen proxy?!?

Martuno · Beitrag von **Martuno** » Mi 21. Dez 2005, 19:10

Kann leider nicht direkt weiterhelfen, aber FTP ist übrigens ebenso ein Sicherheitsrisiko. (pwd im Klartext)

Nimm doch z.B. http://winscp.net/ für etwas Sicherheit! (SCP oder SFTP)

Gruss
Martin

PS: kenne es auch erst seit unser CSO (Chief Security Officer) droht FTP ganz abzustellen. Ist aber super...

risibility · Beitrag von **risibility** » Do 22. Dez 2005, 08:58

Martuno hat geschrieben:Nimm doch z.B. http://winscp.net/ für etwas Sicherheit! (SCP oder SFTP)

Danke Martuno, ist ein guter Tipp. Werde das mal gleich runterladen. Ist schade das ich nicht wirklich rausbekomme woran es gelegen hat...

Ich werde einfach jeden Tag mal die ganze Seite runterladen und auf Hackertools checken... Mal schauen was die Zeit so bringt

kummer · Beitrag von **kummer** » Do 22. Dez 2005, 11:56

es gibt verschiedene probleme. das wichtigste ist wohl, dass das backend - mindestens standardmässig - nicht über ssl bedient wird. konktret bedeutet das, dass bei der anmeldung stets der benutzername und das passwort im klartext übertragen wird. und danach wird die session-id im klartext übertragen. alle sicherheitspatches von contenido werden nicht viel bringen, wenn die bedienung des backend nicht über ssl erfolgt.

das zweite problem ist die tatsache, dass es möglich sein muss, in das dateisystem zu schreiben. ein umstand, der es eben ermöglicht, dass schaden-code auf dem system gespeichert und anschliessend ausgeführt wird. das wäre im übrigen nicht nötig. die speicherung von bildern und dokumenten für den download könnte im prinzip - mit geringen leistungseinbussen - auch in die datenbank erfolgen. und das ansprechen könnte trotzdem normal erfolgen, in dem mit mod_rewrite dateien mit bestimmten endungen übersetzt werden:

Code: Alles auswählen

/upload/mein/bild.jpg -> getImage.php?uri=mein/bild.jpg

die datei getImage.php müsste nur die datei mit der bezeichneten uri aus der datenbank lesen und ausgeben.

und das dritte grundsätzliche problem besteht in der tatsache, dass der modulcode aus der datenbank gelesen und mit eval() ausgewertet wird. wenn im dateisystem keine schreibrechte mehr bestehen würden und die modulcodes in das dateisystem geschrieben werden müssten (upload mit ftp), dann könnte auch auf diese weise kein schadhafter code in contenido integriert werden.

die bestehende kombination aus schreibrechten in das dateisystem sowie die speicherung von modul-code in der datenbank und die klartext-übertragung von benutzernamen und passwort und der session-id öffnet einem hacker tür und tor.

das soll alles kein vorwurf sein. ich benütze contenido schon eine weile und oft und auch gerne. und ich habe bisher noch keinen hacker-angriff gehabt. mindestens keinen erfolgreichen. allerdings sind diese sicherheitsaspekte je nach anwendung durchaus von bedeutung. und ich würde es begrüssen, wenn diesbezüglich in einer nächsten version anpassungen vorgenommen werden würden.

für die bedienung des backends muss halt jeder anwender selber besorgt sein. die möglichkeiten bestehen seitens von contenido ja bereits. was man daneben auch noch machen kann, ist die ausführung von code innerhalb des verzeichnisses /upload (unter darunter) einfach abzustellen. dann kann schadhafter code zwar noch gespeichert, aber nicht mehr ausgeführt werden.

aber die speicherung von modul-code in der datenbank müsste man aus meiner sicht grundsätzlich vermeiden. und da module nur von administratoren gepflegt werden, dürfte es auch nicht als nachteil gewertet werden, wenn deren pflege über ein ftp-tool erfolgen muss.

ich betone nochmals: das ist alles kein vorwurf. nur eine anmerkung am rande.

rezeptionist · Beitrag von **rezeptionist** » Do 22. Dez 2005, 12:11

kummer hat geschrieben:für die bedienung des backends muss halt jeder anwender selber besorgt sein. die möglichkeiten bestehen seitens von contenido ja bereits. was man daneben auch noch machen kann, ist die ausführung von code innerhalb des verzeichnisses /upload (unter darunter) einfach abzustellen. dann kann schadhafter code zwar noch gespeichert, aber nicht mehr ausgeführt werden.

kannst du das bitte genauer beschreiben !

Begründung :
Da einem Kunden und somit auch mir ein ei ins nest gelegt wurde das danach ca 11000 mails versendet hat.

greets

Beitrag von **HerrB** » Do 22. Dez 2005, 12:24

aber die speicherung von modul-code in der datenbank müsste man aus meiner sicht grundsätzlich vermeiden. und da module nur von administratoren gepflegt werden, dürfte es auch nicht als nachteil gewertet werden, wenn deren pflege über ein ftp-tool erfolgen muss.

Den verstehe ich nicht so ganz. Wo ist der Unterschied, wenn nur ein Administrator via FTP die Module hochladen kann oder nur ein Administrator Layouts und Module in der DB speichern kann?

Gruß
HerrB

kummer · Beitrag von **kummer** » Do 22. Dez 2005, 12:43

HerrB hat geschrieben:Den verstehe ich nicht so ganz. Wo ist der Unterschied, wenn nur ein Administrator via FTP die Module hochladen kann oder nur ein Administrator Layouts und Module in der DB speichern kann?

weil die sicherheit nicht nur durch das applikationslayer sicher gestellt werden kann und soll. der administrator verwendet die selbe datenbankverbindung, wie ein nicht-administrator und dieser wiederum die selbe wie ein nicht authentifizierter nutzer.

angenommen, es findet sich ein formular in einem auftritt, bei dem keine ausreichende prüfung der eingaben erfolgt. dann wäre es grundsätzlich möglich, eine sql-injektion vorzunehmen und damit z.b. modulcode in die datenbank zu speichern. diesen kann der hacker dann ausführen, in dem er eine seite aufruft, die von diesem modul gebrauch macht.

das gleiche problem tritt auf, wenn ein hacker z.b. die session eines benutzers übernimmt und anschliessend eigenen code in die datenbank schreibt.

beides wäre nicht möglich, wenn sich der modulcode in einem verzeichnis befinden müsste, auf das php kein schreibrecht besitzt.

absolute sicherheit gibt es nicht. deshalb stört mich persönlich die bestehende situation nicht allzusehr. allerdings sollte man die grössten tore schliessen...

Beitrag von **emergence** » Do 22. Dez 2005, 13:26

ähm, alles recht nett und schön...
wer zeit hat kann das gerne komplett umbauen und wird auch dann zum schluss kommen, dass es keine sicheren wcms gibt...

@rezeptionist
schon mehr rausgefunden ? ohne einen hinweis darauf wie der hack erfolgt ist tun wir uns etwas schwer etwas zu empfehlen...

rezeptionist · Beitrag von **rezeptionist** » Do 22. Dez 2005, 13:30

@emergence

Nein leider nicht den der bisherige Provider verwehrte sämtliche Auskünfte uns scgiebt die schuld alleine auf Contenido ohne eine Beweisführung (valuveweb) , und hat uns per sofort untersagt Contenido auf diesem Server zu installieren.

Mein Kunde und ich haben schnell reagiert und nun einen Server bei 4fb. Meine Frage bzw anliegen war reine vorsichtsmaßnahme für die neuinstallation auf dem neuen Server um so weit es möglich ist alle Löcher zu stopfen.

greets