nnz-intern: Path-Traversal-Attacken ohne regionalen Bezug
Es ist wahrscheinlich nie vorbei!
Montag, 23. März 2026, 13:57 Uhr
Nach dem Server-Ausfall am 16. März sind wir etwas Aufmerksamer geworden, was unsere Error-Logs angeht. Hierbei haben wir neuen "Spaß" entdeckt...
0100011001010 0100011001010 (Foto: vgf)
Über 400 Path-Traversal-Attacken und hunderttausende Loginversuche aus vermeintlich chinesischen Netzen halten uns aktuell auf Trab. In den Tagen nach dem 16. März 2026 verzeichneten wir die Fortsetzung von Angriffen auf unsere Serverinfrastruktur — diesmal mit geänderten Methoden.
Während am 16. März noch massenhaft SQL-Injection-Versuche (Datenbankeinschleusungsangriffe) mit dem Werkzeug „uwInjector" sowie eine Überlastung durch Bot-Anfragen registriert wurden, haben wir es nun mit sogenannten Path-Traversal-Angriffen (Verzeichnis-Überquerungsangriffe) zu tun.
Bei einer solchen Attacke versuchen Angreifer, durch geschickt manipulierte Webadressen aus dem eigentlich erlaubten Bereich einer Website auszubrechen. Konkret wird dabei die Zeichenfolge /../ in die URL eingeschleust — das ist der normale Computerbefehl, um im Dateisystem eine Ebene nach oben zu wechseln.
Ein Angreifer könnte also statt einer harmlosen Adresse wie www.nnz-online.de/news/artikel.php etwas wie www.nnz-online.de/news/../../../geheim/passwort.php anfragen und hofft so, an Dateien oder Skripte zu gelangen, die nie für die Öffentlichkeit gedacht waren — etwa Konfigurationsdateien, Anmeldeseiten oder interne Verwaltungsskripte. Insgesamt wurden bis heute über 400 solcher Versuche registriert, die allesamt vom Webserver automatisch blockiert wurden.
Gleichzeitig wurden erneut Hunderttausende Zugriffsversuche auf die Anmeldeseite aus chinesischen Cloud-Netzen — vor allem aus der Bytedance- und Tencent-Infrastruktur — abgefangen. Die serverseitige IP-Sperre griff dabei zuverlässig und verhinderte, dass diese Anfragen überhaupt die Anwendung erreichten.
Positiv zu vermerken: Das Datenbanküberlastungsproblem vom 16. März ist behoben. Weitere SQL-Injection-Versuche wurden nicht registriert bzw. konnten zurück gewiesen werden.
Volker Georg Franke
technischer Support
Autor: vgf
0100011001010 0100011001010 (Foto: vgf)
Über 400 Path-Traversal-Attacken und hunderttausende Loginversuche aus vermeintlich chinesischen Netzen halten uns aktuell auf Trab. In den Tagen nach dem 16. März 2026 verzeichneten wir die Fortsetzung von Angriffen auf unsere Serverinfrastruktur — diesmal mit geänderten Methoden.
Während am 16. März noch massenhaft SQL-Injection-Versuche (Datenbankeinschleusungsangriffe) mit dem Werkzeug „uwInjector" sowie eine Überlastung durch Bot-Anfragen registriert wurden, haben wir es nun mit sogenannten Path-Traversal-Angriffen (Verzeichnis-Überquerungsangriffe) zu tun.
Bei einer solchen Attacke versuchen Angreifer, durch geschickt manipulierte Webadressen aus dem eigentlich erlaubten Bereich einer Website auszubrechen. Konkret wird dabei die Zeichenfolge /../ in die URL eingeschleust — das ist der normale Computerbefehl, um im Dateisystem eine Ebene nach oben zu wechseln.
Ein Angreifer könnte also statt einer harmlosen Adresse wie www.nnz-online.de/news/artikel.php etwas wie www.nnz-online.de/news/../../../geheim/passwort.php anfragen und hofft so, an Dateien oder Skripte zu gelangen, die nie für die Öffentlichkeit gedacht waren — etwa Konfigurationsdateien, Anmeldeseiten oder interne Verwaltungsskripte. Insgesamt wurden bis heute über 400 solcher Versuche registriert, die allesamt vom Webserver automatisch blockiert wurden.
[Tue Mar 17 01:11:40.572380 2026] [core:error] [pid 968345:tid 968370]
[client 5.231.x.x:37899] AH10244: invalid URI path (/../jobs/jobs_kurz.php)
Beispiel-Auszug aus dem LogGleichzeitig wurden erneut Hunderttausende Zugriffsversuche auf die Anmeldeseite aus chinesischen Cloud-Netzen — vor allem aus der Bytedance- und Tencent-Infrastruktur — abgefangen. Die serverseitige IP-Sperre griff dabei zuverlässig und verhinderte, dass diese Anfragen überhaupt die Anwendung erreichten.
Positiv zu vermerken: Das Datenbanküberlastungsproblem vom 16. März ist behoben. Weitere SQL-Injection-Versuche wurden nicht registriert bzw. konnten zurück gewiesen werden.
Volker Georg Franke
technischer Support