www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/7d6b8838-81e6-40ab-96a8-1290323dced6/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string ((select DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)CHR(98)CHR(98),15) from dual)-01-01) at position …

Automatisch erstellt durch n8n

KI-Analyse:

Analyse¶

1. Ursache¶

Es handelt sich um einen SQL-Injection-Angriffsversuch über einen unsanitisierten Parameter, der in ein Date-Parsing-Gerät gerät:

• Ein Angreifer sendet einen manipulierten Request, dessen Parameterwert den Oracle-DB-Injection-Payload enthält: (select DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15) from dual)-01-01
• Dieser Wert landet in einem Date-Kontext (z. B. ein EXT:formular-, News- oder Routing-Parameter, der als Datum erwartet wird)
• PHPs DateTime versucht den String zu parsen → DateMalformedStringException
• Die eigentliche Schwachstelle ist jedoch nicht der Date-Parser, sondern die Stelle, an der Benutzerinput unvalidiert in eine SQL-Abfrage gelangt (fehlende Prepared Statements / Parameter Binding)

2. Fix (konkret)¶

1. Identifiziere den Parameter: Logge $_GET/$_POST/_POST oder nutze GeneralUtility::_GET() um den angriffsverseuchten Request-Parameter zu identifizieren.
2. Input Validation: Alle Parameter, die als Datum erwartet werden, müssen mit DateTime::createFromFormat() oder GeneralUtility::validateDate() streng validiert werden, bevor sie weiterverarbeitet werden.
3. SQL Injection beheben: Jede DB-Abfrage muss mit QueryBuilder / Prepared Statements arbeiten — niemals String-Concatenation mit User Input:

   // FALSCH
   $row = $GLOBALS['TYPO3_DB']->sql_query("SELECT * FROM tx_ext_table WHERE datum = '" . $_GET['datum'] . "'");
   
   // RICHTIG
   $queryBuilder->select('*')->from('tx_ext_table')->where(
       $queryBuilder->expr()->eq('datum', $queryBuilder->createNamedParameter($validatedDate))
   );
   

4. Extension updaten: Installierte Version der betroffenen Extension auf den neuesten Stand bringen.
5. WAF / Rate-Limiting: als临时 Massnahme SQLi-Patterns blockieren.

3. Betroffene TYPO3 Extension¶

Ohne die vollständige Extension-Liste nicht 100%ig benennbar. Typische Kandidaten für solche Schwachstellen:

• FORM-basierte Extensions (z. B. form, sr_feuser_register, fpf_form)
• News/Listing-Extensions mit Filterparametern (z. B. news, tx_news)
• Custom Extensions mit eigenem SQL-Code
• Extensions mit bekannten SQLi-Lücken wie ältere Versionen von rsaauth, realurl, bootstrap_package

Triage: Prüfe typo3conf/ext/ auf Custom-Extensions und die ext_emconf.php-Versionen aller Extensions gegen bekannte CVEs.

4. Confidence¶

SQLi-Angriff: 95% | Genau betroffene Extension: 40% (braucht Kontext: installed extensions, Request-Log)

Empfehlung: Unbedingt den gesamten Request (Headers, GET/POST, Body) in den Webserver-Logs / TYPO3-Systemlog prüfen, um den exakten Einfallspfad zu identifizieren. Bei Verdacht auf erfolgreichen Inject: sofort Passwörter/RSA-Keys rotieren und DB auf verdächtige Einträge prüfen.