Kommentare zu folgendem Beitrag: WordPress: 26 ungepatchte Sicherheitslücken – Haikhavan wirft Automattic Untätigkeit vor
Sicherheitsforscher Aria Akhavan informierte am 12. August das Softwareprojekt WordPress über 26 Lücken, nichts ist passiert.
Kommentare zu folgendem Beitrag: WordPress: 26 ungepatchte Sicherheitslücken – Haikhavan wirft Automattic Untätigkeit vor
Wordpress schrieb aber auch:
Backports
Aus Kulanzgründen werden die Sicherheitskorrekturen, falls erforderlich, auf alle Zweige zurückportiert, die für den Empfang von Sicherheitskorrekturen berechtigt sind (derzeit bis einschließlich Version 4.7). Zur Erinnerung: Nur die aktuellste Version von WordPress wird aktiv unterstützt .
Die Rückportierungen sind in Arbeit und werden veröffentlicht, sobald sie fertig sind.
Also lieber neue Versionen mit bestehenden Lücken veröffentlichen, damit man Shareholder glücklich macht und Security Advisories ignorieren? Nachträgliches patchen ist ja noch okay, aber dazwischen Featureupdates und sonstiges vorzuschieben, auf ernste Reports nicht reagieren über Monate hinweg, aber währenddessen gemütlich mehr releasen ist definitiv nicht, wie es 1. das Gesetz vorsieht 2. das beste für die bestehenden User.
Andere Hersteller veröffentlichen doch auch keine kaputten Projekte basierend auf kaputten Fundamenten, während alles schon gemeldet wurde und ihnen bekannt ist.
1 Like
WIE BITTE ? 
oder war das Satire ?
XML RPC wird bereits seit längerem empfohlen zu disablen. Klar sollte nicht default sein.
Ordner /wp-content/uploads/ zusätzlich auf Serverebene vor einem direkten Web-Zugriff zu schützen.
Sowas war früher mal selbstverständlich. Opa erzählt aus dem Krieg.
Contao wird komplett außerhalb installiert, da geht man allem aus dem Weg, was die Installation aber leider auch recht gurkig macht.
Jap, dachte ich auch als erstes!
Aber irgendwie vermisse ich noch den absoluten Standard-Fehler → Das WP-Installationspaket im Anschluß stehen zu lassen, damit jeder Honk
dann nur noch → /wp-content/wp-admin/install.php tippeln muss!!
Aber locker vom 30-jährigen Krieg, odää?
Nein, die Vorstellungen von @entropyaria mögen nicht mehr aktuell sein, aber sind sie deswegen schlecht?
Der status quo, wie manche aktuell Firmen Software veröffentlichen/entwickeln ist doch keine Verbesserung, oder etwa doch?
Auch wenn es sicher nicht ernst gemeint war, mal etwas zum Thema Opa - Erfahrungen aus dem Krieg sind (meistens) EXTREM NEGATIV. Aber was er schrieb, doch nicht.
Und weiter:
Ist es von einer Firma wegen des zusätzlichen Aufwands wirklich zu viel verlangt, was er schreibt?
Nur weil es heute üblich ist und vielleicht modern erscheint, macht es das Verhalten besser?
Oder sind die Ansprüche damals wie heute einfach überzogen? Ich bin kein Entwickler, keine Ahnung. Was sagt ihr?
Ging nicht um aktuell. Es ging mir um die Ansicht das andere Anbieter regelmäßig Sicherheitsupdates bringen würden (und im Gegensatz zu Wordpress). Und das ist definitiv falsch. Zudem schimmerte mir da etwas hate auf Wordpress durch. Was nicht heissen soll das das Konzept das Beste ist, kommt halt aus dem Blog Bereich und nicht aus dem CMS Bereich.
Natürlich sollten Anbieter regelmäßig Sicherheitsupdates bringen. Da bin ich doch dabei.
Was Wordpress betrifft, die machen das eigentlich schon recht gut, da kommen dauernd Sicherheitsupdates, deshalb passt da der Vorwurf nicht so ganz (*1), grad wenn man mit anderen CMS vergleicht. Sowohl die Addons als auch Wordpress selbst aktualisiert automatisch, selbst über Hauptversionen hinweg! Das ist bei anderen CMS eher die Ausnahme. Die bleiben dann teils bei Uralt Versionen stehen. Da meine ich auch die großen Anbieter.
Klar könnte noch Sachen verbessert werden wie XML RPC, install.php usw , wobei es möglicherweise irgendwelche Gründe gibt warum mans nicht macht. install.php würde ich sagen wenn die Installation schief gegangen ist, hätte man keine Möglichkeit die neu zu starten.
Nochmal ein ganz anderer Punkt, der mir auch gegen den Strich geht. Man sollte aus dieser Opferrolle raus. Das Hauptproblem … sind fehlende Backups. Da kann ich selbst im worst Case alles neu einspielen. Das Problem haben aber auch große Firmen. Da wird dann immer auf die bösen Hacker abgewälzt. Ne, ihr habt eure Arbeit nicht gemacht.
(*1) was den Fall Haikhavan betrifft kann ich nichts zu sagen weil ich den Fall nicht kenne. Vielleicht hat er recht, vielleicht hätte er gern mehr Aufmerksamkeit, idk.
Du weißt doch…
…wer Backups macht, ist feige…!
Natürlich soll die PHP-Datei solange in der Struktur erhalten bleiben, bis eine Installation komplett & erfolgreich war! Sobald man dann ins administrative Backend reinkommt, ist ja alles soweit tutti. DANN erst wird die „install.php“ aus dem Konstrukt gelöscht!
Einige Software-Anbieter haben diesen Delete-Vorgang sogar in ihrer Installationsroutine integriert, aber noch lange nicht alle…
1 Like
Das war mir schon klar 
Es könnte aber der Fall eintreten das die Routine meldet alles ok und trotzdem gibts ein Problem, oder man will die Installation mit anderen Daten wiederholen. Aber ja ich wäre auch dafür die nach der Installation zu löschen, im Notfall muss man die einfach neu einspielen.
Entweder das…oder man könnte die Datei einfach umbenennen an der Stelle. Möglich wäre aber auch, die Datei einfach in einen selbst erstellten Ordner „xyz“ zu verschieben.
1 Like
Okay, verstehe, die anderen bringen die nicht häufiger (bzw. regelmäßig Sicherheitspatches heraus). Gut, das machen sie besser.
Zu dieser aktuellen WP Problematik passt natürlich, dass nun auch „Elementor“ die administrative WP-Security unterwandert!
Eine Cross-Site-Request-Forgery-Schwachstelle (CSRF) im Elementor-Plugin für WordPress könnte es einem nicht authentifizierten Angreifer ermöglichen, Administratorkonten zu erstellen.
Angreifer können die Schwachstelle ausnutzen, indem sie einen angemeldeten Administrator dazu verleiten, einen schädlichen Link zu öffnen, wodurch die authentifizierte Sitzung des Opfers eine REST-API-Aktion ausführt, die von seinem Konto erlaubt ist.
Bei Standardinstallationen führt dies zur Erstellung eines Administratorkontos, das unter der Kontrolle des Angreifers steht.
Der Elementor Website Builder ist ein beliebtes WordPress-Plugin, das auf 10 Millionen Websites aktiv ist und es Benutzern ermöglicht, Websites mithilfe einer Drag-and-Drop-Oberfläche zu erstellen.
Die CSRF-Schwachstelle hat noch keine Kennung erhalten und betrifft nur die Versionen 4.3.0 und 4.3.1. Laut Statistiken von WordPress.org werden diese beiden Versionen von bis zu 2 Millionen Websites verwendet .
Das Sicherheitsunternehmen Patchstack meldete die Sicherheitslücke am 22. September an das Elementor-Team, nachdem es sie vom Bug-Hunter „Saggre“ erhalten hatte. Elementor veröffentlichte zwei Tage später einen Fix in Version 4.3.2 des Plugins.
Laut der Analyse von Patchstack wird die CSRF-Schwachstelle dadurch verursacht, dass das Editor Events-Modul von Elementor die rohe Anfrage-URI für den Pfad elementor/v1/events/ überprüft und die REST-Nonce-Validierung von WordPress umgeht, wenn diese Zeichenkette vorhanden ist.
Da die URI auch vom Angreifer kontrollierte Abfrageparameter enthält, können Angreifer den Pfad an Anfragen anhängen, die auf andere REST-Endpunkte abzielen, und angemeldete Benutzer dazu verleiten, diese mit ihren bestehenden Berechtigungen auszuführen.
Patchstack zufolge kann die Schwachstelle für Ein-Klick-Angriffe gegen einen angemeldeten Administrator ausgenutzt werden, um ein neues, vom Angreifer kontrolliertes Administratorkonto zu erstellen.
„Ein Link, der von einem eingeloggten WordPress-Benutzer geöffnet wird, veranlasst diesen Benutzer, jede beliebige REST-API-Aktion auszuführen, zu der sein Konto berechtigt ist“, erklärt Patchstack .
Das Sicherheitsunternehmen erklärt, dass für den Angriff weder JavaScript noch eine vom Angreifer kontrollierte Webseite oder ein ausgefülltes Formular erforderlich sind und der Link dem Ziel per E-Mail, Chatnachricht oder Kommentar auf der Webseite übermittelt werden kann.
Elementor-Versionen vor 4.3.0 enthalten den betroffenen Editor Events-Proxy nicht, aber diese älteren Versionen sind anfällig für andere Schwachstellen, von denen einige bereits aktiv ausgenutzt werden .
Benutzern des Plugins wird empfohlen, so schnell wie möglich auf Elementor Version 4.3.2 zu aktualisieren, da dies verhindert, dass Angreifer die Umgehung über die Abfragezeichenfolge auslösen können.
Mein Tipp dazu:
Wenns vorne juckt und hinten beißt, nimm Klosterfrau Melissengeist!
