Hallo, kann mir jemand helfen folgendes nach zu vollziehen.
Jemand findet auf einen Apache2 mit su_php ein unsicheres script bei dem man Fremde Datein includen kann.
Fürhrt somit einen PHP Shell aus.
Und schafft damit sowas:
web486 20750 0.0 0.0 2356 1036 ? S May31 0:00 /bin/sh
apache 21200 0.0 0.0 3160 2064 ? S May31 0:00 _ bash -i
Der User apache ist neu uns hat uid 0 also somit root rechte.
Somit hat er damit auch ssh Zugang. aber wie kommt der an die passwd wenn die nur Schreibrechte für root hat.
Und nichts läuft als root / in seiner gruppe also weder su_php noch der Apache selber.
Ich habe den user apache erstmal gelöscht und web486 dich gemacht. Werde mir noch überlegen wie ich weiter verfahre, da der Einbrecher (Marokaner) sonst ziemlich unbedacht vorgegangen ist. So wie seine Hilfsmittel aussehen nur ein Skriptkiddy. (hat nur 2 psybncs und eggdrops eröffnet)
PS System ist eine Debian 3.1 komplett aktuell.
Einbruch nach volziehen
-
miker
- Posts: 64
- Joined: 2005-03-26 13:33
- Location: Wildeshausen
Re: Einbruch nach volziehen
Ein 3.1 kann nicht "aktuell" sein, weil es schon seit längerem keine Updates mehr zur Verfügung gestellt werden. Nutze den Hack als Ausgangspunkt für eine Neuinstallation und wechsel dann gleich auf das aktuelle 4.0.PS System ist eine Debian 3.1 komplett aktuell.
-
daemotron
- Administrator
- Posts: 2641
- Joined: 2004-01-21 17:44
Re: Einbruch nach volziehen
Um root-Rechte zu erschleichen gibt's viele Wege... wenn ein alter Kernel werkelt, gibt's einige Exploits dafür. Oder er hat sich eines Binary mit SUID-Bit bedient, das einen bekannten oder unbekannten Fehler aufweist. Möglicherweise ist sogar Dein suphp selbst die verwundbare Stelle, oder der Apache-Elternprozess, der seine root-Rechte ja nicht abgibt.
Was Du hättest tun sollen: Image und Memory Dump des Systems erstellen, ohne vorher etwas daran zu verändern. Damit hättest Du eine Chance gehabt, den tatsächlichen Einbruchsweg nachzuvollziehen. So bleibt Dir nichts anderes übrig, als das System frisch aufzusetzen - der Kerl hatte immerhin root-Rechte und könnte Dir wer weiß was für Eier ins System gelegt haben. Als vorbeugende Maßnahme kannst Du ja dann zusätzlich PHP-Prozesse in ein chroot sperren, das per grsecurity o. ä. gegen Ausbrüche abgesichert ist. Dann dürfte es schon deutlich schwerer werden, über eine knackbare Webapplikation gleich root zu werden.
Was Du hättest tun sollen: Image und Memory Dump des Systems erstellen, ohne vorher etwas daran zu verändern. Damit hättest Du eine Chance gehabt, den tatsächlichen Einbruchsweg nachzuvollziehen. So bleibt Dir nichts anderes übrig, als das System frisch aufzusetzen - der Kerl hatte immerhin root-Rechte und könnte Dir wer weiß was für Eier ins System gelegt haben. Als vorbeugende Maßnahme kannst Du ja dann zusätzlich PHP-Prozesse in ein chroot sperren, das per grsecurity o. ä. gegen Ausbrüche abgesichert ist. Dann dürfte es schon deutlich schwerer werden, über eine knackbare Webapplikation gleich root zu werden.
-
eof__
- Posts: 30
- Joined: 2005-07-12 17:40
Re: Einbruch nach volziehen
moin,
also _ein_ apache prozess laueft immer als root. (oops hat mein vorredner ja schon gesagt :oops: ) Ansonsten Jails und Mod Security. Wobei Du Dir klarmachen musst
dass Mod_Security hauptsaechlich pattern matching betreibt. Wenn Du beim naechsten mal _alles_ dokumentieren willst, ist ein IDS eine gute Sache bzw. ein Diff gegen
einen bekannten Status von laufenden Prozessen. Also ich halte viel von sicheren default Einstellungen, ob man gleich grsecurity braucht ist sicher auch eine Abwaegung des Grades der Paranoia, bei php gibt es auch eine disable_functions Option fuer die php.ini. Zur Not musst du mal Deine PHP Programmierer zwingen bestimmte Funktionen nicht mehr zu nutzen. :twisted: wenn diese Option fuer Dich in Frage kommt :roll:
gruss __eof, grad auf jobsuche :evil:
also _ein_ apache prozess laueft immer als root. (oops hat mein vorredner ja schon gesagt :oops: ) Ansonsten Jails und Mod Security. Wobei Du Dir klarmachen musst
dass Mod_Security hauptsaechlich pattern matching betreibt. Wenn Du beim naechsten mal _alles_ dokumentieren willst, ist ein IDS eine gute Sache bzw. ein Diff gegen
einen bekannten Status von laufenden Prozessen. Also ich halte viel von sicheren default Einstellungen, ob man gleich grsecurity braucht ist sicher auch eine Abwaegung des Grades der Paranoia, bei php gibt es auch eine disable_functions Option fuer die php.ini. Zur Not musst du mal Deine PHP Programmierer zwingen bestimmte Funktionen nicht mehr zu nutzen. :twisted: wenn diese Option fuer Dich in Frage kommt :roll:
gruss __eof, grad auf jobsuche :evil: