1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Brutforce Angriff auf Admin Login - diesmal mit korrekten Usernnamen

Dieses Thema im Forum "Allgemeines" wurde erstellt von RemoteC, 15. Januar 2015.

  1. RemoteC

    RemoteC Member

    Registriert seit:
    23. April 2010
    Beiträge:
    22
    Zustimmungen:
    0
    Hallo,

    ich habe privat und für Freunde/Vereine schon mehrere WP-Seiten erstellt. Überall das Plugin Limit Login Attempts installiert.
    Bisher haben mich die Mails, die nach x erfolglosen Logins von dem Plugin verschickt werden ziemlich kalt gelassen weil immer probiert wurde sich mit "admin" anzumelden. Die Zeiten, wo das der Standard-Admin bei der Installation war, sind zum Glück schon lange vorbei. Es gibt daher nirgendwo einen "admin".

    Heute war es aber anders: Es wurde probiert mit zwei verschiedenen Benutzern anzumelden, die genau so auch existieren. Auf dieser Website gibt es 1.) keine Kommentarfunktion wo Benutzernamen sichtbar sind 2.) keine author-meta Infos im HTML head 3.) im Template bei Beiträgen/Seiten/... kein the_author()
    Keiner der getesteten User hat sich zu den Zeiten probiert anzumelden.

    Gibt es irgendeine andere Möglichkeit herauszufinden welche Usernamen bei einer WP-Installation existieren? Wie kommen Angreifer zu diesen Infos?

    Die IP Adressen kamen laut verschiedener Websites aus Polen und den USA (Botnet?!).

    WP und alle Plugins sind am neuesten Stand. WP 4.1, Limit Login Attempts Version 1.7.1 und The Subtitle 1.4.
     
  2. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
  3. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Diese Art des Angriffs kann man z.B. so verhindern, vor dem WordPress-Block in .htaccess setzen, die RewriteBase ggf. anpassen.
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Das leitet alle o.g. URLs intern zu einem User mit ID 999999 weiter, den es aber (höchstwahrscheinlich) nicht gibt und daher eine 404-Seite anstelle der Autor-Seite geliefert wird.
     
    #3 b3317133, 15. Januar 2015
    Zuletzt bearbeitet: 15. Januar 2015
  4. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Die Zeile Options +FollowSymlinks ist nicht erforderlich, war ein copy&paste Fehler... :oops:
     
  5. himitsu

    himitsu Well-Known Member

    Registriert seit:
    10. März 2011
    Beiträge:
    612
    Zustimmungen:
    0
    Na danke. (auch wenn ich die 2 bin :twisted:)
    http://forum.wpde.org/allgemeines/136445-sicherheit.html
    Warum steht in dieser URL denn nicht mein öffentlicher Name?


    deineseite.de?author=1
    deineseite.de/?irgendwas&author=1


    Hmmmm, entweder ich geb mir eine schön hohe ID, oder ich werde wohl eher gleich die kompletten Authorseiten sperren.
     
    #5 himitsu, 15. Januar 2015
    Zuletzt bearbeitet: 15. Januar 2015
  6. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Stimmt, "irgendwas&" ist durchgerutscht, hier eine angepasste Version:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Noch weitere Lücken?
     
  7. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
    Einfach den Author Slug ändern. Benutzer, öffentlichen Namen und Slug unterschiedlich gestallten. Und natürlich den Benutzernamen niemals als öffentlichen Namen verwenden. Auf diese Weise können Benutzernamen nicht mehr "ausgelesen" werden.
     
  8. himitsu

    himitsu Well-Known Member

    Registriert seit:
    10. März 2011
    Beiträge:
    612
    Zustimmungen:
    0
    Das klingt auch gut.

    War grade mal in den Logs.
    Die letzten 1-2 Wochen hatte zumindestens keiner diesen Author-Link-Trick benutzt.
    Die wenigen Loginversuche der letzten 5 Wochen gingen einmal gegen "admin", den es nicht gibt, und ansonsten ging es ausschließlich gegen meinen öffentlichen Namen.
    Aktuell versucht einer es gegen Passwort "öffentlicher Name"+"angebliches Geburstjahr" (1986, 1987, 1989, ...) und so jung bin ich nu och nimmer.
    Aber im Login sind Angriffe aktuell stark gesunken (man konzentriert sich seit Dezember dafür vermehrt wieder darauf in den Kommentaren erfolglos rumzuspammen.
     
  9. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
    Bei mir läuft fail2ban. Ich habe rund 200 Loginversuche pro Tag und etwa 1000 Hex-Hacks (Proxy Scans, URL Exploits, usw.). In etwa 95% davon kommen aus Asien (China, Taiwan).
     
  10. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Es gibt auch viele Loginversuche via XML-RPC, die werden oft vergessen bei der "Verteidigung". Die einzige echte Lösung hier ist das Abschalten der Schnittstelle.
     
  11. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
    Oder über eine Funktion abfangen.
     
  12. Gast 64612

    Gast 64612 Gast

    sehr interessantes Thema, @mensmaximus etwa so? add_filter( 'xmlrpc_enabled', '__return_false' );
     
  13. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Über welche genau?

    Das schaltet die Schnittstelle ab.
     
  14. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
    Ich denke da eher an eine Funktion, die die Fehlversuche aufzeichnet und die IP sperrt, nach dem Model

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Wie gesagt ist eine Idee.
     
  15. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Wie verhindert man dann den nächsten Loginversuch der aufgezeichneten IP?

    WordPress XML-RPC stellt meines Wissens keine Filter/Actions vor dem XML-RPC Loginversuch zur Verfügung.
     
  16. Gast 64612

    Gast 64612 Gast

    vielen Dank ^^ wobei ein Bruteforce den Datenbank Connect allgemein schon sehr belastet
     
  17. borusse

    borusse Gast

    Ich hatte vor einiger Zeit auch versuche auf die xml-rpc stelle. Nachdem ich auch den Lösungsweg aus dem Link oben probierte, konnte ich mich selber nicht mehr einloggen. Jemand meinte hängt mit dem htaccess Schutz der Admin Seite zusammen. Daraufhin habe ich einfach dort die xml-rpc mit eingetragen. Entweder hat derjenige just in dem Moment seine Versuche aufgegeben oder der Eintrag hat geholfen.
     
  18. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.636
    Zustimmungen:
    1.778
    Derzeit ist meines Erachtens die einzige Lösung mit WordPress-Bordmitteln das Abschalten der XML-RPC Schnittstelle in functions.php via
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    und das Entfernen der damit nutzlosen <link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" /> o.ä. in header.php oder sonstwo im Theme. Bitte gern andere Vorschläge zu XML-RPC posten.

    Für Bruteforce bei normalen Logins mit den üblichen Account-Namen bevor überhaupt Plugins o.ä. geladen bzw. die Datenbank connected wird, nutze ich einen Code-Block wie z.B. diesen in der wp-config.php
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Das reduziert die Serverlast erheblich...

    Ergänzung: Oft wird als Login auch der Domainname ohne www. und .de/.com versucht, oder E-Mail Adressen die auf dem Website vorkommen. Die trage ich dann noch in das o.g. Array ein.
     
    #18 b3317133, 15. Januar 2015
    Zuletzt bearbeitet: 15. Januar 2015
  19. mensmaximus

    mensmaximus Well-Known Member

    Registriert seit:
    24. Juli 2014
    Beiträge:
    8.857
    Zustimmungen:
    437
    muplugins_loaded kommt bestimmt davor ;) Das ist aber auch gar nicht weiter nötig. Mit wp_authenticate steht einem der notwendige Hook zur Verfügung, da er vor der eigentlichen Authentifizierung stattfindet.

    Grundsätzlich sind wir uns aber wahrscheinlich alle einige, dass Abwehrmaßnahmen dieser sowieso außerhalb von WordPress stattfinden sollten (IP-Tables, Fail2Ban oder mit vorgeschalteten Proxy-, Firewall- oder IPS-Systemen).
     
  20. RemoteC

    RemoteC Member

    Registriert seit:
    23. April 2010
    Beiträge:
    22
    Zustimmungen:
    0
    Dachte gestern Abend nicht, dass ich mit diesem Thread so einen Stein ins Rollen bringe - finde ich sehr gut, dass die Community so sicherheitsbewusst ist und eine solche konstruktive Diskussion gestartet wurde mit jede Menge Tipps. Habe ich gleich ein wenig etwas zu tun mit dem Einbau der genannten Codeschnipsel.

    Ich habe in dem Template zwar keine author-Seite definiert, wodurch domain.de/?author=1 komplett zerstört aussieht und der Name nirgendwo zu lesen ist, im Quelltext steht er aber an zwei Stellen. Vermutlich kamen die Angriffe also auf diesem Weg.

    Das hatte ich, neben admin und administrator, auch schon öfters.

    Kann ich mir mit einer Adaption von Limit Login Attempts auch die eingegebenen Passwörter anschauen bzw. zusenden lassen?
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden