Drupal, Joomla, Magento Sicherheit: Die Schwachstellen, die niemand prüft
WordPress bekommt die ganze Sicherheits-Aufmerksamkeit — aber Drupal, Joomla und Magento haben ihre eigenen kritischen Schwachstellen. Eine Lücke in Magento = exponierte Kreditkartendaten. Die Risiken sind enorm.
- Jedes CMS hat standardmäßig exponierte Dateien und Endpoints: CHANGELOG.txt (Drupal), configuration.php.bak (Joomla), /app/etc/local.xml (Magento) — ohne Admin-Zugang sichtbar
- Externe Audits (ohne Back-Office-Zugang) können die meisten dieser Schwachstellen erkennen — genau wie es ein Angreifer bei der ersten Erkundung tun würde
- Oriyts Batch 1 und 2 werden CMS-spezifische Sicherheitstests hinzufügen — Joomla, Magento, PrestaShop, Drupal, OpenCart, alle extern, alle automatisch
WordPress absorbiert die gesamte Aufmerksamkeit in der Web-Sicherheit. Verwundbare Plugins, veraltete Versionen, Brute-Force-Angriffe auf wp-admin — darüber wird ständig gesprochen. Unterdessen betreiben Drupal, Joomla und Magento weiterhin Regierungswebsites, Universitätsportale und E-Commerce-Shops, ohne dass jemand ihre Sicherheit ernsthaft auditiert.
Die Risiken sind erheblich. Eine Schwachstelle in Magento bedeutet potenziell exponierte Kreditkartennummern. In Drupal sind es Regierungsdaten in Gefahr. In Joomla sind es Kundendatenbanken in Reichweite. Drupalgeddon 2018 betraf Hunderttausende von Websites — und ähnliche Muster existieren noch heute.
Was die Situation noch beunruhigender macht: Die meisten dieser Schwachstellen sind ohne Admin-Zugang erkennbar — einfach indem man schaut, was der Server öffentlich exponiert. Genau das tut ein Angreifer in der Aufklärungsphase. Und genau das wird Orilyt für Ihr nächstes Audit automatisieren.
Drupal — die Schwachpunkte des Enterprise-Giganten
Drupal betreibt Ministerien, Universitäten und Fortune-500-Unternehmen. Sein Ruf für Robustheit ist verdient — aber er erzeugt einen falschen Eindruck automatischer Sicherheit. In Wirklichkeit sind mehrere Angriffsvektoren bereits bei der ersten externen Erkundung zugänglich.
Drupal hält eine CHANGELOG.txt-Datei im Stammverzeichnis, die die genaue installierte Version preisgibt. Ein Angreifer benötigt nur diese Information, um spezifische CVEs anzuvisieren. Diese Datei sollte in der Produktion gelöscht oder eingeschränkt werden.
Das /update.php-Skript ermöglicht es, die Datenbank nach einem Drupal-Upgrade zu aktualisieren. Ungeschützt zugänglich gelassen, kann es von jedem ausgelöst werden — ein klassischer Vektor für die Manipulation des Datenbankschemas.
Der Standard-Administrationspfad /user/login ist leicht identifizierbar. Kombiniert mit der Versionserkennung über das Meta-Generator-Tag (oft bei Standard-Installationen vorhanden), liefert dies alle notwendigen Informationen für einen gezielten Angriff.
Der Fall Drupalgeddon (SA-CORE-2018-002) bleibt emblematisch: Remote Code Execution ohne Authentifizierung, massiv innerhalb von Stunden ausgenutzt. Die ursprüngliche Schwachstelle war eine SQL-Injection-Lücke — aber die Versionsexposition ermöglichte es Angreifern, ungepatchte Websites mit chirurgischer Präzision anzuvisieren.
Joomla — das vergessene Mittelkind
Joomla nimmt eine unbequeme Position im CMS-Ökosystem ein: populär genug, um ein attraktives Ziel zu sein, ignoriert genug, damit seine Schwachstellen unbemerkt bleiben. Millionen von Websites laufen noch auf Joomla 3.x — einem Branch, der im Dezember 2023 das End-of-Life erreicht hat.
Bei Updates oder Migrationen werden manchmal Backup-Dateien der Hauptkonfiguration zugänglich gelassen. configuration.php.bak — oder configuration.php.old, configuration.bak.php — kann Datenbankzugangsdaten im Klartext enthalten.
Die Administrationsoberfläche von Joomla ist standardmäßig unter /administrator/ zugänglich. Während der Installation wird keine Pfadänderung vorgeschlagen. Dieser Pfad wird von automatisierten Angriffsbots vorrangig gescannt.
Joomla exponiert oft seine genaue Version über das Meta-Generator-Tag. Schlimmer noch: Den Debug-Modus in der Produktion aktiviert zu lassen (configuration.php: $debug = 1) führt dazu, dass sensible Informationen auf Fehlerseiten angezeigt werden — Serverpfade, SQL-Abfragen, Session-Variablen.
Joomla-Erweiterungen sind ein wichtiger und oft unterschätzter Angriffsvektor. Im Gegensatz zu WordPress, das ein zentralisiertes Repository mit Meldesystemen hat, zählt das Joomla-Ökosystem Tausende von Drittanbieter-Erweiterungen, von denen viele nicht mehr gepflegt werden.
Magento — wo Geld auf Risiko trifft
Magento (Adobe Commerce) ist das Referenz-E-Commerce-CMS für hochvolumige Shops. Es ist auch eines der lukrativsten Ziele für Angreifer. Magecart-Angriffe — Injektion von bösartigem JavaScript in den Checkout zur Erfassung von Kartendaten — haben Tausende von Magento-Shops betroffen.
Magento 1.x exponierte einen Downloader unter /downloader/ zur Extension-Installation. Magento 2.x hat seinen Installationsassistenten unter /setup/. Diese Endpoints, nach der Installation zugänglich gelassen, sind direkte Einstiegspunkte für Angreifer.
Die Datei /app/etc/local.xml (Magento 1) oder /app/etc/env.php (Magento 2) enthält Datenbankzugangsdaten, Verschlüsselungsschlüssel und andere Geheimnisse. Ein falsch konfigurierter Server, der diese Datei direkt ausliefert, exponiert alle Daten des Shops.
Magento erlaubt die Anpassung des Admin-Pfads während der Installation, aber viele Deployments behalten /admin/ oder /index.php/admin/. Das Sicherheits-Patch-Management ist ebenfalls ein Problem: Händler verzögern oft Updates aus Angst, Anpassungen zu brechen, und lassen kritische CVEs monatelang ungepatch.
Magecart-Angriffe veranschaulichen die Realität des Risikos perfekt: Ein Angreifer braucht keinen Admin-Zugang, um katastrophale Schäden zu verursachen. Eine einfache JavaScript-Injektion in das Checkout-Formular — ermöglicht durch eine ungepatchte Version oder eine verwundbare Extension — reicht aus, um alle Zahlungsdaten zu exfiltrieren.
PrestaShop und OpenCart — die E-Commerce-Außenseiter
PrestaShop und OpenCart bekommen nicht dieselbe Medienaufmerksamkeit wie Magento, betreiben aber Hunderttausende von Online-Shops. Ihre Schwachstellen sind umso gefährlicher, als sie selten auditiert werden.
PrestaShop benennt den Admin-Ordner normalerweise während der Installation um, aber /admin-dev/ wird manchmal in Entwicklungsumgebungen belassen, die in der Produktion eingesetzt werden. Die Dateien /app/config/parameters.php und /config/settings.inc.php enthalten Datenbankzugangsdaten.
OpenCart behält /admin/ als Standard-Pfad in den meisten Installationen bei. Kritischer noch: config.php und admin/config.php enthalten den absoluten Serverpfad, Datenbankzugangsdaten und geheime Schlüssel — und sind auf falsch konfigurierten Servern manchmal direkt über den Browser lesbar.
Ein bekanntes SQL-Injection-Muster betrifft mehrere OpenCart-Versionen, insbesondere in Produktfilter-Modulen. Diese Schwachstellen sind dokumentiert und öffentliche PoCs existieren — was die Ausnutzung für jeden Script-Kiddie mit Suchmaschinen-Zugang trivial macht.
Warum externe Audits erkennen, was interne Tools übersehen
Die große Mehrheit der CMS-Sicherheitstools erfordert Admin-Zugang oder die Installation eines Monitoring-Plugins. Dieser Ansatz hat einen grundlegenden blinden Fleck: Er setzt voraus, dass der Angreifer nicht sehen kann, was das Tool nicht betrachtet.
Ein externes Audit testet, was ein Angreifer von außen sieht. Keine Installation, kein Zugang, keine Abhängigkeiten. Der Server antwortet oder nicht — und diese Antwort enthüllt alles.
Dieselben HTTP-Anfragen wie ein offensiver Sicherheitsscanner: CHANGELOG.txt suchen, /administrator/ testen, /app/etc/env.php anfordern. Wenn ein Angreifer es tun kann, muss das Tool es tun.
Die CMS-Version ist oft in Meta-Tags, HTTP-Headern, README-Dateien oder versionierten Assets exponiert. Die Version ohne Admin-Zugang zu kennen ist der erste Schritt jedes gezielten Angriffs.
Externes Auditing ersetzt keinen gründlichen Pentest — aber es erkennt die niedrig hängenden Früchte, nach denen Angreifer zuerst suchen. In 80 % der realen Einbrüche war der Einstiegspunkt öffentlich zugängliche Information, an die niemand gedacht hatte zu prüfen.
Oriyts Multi-CMS-Sicherheits-Roadmap
Orilyt auditiert heute hauptsächlich WordPress-Websites. Der nächste Schritt — bereits in Entwicklung — ist es, diese Fähigkeiten auf die meistgenutzten CMS im Web auszuweiten. Der Ansatz bleibt derselbe: alles extern, alles automatisch, alles umsetzbar.
Joomla (configuration.php.bak, ungeschütztes /administrator/, Meta-Generator-Version), Magento (/downloader/, /setup/, /app/etc/local.xml), PrestaShop (/admin-dev/, parameters.php). Diese Tests prüfen die Exposition der gefährlichsten Dateien und Endpoints.
Drupal (CHANGELOG.txt, update.php, Versionserkennung), OpenCart (exponiertes config.php, /admin/ ohne zusätzlichen Schutz), Ghost (Version in Assets, exponierte API-Endpoints). Tests, die CMS-Erkennung + Prüfung sensibler Dateien + Header-Analyse kombinieren.
Alle diese Tests werden im selben Orilyt-Bericht verfügbar sein, den Sie bereits kennen — mit FIA-Empfehlungen (Fakt, Auswirkung, Aktion), die zur Präsentation bei Kunden bereit sind. Keine zusätzliche Konfiguration, kein Zugang erforderlich.
Der blinde Fleck, den Sie heute schließen können
Die Sicherheit von Nicht-WordPress-CMS ist ein massiver blinder Fleck in der Web-Industrie. Besitzer von Joomla-, Magento- oder Drupal-Websites haben oft ein falsches Sicherheitsgefühl, weil ihr CMS "weniger angegriffen" wird als WordPress. Das ist gefährliches Denken: Angreifer passen sich dem Ziel an, nicht umgekehrt.
Für Freelancer und Agenturen ist dieser blinde Fleck eine Chance. Einem Magento-Kunden ein Sicherheitsaudit anzubieten, der nie überprüft hat, ob /app/etc/env.php zugänglich ist — das bedeutet sofortigen, nachweisbaren, greifbaren Mehrwert zu liefern. Es bedeutet auch, ihm potenziell eine Katastrophe zu ersparen.
Orilyt wird diese Prüfungen automatisieren. Während auf Batch 1 und 2 gewartet wird, decken die vorhandenen WordPress-Tests bereits Muster ab, die allen CMS gemeinsam sind: Sicherheits-Header, SSL, Weiterleitungen, IP-Reputation. Ein vollständiges Audit bleibt ein ausgezeichneter Ausgangspunkt.