Remotezugriff mit Metasploit über Apache (Ports 80/443)

G

gany

0
Hallo zusammen,


wir haben in der Schule folgende Aufgabe zu IT-Sicherheit bekommen.
Eine Grupppe hat einen Apache Webserver und einen Dateiserver auf zwei verschiedenen Ubuntu-Rechnern installiert. Meine Gruppe hat die Aufgabe auf die Ubunturechner zu kommen und von dort jweils ein "Geheim"-Dokument zu klauen.


Der Apache ist ungebatcht da es wahrscheinlich sonst nur für Profis machbar wäre auf den Rechner zu kommen. Es gibt auch keine Firewall etc.


Meine Idee war es hierfür Metasploit zu benutzen.Für den Zugriff auf den Dateiserver hat das mit Metasploit funktioniert. Es gab eine prima Anleitung im Netz.


Hat mir jemand vlt. jemand einen Tip wie das mit dem Zugriff über den Apache Webserver (Ports 80 und 443 sind offen) funktionieren könnte bzw. welche exploits bzw. payloads man verwenden könnte.

Mit der Version des Apache kann ich leider nicht dienen.

Wir hatten gehofft, dass im Antwortheader des Apache was über die Version zu finden wäre. Der Apache gibt in der Antwort lediglich an, dass er ein Apache ist
happy.png



Ich wäre euch für jeden Tip/Hinweis/Link dankbar.
Gruesse
gany
 
Kannst ja mal mit nmap nen Portscan machen. Ein Anhaltspunkt zur Apache-Version sollte die service detection bieten.
 
Schau doch erstmal mit nikto nach ob ggf. der Apache selbst was über den Ort des Dokuments verrät oder wenigstens ein paar mehr Informationen auswirft. Und ansonsten würde ich mich mal bei Packetstormsecurity o.ä. nach passenden Metasploit-Modulen umschauen.
 
Hallo,

erst mal danke für die bisherigen Antworten.

Ich hab das gestern mal mit nmap Sevice Detection versucht.
Ich habe hierzu die option -sV benutzt.
Falls das falsch ist bitte berichtigen :)

Hier die Ergebnisse des Scans.

Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd
443/tcp open ssl/http Apache httpd

Unter Version steht httpd, bringt mich das irgendwie weiter?
httpd bedeutet ja eignetlich nur das der Server ein Webserver ist oder seh ich das falsch?

Mit nikto habe ich die grundlegenden Scans aus der Doku ausprobiert. Ebenfalls ohne Ergebnis.

Wie schon erwähnt gab es für den Dateiserver eine Spitzenanleitung die fuktioniert hat.

How to hack a remote computer running Windows. « XtremeFX

Gibt es so eine Anleitung auch für einen Apache Webserver.

Ach ja, ein Anderer aus meiner Gruppe hat herausgefunden, dass der Webserver auf einem Ubuntu-Rechner läuft, falls das was bringt.

Gruesse
gany
 
Die meisten Intrusions bei Webservern geschehen nicht über den Webserver selbst, sondern über die darauf laufenden Webapps. Es gibt nicht sonderlich viele Angriffspunkte bei einem "leer laufenden" Indianer. Ein Scan mit skipfish o.ä. kann bei Webapps manchmal sehr aufschlussreich sein. Tools wie Nessus können auch oft Aufschluss über das dahinter laufende System geben. Ist erstmal eine Lücke in einer Webapp gefunden, ist lediglich etwas Kreativität gefragt.
 
Apache an sich ist so eine alte Software, die schon seit 10 Jahren keine relevanten neuen Features mehr bekommen hat, dass die Anzahl der Sicherheitslücken, die übers Netzwerk ausnutzbar sind, gegen null konvergiert.
Meistens ist aber PHP installiert und meistens auch noch die eine oder andere PHP-Applikation... und sowohl PHP an sich als auch PHP-Anwendungen sind meistens nicht sonderlich sicher. Eigentlich nie.
 
Auch mit laufenden PHP-Webapps kann Apache relativ sicher sein, wenn z.B. der Suhosin-Patch verwendet wird und wenigstens keine File-Inclusions vorhanden sind. Die Frage bei der Aufgabenstellung ist halt, ob das "Geheimdokument", das es zu finden gilt, innerhalb des Zugriffs des Webservers liegt (man also z.B. über einen simplen Fehler in der Webapp rankommt) oder ob es z.B. im Home-Verzeichnis von root liegt. Die Schwierigkeitsstufen könnten dann unterschiedlicher nicht sein.
 
Ich bezog mich eher auf die allgemeine Sicherheit der durchschnittlichen Webanwendung, die selbst bei verbreiteten Zeug wie Drupal oder Wordpress besser sein könnte. Aber natürlich ist dann noch der Ort des Ziels eine klare Abstufung und die Art der Lücke. Hier muss es was serverseitiges sein, womit die auch extrem häufigen XSS und andere Lücken nutzlos sind, aber dank PHP gibt es ja oft genug die Möglichkeit Skripte von URLs zu holen und ausführen zu lassen *hust*
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben