Brauche Dringend Hilfe

[macbill]

bin mir ganz sicher das das die Version 6.15 ist. Das die news.php gelöscht werden muss hab ich wohl überlesen. Wo steht das eigentlich?

Brauche dann natürlic hauch ein backup des webspace, weil sonst alle bilder aus dem upload Ordner futsch wären?

[holger.librenz_4fb]

Dann schau Dir aber genau an, was im Upload-Ordner liegt. Nicht das da auch noch was "hinterlegt" wurde um den Server von vorn übernehmen zu können. Die Module in der Datenbank musst Dir natürlich danach auch noch einmal anschauen, wenn Du kein Backup vor dem Angriff zur Hand hast.

Gruß, Holger

[wosch]

Das heisst dann, der Richtigkeit halber, für mich nun:
Alles vom server löschen (backup inkl. DB vorher ist klar).
Dann die Version 4.6.23 aufspielen, update setup und die upload Dateien wieder einspielen. Richtig? oder habe ich etwas vergessen?

Wenn upload Dateien heißt:
Dateien im Verzeichnis cms/upload/ -> ja, aber ...
Jede Datei vorher sehr genau prüfen, Datei = Bild -> mit einem Bildbe-/verabeitungsprogramm einmal öffen (ob es auch wirklich ein Bildformat ist)

Wer verschweigt denn die Lücken von Contenido
... Ansonsten bin ich gern für Tipps und Hinweise dankbar

Dann pack mal eine genau Anleutung was man nach einem erfolgreichen Hackangriff macht in das Forum "Tipps & Tricks"
Das dieses Thema "Was mache ich danach" hier nicht offen erklärt wird ist es was mich aufregt.

[derSteffen]

Darf ich mal kurz fragen von welcher news.php hier die Rede ist und in welcher Contenido Version die ist?

[holger.librenz_4fb]

Hi wosch.

Kümmere ich mich drum. Wäre Dir dankbar, wenn Du mir per PM ein paar Punkte schicken könntest, die Du gern mit drin hättest und evtl. ein paar Stichpunkte die Du mit auf der Liste hast.

Gruß, Holger

[macbill]

In dem Pfad

Code: Alles auswählen

contenido/external/frontend/

liegt die news.php. Diese scheint in den neuen Versionen nicht mehr nötig zu sein, wird beim update aber auc hnicht gelöscht oder überschrieben.

[kummer]

das grundproblem ist, dass zuviele schreibrechte auf das dateisystem bestehen müssen. wenn diese bestehen, wird man diesen problemen immer ausgesetzt sein.

zunächst sollte man verzeichnisse, die nicht mit den browser angesprochen werden, mit .htaccess vor dem zugriff schützen. das kann contenido nicht selber vornehmen, weil das auch nur bei apache funktioniert und auch nicht bei jedem provider möglich ist. dann sollte man nach erfolgter installation alle verzeichnisse, die keine schreibrechte benötigen, wieder zurückstellen. also die schreibrechte wieder entfernen.

ansonsten wird es aufgabe der entwickler sein, eine stringente kontrolle der request-parameter einzuführen, die in jedem einzelnen script vorgenommen werden muss.

[holger.librenz_4fb]

Die Datei ist in der Tat nicht mehr notwendig. Problematisch ist leider, das die Datei bei einem puren Überschreiben der Installation mit einer neueren Version nicht gelöscht wird, da es keine neuere Version der news.php gibt.

Eine grundsätzliche Prüfung ist mit der 4.6.22 als Hotfix mit eingegangen. Hier werden die wichtigsten Parameter geprüft und ggf. die Verarbeitung abgebrochen. Eine Prüfung der Konfigurationsvariablen wird bereits seit einigen Versionen direkt geprüft.

[macbill]

Und ich muss alle Bilder öffnen und kontrollieren? Das sind hunderte. Gibts da ne andere Möglichkeit? Software mäßig?

[wosch]

Und ich muss alle Bilder öffnen und kontrollieren? Das sind hunderte. Gibts da ne andere Möglichkeit? Software mäßig?

Wenn du das mit z.B. ACDSee (oder Irfan-View) machst ist das ein Aufwand von Minuten.
Es geht nur darum zu erkennen ob die Dateiendung (jpg, gif, ...) auch wirklich stimmt (und die Datei eine Grfaik ist) und sich dahinter nicht wieder ein Script versteckt.

[derSteffen]

Hallo Kummer,

das mit der htaccess hört sich interessant an! Soll ich denn jetzt in alle contenido-Ordner htaccess reinbasteln? Gibt es da eventuell ein Liste?

Würde denn folgende htaccess reichen?

Code: Alles auswählen

<Files *.*>
order allow,deny
deny from all
</Files>

Steffen

[woldini]

Hallo macbill,

was Dir, bzw. Deinem Account passiert ist, war eine typische URL-Injection. Wirt hatten das Problem auch. Es kommt zum einen dadurch zustande, dass Dein Provider einen PHP-Grundschutzmechanismus, nämlich die PHP-Direktive: allow_url_fopen nicht deaktiviert (auf off gesetzt) hat, zum anderen ist es in einem gewissen Umfang auch ein Contenido-Problem.

Wegen dieser Direktive befanden wir uns schon mit einem Provider in einer umfangreichen E-Mail-Supportschlacht mit dem Ergebnis dass er trotzdem nichts getan hat. Bliebe also die .htaccess-Datei mit "deny from all". Dieser Schritt ist aber mit einer gewissen Vorsicht zu genießen: Nicht alle Verzeichnisse können/sollen mit der .htaccess-Datei geschützt wertden, da ja einige Dateien vom Browser geladen werden (z.B. das kleine Popup-Fenster für die Zeitsteuerung in den Artikeleigenschaften), wenn man in Contenido arbeitet. Dies bietet also auch keinen 100%-Schutz. Deshalb haben wir eine eigene kleine Lösung entwickelt:

1. wir schieben auf das Hauptverzeichnis des Web-Account eine .htaccess-Datei mit folgendem Inhalt:

Code: Alles auswählen

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Set a base path if website starts in subdirectory
  #RewriteBase /frontend

  # 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]
</IfModule>

Dieses Script 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:

2. eine PHP-Datei namens "attackmsg.php" auf, die den Angriff registriert und in eine Log-Datei schreibt, um ihn zu protokollieren. Die PHP-Datei hat folgende Code-Zeilen:

Code: Alles auswählen

<?
//* hier bitte den konkreten Serverpfad für das 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 ...

Die Datei attack.log protokolliert die Angriffe per URL-Injection mit Datum, IP-Adresse des Angriffsrechners und dem "Angriffs-Code". Ggf. kann diese Datei, falls jemand Anzeige erstatten möchte, mit entsprechendem Kommentar auch der Staatsanwaltschaft übergeben werden. Leider sind aber die meisten IP-Adressen von denen ein Angriff ausgeht nicht im Europäischen Raum angesiedelt, also strafrechtlich nicht verfolgbar.

Wir haben festgestellt, dass in der Log-Datei zwischen 5 - 15 Angriffe pro Tag stattfinden!! Die Hacker haben also Ihre Methoden schon längst "teil-automatisiert".

Dieser Sicherheitsmechanismus empfiehlt sich vor allem auch für ältere Contenidos.

Viel Spass mit dem Dicht-Machen von Contenido

[Contenider]

...

zunächst sollte man verzeichnisse, die nicht mit den browser angesprochen werden, mit .htaccess vor dem zugriff schützen.

...

@ Kummer: Wenn Du oder einer der Supermods in Kürze die Zeit dazu haben, wäre es sinnig wenn Ihr zur Absicherung mittels .htaccess einen Thread in diesem Topic aufmacht, fett markiert und genau schildert wie man es umsetzt.

Das Problem ist einfach, dass die Meisten "Neulinge" zum Teil nicht wissen wie man das realisiert und was dabei zu beachten ist. Ich halte dies für sehr wichtig und man könnte damit von vornherein eine Menge Ärger vermeiden.

Darüber hinaus sollte man überlegen, ob in dem nächsten Release von Contenido nicht schon fertige .htaccess Dateien "ausgeliefert" werden, welche ggf. nur angepasst werden müssen.

In jedem Fall sollte dieses Thema sehr ernst genommen werden, auch wenn das Problem grundsätzlich nur für diejenigen gilt, welche bisher ihre Versionen nur auf die jeweils neue aktualisiert haben.

[wosch]

@Contenider,
du hast sicher recht, aber das Problem geht noch sehr viel tiefer.

Und Contenido wird in der Zukunft Probleme ohne Ende bekommen da es im Visier der Scammer steht.

Es wird mit bots gezielt gesucht nach Contenido-Installationen, nach ganz bestimmten strings, die die bestehenden Lücken darstellen.
Lücken die in bestimmten Versionen vorhanden sind oder durch Updates nicht geschlossen werden.
Und das betrifft die Versionen 4.4 und 4.6.8.ohne_x

Wenn die Entwickler und "Supermods", wie du sie nennst, nicht bald aufwachen werden sie ins Komma fallen und Contenido auch.

Hier eine Seite die mit einem "stinknormalem Hackerstring" gefunden wurde:
http://www.musik-ohne-grenzen.at/cms/



wobei das "Freizeit-Hacker" waren und keine kommerziellen Interessen im Hintergrund standen.


EDIT:
Traut sich wer zu wetten?
Sind die schon gehackt?
Oder werden sie es noch:

http://www.webquests.at/fla/cms/front_content.php

http://vc-stralsund.de/contenido-4.4.4/ ... hp?idcat=9

http://apfelix.net/con/cms/front_conten ... cat=6.html

http://www.robber.ch/cms/front_content.php

usw.

[Contenider]

@ Wosch

Ja das mag sein, davon verstehe ich jedoch nicht sehr viel da meine Kenntnisse in PHP nicht so besonders sind. Denn diese reichen gerade einmal um ein Modul an meine Bedürfnisse anzupassen - und das auch nicht immer.

@ HerrB und alle anderen Mods

Ich schlage eine wichtige neue Funktion für das Backend vor, die mit dem kommenden Release unbedingt umgestetzt sein sollte:

Im Backend wird eine Art von RSS Feed direkt auf der Übersichtsseite integriert, auf welche man nach einem Login gelangt, über den die Administratoren über aktuelle Sicherheitslücken informiert werden, welche public geworden sind. Das System sollte von 4FB gepflegt werden - schließlich sind die Jungs, und Mädels, ja die "offiziellen" Entwickler und tragen die "Verantwortung" für das System.

Dies lässt sich auch noch weiter ausbauen, Möglichkeiten gibt es da sicherlich viele. Ich kenne etwas ähnliches von XTCommerce, welches ich auch einsetze. Dies erspart jedem Benutzer des Systems die manuelle Suche und vereinfacht die Angelegenheit um einiges.

Edit:

Das obige Bild ist zumindest klasse ;)