WordPress DOS – wp-admin Verzeichnis schützen

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.

Der Angriff

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.

Was meint WordPress dazu ?

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.

Eine Lösung des Problems

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 :

Admin-Weboberfläche nach dem Anlegen des Benutzers

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.

Followup – Der SSLv3 Stand

Ihr erinnert Euch noch an diese Beiträge zum Thema SSLv3 aus 2016 ?

Sächsische Polizei benutzte gebrochene Verschlüsselung

Neue TLS Probleme beim BSI

Häufigkeit von TLS Ciphern

Stand der Dinge

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 :

214417xTLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
109616xTLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128
40927xTLSv1:ECDHE-RSA-AES256-SHA:256
19728xTLSv1.2:ECDHE-RSA-AES256-SHA384:256
16346xTLSv1:ECDHE-RSA-AES128-SHA:128
12112xTLSv1:AES128-SHA:128
9864xTLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
7270xTLSv1:DHE-RSA-AES256-SHA:256
7139xTLSv1.2:AES256-GCM-SHA384:256
6924xTLSv1:AES256-SHA:256
3767xTLSv1.2:AES128-SHA256:128
2649xTLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256
2443xTLSv1.2:DHE-RSA-AES128-SHA:128
2062xTLSv1.2:ECDHE-RSA-AES256-SHA:256
1226xTLSv1.1:ECDHE-RSA-AES256-SHA:256
805xTLSv1.2:AES128-SHA:128
748xTLSv1.2:DHE-RSA-AES256-SHA:256
442xTLSv1.2:AES256-SHA:256
362xTLSv1:DHE-RSA-CAMELLIA256-SHA:256
167xTLSv1:DES-CBC3-SHA:168
151xTLSv1.2:AES256-SHA256:256
135xTLSv1.2:ECDHE-RSA-AES128-SHA256:128
59xTLSv1:EDH-RSA-DES-CBC3-SHA:168
51xTLSv1.2:DHE-RSA-AES256-SHA256:256
40xTLSv1.2:AES128-GCM-SHA256:128
35xTLSv1:DHE-RSA-AES128-SHA:128
22xTLSv1.1:DHE-RSA-AES256-SHA:256
14xTLSv1.1:AES256-SHA:256
5xTLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
3xTLSv1:DHE-RSA-DES-CBC3-SHA:168
3xTLSv1.2:ECDHE-RSA-AES128-SHA:128
2xTLSv1.2:ECDHE-RSA-DES-CBC3-SHA:168
1xTLSv1.2:DHE-RSA-CAMELLIA256-SHA:256
1xTLSv1.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.

 

Das FF 3 Tage Update

3 Tage Quantum Firefox sind rum. Einige Firefoxe wurden schon durch diese userChrome.css bereinigt. Und ja, an einigen Stellen, ist er auch schneller als früher. Auf extrem auf Javascript angewiesenen Webseiten, gehen einige Sachen schneller als früher. Ob das den Ärger wert war, würde ich verneinen, weil sooo langsam wars vorher dann doch nicht.

Die Nacharbeiten

PreFetching mußte wieder abgeschaltet werden. Das lädt ungefragt alle Links einer Seite vor, damit im unwahrscheinlichen Fall, daß man auf die Werbelinks 😉 klickt, die schneller da sind. Da dies auch meint, das unsichtbare Links geladen werden, beglückt so ein Firefox auch mal Seiten, die man gar nicht besuchen will. Ist mehr so ein Datensparsamkeitsproblem, denn ein Bandbreitenproblem und auch nicht neu. Mozilla ist sich dessen durchaus bewußt und hat eine Webseite zum Thema im Angebot:

https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections

Damit kein falscher Eindruck entsteht, die ist auf Stand. Geht also 🙂

Ganz im Sinne der aktuellen Spectre und Meltdown CPU-Probleme fällt einem sofort der Begriff „Speculative pre-connections“ auf.

To improve the loading speed, Firefox will open predictive connections to sites when the user hovers their mouse over thumbnails on the New Tab Page or the user starts to search in the Search Bar, or in the search field on the Home or the New Tab Page. In case the user follows through with the action, the page can begin loading faster since some of the work was already started in advance.“ ( Quelle: how-stop-firefox-making-automatic-connections )

d.h. Firefox macht also schon Verbindungen zu Servern auf, damit es im Fall es Falles dann eine halbe Mikrosekunde schneller geht, nur weil man die Maus kurz wo geparkt hat. Bei langsamen Anbindungen spielt das sicherlich eine Rolle, aber mit so 16 Mbit aufwärts, sollte so was eigentlich gar kein Problem mehr sein. Das wird sich in den nächsten Stunden dann mal wieder zeigen müssen.

Natürlich sind einige Fanboy Kommentar eingegangen, die nicht abgedruckt wurden. Um es nochmal ganz klar zu sagen, FireFox ist auch mir sympathischer als Chrome, Edge & Co. sonst würde ich mir das ja nicht geben 🙂 Ich bin aber auch stinkig über die Art und Weise wie das gelaufen ist, und ich bin es noch. Das hätte so nicht sein müssen. Und noch was, was den FanBoys nicht passen wird: FireFox ist nicht das Vorzeige Open-Source-Macht-Alles-Richtig-Gut Projekt, das Ihr Euch vorstellt. Ich war an dem !KAMPF! beteiligt, das „ß“ bei uns  in die Domainnamen zu bekommen. Nach Internationalen Regeln war das 2008 beschlossen worden und wurde 9 Jahre todgelabbert. Es hat alle Beteiligten viel Kraft gekostet, FireFox auf Linie mit internationalen Standards zu bringen, das kann man kaum erahnen. Das es keinen Großbuchstaben „ß“ gibt, war ein echtes Problem.

Das sind dann so Dinge, die man als User nicht mitbekommt, weil es einen nicht interessiert oder man schlicht nichts davon weiß. Wenn ich allein von der Erfahrung auf die Prozesse bei Mozilla und Firefox rückschliessen müßte, gäbe das kein gutes Bild. Wer sich da selbst mal Überzeugen will, sollte in den Bugtracker einloggen und sich mal die jahrealten OPEN Fälle ansehen, weil da teilweise auch jahrelang gestritten wird, was denn nun richtig ist. Dabei sind das nur Bugreports, keine Idee wie die intern miteinander streiten 😉 Da merkt man dann auch, daß auch Entwickler ein Ego haben, daß sie durchsetzen wollen und manchmal auch müssen. Nur fehlt da hin und wieder die ordnende Hand eines Bosses.