Beiträge von Bremmo

Zitat von r23

kein Perl auf dem Server?

und funktioniert dein Filematch so wirklich? sieht merkwürdig aus... ich verwende in der Regel <Files

und bei \.php$

Code

<FilesMatch \.php$>

Ja das funktioniert tatsächlich so bei mir :)

Kannst ja mal testen: http://www.e-poetry.de/wp-content/uploads/wysija/test.php

Ich schwöre feierlich, dass die Datei existiert :)

Von Perl hab ich jetzt keinen Schimmer ehrlichgesagt. Braucht man dazu nicht CGI? Hat meines Wissen nach mein Hoster Strato abgestellt.

Hallo,

bei Strato ist noch wichtig in der wp-config den MySQL-Server zu verändern, der ist nämlich nicht localhost, sondern: rdbms.strato.de

Evtl. hilft das?

Danke Ralf,

ich habe jetzt zur Sicherheit mal das Ausführen von php im Upload-Ordner geblockt via .htaccess:

<FilesMatch .php>
   Order deny,allow
   Deny from all
</FilesMatch>

Bin aber zuversichtlich, dass jetzt Ruhe ist. Meine Blogs wurden diese Nacht zum ersten mal seit 17.07. nicht wieder kompromitiert.

Sorry, dass ich nochmal schreibe, aber ich bin jetzt einfach der Sache weiter auf den Grund gegangen. Habe jetzt noch die Datenbanken der Blogs durchforstet und bin darauf gestoßen, dass in den Tabellen wp_user und wp_usermeta ein Nutzer mit folgender ID eingetragen ist: 1001001 <- der hat Administratorrechte.

Sind insgesamt 5 Einträge vorhanden, wenn man nach 1001001 sucht.

Wie es sich mir jetzt darstellt war bei mir zumindest das Einfallstor der Ordner /wp-content/uploads/wysija/themes/mailp/

Dort wurde scheinbar eine php-Datei index.php reingeladen, die dann alles weitere veranlasst hat.

Soweit ich das sehe gehört der ganze Ordner da gar nicht rein.

So, ich verspreche jetzt keinen Vierfachpost zu erzeugen, weil ich längstens schon im Bett sein müsste.

Greetz & over

Sorry für Doppelpost, aber eine Frage: Kann es sein, dass die anderen gehackten auch den Mailpoet-Newsletter (wysija benutzen? Ich habe da einen weiteren Hinweis gefunden:

http://blog.sucuri.net/2014/07/remote…ewsletters.html

Mich hat auch der gleiche Angriff erwischt. Gleich auf drei Blogs und Piwik und Owncloud. Es wurden einfach alle php-Dateien infiziert. Ich konnte jedoch noch keine Schwachstelle ausmachen. Hab jetzt erstmal ftp und ssh-Zugriff vorsorglich komplett dicht gemacht. Mal sehen ob morgen wieder Ruhe ist.

Es ist scheinbar ein Problem, das seit 3.9.1 auftritt.

Siehe auch http://www.sascha-endlicher.de/uncategorized/…s-v3-9-1-sites/

und

http://www.sascha-endlicher.de/uncategorized/…s-v3-9-1-sites/

Das müsste so funktionieren:

RewriteCond %{SERVER_PORT} !=443
 RewriteRule ^(.*)$ [URL]https://www.ssl-id.de/meinewebseite.de/$1[/URL] [R=301,L]

Das leitet aber wirklich alles um, was auf deine Domain meinewebseite.de kommt!

Guten Tag,
mich hat das mit den Google-Fonts auch gestört, habe ein kleines Plugin gemacht, dass sie nicht mehr abgerufen werden:
http://www.bremmert.de/2013/08/05/dat…wenty-thirteen/

Greetz
Bremmo

Habe auch grade mit Erschrecken festgestellt, dass das neue Standard-Theme Twenty Thirteen Google Fonts benutzt. Werde jetzt sehen müssen, wie ich das Thema auf selbst-gehostete Fonts umleiten kann.

Das Problem ist doch einfach, dass man in Deutschland diese Themes eigentlich nicht benutzen darf, da beim Websitenaufruf die Referrer an google in die USA übertragen werden - und das noch zudem ohne das Wissen meiner Websitenbesucher.

Also entweder man schaltet eine Seite vor, die dem User die Wahl gibt ob man seine Daten an google in die USA gibt

oder

man schaut, dass man die google Fonts irgendwie rausbekommt.

Zweiteres werde ich jetzt mal versuchen, auch wenns ein harter und steiniger Weg wird.

Meines Erachtens müsste wirklich in Deutschland / Europa bei der Auswahl der Themes / Plugins für Wordpress ein Warnhinweis erscheinen, wenn man datenschutzrechtlich bedenkliche Abfragen mit den Codes erzeugt.