Wordpress Seite kein Login möglich

[mausfang]

Die Tipps zur Absicherung sollte man sich zu Anfang des Betriebs oder vor dem Betrieb holen.

Und tägliche Backups per Plugin sind auch kein Hexenwerk. Es besteht ja noch die Chance, dass @TechGeek eins hat.

Mein Beleid, dennoch zum Verlust der Datenbank.

 

[mausfang]

Die WP Seite war passwortgeschützt.

Wie viele fehlerhafte Loginversuche hattest Du gestattet bis zum „Bann“ der Angreifer-IP?

 

[Difool]

@Difool
Nichts gegen solche Tipps. Aber damit begibt man sich in eine trügerische Sicherheit ("bremst die bösen Bots auch schon nachhaltig aus") – mal angenommen man ist nicht der große Experte auf diesem Gebiet, was ich beim TE, ohne ihm nahetreten zu wollen, vermute. Man schaue sich beispielsweise nur die lange Liste der bekannten Vulnerabilities an. Und das betrifft jetzt nur Wordpress. Der Webserver an sich ist dann nochmal ne andere Nummer. Man kann das nicht einfach vernachlässigen und das Gefühl vermitteln, mit einem simplen .htaccess-Eintrag sei alles ok.

Das alles > Vulnerabilities … betrifft ja soweit alle möglichen Plugins für Wordpress und nicht Wordpress selbst.
Bei dem TE war und ist das Problem mit und über MAMP und dem öffentlichen Zugang von draussen gewesen –
darüber sollte der "Hacker" in seine Datenbank gekommen sein und da hätte ihm kein "wordfence", "login attempt" oder htaccess-Passwort geholfen.

Mit einer aktiven .htaccess Passwort-Abfrage explizit für die wp-login.php ist so erstmal das System Wordpress relativ dicht,
was das Backend betrifft. XSS oder sql-injection sind da aber auch noch möglich – da gebe ich dir recht.

MAMP ist für lokale Dinge gut – auch mal zur kurzzeitigen Kundeneinsicht eines Projekts;
aber dauerhaft als "Serverhost" nach draussen würde ich das nicht empfehlen.

Mein Hinweis mit der htaccess-Passwort-Abfrage bezog sich aber auch auf die zig Bots,
die 24/7 bei jeder sich im Netz erreichbaren "wp-login.php" rumprobieren.
Weiß man um die mögliche Vulnerabilität von Plugins und Themes, dann ist htaccess-Passwort und die url-Änderung zur wp-login.php schon recht safe.

Die meisten gehackten Wordpress-Systeme, die ich persönlich über die Jahre gefixt und wieder zur Funktionalität gebracht habe,
belaufen sich schlicht zu 100% auf kompromittierte Plugins oder Themes.
Entweder aus zweifelhaften Quellen runtergeladen (bereits mit Schadcode wie Exploits, web shells usw. ) und installiert,
oder eben durch sql-Injection eines (veralteten) Plugins in die Datenbank.

 

[mausfang]

Bei dem TE war und ist das Problem mit und über MAMP und dem öffentlichen Zugang von draussen gewesen –
darüber sollte der "Hacker" in seine Datenbank gekommen sein und da hätte ihm kein "wordfence", "login attempt" oder htaccess-Passwort geholfen.

Interessant - aus welcher Info im Thread leitest Du ab, dass es so war … und nicht über den quasi im Internet freigegebenen Login?

Edit: Ich würde da gerne was dazulernen.

 

[Difool]

Interessant - aus welcher Info im Thread leitest Du ab, dass es so war … und nicht über den quasi im Internet freigegebenen Login?

Edit: Ich würde da gerne was dazulernen.

Aufgrund des Artikels von Sjoerd Langkemper, schliesse ich hier darauf.
Der in MAMP inkludierte SQLiteManager sollte das Problem gewesen sein – je nach dem wie alt das MAMP ist/war.

Siehe hier:
https://www.macuser.de/threads/wordpress-seite-kein-login-moeglich.909455/post-11747287

 

[mausfang]

@Difool
Wenn ich das richtig verstanden habe muss das Opfer aber eine entsprechend präparierte Webseite besuchen, damit im Browser des Opfers JavaScript ausgeführt werden kann.

 

[Difool]

@Difool
Wenn ich das richtig verstanden habe muss das Opfer aber eine entsprechend präparierte Webseite besuchen, damit im Browser des Opfers JavaScript ausgeführt werden kann.

Das und aber auch via php code injection bsw., wenn und falls seine MAMP älter ist/war und die SQLite Manager Version von 2013 usw.
Zuletzt 2018: Directory traversal vulnerability in SQLiteManager 1.2.0 allows remote attackers to read arbitrary files via a .. (dot dot) in a SQLiteManager_currentTheme cookie.
Quelle: https://www.cvedetails.com/vulnerab...407459/Sqlite-Manager-Sqlite-Manager-1.2.html

Letztendlich entscheidet dann noch die Portfreigabe vom MAMP-Server nach draussen und auf was die Files so stehen: 777 or 444 or 744…
Gibt genügend bots da draussen, die alle möglichen bekannten Dinge und Pfade permanent abfragen.

Ich hatte mal bsw. das Problem, dass bei einem Wordpress-Theme, welches ich installiert hatte, deren Server gehackt worden waren und
die Aktualisierung des Themes danach kompromittiert waren. Folglich lud man sich mit der Aktualisierung des Themes dann eine Backdoor.
Und danach wurden dann diverse Dateien mit fiesen Links auf irgendwelche Porno-Websites in die Templates gesetzt –
schön mit gefühlten über 4000 Zeilen Abstand zum originalen Sourcecode, was bei einem Durchschauen dann nicht gleich auffiel.
Sprich, die Dateien und der Sourcecode davon sahen alle wie sonst und regulär aus – nur scrollte man gaaaanz nach unten kam base64-Code mit deren Codes.

Beispiel: php code injection SQLite Manager