4
Analyse eines Einbruchs
Hallo,
bei uns wurde am 6. Juni in unseren Server "eingebrochen". Bei dem Server handelt es sich um einen Apache 2.2.22 hinter dem ein Jboss 5.10 läuft. Wir haben den Apache mit mod_jk so konfiguriert, dass dieser nur die Adresse /apps an den Jboss weiterleitet. Der Jboss lauschte nur auf 127.0.0.1 Port 8009(AJP) und 8080(HTTP). Iptables wurde so konfiguriert, dass nur Port 80, 443 und ein SSH Port von außen Freigegeben waren. Wir hatten den Server erst am 6. Juni soweit eingerichtet (waren noch nicht komplett fertig) dass die JMX-Console noch nicht abgesichert war und der Jboss testweise noch mit root Rechten lief. Uns war bekannt, dass es einen Wurm für Jboss gibt, welcher über die JMX-Console eindringt, wir waren uns jedoch sicher, da wir von außen nicht auf die JMX-Console zugreifen konnten (Jboss lauschte ja nur auf 127.0.0.1 und Apache leitete nur /apps weiter), dass wir davon verschont bleiben sollten. Nun wurden wir am selben Tag um 23 Uhr eines besseren belehrt, als genau mit diesem Exploit unser System kompromitiert wurde.
Nun ist uns die Vorgehensweise des Angreifers ein komplettes Rätsel, da auch in den Apache Logs an diesem Tag nichts allzu auffälliges zu sehen ist. Habt ihr eine Idee wie das funktionieren könnte? Wir würden das gerne in Zunkunft vermeiden, auch wenn wir schon die JMX-Console abgesichert haben und JBoss nicht mehr als root laufen lassen.
Gruß, homedom
bei uns wurde am 6. Juni in unseren Server "eingebrochen". Bei dem Server handelt es sich um einen Apache 2.2.22 hinter dem ein Jboss 5.10 läuft. Wir haben den Apache mit mod_jk so konfiguriert, dass dieser nur die Adresse /apps an den Jboss weiterleitet. Der Jboss lauschte nur auf 127.0.0.1 Port 8009(AJP) und 8080(HTTP). Iptables wurde so konfiguriert, dass nur Port 80, 443 und ein SSH Port von außen Freigegeben waren. Wir hatten den Server erst am 6. Juni soweit eingerichtet (waren noch nicht komplett fertig) dass die JMX-Console noch nicht abgesichert war und der Jboss testweise noch mit root Rechten lief. Uns war bekannt, dass es einen Wurm für Jboss gibt, welcher über die JMX-Console eindringt, wir waren uns jedoch sicher, da wir von außen nicht auf die JMX-Console zugreifen konnten (Jboss lauschte ja nur auf 127.0.0.1 und Apache leitete nur /apps weiter), dass wir davon verschont bleiben sollten. Nun wurden wir am selben Tag um 23 Uhr eines besseren belehrt, als genau mit diesem Exploit unser System kompromitiert wurde.
Nun ist uns die Vorgehensweise des Angreifers ein komplettes Rätsel, da auch in den Apache Logs an diesem Tag nichts allzu auffälliges zu sehen ist. Habt ihr eine Idee wie das funktionieren könnte? Wir würden das gerne in Zunkunft vermeiden, auch wenn wir schon die JMX-Console abgesichert haben und JBoss nicht mehr als root laufen lassen.
Gruß, homedom
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 186216
Url: https://administrator.de/forum/analyse-eines-einbruchs-186216.html
Ausgedruckt am: 18.04.2025 um 11:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
es gibt mit Sicherheit verschiedene Wege,da aber ein "bekanntes" Exploit genutzt wurde hat der Angreifer vieleicht mit Nessus gearbeitet?
Dieses Tool kann man sehr gut benutzen um Schwachstellen in seinem System zu ueberpruefen.
Fuer Firmen ist es jedoch nicht kostenlos und leider koennen es Angreifer ebenso nutzen.
Aber es gibt viele Wege nach Rom.... Was sagen den die Firewalllogs?
Gab es auffaellige ssh scans?
Oder hat vieleicht jemand von "Intern" der vertraut war mit der Schwachstelle, diese fuer sich genutzt?
Gruss
es gibt mit Sicherheit verschiedene Wege,da aber ein "bekanntes" Exploit genutzt wurde hat der Angreifer vieleicht mit Nessus gearbeitet?
Dieses Tool kann man sehr gut benutzen um Schwachstellen in seinem System zu ueberpruefen.
Fuer Firmen ist es jedoch nicht kostenlos und leider koennen es Angreifer ebenso nutzen.
Aber es gibt viele Wege nach Rom.... Was sagen den die Firewalllogs?
Gab es auffaellige ssh scans?
Oder hat vieleicht jemand von "Intern" der vertraut war mit der Schwachstelle, diese fuer sich genutzt?
Gruss
Der beste Weg das nachzuvollziehen ist den Exploit selbst auszuführen und zu beobachten was passiert. Die Kiste sollte neu aufgesetzt werden, wer weiss, was sich da jetzt sonst noch so tummelt. Dieser Link könnte noch interessant sein.
Den Exploit hab ich mittels Metasploit schon erfolgreich an einem ungesicherten System ausgeführt. Wenn ich jedoch einen Apache Webserver vorschalte mit der selben Konfiguration wie bei unserem alten System, dann kann man gar nicht mehr auf die URL http://host/jmx-console zugreifen, da wir mittels mod_rewrite alle nicht http requests auf https://host/apps umschreiben. auch https requests auf https://host/ werden auf https://host/apps weitergeleitet. Daher ist es mir noch ein Rätsel wie man auf die Jboss Console zugreifen soll der, wie bereits gesagt, nur hinter dem Apache auf die Verbindungen von localhost lauscht. Gibt es für apache2 2.2.22 eine bekannte Sicherheitslücke im mod_rewrite welche solch etwas zulässt? In den Firewalllogs gab es nur einige wenige request auf ssh port und auf samba port, da ist nichts dran auffällig. Im kernel log fehlt allerdings der komplette 6. Juni:
Jun 5 16:29:26 ubuntu kernel: [ 19.895384] eth1: no IPv6 routers present
Jun 7 20:24:32 ubuntu kernel: [186921.565553] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Wir haben den Server komplett neu aufgesetzt und alle keys und Passwörter getauscht. Wir verwenden nun Jboss7 und haben auch noch einige kleinere Änderungen an der Apache Konfiguration gemacht.
Jun 5 16:29:26 ubuntu kernel: [ 19.895384] eth1: no IPv6 routers present
Jun 7 20:24:32 ubuntu kernel: [186921.565553] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Wir haben den Server komplett neu aufgesetzt und alle keys und Passwörter getauscht. Wir verwenden nun Jboss7 und haben auch noch einige kleinere Änderungen an der Apache Konfiguration gemacht.
afaik gibts da nix... aber der Angreifer könnte ja über einen anderen Weg reingekommen sein. Da müsste man dann wohl einen ausführlichen Test machen, auch Nessus muss vermutlich nicht immer alles finden.
