Test-Root gehackt

[hugohorst]

Hallo,
bevor sich alle wieder zurecht aufregen. Ich habe den Testserver nach sichern der Logfiles neu aufgesetzt.
Da ich aber wieder schlauer werden möchte habe ich recht einfach gefunden welche Befehle der Hacker so genutzt hat.

Leider werde ich daraus nicht ganz schlau.
Zur Info, habe für den SSH Login ein Passwort-Zertifikat laufen. Dieses wurde umgangen wie auch immer =D>
Um das rauszufinden, und was der Hacker sonst so getrieben hat würde ich gerne wissen ob mir jemand sagen kann was er genau vor hatte.
FÜr mich macht das nicht viel Sinn.

Code: Select all

atx -u bin
id
df -h
pwd
exit
mv /tmp/x64 /bin/putty
cd /bin
ls
w
atx -u bin
w
ls -lah
chown root .ssh
ls -lah
chown root putty
ls -lah
exit
ls -lah
atx -u bin
ps ax
killall -9 x64
ps ax
id
pwd
ls
ls -lah
chown root root putty
chown root:root putty
ls -lah
chown root:root .ssh
mv putty ptty
ls -lah
chmod --help
cat /sbin/ifconfig
/sbin/ifconfig
exit

Dazu gab es einen Ordner "jail" mit dem Inhalt: glftpd
Die IP stammt laut lokalisierung aus den Niederlanden und der User war "bin".
Wie er reingekommen sein mag versuche ich noch zu erfahren.

Danke für eure Hinweise zum schlauer werden!

[Roger Wilco]

Allein an der Bash History lässt sich der Einbruch nicht rekonstruieren. Tatsächlich hatte der Eindringling nicht allzuviel Ahnung von Linux...

Hattest du irgendwelche Dienste als Benutzer "bin" laufen?

[braindead]

Tatsächlich hatte der Eindringling nicht allzuviel Ahnung von Linux...

Das war aber freundlich formuliert.

Code: Select all

chmod --help
cat /sbin/ifconfig

Das sind schon echte Highlights. Ich würde sagen der Angreifer hat wohl mit einem Tool automatischen Zugriff bekommen und wusste das net so genau was er tun sollte. Sieht irgendwie aus als hätte er versucht putty??? zu installieren, was ja wohl eher ein SSH Client für Windows als ein Rootkit ist. Vielleicht kannst du ja nochmal ein paar Logfiles posten.

Btw. Anzeige erstattet?

edit: *arg* warum geht ein quote=username nichtmehr?

[Roger Wilco]

Sieht irgendwie aus als hätte er versucht putty??? zu installieren, was ja wohl eher ein SSH Client für Windows als ein Rootkit ist.

Fairerweise muss man erwähnen, dass es von PuTTY auch einen Port für Linux/Unix gibt.

edit: *arg* warum geht ein quote=username nichtmehr?

Geht doch. Vielleicht hast du die Anführungszeichen vergessen?

[braindead]

Fairerweise muss man erwähnen, dass es von PuTTY auch einen Port für Linux/Unix gibt.

Stimmt, aber auch wenn man das bedenkt ... was will er damit auch einem root anfangen? Das Ding starten und per X-Forward nach Hause schicken? Egal wie, die Aktion war wohl sinnlos.

Zum Rest *ups*

[oxygen]

Das ist so sinnlos, ich würde fast kaum glauben dass es sich dabei um einen Hack handelt. Merkwürdig.

[Joe User]

Der Angreifer hatte mindestens einen FTPd erfolgreich und dummerweise putty als ptty statt [s]tty installiert. Eventuell war die .bash_history auch nur ein Ablenkungsmanöver?
Lass mich raten: in der sshd_config war UsePAM aktiviert...

[hugohorst]

Also erstmal vielen Dank für eure Meinungen.
So ein Bild wie Ihr hab ich auch davon, sehr komische Sache!

Ich bin noch am suchen ob ich noch mehr Merkwürdigkeiten herausfinde.
Bislang war es aber rnur diese bash_history im ordner bin!

UsePAM war deaktiviert! Hatte soweit ich weiß nichts von "bin" am laufen.

Frage mich wie er sich in SSH am Zertifikat-Key vorbeigeschlängelt hat und wie er somit den ordner jail draufladen konnte.
Werde mein SSH also nochmal deutlich absichern! Schade das man fast nichts lernen konnte! Außer das Hacker/Eindringlinge nicht immer die Linux Profis sind.

[Joe User]

Wenn UsePAM wirklich deaktiviert war, dann wird Dein (aktueller?) SSHd auch nicht das Einfallstor gewesen sein. Vielmehr wird die Kombination aus fehlenden System-Updates, unsicheren Webapplikationen und unsicherer Konfiguration einzelner Dienste oder gar des gesamten Systems.

[hugohorst]

Ok, habe weitere Spuren entdeckt.
mein keyfile für den ssh-dss wurde verändert /erweitert um einen rss key.
Die Datei gehört einem webX User, also einem Webspace Nutzer von Confixx.

Frage mich wie zum Henker diese Datei vom Root verändert werden konnte. Dann ist es natürlich keine Kunst sich per Key einzuloggen.
Hättet Ihr ne idee wie sowas verhinderbar wäre?

SSH Port verlegen macht das ganze schon sinnlos richtig?
Sonst noch Einstellungen in der SSH config die sowas verbieten?

[EdRoxter]

Wenn die Datei einem webX gehört, ist SSH mit Sicherheit nicht dasjenige Element, welches "geknackt" wurde.

Wie lauten denn die Zugriffsrechte deiner authorized_keys? Wie loggst du dich via SSH ein? Hast du root-Login erlaubt und für root Pubkey-Auth eingerichtet?

Bzw., wie genau sieht dein Konzept aus? root kann alles - wieso wundert es dich, dass root eine Datei eines anderen Users verändert? Und was hätte das mit dem Pubkey-Login zu tun?

Ich blicke da gerade nicht ganz durch, ehrlich gesagt...

[daemotron]

Meine Vermutung: Der Angreifer war gar nicht so dumm, wie hier einige mutmaßen. Meine wilde (weil unbewiesene) Theorie: $Einbrecher hat eine Schwachstelle in einer Webapplikation, möglicherweise Confixx selbst, genutzt, um dafür zu sorgen, dass z. B. das Confixx-Counterskript, das ja bekanntlich von root ausgeführt wird, etwas tut, was sich eigentlich nicht gehört. z. B. eine PHP-Shell mit SUID-Bit zu versehen, oder einen öffentlichen Schlüssel in die passende authorized_keys einzutragen, ein Shell-Skript auszuführen oder was auch immer. Wie auch immer, $Einbrecher hat es geschafft, root-Rechte zu erlangen. Von daher würde ich auf den Inhalt der .bash_history nicht allzu viel geben. Die meisten Angreifer begnügen sich heute eigentlich damit, eigene Skripte im Kontext des Webserver-Benutzers ausführen zu können. Das genügt, um eine Spam- oder Warez-Schleuder zu betreiben. Jemand, der sich noch die Mühe macht, sich root-Rechte zu beschaffen, war vermutlich kein "kommerzieller" Cracker. Entweder ein hirntotes Kiddie, das mit einer Exploit-Anleitung über einen scheunentorweit offenen Server gestolpert ist und zufällig reingekommen ist, oder jemand, der ein bisschen mehr drauf hat und seinen dreijährigen Sohn auch mal rangelassen hat, nachdem Papi fertig war.

[caput]

Wenn UsePAM wirklich deaktiviert war, dann wird Dein (aktueller?) SSHd auch nicht das Einfallstor gewesen sein. Vielmehr wird die Kombination aus fehlenden System-Updates, unsicheren Webapplikationen und unsicherer Konfiguration einzelner Dienste oder gar des gesamten Systems.

Offtopic, aber was spricht gegen UsePAM? Wo liegt das grundlegende Problem? Afaik funktioniert doch ohne UsePAM die limits.conf nicht oder irre ich mich da? Und was wäre die alternative diese Limits ohne UsePAM zu setzen?

[Joe User]

man sshd_config
Dort steht der Grund für "UsePAM no", danach sind einem die Limits wurscht...

[blueroot]

Es soll angeblich ein paar "Hacker" geben, die Zugangsdaten "verteilen" um so Ihre Leistung zu zeigen und so "Respekt" zu erlangen.
Oft ist es so, dass dann "Kiddies" diese Logindaten benutzen. Kann in diesem Fall so sein, muss aber nicht. Ohne tieferen Einblick kann man nur spekulieren.

Da aktuell ein einfacher root-exploid durch viele Foren geht, tippe ich auch stark darauf. Hierfür reicht ein einfacherer Zugang und falsche Einstellungen (Ausführen von Dateien. Kein begrenzter Zugriff auf Interpreten [PHP/PERL - Verzeichnisse]).

[hugohorst]

Suse 10.2 war auf dem System mit Apache 2 mit PHP 5.2.0
Updates wurden regelmäßig gefahren eigentlich.
Konnte leider bis heute nicht genau identifizieren durch welche Software der Fehler produziert wurde.
Einträge aus den log-Dateien sprechen aber für eine unsichere Websoftware wie ein CMS etc.
Man lernt nie aus und drum hab ich die Sicherheit extrem erhöht, Beschränkungen durch PHP etc vergrößert und hoffe nun darauf damit solche verfehlten Hacks auszuschließen.

[hugohorst]

Größtenteils eigentlich nur Joomla, leider aber wohl auch in unterschiedlich alten Versionen. Da ich nicht der Webmaster bin von manchen Accounts blieb mir nur per Apache und PHP Rechte einzugrenzen.

[chw]

Wie hat derjenige es geschafft über eine CMS Lücke soviel Rechte zu erlangen?
Wie hattest Du php eingebunden und konfiguriert?

[Anonymous]

Hi, wieso ändert ihr den SSH port nicht einfach und lasst nur einen benutzer zum ssh login zu? Ich hab das bei mir auch so gemacht. Seit dem habe ich auch keine fehlgeschlagenen SSH zugriffsversuche mehr in meine var/log/massages zu stehen.
LG

[EdRoxter]

Weil der Angriff in erster Instanz offenbar nicht via SSH erfolgt ist...

[hugohorst]

Richtig!
SSH Port verlegen Login nur mit Zertifikat etc. alles keine Probleme wenn der Angreifer sich sein eigenes Zertifikat in den Key schreibt und somit einen Login hinbekommt. Interessanter wäre es zu wissen wie man sowas hinbekommt, wenn über den Webserver per

Code: Select all

php_admin_value disable_functions system,exec,passthru,popen,escapeshellcmd,shell_ex,show_source,proc_open

so einiges verboten wird. Muss ich die auf dem Server liegenden Accounts verdächtigen? Verwaltung läuft und lief über Confixx 3.3.1 falls ich das noch nicht sagte.

[EdRoxter]

Hast du da auch den Hotfix angewendet, der neulich herausgegeben wurde? Schau mal bei den pinned Threads im "Administrationshilfen"-Forum!

[hugohorst]

Danke, den hatte ich nicht eingespielt. Jetzt nachgeholt!
Aber kann man durch diese Lücke wirklich den shared_key verändern um somit SSH zugang zu erhalten um dann doch nichts schädliches anzufangen?

[Joe User]

Aber kann man durch diese Lücke wirklich den shared_key verändern um somit SSH zugang zu erhalten um dann doch nichts schädliches anzufangen?

Ja, das ist zusammen mit einem Local-Privileges-Escalation-Bog (z.B. den letzten beiden Kernel-Sicherheitslücken) möglich und der Grund warum ich z.B. FreeBSD nicht als sicheres OS bezeichnen kann...

[daemotron]

Aber kann man durch diese Lücke wirklich den shared_key verändern um somit SSH zugang zu erhalten um dann doch nichts schädliches anzufangen?

Ja. Solange der Webserver (bzw. der PHP-Prozess) nicht in einem ausbruchssicheren Jail (z. B. grsec-gehärtetes chroot) läuft, ist theoretisch jeder Unfug denkbar. Praktisch dann eher der, der durch Ausnutzung der von Joe User angeführten bekannt gewordenen Lücken möglich wird.

Ja, das ist zusammen mit einem Local-Privileges-Escalation-Bog (z.B. den letzten beiden Kernel-Sicherheitslücken) möglich und der Grund warum ich z.B. FreeBSD nicht als sicheres OS bezeichnen kann...

Hmm, ein Vanilla-Linux (ohne PaX o. ä.) ist IMHO auch nicht wirklich besser (ich wette, es ließen sich einige Debian/SLES/RHEL-Installationen finden, auf denen eine LPE möglich wäre). Aber generell tendieren die Berkeley-Unixoide (diverse BSDs, Solaris) schon zu lokal nutzbaren Schwächen, wenn man die fortgeschritteneren Sicherungsmethoden (Jails bzw. Zones, RBAC/MAC) nicht einsetzt.