Seite gehackt trotz Contenido 4.6.4
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
Seite gehackt trotz Contenido 4.6.4
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?
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?
Contenido Version: 4.8.3
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
check die server logs... wenn der angriff wirklich über contenido stattgefunden hat, muss dort der einstiegspunkt ersichtlich sein...
*** make your own tools (wishlist :: thx)
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
Haben sie auch gesagt, an welchem? Contenido besteht ja praktisch nur aus PHP-Dateien.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?!?
Bitte keine unaufgeforderten Privatnachrichten mit Hilfegesuchen schicken. WENN ich helfen kann, dann mache ich das im Forum, da ich auch alle Postings lese. PN werden nicht beantwortet!
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
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.
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.
Contenido Version: 4.8.3
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
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...
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...
-
- Beiträge: 89
- Registriert: Fr 25. Feb 2005, 00:13
- Wohnort: Darmstadt
- Kontaktdaten:
Danke Martuno, ist ein guter Tipp. Werde das mal gleich runterladen. Ist schade das ich nicht wirklich rausbekomme woran es gelegen hat...Martuno hat geschrieben:Nimm doch z.B. http://winscp.net/ für etwas Sicherheit! (SCP oder SFTP)
Ich werde einfach jeden Tag mal die ganze Seite runterladen und auf Hackertools checken... Mal schauen was die Zeit so bringt
Contenido Version: 4.8.3
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
Apache 1.3.34
MySQL Serverversion 5.0.32
Installierte PHP-Version 5.2.5
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:
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.
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
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.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 1536
- Registriert: Fr 20. Aug 2004, 10:07
- Kontaktdaten:
kannst du das bitte genauer beschreiben !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.
Begründung :
Da einem Kunden und somit auch mir ein ei ins nest gelegt wurde das danach ca 11000 mails versendet hat.
greets
greets
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?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.
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
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.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?
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...
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
ä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...
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...
*** make your own tools (wishlist :: thx)
-
- Beiträge: 1536
- Registriert: Fr 20. Aug 2004, 10:07
- Kontaktdaten:
@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
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
greets