Support » Plugin: WP DSGVO Tools (GDPR) » gehackt….

  • euer Plugin wurde gehackt. vielen Dank.
    Website ist wegen Umleitung auf spam-Seite nicht mehr aafrufbar.

    Hilfe für Betroffene: über ftp im Ordner wp-content/plugins den Ordner shapepress-dsgvo löschen oder umbenennen. Danach funktioniert die Seite wieder.

    Da die Datenschutztexte nun aber nicht mehr generiert werden, muss die Datenschutzseite angepasst werden. Ihr findet die Datenschutztexte zur Not in der Datenbank in der Tabelle wp_options unter option_name: sp_dsgvo_privacy_policy

Viewing 8 replies - 16 through 23 (of 23 total)
  • es war / ist eine Stored XSS Sicherheitslücke (beliebiger Code konnte so über eine einfache Anfrage gespeichert werden) und soweit nachvollziehbar keine SQL Injection Sicherheitslücke, auch ersichtlich an den letzten Änderungen hier im Repository des Plugins (siehe https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=2604127%40shapepress-dsgvo&old=2602901%40shapepress-dsgvo&sfp_email=&sfph_mail= sowie https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=2604195%40shapepress-dsgvo&old=2604176%40shapepress-dsgvo&sfp_email=&sfph_mail=).

    Es gibt dazu bei jemandem auf dem Blog einen Proof of Concept bzw. Exploit, der das demonstriert. Die Person geht seit Jahren nicht ethisch vor und ist entsprechend bekannt. Der Blogpost dazu sowie die Tweets sind von vorgestern und gestern.

    Die ausgenutzte Sicherheitslücke wird von Sicherheitslösungen wie NinjaFirewall erfolgreich verhindert / blockiert.

    Generell dürfte aber noch (wie bei demjenigen beschrieben, der den Exploit-Code dazu veröffentlicht hat), weiterhin ein Sicherheitsproblem wegen den AJAX-Funktionen (siehe register Funktion) bestehen (scheint in der aktuellen Version im Repository halbwegs behoben zu sein).

    Da derjenige auch bereits mehrfach ähnliche Sicherheitslücken dort entdeckt hat und ähnliche Probleme vor ein paar Jahren entdeckt wurden, wäre ein kompletter Audit bzw. Prüfung des Quellcodes durch Externe (in Zukunft) empfehlenswert.

    Es wurde im Code bislang keine Unterscheidung zwischen Admin und Nicht-Admin gemacht.

    if(method_exists($self, 'viewSubmit')){
        $action = $class::action();
        add_action("wp_ajax_{$action}", array($self, 'viewSubmit'));
        add_action("wp_ajax_nopriv_{$action}", array($self, 'viewSubmit'));
    }
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    • This reply was modified 3 months, 3 weeks ago by danielrufde.
    Plugin Author legalweb.io

    (@legalweb)

    @kipperlenny sehr gern:

    Es wurde von außen, die Speicherroutine aufgerufen, die den Wert der Textfelder in die Datenbank speichert.
    Um beide möglichen Fehlerquellen auszuschließen, wurde ein ein Prüfung ergänzt ob der User der die Routine aufruft Administrator Rechte hat und eine CSRF Überprüfung ergänzt, sodass wir sicherstellen können das die Speicherroutine vom Formular aufgerufen wird und das der User, der aktuell ändert auch berechtigt ist.
    Zusäztlich deaktivieren wir beim Update auf 3.1.23 alle Integrationen, sodass diese manuell wieder aktiviert werden müssen. Davor empfehlen wir eine Kontrolle des Scriptcodes im Textfeld der jeweiligen Integration.

    Uns ist nur bekannt, dass der Angreifer anstatt der Tracking Scripte durch “Weiterleitungsscripte” ersetzt hat. Code wurde nicht manipuliert.

    Plugin Author legalweb.io

    (@legalweb)

    @danielrufde
    das Ajax Security Issue haben wir auch behoben, nicht an der von dir markierten Stelle, sondern direkt beim Aufruf. Wir werden es aber an der von dir genannten Stelle auch ergänzen, da es durchaus Sinn macht.

    @legalweb erst mal herzlichen Dank für die schnelle Reaktion

    Ich verwende die free-version der DSGVO tools. Da sollte es eigentlich gar nicht möglich sein, die Speicherung aufzurufen – es sei denn, die Speicherfunktion ist nur im Frontend abgesichert.

    Habt ihr die beschriebenen Maßnahmen für alle APIs/Speicherroutinen eingeführt?

    Ich wurde durch einen Besucher darauf aufmerksam gemacht. Die weiteregeleitete Seite könnte m.E. durchaus Schaden anrichten – zumindest fragt sie nach diveersen Erlaubnissen. Das habe ich aber nicht probiert.

    • This reply was modified 3 months, 3 weeks ago by bwl21.
    • This reply was modified 3 months, 3 weeks ago by bwl21.

    s.u.

    • This reply was modified 3 months, 3 weeks ago by Arthur Končar. Reason: double entry

    Hallo Leute,
    wie geht’s voran? Stand der Dinge? Könnt Ihr schon abschätzen, wann das Tool wieder online sein wird?
    Cheers, Arthur

    Bitte um ein Update. Ich sehe, das Update für das Plugin ist wieder normal zugänglich. Bitte um eine kurze Info und Bestätigung hier, dass die Probleme beseitigt wurden.
    Was ist nun konkret zu tun? Einfach WP DSGVO Tools wieder aktivieren?
    Mich würde auch interessieren, wie der Schadcode aussieht, der in den Matomo-Code eingespeist wurde.
    danke, Angie.

    @angiepunkt die notwendigen Schritte sind dort im ersten Beitrag beschrieben: https://wordpress.org/support/topic/weiterleitung-redirects/

    Wie der Schadcode in den meisten Fällen aussah, kann man hier zum Beispiel sehen:
    https://wordpress.org/support/topic/weiterleitung-redirects/page/2/#post-14914281

Viewing 8 replies - 16 through 23 (of 23 total)
  • You must be logged in to reply to this topic.