Contenido gegen URL-Injection im Shared Hosting schützen

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Marion
Beiträge: 18
Registriert: Mo 30. Jan 2006, 11:33
Kontaktdaten:

Beitrag von Marion » Fr 27. Jun 2008, 15:09

Ich habe nach einem Hackangriff auf 4.8.6 upgedatet.
Macht es trotzdem Sinn die hier beschriebenen Massnahmen zu ergreifen oder ist das dann doppelt gemoppelt?

walter999
Beiträge: 161
Registriert: Di 24. Mai 2005, 11:23
Wohnort: Rain/Dürnhart
Kontaktdaten:

Beitrag von walter999 » Mi 9. Jul 2008, 09:59

Hallo,

ich hätte eine Frage zu folgendem "Patch":
Habe die Lücken (hoffentlich) manuell in 4.4.5 geschlossen und in die Files:

contenido/classes/class.inuse.php
contenido/classes/class.htmlelements.php
conlib/local.php
contenido/external/frontend/news.php
contenido/includes/include.con_subnav.php (auch in 4.6.4!)
contenido/includes/include.grouprights_subnav.php (auch in 4.6.4)
contenido/includes/include.logs.php
contenido/includes/include.newsletter_edit.php
contenido/includes/include.recipients_edit.php
contenido/includes/include.right_top_blank.php (auch in 4.6.4)
contenido/includes/include.rights_subnav.php (auch in 4.6.4)
contenido/includes/include.subnav.php (auch in 4.6.4)
contenido/includes/include.tpl_subnav.php (auch in 4.6.4)
contenido/includes/pseudo-cron.inc.php (indirekt über crontab.txt?, auch in 4.6.4)

mit dem einfachen Eintrag in den jeweils ersten Zeilen:
Code:
if ( $_REQUEST['cfg'] ) { exit; } // workaround remote hacking exploit
Warum trägt man das if ( $_REQUEST['cfg'] ) { exit; } nicht generell in alle Dateien ein oder an einer globalen Stelle die in alle Dateien includet wird? Oder blockiert mir dies auch gewollte Variablenübergaben? Anderseits wann übergibt man die Varibale cfg mal per GET oder POST?

Vielen Dank im Voraus und viele Grüße
Walter[/code]

frederic.schneider_4fb
Beiträge: 967
Registriert: Do 15. Apr 2004, 17:12
Wohnort: Eschborn-Niederhöchstadt
Kontaktdaten:

Beitrag von frederic.schneider_4fb » Mi 9. Jul 2008, 10:06

Grundsätzlich: Es gibt einige Dateien, die als so genannte "Einsteigsseiten" fungieren, d. h. wenn man sie manuell aufruft, kann man manipulierte Variablen übergeben. Diese Dateien werden zukünftig auch über eine Standard-Methode überprüft.

"Wann übergibt man die Variable cfg mal per GET oder POST?"
Sicherheit ist keine Frage der Praxis, sondern der Theorie. Fakt ist: Man kann die Variable "cfg" über GET übergeben - und deshalb muss sie überprüft werden.

walter999
Beiträge: 161
Registriert: Di 24. Mai 2005, 11:23
Wohnort: Rain/Dürnhart
Kontaktdaten:

Beitrag von walter999 » Mi 9. Jul 2008, 10:15

Erst mal danke für die schnelle Antwort.

Hier haben wir uns mißverstanden:
"Wann übergibt man die Variable cfg mal per GET oder POST?"
Sicherheit ist keine Frage der Praxis, sondern der Theorie. Fakt ist: Man kann die Variable "cfg" über GET übergeben - und deshalb muss sie überprüft werden.
Dies ist mir klar. Nur könnte ich nicht generell mit if ( $_REQUEST['cfg'] ) { exit; } überprüfen ob per GET, POST usw. eine Variable "cfg" in einer beliebigen Datei eingeschleust wird?

Also nicht nur in den aufgelisteten Dateien sondern in jeder?

Konkretes Beispiel:
Patch in die besagten Dateien eingespielt -> eine andere Datei gehackt.

Danke und viele Grüße
Walter

frederic.schneider_4fb
Beiträge: 967
Registriert: Do 15. Apr 2004, 17:12
Wohnort: Eschborn-Niederhöchstadt
Kontaktdaten:

Beitrag von frederic.schneider_4fb » Mi 9. Jul 2008, 11:13

Mit $_REQUEST hast du alle Typen eingeschlossen, also: GET, POST, FILES... Prinzipiell schließt du damit nur Manipulationen in der jwg. Datei aus, da du, wenn du eine includierte Datei manuell aufrust, ja den Aufruf nicht implementiert hast. Da gebe ich dir Recht. Das Problem tritt also eigentlich in jeder Datei auf, dazu ist jedoch zu bemerken:
  • Besteht eine Datei lediglich aus einer Klasse, also es findet kein normaler Aufruf statt, ist sie bei einem manuellen Aufruf ungefährlich
  • Kommt gleich am Anfang etwas á la cInclude(), plugin_include() oder ein sonst nicht standardmäßig von PHP implementierter Aufruf vor, bricht das Skript bei einem manuellen Aufruf ab, eine Manipulation ist ergo nicht möglich
Das tritt in einigen Dateien auf. Um das Problem generell aber zu lösen, wird es in der nächsten Contenido-Version ja eine Standard-Lösung geben.

walter999
Beiträge: 161
Registriert: Di 24. Mai 2005, 11:23
Wohnort: Rain/Dürnhart
Kontaktdaten:

Beitrag von walter999 » Mi 9. Jul 2008, 11:18

Mit $_REQUEST hast du alle Typen eingeschlossen, also: GET, POST, FILES...
Das war mir klar, danke!

Theroretisch müßte ich den "Patch" also in jeder Datei einfügen. Oder zumindest für die Methode GET.

Das wollte ich eigentlich nur wissen.

Vielen Dank!
Walter

frederic.schneider_4fb
Beiträge: 967
Registriert: Do 15. Apr 2004, 17:12
Wohnort: Eschborn-Niederhöchstadt
Kontaktdaten:

Beitrag von frederic.schneider_4fb » Mi 9. Jul 2008, 11:22

Ja, korrekt, der Patch gehört eigentlich in jede Datei.

walter999
Beiträge: 161
Registriert: Di 24. Mai 2005, 11:23
Wohnort: Rain/Dürnhart
Kontaktdaten:

Beitrag von walter999 » Do 10. Jul 2008, 08:26

Ich habs jetzt bei mir mal in jeder Datei im Include-Verzeichnis integriert.

Grüße
Walter

Mc
Beiträge: 188
Registriert: Mi 2. Mär 2005, 21:19
Kontaktdaten:

Beitrag von Mc » Mo 28. Jul 2008, 17:08

Zunächst vielen Dank an woldini. Hat mir sehr viel gebracht.

Ergänzung zu Punkt 1 - Test, ob Seite sicher:

Meine Seite wurde über contenido/includes/include.newsletter_jobs_subnav.php gehackt. Der Provider Profihost hat sofort den account gesperrt. Im Verzeichnis contenido/includes wurde aber bereits vom Angreifer eine Datei installiert. Über Virenprogramm gefunden.

Nun zur eigentlichen Ergänzung:
Hier die Aussage des Providers: "Wenn Sie einen eigenen Angriff auf Ihre Webseite durchführen, erkennt unser System diesen automatisch und teilt uns per Email mit."
Dann wird mir die Seite also sofort wieder gesperrt.
Profihost (sehr guter service, fast immer sofortige Antwort auf Anfragen) bietet mir allerdings an, trotzdem testen zu können. Vorgang will ich allerdings hier nicht posten aus Sicherheitsgründen.

Über die php.ini kann ich übrigens bei Profihost folgende Einstellungen vornehmen:
Wichtig:
Alle Einstellungsoptionen, die Ausführungzeiten und Memorylimits betreffen, lassen sich nicht abändern. Um die Sicherheit auf dem Account zu verbessern, sollten folgende Einstellungen gesetzt werden (falls eingesetzte Skripte nicht explizit eine andere Einstellung brauchen):

register_globals = Off
allow_url_fopen = Off
display_errors = Off

Da habe ich offensichtlich einen sehr guten Provider gefunden (hat mir vor einigen Jahren mal Halchteranerin vorgeschlagen. Danke)

Gruß
Mc

Mc
Beiträge: 188
Registriert: Mi 2. Mär 2005, 21:19
Kontaktdaten:

Beitrag von Mc » Di 29. Jul 2008, 20:17

Noch zwei Fragen an woldini:

1.
Macht dies aber erst nachdem ihr sicher gestellt habt, dass eure Datenbank nicht vom Angriff betroffen war.
Wie kann ich das überprüfen?

2.
zu a):
Als erste Maßnahme bittet euren Provider in der VirtualHost-Konfiguration eurer Domain die PHP-Direktive: php_admin_value allow_url_fopen auf "off" zu setzen. Wenn er das machen kann, dann sind die nachfolgenden Schritte unter b.) in gewissem Umfang Fleißarbeit.
Bringt die Fleißarbeit etwas?
1. Ihr fahrt ein Update auf eine neuere Version (4.6.) inkl. ModRewrite - Bundle,
2. Ihr seid gute Entwickler und schreibt ein PHP-Script, das fremde URLs nicht zuläßt und baut es in Contenido an die entsprechenden Stellen ein.
3. Ihr schützt den Webspace und Contenido mit Hilfe von .htaccess-Datei(en).
1. habe ich gemacht auf 4.8.6; ModRewrite fehlt noch
3. Bringt dies zusätzlichen Schutz, wenn beim Provider allow_url_fopen = Off eingestellt ist?

Danke
Gruß
Mc

Antworten