Seitentest von sb-innovation

[Cerberus]

Ja, es wurde ein Test durchgeführt. Ich selbst war ob der Unverhofftheit sehr überrascht.
Test-Link: Safe eXtreme Hot



Was mich aber im Nachgang doch sehr verwundert hat, ist die Resitenz, mit welcher jegliche Informationen zurückgehalten werden.
Da ich auch beruflich mit derlei Tests uns Szenarien regelmäßig zu tun habe, weiß ich das ohne Szenario der Test nicht bewertbar ist.


Ein Szenario umfasst immer 3 Punkte:
1.) Test-Kriterium (was wird genau überprüft)
2.) erwartes Ergebniss (wass soll passieren, wenn alles richtig ist)
3.) tatsächliches Ergebnis (was ist wirklich passiert)
Dabei ist anzumerken, das gerade Punkt 3 nur Bewertbar ist, wenn entsprechende Screenshots vorligen.


Mit diesem Thread möchte ich den Test bewertbar machen. Die Analyse erfolgt vollständig ohne (eigendlich gewünschte) Mittwirkung des Testers.
Ich habe mir (um einige Szenarien korrekt bewerten zu können) Unterstützung von professionellen Intruder- und Penntestern geholt.

Sehen wir uns nun als erstes an, was direkt in der Seite aufgelafen ist. Ein Filter auf das IDS-System fördert entsprechende Einträge zutage.

Der Screenshot ist im Anhang zu finden.


Was wurde getestet:
Als erstes wurde versucht, ob das Login-System (login.php) den angehägten Parameter verarbeitet. Es wurde versucht, die Passwortdatei eines Linux-Systems herunter zuladen.
Damit sollte die Konfiguration des Apachen überprüft werden. Alle halbwegs aktuellen Installationen haben ein HomeDir, in welchem der Apache lesen darf. Er kann dieses Verzeichnis
(per Default) nicht verlassen. Diese Art des Aufrufes muss daher zwangsweise fehlschlagen. Und selbst wenn dies nicht der Fall sein sollte und der Apache zu dieser Datei vordringen darf,
so sollte doch jedem klar sein, das der Kernel selbst den Zugriff darauf unterbindet. Diese Datei gehört dem "root" und funktioniert nur dann korrekt, wenn Sie 600 besitzt.
Der Zugriff auf diese Datei wurde mit unzähligen Pfaden getestet. Es wurden hierbei auch komplett unmögliche Aktionen getestet. Selbst der Aufruf ?email=file:/// wurde versucht.
Dieser wird in der Form aber vom Handler schon seit vielen Jahren nicht mehr unterstützt.


Danach wurde sich dem Bann-System (banned.php) zugewendet. Dort wurde als eMail ebenfalls versucht, die Passwort-Datei herunterzuladen. Der Versuch eine Datei namens passwd%00.jpg
herunter zuladen konnte ich nicht nachvollziehen.


Danach wurde das Login-System erneut untersucht (login.php). Diesmal wurde ein JS-Aufruf eingesetzt, um Hijagging zu untersuchen. Einige Versuche später, welche erneut mit der
Passwort-Datei durchgeführt wurden, wurde ein neues Ziel ausgewählt.


Da wir zu Minimierung von Header-Aufrufen ein Style-System (addstyle.php) nutzen, wurde dies ausgewählt. Als erstes erfolgte auch hier der Versuch mit der Passwort-Datei.
Auch hier wurde das gleiche Muster verwendet. Danach wurde im System versucht, eine externe Datei einzubinden. Es sollte hierbei aber erwähnt werden, das dies so nicht funktionieren kann.
Damit eine externe Datei vom PHP-Interpreter überhaupt berücksichtigt wird, muss dies im Code hinterlegt sein. Andernfalls scheitert dies dann an der internen Pfad-Auflösung.
Nach weiteren unzähligen (fast identischen) Versuchen mit der Passwort-Datei wurden eigene Actions getestet. Das diese vom Script aber verworfen werden sollte jedem Code-Entwickler
mit Grundwissen klar sein. Der Versuch die Actions durch Script-Einbettungen zu verwirren wurde ebenfalls versucht. Das Ergebnis sollte mit der vorigen Vemerkung identisch sein.
Es ist dabei davon auszugehen, das die Verarbeitung von Parametern hier überprüft werden sollte. Es wurde hier versucht, auf Dateien zuzugreifen, welche ich sebst erst mal bei Gogole suchen musste:
(WEB-INF/web.xml) Diese gehört zu Java-Web-Projekten. Warum diese auf PHP-Systemen vorhandens ein sollte konnte ich mir bisher nicht erklären. Das Style-System sollte dann ebenfalls JS-Code verarbeiten.
Danach folgte der Versuch, eine SQL-Abfrage abzusenden. Was die Funktion genau bezwecken sollte, kann nur vermutet werden. Unser IDS-Tester konnte sich keinen eindeutigen Reim darauf machen.
Danach hat man sich erneut auf die Passwort-Datei gestürzt.


Zum Schluss wurde noch einmal das Login-System (login.php) geprüft. Dort wurde versucht, ein JavaScript in den Parameter einzuschleusen.


Dies waren die vom IDS direkt erkannten Aktionen.


Als nächstes schauen wir einmal in die PHP-Error-LOG. Darin werden alle Fehler abgefangen, welche der Interpreter sonst in die Seite "spucken" würde.
Dort fanden sich unzählige Aufrufe nach den folgenden Mustern:

[13-Mar-2019 20:47:40 Europe/Berlin] PHP Warning:  session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /***/***/***/***/***/***/config.php on line 23
[13-Mar-2019 20:47:40 Europe/Berlin] PHP Warning:  Unknown: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0
[13-Mar-2019 20:47:40 Europe/Berlin] PHP Warning:  Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0
...
[13-Mar-2019 20:47:40 Europe/Berlin] PHP Notice:  Array to String  conversion in /***/***/***/***/***/***/config.php on line 23

Diese Versuche haben alle samt in leeren und/oder kaputten Seiten geendet. Die Session wird (in diesem Fall) ausschließlich vom System verwaltet und ist nicht veränderbar. Dies muss im Code direkt erfolgen.


Sehen wir uns nun die Error-LOG einmal genauer an. Diese genau zu verstehen war doch recht komplexer als Ursprünglich angenommen. Wir haben uns dann auf den Tenor geeinigt, das unterschiedliche
Aufrufe auf ihre Existenz getestet wurde. Dies ist in der Error-LOG zu erkennen. Hier stellen sich aber leider ein "handwerkliches" Problem heraus. Das Stichwort hier lautet URL-Encoding. Auch die Random-Name-Scripts
konnten wir nicht korrekt zuordnen. Was diesen Teil angeht, bin ich offen für zusätzliche Informationen. Was mich hier aber doch sehr verwirrt:
Der Tester weiß, das es sich um ein Linux-System handelt. Warum versucht dieser Test dann (auch fast 30 Jahre alte) Windows-Dateien zu bekommen?

Invalid URI in request GET /skin//./../../../../../../../.windows/win.ini HTTP/1.1
Invalid URI in request GET /skin//../../../../../../../../boot.ini HTTP/1.1

Die Art der Aufrufe konnte nicht eindeutig geklärt werden. Interessant waren aber die Versuche, direkt auf das www-Verzeichnis. Dort wurde einige Versuche von Datei-Aufrufen unternommen.
Ein blanker Aufruf einer externen URL konnte dabei ebenfalls nicht erklärt werden. Einge Versuche wurden duch den HTACCESS unterbunden. Sonst gibt es hier keine weiteren Aktionen.


Die Server-Autentification war ebenfalls mit Informationen gespickt. Es wurde ein LOGIN mit dem Account "sa" versucht.

Mar 13 20:49:40 localhost sshd[20464]: input_userauth_request: invalid user sa [preauth]
Mar 13 20:49:40 localhost sshd[20464]: Connection closed by xxx.xxx.xxx.xxx [preauth]
Mar 13 20:49:41 localhost sshd[20466]: Address xxx.xxx.xxx.xxx maps to xxx.xxx.xxx.xxx.static.xxxxxxxxxxxxx.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

Das Resultat war in allen Fällen das gleiche.


Weitere Informationen waren in der SYSLOG und der Mail-LOG zu finden. Es wurde der Versuch unternommen, sich auf dem Mail-Server einzuloggen. Auch das Einrichten eines Mail-Relay wurde versucht, aber
vom Server unterbunden. Der Mail-Sever ist so eingerichtet, das er ausschließlich senden kann und das auch nur an einen einzigen Server.

Mar 13 20:49:37 localhost postfix/smtpd[20433]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 454 4.7.1 <testrelay2@acunetix.com>: Relay access denied; from=<testrelay1@acunetix.com> to=<testrelay2@acunetix.com> proto=SMTP helo=<acunetix.com>

Mehr gibt es dann im Grunde nicht mehr zu erkennen.


Ich werde hier keine Subjektive Meinung abgeben. Dies ist eine Analyse ohne Support der Tester, welche alle verwertbaren Informationen zusammenträgt. Diese Aufstellung soll eine Bewertung der Test überhaupt erst ermöglichen.


Einige Fragen stellen sich hier aber dennoch:
1.) Wenn ein Linux-System vorhanden ist, warum sucht der Test dann nach (auch längt veralteten) Windows-Dateien?
2.) Warum wird nicht konstruktiv und strukturiert vorgegangen, sondern eher nach dem Zufallsprinzip?
3.) Warum werden offensichtliche Fehler (URLs) nicht korrigiert?
All dies könnten nur die Tester beantworten. Dies wird aber verweigert.


Der allgemein gültige Codex der IT besagt:
Wenn ein Test durchgeführt wird, wird dem getesteten das Ergebnis zugestellt. Wenn Bugs und Fehler gefunden wurden, hat dieser 90 Tage Zeit diese zu beheben. Danach erfolgt die Veröffentlichung.
All dies wird von den Testern nicht eingehalten. In wie fern dieser Test Relevanz und Aussagekraft hat, soll jeder für sich selbst ermitteln. Daher gibt es diese Analyse.


In unserem Fall gab es nur 2 Dinge:
1.) Apache (aktuell kann ich keine höhere Version installieren, was sich aber ändern wird)
2.) ein horchender SMTP, der aber alles ablehnt (ja -- Asche auf mein Haupt)


Weitere "Mängel" wie die Standard-Ports sind hierbei nicht von Relevanz. Wenn ein System gescannt wird, läuft der Portscann von 1-65535. Ob ein Dienst dort auf Default (22, 80, 443) oder auf einem anderen Port läuft hier dabei ohne Bedeutung.
Unser Tester meinte, das eine veränderte Port-Nummer ihn nur wenige Sekunden der Anpassung abringt. Dies ist kein BUG oder Problem, sondern einzig ein "Nice-To-Have".


Dies sollte es zum Test-Szenario an dieser Stelle gewesen sein.


Nun noch eine Bemerkung in eigener Sache (dies gehört NICHT zur Analyse!):

Als zusätzlicher Schutz wird CTracker benutzt. Dies scheint zu funktionieren. Wir konnten zwar potentielle Sicherheitslücken finden, diese jedoch aufgrund der zusätzlichen Überprüfungen nicht ausnutzen. Also Glück im Unglück für den Trackerbetreiber kann man sagen.

Server und Source überzeugen beide nicht besonders, da wir aber nicht einbrechen konnten, müssen wir mit einem Zähneknirschen ein Safe vergeben.

Zum einen ist der erste Satz einfach nur falsch (IDS ist nicht CTracker) zum anderen suggestiert er, das das Gesamt-Konstrukt ist misserabel ist das Bugs und Fehler enthalten sein müssen. Leider müssen sie ihre Niederlage nichts erreicht zu haben aber eingestehen.

Wir empfehlen den Betreibern trotzdem den Server in Ordnung zu bringen und die Source auf mögliche Lücken zu untersuchen. Sobald CTracker nicht mehr läuft, kann man den Tracker höchstwahrscheinlich ohne größere Anstrengungen hacken.

Dies ist eine Vermutung. Aktuell betreiben wir ein 4-Stufiges Sicherungs-System. Der Test ist bereits an der 1. Schicht "zerbrochen". Um eine solche Einschätzung vertreten und publizieren zu können, sollten definitif sehr viel Mehr Informationen vorliegen. Im Grunde wurde rein garnichts wirklich gefunden. Trotzdem wird klargestellt, das wir (ich) sehr sehr schlechte Arbeit leisten.


Einen Hinweis in eigener Sache:
Wer (Pen)-Tests machen will, kann sich gern bei mir melden. Ich stelle einen entsprechenden Account gern bereit. Ich erwarte im Gegenzug nur, was der IT-Codex vorsieht. Nicht mehr - aber auch nicht weniger.
Für einen Streß-Test stelle ich gern das Entwicklungs-System bereit. Dies will ich nicht im Life-System haben. Wobei mir Pen-Tests im Life-System auch nicht wirklich recht sind. Dort sollte schon eine entsprechende Qualifikation nachgewiesen werden.


In diesem Sinne -- euer Cerbi