nicht angemeldet claus ginsel
Rolf B
Der Martin
claus ginsel
Rolf B
Rolf B
claus ginsel
Hallo,
weil die betreffenden Requests mit mir nicht nachvollziehbaren HTTP-Statuscodes beantwortet wurden.
Hier ein 200er:
"HEAD /icons/sphere1.png HTTP/1.1" 200 5008 "
obwohl es diesen Pfad nicht gibt (versteckte Pfade?). dagegen:
"HEAD /icons/.%2e/%2e%2e/apache2/icons/sphere1.png HTTP/1.1" 400 4801 "
Aber mehr noch sorgen mich 302er:
"GET /.well-known/security.txt HTTP/1.1" 302 460 "
da erwarte und bekomme ich 404
"GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 302 557 "
da erwarte und bekomme ich 403
Kann mir das jemand erklären?
Dann gleich noch eine Frage zu dem Ordner cgi-bin. Dieser Ordner wird ja auch gern inspiziert. Ist es sinnvoll, dort Libraries wie phpmailer oder tcpdf reinzulegen?
Gruß Claus
Rolf B
Der Martin
Rolf B
Hallo claus,
Libraries - also Code, der nicht eigenständig läuft, sondern von Dir inkludiert wird, sollte in einem Ordner liegen, der vom Web aus nicht erreichbar ist.
Also optimalerweise außerhalb des document root, oder wenn das nicht geht, in einem Order, der diese .htaccess Datei enthält:
Deny from all
Sagt mir Stackoverflow jedenfalls - ich bin ja bekanntlich kein Apachologe.
Das Gleiche gilt für Konfigurationsdateien. Entweder aus dem document root verbannen, in einen Deny From All Ordner sperren, oder so benennen, dass man sie in der .htaccess gegen Zugriffe aus dem Web sperren kann. Dann können sie nur noch von deinen PHP Scripten gelesen werden.
Die Kopfologie hat mich allerdings leicht in Panik versetzt. Sowas kann gehen?! Gut, dass ich bei IIS bin (der hat andere Macken 😂).
HEAD /icons/sphere1.png HTTP/1.1" 200 5008
HEAD /icons/.%2e/%2e%2e/apache2/icons/sphere1.png HTTP/1.1" 400 4801
sind augenscheinlich verschiedene Pfade. %2e ist der Punkt, d.h. der zweite Head-Request möchte auf /icons/../../apache2/icons/sphere1.php zugreifen. Also: runter den icons-Ordner, von da aus zwei Ordnerstufen rauf und von da aus runter nach apache2 und weiter nach icons/sphere1.png darin gibt.
"Zwei hoch" - kann ja bei /icons gar nicht gehen? Tjaaa - ein Default-Apache aliased Dir in dein Documentroot einen /icons-Ordner hinein, dessen physikalischer Ort im Installationsordner des Apache liegt. Das kannst Du nur in der zentralen Apache Konfiguration abschalten, hab ich gerade gelesen, das kann man in der eigenen .htaccess nicht wegmachen. Das mag falsch oder veraltet sein, das wäre eine Frage an die Indianerhäuptlinge hier.
Wenn es also dumm und fehlerhaft läuft, greifst Du mit /icons/../.. auf das Elternverzeichnis des Icons-Ordners zu, also auf die Apache-Installation, und wenn Du dann mit apache2/icons/sphere1.png Erfolg hast, weißt Du, dass der Indianer ein Loch in der Unterhose hat.
Hätte er das Loch gefunden, hätte er darüber die Apache Konfiguration durchstöbern und ggf. Passworte abgreifen können.
Rolf
Hallo Rolf
danke erstmal.
Der Ordner cgi-bin hat eine htaccess. Aber ich werde das alles woanders hinlegen.
Claus
Hallo Claus,
Hier ein 200er:
"HEAD /icons/sphere1.png HTTP/1.1" 200 5008 "
obwohl es diesen Pfad nicht gibt (versteckte Pfade?).
Die Standardkonfiguration von Apache definiert /icons als ein Alias ins /icons-Verzeichnis der Apache-Istallation.
"HEAD /icons/.%2e/%2e%2e/apache2/icons/sphere1.png HTTP/1.1" 400 4801 "
Vom /icons-Verzeichnis zwei Ebenen nach oben (.%2e ist gleichbedeutend mit ..)?
Das darf nicht gelingen.
"GET /.well-known/security.txt HTTP/1.1" 302 460 "
da erwarte und bekomme ich 404
Das kann ich auch nicht erklären.
"GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 302 557 "
da erwarte und bekomme ich 403
Aber vielleicht erst in der zweiten Runde. Status 302 ist ja ein Redirect auf eine andere Ressource. Kann es sein, dass die dann erst den 403 schmeißt?
Kann mir das jemand erklären?
Teilweise. Das sind typische Versuche, eine Sicherheitslücke des Webservers oder eines CMS zu finden. Bei dir finden sie anscheinend nichts.
Dann gleich noch eine Frage zu dem Ordner cgi-bin. Dieser Ordner wird ja auch gern inspiziert.
Brauchst du den überhaupt? in meinen bisherigen Hosting-Paketen hatte ich nie ein /cgi-bin - jedenfalls nicht in meinem Webspace. Vielleicht auch als Alias, das mag sein. Das war mir dann aber nicht zugänglich.
Einen schönen Tag noch
Martin
Hallo Martin
Vom /icons-Verzeichnis zwei Ebenen nach oben (.%2e ist gleichbedeutend mit ..)? Das darf nicht gelingen.
Weißt Du, wo das verhindert wird?
Aber vielleicht erst in der zweiten Runde. Status 302 ist ja ein Redirect auf eine andere Ressource. Kann es sein, dass die dann erst den 403 schmeißt?
[30/Mar/2022:01:51:46 +0200] "GET /.well-known/security.txt HTTP/1.1" 302 460 "-" "-" [30/Mar/2022:07:15:31 +0200] "GET /.well-known/security.txt HTTP/1.1" 404 5249 "-" "-"
Ist das die 2. Runde? 1 Uhr und dann 7 Uhr? Von mir kam kein Redirect.
Brauchst du den überhaupt? in meinen bisherigen Hosting-Paketen hatte ich nie ein /cgi-bin - jedenfalls nicht in meinem Webspace. Vielleicht auch als Alias, das mag sein. Das war mir dann aber nicht zugänglich.
Also ich brauche cgi-bin nicht wirklich, mein Hoster hat eine Readme.txt reingelegt, da steht drin, ich solle die Programme darein legen. Irgendwie hängt doch dieser Ordner auch mit FastCGI zusammen oder ?
Claus
Hi,
Vom /icons-Verzeichnis zwei Ebenen nach oben (.%2e ist gleichbedeutend mit ..)? Das darf nicht gelingen.
Weißt Du, wo das verhindert wird?
nicht mit Gewissheit. Ich meine, das ist im Apache-Code hartcodiert.
Aber vielleicht erst in der zweiten Runde. Status 302 ist ja ein Redirect auf eine andere Ressource. Kann es sein, dass die dann erst den 403 schmeißt?
[30/Mar/2022:01:51:46 +0200] "GET /.well-known/security.txt HTTP/1.1" 302 460 "-" "-"
[30/Mar/2022:07:15:31 +0200] "GET /.well-known/security.txt HTTP/1.1" 404 5249 "-" "-"Ist das die 2. Runde? 1 Uhr und dann 7 Uhr?
Nein, auf keinen Fall. Die beiden Aufrufe müssten im Abstand von Sekundenbruchteilen kommen.
Von mir kam kein Redirect.
Doch, der 302er um 01:51:46. Wohin der umleitet, erkennt man aus dem Protokolleintrag leider nicht. Aber wenn du den Request mal mit wget stellst, bekommst du es direkt angezeigt.
Einen schönen Tag noch
Martin
Hallo Martin
Doch, der 302er um 01:51:46. Wohin der umleitet, erkennt man aus dem Protokolleintrag leider nicht. Aber wenn du den Request mal mit wget stellst, bekommst du es direkt angezeigt.
Also zumindest hab ich keinen location header gesetzt.
Ich kann jetzt leider wget nicht installieren, habe nur ein eingeschränktes Konto. Muss ich auf übermorgen verschieben.
[30/Mar/2022:01:51:46 +0200] "GET /.well-known/security.txt HTTP/1.1" 302 460 "-" "-"
[30/Mar/2022:07:15:31 +0200] "GET /.well-known/security.txt HTTP/1.1" 404 5249 "-" "-"
Aber ist das logisch, dass der gleiche Request unterschiedlich behandelt wird, einmal 302, dann später 404?
Gruß Claus
Aber ist das logisch, dass der gleiche Request unterschiedlich behandelt wird, einmal 302, dann später 404?
Sicher, dass es wirklich der gleiche Request ist? Denkbar wäre z.B. eine pauschale Weiterleitung von http-Requests nach https. Wobei man dafür besser 301 verwenden sollte.
Aber ist das logisch, dass der gleiche Request unterschiedlich behandelt wird, einmal 302, dann später 404?
Vermutlich war der erste Aufruf mit http://..., bekam die Weiterleitung zum https-Protokoll (302) und nachfolgend wurde es mit https:// versucht und erst jetzt bemühte sich der Indianer darum, überhaupt nach der Datei zu sehen: die gibt es nicht → 404.
Der Zeitunterschied ist dadurch zu erklären, dass das kein normaler UserAgent (Browser) ist, sondern ein Programm, welches abertausende Webseiten „abklopft”. Die mit dem 302er gelieferte neue URL wird da in eine Jobliste eingereiht.
Wenn Du also selbst HTTPS erzwingst, dann ist das ganz normal. Abgesehen davon, dass (wie schon Martin schrieb) jemand nach unsicherem Zeug sucht. Das scheint ein Standard-Penetrationstest zu sein: Bei meinem Server @home wird auf den Versuch des Abrufs von /\.well-known/ (und einer Liste anderer URLs) mit einer 60 Minuten-Sperre in der Firewall reagiert. Das scheint zu reichen.
Bei meinem Server @home wird auf den Versuch des Abrufs von
/\.well-known/(und einer Liste anderer URLs) mit einer 60 Minuten-Sperre in der Firewall reagiert. Das scheint zu reichen.
Toll. Ganz toll!
Moin Raketenwilli
Wenn Du also selbst HTTPS erzwingst, dann ist das ganz normal.
Ja, HSTS ist aktiviert. Besten Dank 👍
Gruß Claus
"GET /.well-known/security.txt HTTP/1.1" 302 460 "
da erwarte und bekomme ich 404Das kann ich auch nicht erklären.
[https://en.wikipedia.org/wiki/Well-known_URI](Well-known URI)
Edit by Rolf B: https://en.wikipedia.org/wiki/Well-known_URI
Hallo Linksetzer,
das ging daneben.
Entweder so: <url>
Oder so: [Linktext](url)
Siehe unten:
Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge
Rolf
Moin
ich hab mal noch eine Frage zu den directory traversal Attacken
Wenn ich über http-Requests zu Systemdateien kommen will, dann muss ich ausgehend vom Domain-Verzeichnis in der Dateistruktur hochklettern mit ../, ist das korrekt?
das hab ich mal probiert und komme zu dem Ergebnis:
https://example.org/../etc/passwd 404, wird zu https://example.org/etc/passwd
https://example.org/../../etc/passwd 404, wird zu https://example.org/etc/passwd
https://example.org/../../../etc/passwd 404, wird zu https://example.org/etc/passwd
Der Hoster teilt mir mit, dass das der Apache standardmäßig so macht, er hätte da nichts speziell konfiguriert. Und auch bei wikipedia wird dieses Beispiel gebracht.
Wenn 90% der Webserver Apache sind, wieso wird dann in diesem Umfang auf diese Attacke gesetzt?
Gruß Claus
Hallo Claus,
ich habe deine Domain ersetzt.
Wenn Du vom Browser aus http://example.org/../foo/bar.dat oder http://example.org/foo/../../etc/hosts abrufst, wird das vom Browser schon normalisiert und kommt gar nicht beim Server an. Auch dann, wenn Du die Punkte als %2E maskierst. Das siehst Du in den Developer-Tools des Browsers.
Du musst das schon unverfälscht mit einem Tool wie wget oder mit einem manuell programmierten HTTP Request zum Server bringen, und da setzt der Exploit an.
Wenn der Server einen solchen Pfad vor Prüfung auf Zulässigkeit nicht normalisiert, und einfach nur das Directory Root mit dem vom Client kommenden Pfad verkoppelt, könnte dort ein Zugriffspfad wie
/usr/web/example.org/icons/foo/../../evil
entstehen. D.h. man läuft aus icons/foo hinaus und ist - vermeintlich - auf der Ebene von /usr/web/example.org. Dies scheint unverdächtig, wenn da nicht der Umstand wäre, dass icons Ordner vom Apache als Alias in jeden Web-Ordner hineingespiegelt wird. Warum?
In der httpd.conf steht:
# Fancy directory listings
Include conf/extra/httpd-autoindex.conf
Und in httpd-autoindex.conf steht
# We include the /icons/ alias for FancyIndexed directory listings. If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "${SRVROOT}/icons/"
Directory Listings verhindert eigentlich jeder, und trotzdem ist dieser Alias für Icons fast überall aktiv.
Also: icons ist ein Ordner der Apache Installation, und ein falsch programmiertes System würde, wenn es erstmal in icons Ordner ist, mit ".." nach ${SRVROOT} kommen - dem Apache Installationsordner. Und wenn dieser Weg offen ist, hat man de facto Leserecht auf den ganzen Server.
Ich nehme an, dass diese Lücke früher mal bestand und aktuelle Indianer Dir eins mit dem Tomahawk geben, wenn Du den Exploit versuchst.
Rolf
In der httpd.conf steht:
# Fancy directory listings Include conf/extra/httpd-autoindex.confUnd in httpd-autoindex.conf steht
# We include the /icons/ alias for FancyIndexed directory listings. If # you do not use FancyIndexing, you may comment this out. # Alias /icons/ "${SRVROOT}/icons/"Directory Listings verhindert eigentlich jeder, und trotzdem ist dieser Alias für Icons fast überall aktiv.
Also: icons ist ein Ordner der Apache Installation, und ein falsch programmiertes System würde, wenn es erstmal in icons Ordner ist, mit ".." nach ${SRVROOT} kommen - dem Apache Installationsordner. Und wenn dieser Weg offen ist, hat man de facto Leserecht auf den ganzen Server.
Ich nehme an, dass diese Lücke früher mal bestand und aktuelle Indianer Dir eins mit dem Tomahawk geben, wenn Du den Exploit versuchst.
Also wenn es je so gewesen wäre, dann hätte jemand an einem Teil der Apache-Konfiguration herumgepfuscht, der dort WIRKLICH keine Schreibrechte haben sollte:
# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
Options FollowSymLinks
AllowOverride None
### Vormals:
#deny from all
### Seit Apache 2.3
Require all denied
</Directory>
(Ich hab das Original um drei Zeilen mit Kommentar bezüglich alter Versionen ergänzt.)
Das verbietet dem Apache erst einmal Zeug auszuliefern, welches auch nur irgendwo im System liegt. Später wird es dann für bestimmte Verzeichnisse wieder erlaubt, aber mit einer Angabe von /../ in der URL kommt man aus diesen nicht raus. Auch nicht mit einem Alias. Es sei denn der zeigt auf etwas explizit Erlaubtes.
Hallo Raketenwilli
dann muss ich mir also keine Sorgen machen.
Ich bin schließlich auch nur Nutzer (von Webspace), das ist dann Sache des Hosters, solchen Attacken zu begegnen, nicht wahr?
Gruß Claus
Ich bin schließlich auch nur Nutzer (von Webspace), das ist dann Sache des Hosters, solchen Attacken zu begegnen, nicht wahr?
So ist es. Es gibt aber andere Attacken (auf Skripte, CMS wie z.B. Wordpress, Helfern wie PhpMyAdmin und Libarys) denen Du - soweit von Dir selbst installiert - auch selbst begegnen musst.