nnz-intern: Path-Traversal-Attacken ohne regionalen Bezug

Es ist wahrscheinlich nie vorbei!

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) 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 Log

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