WordPress: die vergessene mShot DOS Attacke

Posted on 25. Mai 2020 by marius

Alle guten Geschichten beginnen mit „Es war einmal..“ so auch meine heutige Geschichte eines längst vergessenen Dienstes, der zu einem DOS Angriffs mutiert ist. Wer WP betreibt, wird in diesem Artikel einige Denkeanstöße für seine eigene Instanz bekommen.

WordPress: die vergessene mShot DOS Attacke

Es war einmal ein Dienst der Firma AUTOMATTIC, Inc. die Ihres Zeichens nach WordPress.com betreibt. Wir schreiben die Prä-Neulandzeit. Der Dienst konnte Screenshots von Webseiten erzeugen und irgendwo einbasteln. Im Jahre der Merkel 2012 postete jemand eine Anfrage im WordPressforum, wo denn all die komischen Anfragen in seinem Blog herkommen würden, die „WordPress.com mShots“ im Useragent stehen haben.

Es wurde ihm folgendes mitgeteilt:

mShots was a third party extra feature that has been removed > mShots have been deactivated on all WordPress.com blogs, says a Happiness Engineer:
https://en.forums.wordpress.com/topic/does-using-zemanta-disable-mshots?replies=2#post-517481

Damit Ihr wisst um was es geht, hier ein exemplarischer Auszug aus einem Logfiles eines Kundenservers heute morgen, womit wir uns nebenbei +8 Jahre nach „Einstellung des Dienstes“ befinden:

192.0.100.186 – – [20/May/2020:08:51:12 +0200] „GET /trainer/ HTTP/1.1″ 301 20 „-“ „Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3494.0 Safari/537.36 WordPress.com mShots“
LOCALHOST – – [20/May/2020:08:51:21 +0200] „POST /trainer/wp-cron.php?doing_wp_cron=1589957481.2505230903625488281250 HTTP/1.1″ 200 20 „http://eine.wordpress.seite/trainer/wp-cron.php?doing_wp_cron=1589957481.2505230903625488281250″ „WordPress/5.3.3; https://eine.wordpress.seite/trainer“
192.0.100.186 – – [20/May/2020:08:51:22 +0200] „GET /trainer/ HTTP/2.0″ 200 – „-“ „Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3494.0 Safari/537.36 WordPress.com mShots“

Damit der Spannungsbogen Euch nicht umbringt, hier eine erste Auflösung: der Dienst wurde nicht abgeschaltet 😉

Was sehen wir oben?

Wir haben den Zugriff vom WP Servercluster 192.0.100.186, dann einen Cronjob der von der WP Installation selbst stammt, und danach wieder ein Zugriff vom WP Cluster. Damit haben wir 3x PHP im Spiel, pro Aufruf.

Der Angriff aus dem Nichts

Jetzt gab es um 8:51:xx nicht nur Zugriffe auf diese eine WordPressinstanz, sondern über 100 haben gleichzeitig diese mShots Anfrage bekommen, mit dem Resultat das (am Ende) gleichzeitig hunderte PHP Prozesse liefen.

Jeder der sich mit Hosting auskennt, weiß, daß hunderte von PHP Prozessen jede Menge an Speicher, CPU Last und IO erzeugen, besonders wenn PHP nicht als Modul, sondern im sicheren CGI-Modus läuft. Jetzt wäre auch das nicht das Problem, wenn auf dem nur einige dieser WP Instanzen wären, waren sie aber nicht. Ein einziger Server hat diese Wucht abbekommen und der hatte auch nur 4 Kerne zur Verfügung.

Zufälle gibts, die gibt es gar nicht.

Um dem Ganzen oben noch die Krone aufzusetzen, hatte ein Mitarbeiter der für die WP Instanzen zuständigem Werbeagentur, kurz vorher ein Backup einer Präsenz gestartet. Zu den hunderten von PHP Prozessen lief also auch noch ein TAR/GZ Backup eines nicht kleinen Webdienstes mit 100% Leistung auf einem der vier Kerne.

Jetzt könnte man glauben, daß wäre ja schon Zufall genug, aber da lege ich jetzt noch einen drauf 🙂 Ich war nämlich heute morgen auch zufällig auf dem Server und wollte einer Meldung von letzter Nacht nachgehen, als ich aus Routine, aber wiederum zufällig, in TOP geschaut hatte, ob alles rund läuft. Dabei habe ich dann die ganzen PHP Prozesse im Aufbau eines Totalausfalls bemerkt und konnte gerade noch rechtzeitig „killall php-cgi“ eingeben, bevor es zum Kaskadenversagen durch CPU/IO/SWAP kam. Die Load war bereits auf dem Weg gen 75 😉

Die Suche nach der Ursache

Gefahr gebannt, aber was konnte das ausgelöst haben? So einen ähnlichen Vorfall hatten wir vor einigen Jahren auch mal, als ein Möchtegern-Hacker parallel allen WP-Instanzen ein paar unsinnige Anfragen geschickt hatte und das WP diese nicht beantwortbare Anfrage auch fleißig allen WP Plugins anbot, nur um dann doch 404 Seiten auszugeben, die wiederum im WP gelandet sind ( fast wärs eine Endloss-404-Schleife geworden ). Weil auch die 404 Seiten wiederum durch PHP liefen, hatte sich die Load auch unfreiwillig verdoppelt. Das haben wir damals dann geändert, so das 404 jetzt nur noch statische Webseiten sind, was die Performance des Servers stark verbessert hat.

Kein Hacker…

Umso mehr hatte mich dann gewundert, daß es wieder zu so einer DOSartigen Situation kam. Also schaute ich in die Logs und wurde schnell mit einer Reihe von IPs aus dem gleichen Block belohnt: Denen von WordPress.com.

Da dort merkwürdigerweise immer mShots stand habe ich dann Tante Google gefragt, aber die meinte ja, siehe oben, daß es das gar nicht mehr geben würde. Also habe ich vergleichende Forensik betrieben und danach auf anderen bekannten WP Instanzen in unserem Cluster gesucht. Fündig wurde ich aber nicht.

„Wie das gibt es doch nicht..“

Das Gespräch mit dem Kunden, der sein Server da gerade gedost worden war, war dann nach einer Weile des Rätselns doch von Erfolg gekrönt. Im Ausschlussverfahren haben wir dann ein Plugin identifiziert, daß dafür indirekt verantwortlich war: der Elementor!

Elementor ist ein Plugin-System mit dem man „schneller“ (haha) komplizierte Layouts in WordPress umsetzen kann, als wenn man an den Themes rumspielt. Es ist also eine Art Homepagebaukasten innerhalb von WordPress. Jetzt sind meine Ansprüche an eine Webseite nicht so hoch, daß ich da Elementor einsetzen würde, wenn ich schon WP habe, aber das sehen Werbeagenturen naturgemäß anders 😉

Die Auflösung

Jetzt hatten wir einen Verdacht, also gruben wir noch etwas tiefer und schauten uns die Zeiten an, als den Server die mShots in der Vergangenheit getroffen hatten. Dabei stellte sich ein unregelmäßiges Muster ein, anhand dessen der Kunden dann eingrenzen konnte, daß wann immer er selbst in der Elementor-Zentralinstanz bei Elementor eingeloggt war, so ein DOS Angriff statt gefunden hatte. Das hat er selbst nicht gemerkt, weil er ja anderswo beschäftigt gewesen war. Meistens gab es da auch keine laufenden Backupprozesse, so das die mShot Anfragen bislang unbemerkt geblieben waren. Elementor fragt nämlich beim Login WordPress.com:mShots von allen verbundenen Webseiten (>100 Stück) einen aktuellen Screenshot zu besorgen.

Fazit: Der Kunde hatte sich mit dem Login bei Elementor, und dem laufenden Backup unwissentlich selbst gedost. Das erlebt man auch nicht alle Tage 🙂

Die Empfehlung

Jetzt meine Empfehlung an Euch:

Auch wenn etwas bei der Anzahl 1, 2 oder 3 zügig reagiert, ist das bei 100+ nicht mehr der Fall.

Wenn Ihr also irgendein Programm baut, geht nicht davon aus, daß es ja nur die paar Testfälle verkraften muß, die Ihr hattet, sondern überlegt immer, was passieren kann, wenn hundert, tausend oder gar Millionen Abfragen involviert sind 🙂

Unser Kunde fragt derzeit bei Elementor an, ob man die Screenshots abschalten kann, das solltet Ihr auch abschalten, wenn Ihr so viele Instanzen auf einem einzigen Server habt. Glücklicherweise kam das Plugin nur bei den knapp über 100 WP Instanzen zum Einsatz, auf dem Server sind aber noch hunderte andere Instanzen untergebracht 😉

Wie wichtig das mit dem Einplanen nur „Millionen“ Anfragen sein kann, würde Euch ein anderer Feuerwehr-Fall zeigen, aber leider reden wir nicht über Kundenfälle, außer wir haben die Erlaubnis dazu, was aber hier der Fall ist.

CoronaChroniken: Alles beim Alten

Posted on 24. Mai 2020 by marius

Liebe Kasernierte,

außer einem Ende der Maskenpflicht in Thüringen Anfang Juni, gibt es leider nichts bewegendes zu berichten.

CoronaChroniken: Alles beim Alten

Daher hier nur die Updates der Woche für Euch in Bildern:

Trotz Maskenpflicht will dieser Virus einfach nicht weniger Leute anstecken, wer hätte das von den Null-Effekt-Masken auch anders erwartet. Ich fordere hiermit ein Ende der unsinnigen Community-Maskenpflicht in ganz Deutschland.

Wie die Kurve oben zu interpretieren ist, findet Ihr hier: CoronaChroniken: Der negative Maskeneffekt

In anderen Nachrichten: „Pathologen finden schwere Lungenschäden in … Toten, die an Lungenentzündung mit/durch Covid-19 gestorben sind“. Was bitte hatten die da sonst erwartet? Aber man kann ja schon froh sein, daß überhaupt mal wer nachschaut.

CoronaChroniken: Zahlen lügen nicht – Teil 3

Posted on 22. Mai 2020 by marius

Liebe Kasernierte,

heute gab es einen Pressevorfall, der schon an Fakenews grenzt. Es geht um die angebliche Übersterblichkeit in Deutschland. (Alle die wegen IT hier sind, scrollt mal runter zum nächsten Artikel)

CoronaChroniken: Zahlen lügen nicht – die Nicht-Übersterblichkeit

Die Webseite Spektrum.de des Spektrum-Verlags präsentierte jüngst folgende These: „Übersterblichkeit »vergleichsweise gering«“

Der ganze Artikel ist hier erreichbar, aber absichtlich nicht verlinkt, um die nicht auch noch zu belohnen: https://www.spektrum.de/news/uebersterblichkeit-vergleichsweise-gering/1735480 )

Die Grundaussage ist: Es gab im April eine leichte Übersterblichkeit und im Vergleich z.B. zu Frankreich wäre das ja nur vergleichsweise gering ausgefallen.

Da sich der Artikel auf das Bundesamt für Statistik beruft, sollten wir doch mal deren Meinung im Originalbild und „Ton“ vergleichen:

Erklärung: die rote Linie ist der Sterbeverlauf 2020, die blau gestrichelte Linie ist der Durchschnitt 2016-2019 und die grauen Linien sind die beiden letzten Jahre.

Was sehen wir da?

Das im Jahr 2018 in Kalenderwoche 10 ( KW10 ) ~7.000 Menschen mehr gestorben sind als in 2020. In 2020 sind sogar unterdurchschnittlich wenige Menschen gestorben, erkennt man daran, daß die Kurve unter dem gepunkteten Verlauf entlang zieht. In ca. KW 15 fällt der Durchschnitt dann stark ab (Ende der Grippewelle 2-3 Wochen vorher) und die Sterberate in Deutschland steigt in 2020 dagegen leicht an.

Da sind dann ca. 900 Menschen in einer ganzen Woche mehr gestorben, als im Vergleich zu letzten großen Grippewelle 2018. (Kleiner Tip: https://www.destatis.de/ besuchen, die Grafik ist interaktiv und zeigt bei jedem Punkt die nativen Zahlen direkt an.) Am Tag sind das 128 Menschen, oder 5,12% mehr als „normal“. Das sind pro Tag 0,00015418% der Bevölkerung (83Mio).

Was schreibt das Bundesamt dazu?

Um die Frage zu beantworten, ob COVID-19 zu einer Übersterblichkeit führt, beobachten wir anhand einer Sonderauswertung die vorläufigen Sterbefallzahlen in Deutschland. Im Moment sind die Zahlen bis zum 19. April 2020 darstellbar. Im März 2020 mit insgesamt mindestens 86 400 Sterbefällen ist bei einer monatsweisen Betrachtung kein auffälliger Anstieg der Sterbefallzahlen im Vergleich zu den Vorjahren erkennbar. Seit der letzten Märzwoche liegen die Zahlen allerdings über dem Durchschnitt der Jahre 2016 bis 2019.
Quelle: https://www.destatis.de

Es liegt leicht über dem Durchschnitt der letzten 3 Jahre, aber noch im Toleranzbereich der Normalkurve (95% Regel). Diese Kurven haben zwar ein relativ ähnlichen Verlauf jedes Jahr, aber das am Tag 2500 Menschen Sterben, ist natürlich auch nur wieder ein Mittelwert/Durchschnitt. Hätte es einen Flugzeugabsturz gegeben, wären an einem Tag eben auch mal deutlich mehr als 2500 gestorben, die Kurve hätte einen Ausreißer gehabt und das wärs dann auch schon gewesen. Es sterben eben doch nicht jeden Tag gleich viele Menschen.

Argumentieren wir mal wie die Gegenseite

„Die Kurve liegt über dem Durchschnitt, also hatten wir eine Übersterblichkeit“ Stimmt technisch natürlich, aber was war eigentlich in KW 8 – KW 13 los? Da lag doch unsere 2020 Kurve deutlich unter dem Durchschnitt oder? War das nicht eine Untersterblichkeit? Ja, war es, wenn man das mit zwei extrem Grippejahren vergleicht sowieso.

Fakt ist, daß aufgrund der erhöhten Vorsicht, der Mahnungen im Fernsehen, der Isolation der Risikogruppen, sprich der Angst des Individuums am „Killervirus“ zu versterben, weniger Menschen Kontakt hatten und damit natürlich weniger Neuinfektion mit allen anderen Viren da draußen stattgefunden haben, was zu weniger Sterbefällen bei den Risikogruppen geführt hat. Da sich die Natur von uns nicht verarschen lässt, starben diese geschützten Menschen dann halt etwas später, an ihren Resterkrankungen.

Schauen wir uns mal Frankreich an, da kann man das derzeit hervorragend sehen:

Es mag uns nicht gefallen, aber der Virus macht seinen Job und rafft gehäuft die Alten und Schwachen dahin. Die sind ab Woche 17 in Frankreich nicht nochmal gestorben, ergo sterben jetzt weniger als „Normal“. Auf Frankreich bezogen sogar „deutlich“ weniger als normal wäre.

Die Auflösung ist ganz einfach:

Der Virus hat die Sterberaten von Menschen in Frankreich, die ohne den Virusinfekt nicht gleich gestorben wären, im Datum nach vorn verlegt. Wir in Deutschland haben das Sterbedatum von Menschen durch die Isolation für viele Menschen nach hinten verlegt. Als Folge werden wir im ganzen Jahr eine leichte Erhöhung des Sterbeschnitts sehen, bis alle die verstorben sind, die bereits an der Viruswelle hätten versterben sollen.

Können wir jetzt bitte endlich zurück zum Alltag übergehen, dieser Virus ist in seiner Auswirkung auf die Gesellschaft nicht anders als andere Viren auch. Er mag ja andere schwere Verläufe hervorrufen als bislang bekannte Viren, aber ansonsten ist an dem Virus nichts besonderes, außer wir machen was besonderes daraus.

Marius Welt

Monthly Archives: Mai 2020

WordPress: die vergessene mShot DOS Attacke