Anmerkung techn. Support
0x01 - Session-Verwaltung, SQL-Injektion und anderer Spaß
Im großen weiten Datenmeer des Internets ist die kleine nnz kaum mehr als ein Tropfen. Für unsere Daten scheint man sich weit abseits heimischer Gefilde aber trotzdem zu interessieren. Der Herr über unsere Codezeilen berichtet heute einmal vom alltäglichen Kampf des technischen Supports gegen die „bösen Jungs“…
Code (Foto: vgf)
Wann immer eine Website aufgerufen wird, liefert irgendwo auf der Welt ein „WebServer“ die nötigen Daten aus, so funktioniert, in aller Einfachheit, das Internet. Kommt es bei der Auslieferung zu Fehlern, werden diese protokolliert, da macht auch die nnz keine Ausnahme. Immer wenn sich beim „zusammenbauen“ unserer Seiten ein Fehler einschleicht, gibt es einen Eintrag.
In der Regel sind diese Protokolle recht unspektakulär. Wenn aber innerhalb von 24 Stunden 503.874 Einträge (in Worten Fünfhundertdreitausendachthundertvierundsiebzig), von nur einem einzigen „Absender“ generiert werden, ist das schon mal einen genaueren Blick Wert.
Wohlgemerkt, aufgelistet werden allein die registrierten Fehler, normal generierte Seitenaufrufe finden keinen Eingang in das Protokoll. Für die technisch versierte Leserschaft, so* sieht das dann aus:
*Ich habe ein paar „x“ und „…" eingebaut um keine Rückschlüsse auf unsere Systemarchitektur zu erlauben.
Nun werden diese Zeilen nicht jedem etwas sagen, aus Sicht eines Programmierers nur so viel: hier hat jemand massiv versucht, grundlegende Systeme der nnz auszuhebeln und dabei jede Menge Fehler verursacht. Betroffen ist in diesem Fall die „Session-Verwaltung“, die dazu dient, Nutzer nach dem Login über mehrere Seiten sicher zu identifizieren um etwa Kleinanzeigen und Kommentare aufzugeben.
Eggerhard, die Russ’n sin da!
In letzter Zeit haben sich solche Angriffe stark gehäuft. Die IP-Adressen kommen meist aus Russland, China oder Singapur. Haben es also chinesische Hackerbanden oder „Putins Bären“ auf die kleine nnz abgesehen? Eher nicht. Die tagtäglichen Angriffe auf Server im Netz erfolgen heutzutage eher mit der Methode Schrotflinte und da bekommen auch wir unweigerlich ein paar Körner ab. Die „Attribuierung“ der Angriffe, also die Identifikation der „bösen Jungs“ (oder Mädchen), ist bestenfalls wacklig und kaum mehr als ein Indiz. Wer über das nötige Wissen und die passende Technik verfügt, kann seine geographische Herkunft ohne weiteres verschleiern. Die Angreifer können in Moskau oder an einem Rechner drei Häuser weiter sitzen, da theoretisch jeder ans weltweite Netz angeschlossene Rechner ferngesteuert werden kann, ist die genaue Quelle kaum auszumachen, schon gar nicht für eine regionale Online-Zeitung am Rande des Südharzes.
In Summe sind derlei Attacken mehr als ärgerlich und verursachen, neben hoher Serverlast und einer langsameren Ausgabe der Seiten, auch viel Arbeit bei uns. Neben dem Session-Problem gab es in den letzten vier Wochen aber auch noch weitere Versuche uns „auszuheben“.
Login - immer einen Angriff Wert.
Wenn uns also nicht die Russen auf den Leib rücken, was wollen die Angreifer dann von der nnz? Die kurze Antwort: Daten. 261.764 Aufrufe des Login-Formulars registrierten wir vor kurzem innerhalb von nur vier Stunden, wohl mit dem Ziel Benutzername und Passwort-Kombinationen zu erraten und so an Benutzerkonten heran zu kommen. „Brute force“ -„rohe Gewalt“ nennt man diese „Mit-dem-Kopf-durch-die-Wand“ Methode. Die Seite wird so lange mit unterschiedlichen Kombinationen bombardiert, bis eine dabei ist, die passt. Auch das ist nicht allein ein nnz-Problem, die IT-Administratoren in ihrer Mitte haben gute Gründe, wenn sie darum bitten, dass Passwörter alle paar Wochen abgeändert werden sollten und regelmäßige Updates durchzuführen sind. Für unser spezielles Problem haben wir inzwischen eine einfache Lösung gefunden: man kann sich seit gestern nur noch 20 mal erfolglos anmelden, dann wird man für eine gewisse Zeit gesperrt. Hätten wir schon viel früher implementieren müssen.
Suchen will gehackt sein...
Doch damit nicht genug, auch über das Suchformular sollten Datenbankabfragen eingeschleust werden, um so Code ausführen zu können. Noch einmal für die technisch affinen Leser: hier werden SQL-Abfragen in den Suchstring eingegeben um diese in die Abfrage hinein zu „schmuggeln“. Bei älteren Systemen hat das gut geklappt und der Code wurde an die Datenbank gesendet. Mit »Prepared Statements« und anderen Methoden kann man das inzwischen gut verhindern.
Unsere aktuelle Gegenmaßnahme: Die Länge der Suchparameter wurde begrenzt und bestimmte Inhalte werden schon seit einiger Zeit heraus gefiltert. Interessant hierbei, dass es nicht reicht nach Wörtern wie »SELECT« zu filtern, man muss alternative Schreibweisen, mit z.B. UniCode-Zeichen oder chr()-Befehlen berücksichtigen.
Cross Site Scripting – wenn etwas von der Seite kommt
Angriffsvektoren gibt es viele, zum Beispiel auch „Cross Site Scripting“. Hier wird, vereinfacht ausgedrückt, versucht über die Web-Adresse schädlichen Java-Script-Code in die Seite einzuschleusen und auszuführen. Über diesen Weg gab es in den letzten Wochen über eine Million Versuche, an das Allerheiligste heranzukommen – den User.
Die liebe KI...
All das belastet die Serverarchitektur, die Rechner müssen kräftig rödeln, um die vielen Seitenanfragen abzuwickeln. Die müssen nicht zwingend bösartigen Hintergrund haben, oft genug sind es die alltäglichen Dienste, die im Hintergrund das Netz bestimmen. Dazu gehören zum Beispiel „Spider“ und „Bots“, also Programme, die automatisch Seiten auslesen, um die Daten zu verwenden. Da gibt es „gute“ Bots, etwa von Google oder Bing, welche für das Funktionieren der Suchmaschinen wichtig sind. In letzter Zeit sind aber noch ein paar neue „Player“ hinzugekommen: die „KI-Bots“. Chat GPT und Co. fragen auch unsere Daten ab, um ihre Systeme zu „trainieren“. Deren Abfragen erfolgen oft in sehr kurzen Intervallen und belasten unseren Server sehr. Die fünf übelsten Gesellen werden inzwischen beim Aufruf unserer Seiten abgewiesen und gesperrt, die KI bekommt also nur noch leere Seiten zu sehen. Das minimiert die Serverlast.
Soweit unser kleiner Blick hinter die Kulissen. Aufgeführt wurden hier nur ein paar Beispiele, es gäbe noch viel mehr. Für einen Programmier ist es wunderschön, wenn er ein Problem gefunden, verstanden und eliminiert hat. Anstrengend ist es trotzdem und es tauchen fast täglich Neue auf...
Volker Georg Franke
technischer Support nnz
Angelo Glashagel
Redaktion
Code (Foto: vgf)
Wann immer eine Website aufgerufen wird, liefert irgendwo auf der Welt ein „WebServer“ die nötigen Daten aus, so funktioniert, in aller Einfachheit, das Internet. Kommt es bei der Auslieferung zu Fehlern, werden diese protokolliert, da macht auch die nnz keine Ausnahme. Immer wenn sich beim „zusammenbauen“ unserer Seiten ein Fehler einschleicht, gibt es einen Eintrag.
In der Regel sind diese Protokolle recht unspektakulär. Wenn aber innerhalb von 24 Stunden 503.874 Einträge (in Worten Fünfhundertdreitausendachthundertvierundsiebzig), von nur einem einzigen „Absender“ generiert werden, ist das schon mal einen genaueren Blick Wert.
Wohlgemerkt, aufgelistet werden allein die registrierten Fehler, normal generierte Seitenaufrufe finden keinen Eingang in das Protokoll. Für die technisch versierte Leserschaft, so* sieht das dann aus:
[Thu Feb 29 15:10:31.931030 2024] [fcgid:warn] [pid xxx:tid 1625671] [client 147.45.44.x:57223] mod_fcgid: stderr: PHP Fatal error: Uncaught mysqli_sql_exception: Truncated incorrect DOUBLE value: 'qvkqqT2VuMkxxxxx1eGs4U0JFZzQ2UT0sw9qbqkqx' in /pages/x/x/xxx/home/htdocs/.../xxx:124, referer: https://xxx-online.de/
[Thu Feb 29 15:10:31.931049 2024] [fcgid:warn] [pid xxx:tid 1625671] [client 147.45.44.x:57223] mod_fcgid: stderr: Stack trace:, referer: https://xxx-online.de/
[Thu Feb 29 15:10:31.931057 2024] [fcgid:warn] [pid xxx:tid 1625671] [client 147.45.44.x:57223] mod_fcgid: stderr: #0 /pages/83/6c/d0016761/home/htdocs/.../xxx.php(124): mysqli_query(Object(mysqli), 'UPDATE xxx...'), referer: https://xxx-online.de/
[Thu Feb 29 15:10:31.931064 2024] [fcgid:warn] [pid xxx:tid 1625671] [client 147.45.44.x:57223] mod_fcgid: stderr: #1 [internal function]: ws_xxx::ms_write('cb012ee4416e198...', 'return_path|s:2...'), referer: https://xxx-online.de/
[Thu Feb 29 15:10:31.931071 2024] [fcgid:warn] [pid 1625610:tid 1625671] [client 147.45.44.0:57223] mod_fcgid: stderr: #2 {main}, referer: https://xxx-online.de*Ich habe ein paar „x“ und „…" eingebaut um keine Rückschlüsse auf unsere Systemarchitektur zu erlauben.
Nun werden diese Zeilen nicht jedem etwas sagen, aus Sicht eines Programmierers nur so viel: hier hat jemand massiv versucht, grundlegende Systeme der nnz auszuhebeln und dabei jede Menge Fehler verursacht. Betroffen ist in diesem Fall die „Session-Verwaltung“, die dazu dient, Nutzer nach dem Login über mehrere Seiten sicher zu identifizieren um etwa Kleinanzeigen und Kommentare aufzugeben.
Eggerhard, die Russ’n sin da!
In letzter Zeit haben sich solche Angriffe stark gehäuft. Die IP-Adressen kommen meist aus Russland, China oder Singapur. Haben es also chinesische Hackerbanden oder „Putins Bären“ auf die kleine nnz abgesehen? Eher nicht. Die tagtäglichen Angriffe auf Server im Netz erfolgen heutzutage eher mit der Methode Schrotflinte und da bekommen auch wir unweigerlich ein paar Körner ab. Die „Attribuierung“ der Angriffe, also die Identifikation der „bösen Jungs“ (oder Mädchen), ist bestenfalls wacklig und kaum mehr als ein Indiz. Wer über das nötige Wissen und die passende Technik verfügt, kann seine geographische Herkunft ohne weiteres verschleiern. Die Angreifer können in Moskau oder an einem Rechner drei Häuser weiter sitzen, da theoretisch jeder ans weltweite Netz angeschlossene Rechner ferngesteuert werden kann, ist die genaue Quelle kaum auszumachen, schon gar nicht für eine regionale Online-Zeitung am Rande des Südharzes.
In Summe sind derlei Attacken mehr als ärgerlich und verursachen, neben hoher Serverlast und einer langsameren Ausgabe der Seiten, auch viel Arbeit bei uns. Neben dem Session-Problem gab es in den letzten vier Wochen aber auch noch weitere Versuche uns „auszuheben“.
Login - immer einen Angriff Wert.
Wenn uns also nicht die Russen auf den Leib rücken, was wollen die Angreifer dann von der nnz? Die kurze Antwort: Daten. 261.764 Aufrufe des Login-Formulars registrierten wir vor kurzem innerhalb von nur vier Stunden, wohl mit dem Ziel Benutzername und Passwort-Kombinationen zu erraten und so an Benutzerkonten heran zu kommen. „Brute force“ -„rohe Gewalt“ nennt man diese „Mit-dem-Kopf-durch-die-Wand“ Methode. Die Seite wird so lange mit unterschiedlichen Kombinationen bombardiert, bis eine dabei ist, die passt. Auch das ist nicht allein ein nnz-Problem, die IT-Administratoren in ihrer Mitte haben gute Gründe, wenn sie darum bitten, dass Passwörter alle paar Wochen abgeändert werden sollten und regelmäßige Updates durchzuführen sind. Für unser spezielles Problem haben wir inzwischen eine einfache Lösung gefunden: man kann sich seit gestern nur noch 20 mal erfolglos anmelden, dann wird man für eine gewisse Zeit gesperrt. Hätten wir schon viel früher implementieren müssen.
Suchen will gehackt sein...
Doch damit nicht genug, auch über das Suchformular sollten Datenbankabfragen eingeschleust werden, um so Code ausführen zu können. Noch einmal für die technisch affinen Leser: hier werden SQL-Abfragen in den Suchstring eingegeben um diese in die Abfrage hinein zu „schmuggeln“. Bei älteren Systemen hat das gut geklappt und der Code wurde an die Datenbank gesendet. Mit »Prepared Statements« und anderen Methoden kann man das inzwischen gut verhindern.
Unsere aktuelle Gegenmaßnahme: Die Länge der Suchparameter wurde begrenzt und bestimmte Inhalte werden schon seit einiger Zeit heraus gefiltert. Interessant hierbei, dass es nicht reicht nach Wörtern wie »SELECT« zu filtern, man muss alternative Schreibweisen, mit z.B. UniCode-Zeichen oder chr()-Befehlen berücksichtigen.
Cross Site Scripting – wenn etwas von der Seite kommt
Angriffsvektoren gibt es viele, zum Beispiel auch „Cross Site Scripting“. Hier wird, vereinfacht ausgedrückt, versucht über die Web-Adresse schädlichen Java-Script-Code in die Seite einzuschleusen und auszuführen. Über diesen Weg gab es in den letzten Wochen über eine Million Versuche, an das Allerheiligste heranzukommen – den User.
Die liebe KI...
All das belastet die Serverarchitektur, die Rechner müssen kräftig rödeln, um die vielen Seitenanfragen abzuwickeln. Die müssen nicht zwingend bösartigen Hintergrund haben, oft genug sind es die alltäglichen Dienste, die im Hintergrund das Netz bestimmen. Dazu gehören zum Beispiel „Spider“ und „Bots“, also Programme, die automatisch Seiten auslesen, um die Daten zu verwenden. Da gibt es „gute“ Bots, etwa von Google oder Bing, welche für das Funktionieren der Suchmaschinen wichtig sind. In letzter Zeit sind aber noch ein paar neue „Player“ hinzugekommen: die „KI-Bots“. Chat GPT und Co. fragen auch unsere Daten ab, um ihre Systeme zu „trainieren“. Deren Abfragen erfolgen oft in sehr kurzen Intervallen und belasten unseren Server sehr. Die fünf übelsten Gesellen werden inzwischen beim Aufruf unserer Seiten abgewiesen und gesperrt, die KI bekommt also nur noch leere Seiten zu sehen. Das minimiert die Serverlast.
Soweit unser kleiner Blick hinter die Kulissen. Aufgeführt wurden hier nur ein paar Beispiele, es gäbe noch viel mehr. Für einen Programmier ist es wunderschön, wenn er ein Problem gefunden, verstanden und eliminiert hat. Anstrengend ist es trotzdem und es tauchen fast täglich Neue auf...
Volker Georg Franke
technischer Support nnz
Angelo Glashagel
Redaktion