Gerüchteweise, ist in WordPress 4.9.3 ein Updatebug enthalten, der Autoupdates verhindert. Daher soll händisch auf 4.9.4 aktualisiert werden.
Update: falsche Versionsnummern korrigiert.
Der (IT) Blog aus Braunschweig
Gerüchteweise, ist in WordPress 4.9.3 ein Updatebug enthalten, der Autoupdates verhindert. Daher soll händisch auf 4.9.4 aktualisiert werden.
Update: falsche Versionsnummern korrigiert.
Die Hacker News berichten von einem Angriff auf WordPress, der von Seiten der Entwickler als „nicht-unsere-Baustelle“ abgeschmettert wurde, aber ganz leicht abgewehrt werden kann.
Im wp-admin Verzeichnis gibt es ein Script namens „load-scripts.php„, das auf Zuruf, und liegt das Problem, alle Javascripte der Installation, zu einer gemeinsamen Javascriptseite zusammenbaut, damit der Browser nicht jede einzeln laden muß. Das Problem daran ist, jeder kann die Seite aufrufen. Wenn man dann noch die gesamten Javascripte eines WordPress zusammenstellen läßt, reichen wenige Aufrufe, bis die Webseite offline ist.
Das liegt daran, daß bei der Zusammenstellung sehr viel IO entsteht, was den Webserver belastet. Dadurch wird alles langsamer, bis es bei genug Anfragen zum faktischen Stillstand kommt. Dazu kommt eine erhöhte Rechenleistung während die Scripte Ihren Job tun.
Die sagen, daß ein Admin diese Seite aufrufen können muß, wenn er noch nicht als Admin erkennbar ist. Also muß es jeder können. Man solle doch das Problem irgendwo anders löschen, nur nicht bei Ihnen.
„However, the company refused to acknowledge the issue, saying that this kind of bug „should really get mitigated at the server end or network level rather than the application level,“ which is outside of WordPress’s control.“ (Zitat von THN )
Das ist natürlich peinlich, weil jemand das in WordPress gefixt hat und einen Fork davon bereitstellt. Es ist also scheinbar leicht möglich es zu beheben.
Wenn Ihr Zugriff auch Euren Webserver habt, erstellt Ihr einfach für wp-admin eine .htaccess Datei . Das kann man über eine Weboberfläche lösen, so wie hier :

Wenn man die HT-Accessabfrage mit Usernamen und Passwort anlegt, fragt einen der Browser nach den Zugangsdaten, aber merkt sich die auch, so daß man selbst recht unproblematisch wieder ins Backend gelangt. ( Die 5.6 Version von PHP ist wohl beim Testen hängen geblieben und wurde bereinigt 😉 ).
Nach dem Anlegen zeigt meine Oberfläche dann auch an, daß dort eine HTAccess mit Benutzernamen liegt :

Nach dem Anlegen des Benutzers
Wenn man das alles von Hand machen muß, geht das so :
In die Datei wp-admin/.htaccess kommt dieser Inhalt, bei dem Ihr den Pfad anpassen müßt:
AuthType Basic AuthName "Das ist mein WordPress!" AuthUserFile /path_to_wp/wp-admin/.htpasswd Require valid-user
danach gibt man in der Bash ein :
htpasswd -bc /path_to_wp/wp-admin/.htpasswd username password
Das war es dann schon. Jetzt noch im Browser wp-admin/ aufrufen und die neuen Zugangsdaten eingeben und auf Speichern drücken.
Ihr erinnert Euch noch an diese Beiträge zum Thema SSLv3 aus 2016 ?
Sächsische Polizei benutzte gebrochene Verschlüsselung
Ich habe mir mal gedacht, dies Analyse 2 Jahre danach nochmal zu machen und bin zu dem erfreulichen Ergebnis gekommen, daß kein Kontakt der letzten 4 Wochen noch mit SSLv3 um die Ecke gekommen ist. Natürlich hat das jetzt auch einen deftigen Nachteil, ich habe nichts über das man schreiben könnte 😉 Ich finde aber, daß ich den Preis gerne bezahle 😀
Naja, machen wir doch noch was daraus, das Update der meist benutzten Chipers der letzten 4 Wochen :
| 214417x | TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 |
| 109616x | TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 |
| 40927x | TLSv1:ECDHE-RSA-AES256-SHA:256 |
| 19728x | TLSv1.2:ECDHE-RSA-AES256-SHA384:256 |
| 16346x | TLSv1:ECDHE-RSA-AES128-SHA:128 |
| 12112x | TLSv1:AES128-SHA:128 |
| 9864x | TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256 |
| 7270x | TLSv1:DHE-RSA-AES256-SHA:256 |
| 7139x | TLSv1.2:AES256-GCM-SHA384:256 |
| 6924x | TLSv1:AES256-SHA:256 |
| 3767x | TLSv1.2:AES128-SHA256:128 |
| 2649x | TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 |
| 2443x | TLSv1.2:DHE-RSA-AES128-SHA:128 |
| 2062x | TLSv1.2:ECDHE-RSA-AES256-SHA:256 |
| 1226x | TLSv1.1:ECDHE-RSA-AES256-SHA:256 |
| 805x | TLSv1.2:AES128-SHA:128 |
| 748x | TLSv1.2:DHE-RSA-AES256-SHA:256 |
| 442x | TLSv1.2:AES256-SHA:256 |
| 362x | TLSv1:DHE-RSA-CAMELLIA256-SHA:256 |
| 167x | TLSv1:DES-CBC3-SHA:168 |
| 151x | TLSv1.2:AES256-SHA256:256 |
| 135x | TLSv1.2:ECDHE-RSA-AES128-SHA256:128 |
| 59x | TLSv1:EDH-RSA-DES-CBC3-SHA:168 |
| 51x | TLSv1.2:DHE-RSA-AES256-SHA256:256 |
| 40x | TLSv1.2:AES128-GCM-SHA256:128 |
| 35x | TLSv1:DHE-RSA-AES128-SHA:128 |
| 22x | TLSv1.1:DHE-RSA-AES256-SHA:256 |
| 14x | TLSv1.1:AES256-SHA:256 |
| 5x | TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128 |
| 3x | TLSv1:DHE-RSA-DES-CBC3-SHA:168 |
| 3x | TLSv1.2:ECDHE-RSA-AES128-SHA:128 |
| 2x | TLSv1.2:ECDHE-RSA-DES-CBC3-SHA:168 |
| 1x | TLSv1.2:DHE-RSA-CAMELLIA256-SHA:256 |
| 1x | TLSv1.1:AES128-SHA:128 |
Bei 459.536 Emailtransporten insgesamt, ist der hohe Anteil an TLSv1 Protokollen doch erschreckend.
Die beiden Spitzenplätze sind gleich geblieben, aber in nachfolgenden Rängen, hat sich einiges, und das nicht zu guten getan, wenn ich das mit dem Beitrag vom März 2017 vergleiche. Am besten macht Ihr Euch da selbst ein Bild.