Der Stack, den wir auditiert haben
Die WordPress-Site eines kleinen Unternehmens kam zum Sicherheitsaudit, und die Befunde waren von der gewöhnlichen Sorte, die eine Site leise einen automatisierten Scan von der Kompromittierung entfernt hält. Der Page-Builder, Elementor, war auf Version 3.11.1 festgenagelt und trug vier kritische CVEs, darunter SQL injection und stored cross-site scripting. Contact Form 7 lief auf 5.8, anfällig für CVE-2023-6449, einen beliebigen Datei-Upload. Nichts Exotisches, einfach veraltete Plugins, was der dominierende Weg ist, auf dem WordPress-Sites kompromittiert werden.
Das Unangenehme ist, wie normal das ist. Die Site funktionierte. Sie sah gut aus. Der Eigentümer hatte keinen Grund, etwas zu vermuten, denn veraltete Plugins zeigen keine Symptome, bis sie ausgenutzt werden. Das Audit existierte, um die Lücke zu finden, bevor es jemand anderes tat.
Veraltete Plugins sind die Angriffsfläche
Ein Plugin ist sicher, solange es gepatcht wird. In dem Moment, in dem eine Schwachstelle als CVE veröffentlicht wird und Sie nicht aktualisiert haben, ist der Exploit öffentliches Wissen und Ihre installierte Version ein benanntes Ziel für automatisierte Scanner. Angriffe auf WordPress sind überwiegend blind und automatisiert, Bots durchkämmen das Netz nach bekanntermaßen verwundbaren Versionen beliebter Plugins, sodass der Betrieb eines alten Elementor oder Contact Form 7 kein abstraktes Risiko ist. Es ist ein beworbenes.
Auf dieser Site:
- Elementor 3.11.1 trug vier kritische CVEs (darunter SQL injection und stored cross-site scripting), während die gepatchte Linie bereits auf 3.17.3 vorgerückt war. Jedes dieser vier war aktiv.
- Contact Form 7 5.8 war anfällig für CVE-2023-6449, eine Drag-and-drop-Datei-Upload-Schwachstelle, die einem authentifizierten Nutzer mit Redakteursrechten erlaubte, beliebige Dateien hochzuladen, ein direkter Weg zur Remote-Code-Ausführung.
Keines der beiden Plugins war ungewöhnlich. Beide laufen auf einem riesigen Anteil von WordPress-Sites. Genau deshalb sind ihre bekannten Schwachstellen die Zeit eines Scanners wert.
Was das Audit prüft
Ein Sicherheitsaudit ist methodisch statt clever. Sein Kern:
- Jedes installierte Plugin und Theme inventarisieren und jede Version mit ihren bekannten CVEs und der sicheren Mindestversion abgleichen. Das brachte hier die Exposition von Elementor und Contact Form 7 ans Licht.
- Benutzerdefinierten Code und Theme-Code auf die WordPress-Sicherheitsgrundlagen testen, nonce- und Berechtigungsprüfungen bei Aktionen, Eingaben, die vor der Datenbank bereinigt werden, Ausgaben, die vor der Seite escaped werden, und Endpunkte, die Autorisierung verlangen.
- Die Exposition auf Serverebene prüfen, eine offene
xmlrpc.php, in der Produktion angezeigte PHP-Fehler, die Pfade verraten, fehlende Sicherheitsheader. - Die Aktualisierungs- und Backup-Haltung überprüfen, denn eine ungewartete Site treibt binnen Monaten in diesen Zustand zurück.
Der Versionsabgleich ist der unspektakuläre Teil, der am meisten fängt, denn die häufigste WordPress-Schwachstelle ist kein cleverer Zero-Day. Es ist ein beliebtes Plugin drei Versionen hinter seinem Patch.
Wo KI-gestützte Builds es verschlimmern
Bei diesem Audit ging es um veraltete Drittanbieter-Plugins, das Vernachlässigungsmuster. KI-gestützte Builds fügen eine zweite Schicht obendrauf. Sie installieren Plugins schnell, oft ohne irgendeine Aktualisierungsroutine einzurichten, sodass Versionen noch schneller hinter ihren Patches zurückbleiben. Und KI-generierter benutzerdefinierter Code wird häufig ohne die nonce-, Berechtigungs- und Bereinigungsprüfungen erstellt, die WordPress erwartet, sodass Sie zugleich ein Problem mit veralteten Plugins und eines mit generiertem Code erben. Deshalb ist diese Art von Audit Teil unserer umfassenderen Rettung KI-erstellter Websites, und deshalb beginnt ein eigenständiges WordPress-Sicherheitsaudit mit dem langweiligen Versionsabgleich, bevor irgendetwas anderes kommt.
Wie das Beheben aussieht
Die Reihenfolge der Behebung richtet sich nach dem Risiko, nicht nach der Bequemlichkeit:
- Die Plugins mit aktiven CVEs sofort patchen oder entfernen, beginnend mit den Datei-Upload- und Injection-Wegen, denn die haben die höchste Schwere.
- Plugins entfernen, die aufgegeben oder nicht mehr nötig sind, und so die Fläche dauerhaft verkleinern.
- Die Exposition auf Serverebene schließen (
xmlrpc.php, Fehleranzeige in der Produktion, fehlende Header). - Eine echte Aktualisierungs- und Backup-Routine einrichten, damit die Site nicht binnen eines Jahres wieder zu vier aktiven CVEs zurücktreibt.
Glossar
- CVE - ein Bezeichner aus Common Vulnerabilities and Exposures, ein öffentlicher Katalogeintrag für eine bestimmte bekannte Schwachstelle.
- SQL injection - ein Angriff, der Datenbankbefehle durch nicht bereinigte Eingaben einschleust.
- Stored cross-site scripting - bösartiges Skript, das auf der Site gespeichert und anderen Nutzern ausgeliefert wird.
- Nonce- / Berechtigungsprüfung - WordPress-Mechanismen, die bestätigen, dass eine Anfrage beabsichtigt ist und der Nutzer sie stellen darf.
Das Fazit
Eine WordPress-Site muss nicht interessant sein, um angegriffen zu werden. Sie muss eine bekanntermaßen verwundbare Version eines beliebten Plugins betreiben, was auf einen großen Anteil der nicht auditierten Sites zutrifft. Die gute Nachricht ist, dass das dominierende Risiko auch das langweiligste zu beheben ist, gleichen Sie jede Plugin-Version mit ihren CVEs ab, patchen oder entfernen Sie die Übeltäter und richten Sie eine Wartungsroutine ein, damit sich die Lücke nicht wieder öffnet. Die Site in diesem Audit war einen Scan von Ärger entfernt und wusste es nicht. Die meisten Sites in dieser Lage wissen es nicht.
