www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/6dc9b386-d4fe-4da4-a376-039cab7b3d2a/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-1; waitfor delay '0:0:15' -- -01-01) at position 6 (;): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers¶

1. Ursache identifizieren¶

Der Fehler DateMalformedStringException betrifft den String:

2026-01; waitfor delay '0:0:15' -- -01-01

Dies ist ein SQL-Injection-Angriffsversuch (Timing-Based Blind SQL Injection gegen SQL Server).

Der Angreifer hat den erwarteten Datums-String 2026-01-01 manipulierst, indem er ; waitfor delay '0:0:15' -- injiziert hat. Dies verursacht:

• 2026-01 — der geplante Start des Datums
• ; waitfor delay '0:0:15' — SQL Server WAITFOR-Befehl (15-Sekunden-Verzögerung zur Erkennung einer SQL-Injection-Lücke)
• -- -01-01 — SQL-Kommentar, der den restlichen String außer Kraft setzt

Die Wurzelursache: Irgendwo im TYPO3-Code (vermutlich in /public/index.php Zeile 17–21, einem benutzerdefinierten Closure) wird ein Benutzer-/HTTP-Input (wahrscheinlich der Host-Header oder ein GET/POST-Parameter) unzureichend bereinigt in eine DateTime-Funktion eingespeist. Der Host-Header wird vom Middleware-Stack (VerifyHostHeader → NormalizedParamsAttribute) verarbeitet und enthält die injizierte Zeichenkette.

2. Fix (konkret)¶

Schritt 1 – Sofortige Bereinigung:

• Alle Einstellungen in typo3conf/LocalConfiguration.php und typo3conf/AdditionalConfiguration.php prüfen — der Host-Header könnte dort gespeichert worden sein.
• Datenbank-Tabellen auf manipulierte Einträge prüfen (besonders pages, sys_template, cache).

Schritt 2 – Code-Fix in /public/index.php:

// Vor dem DateTime-Parsing:
$input = filter_var($input, FILTER_SANITIZE_FULL_SPECIAL_CHARS);
$dateTime = DateTime::createFromFormat('Y-m-d', $input);

// Oder besser: strikte Validierung VOR dem Parsing
if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $input)) {
    throw new \InvalidArgumentException('Invalid date format');
}

Schritt 3 – Alle Datei-Punkte prüfen:

• /vendor/typo3/cms-core/Classes/Http/AbstractApplication.php — wo der Request initial verarbeitet wird
• Prüfen, ob benutzerdefinierte Hooks/Eigener Code Einträge in config.php oder AdditionalConfiguration.php manipuliert haben

Schritt 4 – Sicherheitsmaßnahmen:

• Alle SQL-Abfragen auf Prepared Statements prüfen
• verify_host_header-Middleware-Konfiguration überprüfen
• Web Application Firewall (WAF) Regeln für waitfor delay-Patterns hinzufügen
• Alle Caches leeren (typo3temp/var/cache/)

3. Betroffene TYPO3 Extension¶

TYPO3 Core (cms-core) — /vendor/typo3/cms-core/
Spezifisch betroffene Klassen:

• TYPO3\CMS\Core\Http\AbstractApplication
• TYPO3\CMS\Core\Http\Application
• TYPO3\CMS\Core\Middleware\VerifyHostHeader
• TYPO3\CMS\Core\Middleware\NormalizedParamsAttribute

Die Verwundbarkeit liegt in benutzerdefiniertem Code (Closure in index.php:17), der TYPO3-Core-Klassen mit unsauber bereinigtem Input füttert. Es könnte auch eine benutzerdefinierte Extension betroffen sein, die eigene Request-Parameter direkt in Date-Parser übergibt.

4. Confidence¶

85%

Begründung:

• ✅ Der String enthält eindeutige SQL-Injection-Syntax (waitfor delay '0:0:15' ist SQL Server-spezifisch)
• ✅ Die Struktur 2026-01[...injektion...]01-01 zeigt klar, dass ein Datum manipuliert wurde
• ✅ Der Middleware-Stack bestätigt, dass der HTTP-Request-Header verarbeitet wird
• ⚠️ Ohne Zugriff auf /public/index.php Zeile 17–21 kann der exakte Code-Pfad nicht 100% bestätigt werden
• ⚠️ Es könnte auch ein bereits kompromittierter Datenbank-Eintrag oder Cache-Eintrag die Quelle sein

Zusammenfassung: Dies ist ein aktiver SQL-Injection-Angriffsversuch, bei dem ein manipulierter Datum-String über den HTTP-Request-Header (wahrscheinlich Host-Header) in TYPO3s PHP-Date-Parser eingespeist wird. Sofortige Eingabevalidierung, Bereinigung aller Konfigurationsdateien und Prüfung der Datenbank sind erforderlich.