Sicherheitsproblem: Umleitung auf file2store.info

[Gérome]

Vielen Dank, das sind gute Hinweise, die ich heute auch gleich mal umsetzen werde.

Grüße,
Gérome

[MotMann]

Ist das unter vB 4 immer noch so?

[Silmarillion]

Ich war heute ebenfalls betroffen. Das ist nicht schön ... zumal die eigentliche Ursache nach wie vor unklar zu sein scheint.

Ich ebenfalls.

Wäre nett, wenn einmal jemand der sich mit der Problematik näher auskennt, wie bspw. Christian, einen kleinen, kontrollierenden Blick über meine 2 betroffenen Foren

fanlager.de und alternative-musik-forum.de

wirft. Aktuell habe ich einen Trafficverlust zwischen 50 und 70 Prozent.
Was aber, so hoffe ich mal, primär mit den durch den Angriff (ich bemerkte es erst 5 Tage später!) geänderten URLs (vBSEO) zu tun haben könnte. Wodurch sich das Suchmaschinenranking verschlechtert hat. Durch entsprechende Maßnahmen und 301 Redirects zeigt sich aber bereits eine Besserung.
Aber ich kann halt, auch aufgrund meiner fehlenden Kenntnisse auf diesem Gebiet, nicht aussschließen, dass sich doch (noch) irgendwo schadhafter Code auf dem Server befindet.

Liebe Grüße,
Christian

[MotMann]

vBseo schreibt, dass das Problem nicht bei denen liegt, vB meinte, dass es auch nicht an vB liegt..

wir stehen im dunkeln. Und ja, auch meine Passwörter sind safe

Wie bereits beschrieben, vBSEO deaktivieren und wieder aktivieren, oder die XML neu installieren. Blog auch deaktivieren und wieder aktivieren. Das hilft für erste.
Ich werde bei vB 4 vBSEO raus schmeißen. Das bringt sowieso nichts. Die URLs, welche serienmäßig in vB sind, reichen aus

Jetzt bin ich auch wieder betroffen. Meine Besuche krachen um 60% runter...

[CThiessen]

Moin,
Die Foren: fanlager.de und alternative-musik-forum.de
währen nach den bisherigen Test nicht betroffen.

Allerdings sieht man bei Alexa wieder einen Anstieg der Aktivität und bei den Upstram Sites konnte ich mit dem bissherigen Test (über Google suchen ggf. Cookie kontrollieren) das nur bei einem Forum feststellen.

Kann natürlich auch sein das der Hacker sich was neues ausgedacht hat.

Woran das liegt kann ich nicht sagen. In der Vergangenheit waren auch vB4 Foren betroffen und auch Foren ohne vBSEO.

Nach den Logfiles (bei mir) sieht es so aus als wenn der Hacker sich normal als Admin eingeloggt hätten.
Das halte ich aber für unwahrscheinlich. Und wenn ich der Hacker wäre würde ich das dort wo es einmal funktioniert hat wieder probieren. Einen erfolglosen Versuch sich bei mir einzuloggen gab es aber nicht.

Von daher habe ich versucht möglichst von den Defaultwerten abzuweichen.

• User ID1 ist kein Admin
• Admincp umbenannt
• .htaccess Schutz für admincp, Bilder Ordner u.s.w
• möglichst wenig Rechte für meinen Admin in der config
• Inhalt vom Install Ordner ganz gelöscht und .htaccess

Bisher ist es nicht wieder passiert.

Gruß
Christian

[Hoffi]

Kontrolliert Eure Phrasen. Die schreiben sich in die Datenbank!

Durchsucht mit phpMyAdmin alle Tabellen die Inhalte speichern. Phrasen und Templates.

Sichert alle Verzeichnisse von aussen mittels .htaccess Daten. Erlaubt KEINE Dateien und Ordner mit den Rechten 777. Und wenn es doch sein muss, schränkt den Zugriff mittels .htaccess Dateien ein.

Das Dingen nistet sich tief ein. Meistens sind Verzeichnisse die mit den Rechten 777 ausgestattet sind und der Zugriff nicht eingeschränkt ist.

[Silmarillion]

Danke für die Infos, Christian und Hoffi.

Nach was genau sollten denn die Inhalte der Tabellen durchsucht werden? Und wie stelle ich das am besten und sichersten an? (sry, kenne mich auf diesem Gebiet einfach noch nicht aus)

Und wie sichere ich einzelne .php-Dateien mittels .htaccess?

[Hoffi]

Suchen nach file2store.

SELECT * FROM `phrase` WHERE text like "%file2store%"
SELECT * FROM `post` WHERE pagetext like "%file2store%"
SELECT * FROM `template` WHERE template like "%file2store%"

Evtl. den Bereich file2store anpassen.

PHP Dateien sicherst du genau so wie Verezichnisse.

http://de.selfhtml.org/servercgi/ser...zeichnisschutz

Aber keine PHP Datei sollte die Rechte 777 haben. Auf keinen Fall. Welche ist das bei Dir?

[CThiessen]

Moin,
der Code in den Phrasen oder Templates oder plugins ist wohl verschlüsselt um ihn zu verstecken.
Du suchst nach "base64"

In Ordner in die z.B Avatare hoch geladen werden sollten nur Image Dateien sei, keine PHP oder anderes.
In diese Ordner packst du eine Datei mit dem Namen
.htaccess (ja mit Punkt am Anfang)

Der Inhalt der Datei:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">
   order allow,deny
   deny from all
</Files>

Gruß
Christian

[Silmarillion]

Suchen nach file2store.

SELECT * FROM `phrase` WHERE text like "%file2store%"
SELECT * FROM `post` WHERE pagetext like "%file2store%"
SELECT * FROM `template` WHERE template like "%file2store%"

Evtl. den Bereich file2store anpassen.

Mahlzeit Hoffi,

kann ich diese Suche auch über das vB-ACP (SQL-Query) vornehmen? Wir wissen halt nicht, ob file2store bei der letzten bekannten Attacke (Anfang August 2010) noch eine Rolle spielte...

PHP Dateien sicherst du genau so wie Verezichnisse.

http://de.selfhtml.org/servercgi/ser...zeichnisschutz

Aber keine PHP Datei sollte die Rechte 777 haben. Auf keinen Fall. Welche ist das bei Dir?

Ok. Werde ich mal machen. Bei mir handelt es sich um die vbseocp.php, welche ich schon umbenannt habe, aber eben noch durch ein zusätzliches Passwort weiter schützen will.

[Silmarillion]

Moin,
der Code in den Phrasen oder Templates oder plugins ist wohl verschlüsselt um ihn zu verstecken.
Du suchst nach "base64"

In Ordner in die z.B Avatare hoch geladen werden sollten nur Image Dateien sei, keine PHP oder anderes.
In diese Ordner packst du eine Datei mit dem Namen
.htaccess (ja mit Punkt am Anfang)

Der Inhalt der Datei:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">
   order allow,deny
   deny from all
</Files>

Gruß
Christian

Servus Namensvetter ,

welche Ordner wären denn bei vB3 (standard) sinnvollerweise separat zu schützen? (customavatars?)

Ansonsten auch hier noch einmal Danke für die schnelle und kompetente Hilfe. (gleiches gilt natürlich auch für Hoffi!)

Liebe Grüße!

[cws]

Was spricht eigentlich dagegen, dass vB das in der Standardinstallation so anlegt?

Also ggf. Feature Request

[Hoffi]

@Christian
Alle Ordner in die Dateien hochgeladen werden. Customavatars, Signaturepics, usw. Die kannst du in den Einstellungen sehen wenn der Debugmodus an ist.

Und die Datei vbseocp.php sollte auf gar keinen Fall die Rechte 777 haben, sondern 644. Wenn das gegeben ist, sollte das eine Passwort reichen.
Die vbseoconfig Datei sollte man nach dem Speichern der Einstellungen wieder zurück setzen. (Wobei ich es ehrlich gesagt echt schwach von vbseo finde, die settings so umständlich und unsicher abzulegen!)

Und ja, du kannst dei Queries auch im ACP ausführen lassen. Sind ja nur SELECT's. Auch mal file2store gegen base64 tauschen.

[Silmarillion]

@ Hoffi: vielen lieben Dank für die Informationen.

Was die vbseocp.php anbelangt, so ist diese natürlich mit chmod 644 versehen. Ich dachte Du wolltest wissen, welche Datei ich mit htaccess schützen will. Mein Fehler.
Du hast die besagte Datei also nicht noch einmal zusätzlich geschützt?

Liebe Grüße!

[Gérome]

Nachdem ich nicht ausschließen konnte, dass der Eingriff u.a. durch die Datei plugin.php im AdminCP-Verzeichnis durch muss, habe ich die Datei erweitert und nur noch mir selbst den Zugriff gestattet:

if ($vbulletin->userinfo['userid'] != 8)
{
    print_cp_no_permission();
} 

Genau genommen müsste ich sagen: Ich hatte gehofft, dass der Eingriff über dieses Script erfolgte und obige Sperre demzufolge eine Wirkung zeigen würde. Bis heute hält's immerhin.

[Hoffi]

Das glaube ich nicht, das der Eingriff darüber erfolgte. Ich hatte damals wie gesagt bei mir auch, und mein admin Verzeichnis heisst anders und ist mit .htaccess geschützt. Da kommt keiner rein.

Das Problem ging durch alle vBulletin Versionen. IB reagiert auf Sicherheitslücken in der Regel innerhalb kürzester Zeit. Die Sicherheitslücke war meiner Meinung immer auf dem Server, nicht im vBulletin. Zumal ich auch ruhe hatte seit dem ich alles dicht gemacht habe. Zum relaunch zu vB4 wird das ganze noch mal verbessert indem ich such die Serverkonfiguration dahingehen änder, das alle Bilder die ausgeliefert werden wie Anhänge usw. auserhalb des Webroot liegen. Die restlichen Ordner sind bereits geschützt.

[MotMann]

Suchen nach file2store.

SELECT * FROM `phrase` WHERE text like "%file2store%"
SELECT * FROM `post` WHERE pagetext like "%file2store%"
SELECT * FROM `template` WHERE template like "%file2store%"

Wenn ich das im ACP in den Query eingebe, erhalte ich eine Fehlermeldung:

Beim Ausführen Ihres Querys trat ein Fehler auf. Die folgenden Informationen wurden zurückgegeben.
Fehlernummer: 1146
Fehlerbeschreibung: Table 'dbxxxxxxxxx.phrase' doesn't exist

Und was muss ich alles tun, um das Adminverzeichnis zu ändern? Einfach den Ordner umbenennen kann ja bestimmt nicht alles sein

Ach ja.. es gibt einen weiteren Übeltäter: myfilestore.com .. wie muss ich verschlüsselt danach suchen?

[Jaydee]

Wenn ich das im ACP in den Query eingebe, erhalte ich eine Fehlermeldung:

Du musst die Tabellen um die von Dir verwendeten Präfixes ergänzen, also z. B. vb_phrase, sonst geht es nicht.

Und was muss ich alles tun, um das Adminverzeichnis zu ändern? Einfach den Ordner umbenennen kann ja bestimmt nicht alles sein

Nein, natürlich nicht.

1. Pfad/Verzeichnis anpassen

2. Suche in der /includes/config.php diese Zeile und trage dort den Namen des ACP Verzeichnisses ein:

$config['Misc']['admincpdir'] = 'hier Dein Verzeichnisname ab Forum-Root'; 

3. Dann lege unbedingt einen .htaccess/.htpasswd Schutz auf dieses Verzeichnis!

[MotMann]

Danke..

Die Datenbankabfrage ergab keine Ergebnisse.. komisch.

Und ja, hab passwortschutz mittels Datei längst angelegt

[Jaydee]

Da fällt mir gerade etwas auf:

Der Inhalt der Datei:

<Files ~ "\.(php\d*|cgi|pl|phtml)$">

... wird nicht funktionieren, "files" erlaubt jeweils nur einen Extender. Also ENTWEDER *.html, *.pl ODER *.php usw.
Für Mischungen mehrerer Extender/Dateitypen wäre <FilesMatch ... richtig.