"Allrequestsallowed.com" ... Hackversuch?

11

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 mich beunruhigt:

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 war, sondern ein 200-Code. Ist das in Ordnung? Kommt mir komisch vor, aber mein Wissen auf diesem Gebiet (und vielen anderen) ist, gelinde gesagt, begrenzt.

luri
quelle
1
Es sieht so aus, als ob ich keine neue Antwort posten darf, aber wir haben einen Eintrag wie diesen in unseren Protokollen gefunden und konnten überprüfen, ob er nicht gefährlich ist, indem wir die Anfrage mit curl reproduzieren : curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Die Standardkonfiguration scheint auf unserem Ubuntu-System eine Seite "Willkommen bei Nginx" ohne aussagekräftigen Inhalt zurückzugeben. Es handelt sich also um eine Antwort von 200, aber es handelt sich um eine einfache Sammel-Seite - wir stellen die Anfrage nicht an eine andere Stelle oder ähnliches.
Frank Farmer

Antworten:

12

Erstens weiß ich nicht, was der mutmaßliche Angreifer zu erreichen versucht. Vielleicht gibt es da draußen ein PHP-Skript oder eine PHP-Version, die für einen seltsamen Sitzungs-ID-Angriff anfällig ist, weiß ich nicht. Sie müssen sich jedoch 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.

Erstens wird http://allrequestsallowed.comes wie der üblichere 'Host:' - Header behandelt ( beachten Sie, dass ich nicht glaube, dass dies im RFC angegeben ist und andere Server es möglicherweise nicht so interpretieren, wie ich mich geirrt habe. Dies wird in RFC 2616 in Abschnitt 5.1 angegeben. 2, 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 Site mit dem Namen "allrequestsallowed.com". Was passiert also, wenn Apache einen Host:Header (oder einen gleichwertigen Header) für einen Hostnamen erhält, den er nicht erkennt? Es wird der erste virtuelle Host als Standard ausgewählt. Dies ist ein genau definiertes und dokumentiertes Verhalten für Apache. Was auch immer Ihr erster virtueller Host ist (oder nur die Hauptserverkonfiguration, wenn keine vhosts vorhanden sind), übernimmt unabhängig davon, wie er heißt.

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

Jetzt sollte der Pfad /auf so ziemlich jedem Webserver vorhanden sein. In den meisten Fällen wird es so etwas wie index.htmloder vielleicht einem index.phpSkript zugeordnet, obwohl Sie natürlich alles überschreiben können.

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

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

Aller Wahrscheinlichkeit nach wird jedoch /nichts Bemerkenswertes passieren , selbst wenn Sie mithilfe von Sitzungen einem PHP-Skript zugeordnet werden. 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 vorhanden ist, könnte der Angreifer möglicherweise die Sitzung eines anderen entführen. Das wäre schlecht, aber es ist nicht wirklich eine Sicherheitslücke an sich - die Lücke wäre überall dort, wo der Angreifer die Sitzungs-ID-Informationen erhalten hat (das Aufspüren eines drahtlosen Netzwerks ist ein guter Kandidat, wenn Sie kein HTTPS verwenden). Sie würden tatsächlich nichts tun können, was der Benutzer, dessen Sitzung es ursprünglich war, nicht tun konnte.

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

Nicholas Knight
quelle
Ich hatte ähnliche Anfragen 404, 500, 403 und 20x auf meinen Servern, die ausgeführt wurden, nginxoder lighttpdnach dem Senden der IPs / Quellhosts an eine Cyber-Analysefirma wurde bestätigt, dass es sich unter anderem um Versuche handelte, Lücken im Server auszunutzen . Ähnliche Anforderungen wie die vom OP angegebenen, unterschiedliche Hosts. Wollen Sie damit sagen, dass sie völlig ignoriert werden sollten? Denn wenn sie wirklich besorgt sind, können sie die Hosts blockieren iptables.
Thomas Ward
@ The Evil Phoenix: Der Host in der URL ist nicht der Ort, von dem die Anfrage stammt, sondern entspricht nur einem 'Host:' - Header. Die tatsächliche Client-IP-Adresse, die von OP verdeckt wurde, könnte auf Wunsch mit iptables blockiert werden. Wenn er jedoch nicht mit Anfragen überflutet wird, spielt dies keine Rolle. Nur weil jemand versucht, ein Loch auszunutzen, heißt das nicht, dass ein Loch vorhanden ist. Ich verwalte zahlreiche (Linux-) Server, die jeden Tag viele seltsame Anfragen aufzeichnen, um Lücken auszunutzen - die meisten davon Windows / IIS-Lücken! Es ist nur blindes Scannen. Wenn es keinen Treffer erhält, geht es weiter zur nächsten IP-Adresse.
Nicholas Knight
@The Böses Phoenix: Wenn weiterhin ein Loch ist vorhanden, die IP - Adresse blockieren , die sie nicht ausgenutzt würde man etwas Gutes tun. Ihr Server wäre bereits kompromittiert und wäre immer noch anfällig für denselben Angriff aus anderen Quellen - und es gibt viele Quellen. Jedes Zombiesystem da draußen (und es gibt viele Millionen) ist eine potenzielle Quelle für böswillige Scans.
Nicholas Knight
Schöne und gründliche Erklärung .... Vielen Dank. Ich habe die beleidigende IP verdeckt , falls er / sie IP-Ego-surft :). Mein / entspricht Apaches Standard "Es funktioniert" (ich weiß, wie unprofessionell ... aber ich sagte, es sei persönlich, lol). Ich gehe also davon aus, dass ich nichts tun muss, es sei denn, dieselbe IP wird zu einem Problem. In diesem Fall werde ich sie mit iptables (oder sogar hosts.deny?) Blockieren. Danke noch einmal.
Luri
1

Ich habe diese alle Anforderungen auf einer IP-Adresse angemeldet, die als 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 zeigt.

Der eigentliche Webserver unter 31.44.184.250 dient nur zur Bearbeitung externer Anfragen.

Meine Meinung: total harmlos. Sie sehen keine Mehrwertnutzung dafür, außer für Dinge, die Sie mit einem anderen gefälschten Domainnamen in Ihrer Hostdatei tun können.

Kajje
quelle