it-swarm.com.de

"allrequestsallowed.com" ... Hackversuch?

Ich habe viele Versuche auf meinem (kleinen, persönlichen und absolut unwichtigen) Webserver, und Apache und fail2ban machen ihre Arbeit normalerweise richtig. Aber es gibt einen Protokolleintrag, der mir Sorgen macht:

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

Das Problem ist, dass die Antwort kein 404-Code ist, sondern ein 200-Code. Ist das in Ordnung? Scheint mir komisch, aber mein Wissen auf diesem Gebiet (und vielen anderen) ist, um es leise auszudrücken, begrenzt.

11
luri

Zunächst einmal weiß ich nicht, was der mutmaßliche Angreifer zu erreichen versucht. Vielleicht gibt es ein PHP Skript oder eine PHP Version, die anfällig für einen seltsamen Session-ID-Angriff ist, keine Ahnung. Sie müssen sich aber wahrscheinlich keine Sorgen machen.

Ihr Server hat sich genau wie erwartet verhalten. 200 ist der erwartete Code in dieser bestimmten Situation, da Apache die an ihn übergebene URL interpretiert.

Zunächst wird http://allrequestsallowed.com wie der übliche 'Host:' - Header behandelt (beachten Sie, dass dies meines Erachtens nicht im RFC angegeben ist und andere Server dies möglicherweise nicht so interpretieren Ich habe mich geirrt, dies ist in RFC 2616 in Abschnitt 5.1.2 angegeben, obwohl Clients dieses Formular selten zu verwenden scheinen. Entschuldigung, ich muss eine HTTP-Server-Implementierung reparieren, die ich vor einiger Zeit geschrieben habe ...).

Vermutlich haben Sie keine Website mit dem Namen "allrequestsallowed.com". Was passiert also, wenn Apache einen Host: -Header (oder ein Äquivalent) für einen Hostnamen erhält, den es nicht erkennt? Es wählt den ersten virtuellen Host als Standard aus. Dies ist ein genau definiertes und dokumentiertes Verhalten für Apache. Was auch immer Ihr erster virtueller Host ist (oder nur die Hauptserverkonfiguration, wenn es keine vhosts gibt), übernimmt dies, egal wie der Name lautet.

Der Rest der angegebenen URL besteht aus zwei Teilen - dem Pfad / und einem GET-Parameter (dem ?PHPSESSID... -Bit).

Nun sollte der Pfad / auf so ziemlich jedem Webserver vorhanden sein. In den meisten Fällen wird es auf etwas wie index.html oder vielleicht auf ein index.php -Skript abgebildet, obwohl Sie natürlich jedes davon überschreiben können.

Wenn es einer statischen HTML-Datei zugeordnet ist, passiert absolut nichts Ungewöhnliches - der Inhalt der Datei wird zurückgegeben, und das heißt, der Parameter wird einfach ignoriert. (Vorausgesetzt, Sie haben bestimmte erweiterte Konfigurationsanweisungen nicht festgelegt und mit ziemlicher Sicherheit auch nicht.)

Wenn es sich hingegen um ein Skript handelt, wird die Variable PHPSESSID an das Skript übergeben. Wenn das Skript tatsächlich verwendet diese Variable (in diesem speziellen Fall sind es wahrscheinlich nur PHP Skripte, die die integrierte Sitzungsbehandlung von PHP verwenden), hängt sein Verhalten vom Inhalt ab.

Aller Wahrscheinlichkeit nach passiert jedoch nichts Besonderes, selbst wenn Ihr / mithilfe von Sitzungen einem PHP -Skript zugeordnet wird. Die Sitzungs-ID ist wahrscheinlich sowieso nicht vorhanden und wird entweder ignoriert oder das Skript zeigt einen Fehler an.

In dem unwahrscheinlichen Fall, dass die Sitzungs-ID existiert, könnte der Angreifer möglicherweise die Sitzung einer anderen Person übernehmen. Das wäre schlecht, aber an sich ist es keine Sicherheitslücke - die Lücke ist überall dort, wo der Angreifer die Sitzungs-ID-Informationen erhalten hat (ein drahtloses Netzwerk zu schnüffeln ist ein guter Kandidat, wenn Sie nicht HTTPS verwenden). Sie wären eigentlich nicht in der Lage, etwas zu tun, was der Benutzer, dessen Sitzung es ursprünglich war, nicht tun könnte.

Bearbeiten: Zusätzlich wird das '% 5C' in der SESSIONID einem Backslash-Zeichen zugeordnet. Dies scheint ein Test für Directory Traversal-Angriffe auf Windows-Hosts zu sein.

12
Nicholas Knight

Ich habe allrequestsallowed auf einer IP, die als A-Datensatz für alle unsere Park-Domains verwendet wird.

Mein Schuss ist, dass dieser Hostname in Kombination mit der lokalen Hostdatei des "Angreifers" verwendet wird, die auf den Zielhost verweist.

Der eigentliche Webserver am 31.44.184.250 dient lediglich der Bearbeitung externer Anfragen.

Meine Meinung: total harmlos. Sie sehen keinen Mehrwert, außer dem, was Sie mit einem anderen gefälschten Domainnamen in Ihrer Hostdatei machen können.

1
Kajje