Veni, Vidi, VISA

Nachdem ich im vorherigen Eintrag geschrieben habe das ich nicht ständig *BSD anstelle von Linux installieren muss wenn es sich um sicherheitsrelevante Systeme dreht, haben mich schon einige Mails erreicht wo mir erklärt wurde, das man auch Linux auf solchen Systemen verwenden kann.
Stimmt auffallend. Die Frage ist nur ob man das auch wirklich will? Das kein System wirklich sicher ist, steht außer Frage (mal XTS-400 und diverse TCSEC-B1 - Systeme mal außer Acht gelassen) und das Sicherheitslücken gefunden werden lässt sich bei komplexen Systemen nicht vermeiden. Aber was ein absolutes KO-Kriterium sein kann, ist, wie auch gefundene Sicherheitslücken reagiert wird. Bei *BSD (damit ich mich auch den vorherigen Eintrag beziehe) gibt es dafür Mailinglisten und Advisories auf der Homepage wo man sich informieren bzw. auf dem laufenden halten kann. Bei Linux gibt es weder noch; nur einen kurzen Log im git-log. Gut.. besser als nix werden sich jetzt einige denken, aber das ist für Admins alles andere als auch nur irgendwie brauchbar. Ein Admin hat i. d. R. keine Zeit um sich ein Repo zu clonen und dort in den Shortlogs nach Änderungen Ausschau zu halten die sich auf Sicherheitslücken beziehen. Und - auch wenn ich jetzt einige enttäuschen muss - es bringt auch nicht viel das z. B. Debian die Mailingliste debian-security-announce@ hat, wo man über Sicherheitslücken benachrichtigt wird. Deren Aufgabe ist es, Patche über ihr Paketmanagementsystem verfügbar zu machen, damit sie eingespielt werden können. Aber das können sie erst, nachdem der Patch auch verfügbar ist.
Wenn eine bekannte Sicherheitslücke über zwei Monate lang nicht behoben wird, dann ist das absolut untragbar und die Tatsache das in keiner Art und Weise veröffentlicht wird, dass es sich um die Behebung eines sicherheitsrelevanten Bugs handelt, ist für mich ein Grund meinen Kunden Linux auf sicherheitsrelevanten Systemen als letzte Möglichkeit zu empfehlen (und selbst da nur mit Einschränkungen).

http://www.welt.de/webwelt/article2756659/iPhone-ruft-automatisch-Abzock-Nummer-an.html

Gefährliche Sicherheitslücke beim iPhone: Mit präparierten E-Mails kann das Handy dazu gebracht werden, dass es selbstständig teure Telefonnummern anruft. Laut dem Fraunhofer Institut wurde Apple bereits vor einem Monat über das Problem informiert. Eine Lösung wird es aber wohl erst Freitag geben.

Hacker können das Multimedia-Handy iPhone mit einem simplen Trick zum Wählen von Abzock-Telefonnummern veranlassen. Betroffen sind alle bisher verkaufen iPhones, wie das Fraunhofer-Institut für Sichere Informationstechnologie SIT mitteilte und damit einen Bericht der „Computerbild“ bestätigte.

Das Szenario: Der iPhone-Nutzer empfängt auf seinem Handy eine E-Mail oder SMS mit einem Internetlink. Klickt der Empfänger darauf, öffnet sich zunächst eine gewöhnliche Internetseite. Doch plötzlich wählt das iPhone ohne Zutun des Nutzers die Abzocke-Telefonnummer. Ein Abbruch des Anrufs ist nicht möglich, der Handy-Bildschirm bleibt grau, die teure Nummer wird gewählt.
[...]

*bruahaaaaaa*

http://www.heise.de/newsticker/meldung/100630

XSS-Schwachstelle auf Bundesregierung.de

Die offizielle Website der Bundesregierung weist eine Schwachstelle auf, über die sich mit Hilfe manipulierter Links beliebige Inhalte ins Seitenlayout einbetten lassen. Der Entdecker dieser so genannten Cross-Site-Scripting-Schwachstelle (XSS), Marcell Dietl, hat in seinem Blog Beispiel-Links gepostet, die nach einem Klick durch den Anwender die Regierungsseite beispielsweise mit einem Bild des Schauspielers Sylvester Stallone öffnen.

(ganzer Artikel auf Heise)

Wahrscheinlich werden deswegen Onternetnutzer, die Webseiten von Aemtern und Ministerien besuchen protokolliert. Ich an Marcell Dietls Stelle haette das nicht veroeffentlich. Nicht wegen dem Hackerparagraphen, sondern wegen der Kiddies die jetzt von ihm h4x0rn lernen wollen.

Am Montag ist es mal wieder soweit. $KUNDE will das ich auf einem Server der gecrackt wurde, eine forensische Analyse und weil ich mal wieder nicht schlafen kann, schreib ich mal zusammen wie ich bei sowas vorgehe. Also nur den technischen Vorgang und nicht das Melden des Angriffes.

Server vom Netz nehmen!

Es gibt kein "Aber.."! Die Kiste muss sofort vom Netz um den Schaden zu minimieren. Einige Personen (hauptsaechlich solche ohne Ahnung, aber mit was zu Sagen) fangen so gut wie immer an zu diskutieren und verlangen das die Analyse/Saeuberung online vorgenommen wird. In solchen Faellen hilft es ungemein wenn man einen Vordruck hat, auf dem steht das der Unterzeichnende die volle Verantwortung fuer diese Entscheidung uebernimmt.
Mit diesem Vordruck in der einen und einen Kuli in der anderen Hand, fragt man dann in die Runde wer unterschreibt. Spaetestens dann darf man den Server vom Netz nehmen.

Nicht rebooten!

Fuer eine Analyse benoetigt man den aktuellen Zustand und der ist nach einem Reboot nicht gegeben. Ein Reboot sorgt dafuer das manuell gestartete Prozesse nicht mehr laufen. Ich hatte aber auch schonmal einen Fall, in dem der Angreifer in einem Runlevel ein Script angelegt hat, dass die von ihm installierten Programme umbenennt und anschliessend startet.

Daten sichern

Nein. Nicht fuer die naechste Installation, sondern fuer eine Kopie des Systems. Nach Moeglichkeit eine Kopie des gesamten Systems im aktuellen Zustand. Sollte der Speicherplatz nicht ausreichen, ist das Minimum /etc und /var.
Es zahlt sich auch aus wenn man sein Vorgehen aufschreibt; das hat den Vorteil das man genau weiss was man schon gemacht/untersucht hat und was nicht.

Logfiles ueberpruefen

Nicht auf irgendwelche Shellscripte von Freshmeat/Sourceforge verlassen; die erleichtern zwar die Arbeit, aber haben auch den Nachteil das sie manipulierbar sind. Das bekannteste Beispiel ist anti-chkrootkit.pl. Wenn man Tools verwendet, dann solche von denen man weiss das sie sauber sind. Ich habe dazu die notwendigen Programme immer auf CD und einem USB-Stick dabei um sie "mal schnell rueberkopieren" zu koennen.

Informationen beschaffen

Dazu gehoert u. a. eine Liste aller laufenden Prozesse, der verwendeten Ports, alle setuid-Programme, neu installierte Programme (Abgleichen mit einer Liste der zuvor vorhandenen Programme), und und und..
Von den existierenden Programmen kann man sich relativ einfach eine brauchbare Liste mit den notwendigsten Informationen erstellen lassen. Dazu benoetigt man lediglich stat(1) und md5sum(1); mal ein kleines Beispiel:

$ mkdir foobar && cd foobar

$ touch foo bar foobar barfoo

$ for i in ~/foobar/*; do stat "$i" && echo -e md5sum: "`md5sum "$i"`\n"; done > ~/chksum.txt

$ cat ~/chksum.txt

  File: `/home/dope/foobar/bar'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716848    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/bar



  File: `/home/dope/foobar/barfoo'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716850    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/barfoo



  File: `/home/dope/foobar/foo'

  Size: 0               Blocks: 0          IO Block: 4096   regular empty file

Device: 803h/2051d      Inode: 10716847    Links: 1

Access: (0600/-rw-------)  Uid: ( 1000/    dope)   Gid: (  100/   users)

Access: 2007-10-14 04:44:54.000000000 +0200

Modify: 2007-10-14 04:44:54.000000000 +0200

Change: 2007-10-14 04:44:54.000000000 +0200

md5sum: d41d8cd98f00b204e9800998ecf8427e  /home/dope/foobar/foo



...

Informationen aus dieser Liste ueber einzelne Programme muss man anschliessend nicht lange per Hand suchen, sondern kann sie sich mit grep -B8 barfoo$ chksum.txt anzeigen lassen. Hauptsaechlich dient diese Liste aber dazu, um sie spaeter mit einer (nach dem gleichen Prinzip erstellten Liste) abzugleichen. Dazu benoetigt man ein identisches System (gleiche Distribution, gleiche Software, ..); auf diesem System wird ebenfalls eine solche Liste erstellt und dann via diff(1) auf Unterschiede geprueft.
Prinzipiell sind erstmal alle Dateien (Ja. alle Dateien!) gefaehrlich.

Einbruchserkennung

Wie erkennt man auf welchem Weg sich der Cracker Zugriff auf das System beschafft hat? Das ist manchmal trivialer als man denkt. Zum Grossteil sind Cracker irgendwelche Scriptkiddies, die sich Exploits herunterladen und ausfuehren. Zuerst besorgt man sich einen Ueberblick ueber die installierte Software (mit besonderem Augenmerk auf Netzwerkdienste); anschliessend sieht man sich auf den bekannten Seiten (Securityfocus, milw0rm, SecuriTeam, metasploit, ..) um und wird in 80% aller Faelle fuendig. Ein Blick in die Logfiles des Systems sollte auch nicht versaeumt werden (sofern diese nicht durch den Angreifer geloescht/geaendert wurden).
So traurig es auch ist, aber fast immer basieren erfolgreiche Angriffe auf Nachlaessigkeit des Admins. Sei es durch Fehlkonfiguration oder durch fehlende Security-Updates.

Backups

Von einem solchem System werden keine Backups erstellt, damit man sie anschliessend wieder einspielen kann. Auch nicht ausnahmsweise. Selbst schon vorhandene Backups sollte genauestens ueberprueft werden, bevor man diese einspielt. Sobald ein Server kompromittiert wurde, ist die einzig brauchbare Loesung eine Neuinstallation. Und zwar vom kompletten System und von den Originalmedien.

Es gaebe noch etliche Punkte die man beachten muss und auf die ich eingehen koennte, allerdings fuellt dieses Thema ganze Buecher und es gibt keine allgemein gueltige Vorgehensweise die man per copy&paste nutzen kann. Stattdessen verweise ich jetzt einfach mal auf URLs die sich mit diesem Thema befassen:

• Intruder Detection Checklist
• Steps for Recovering from a UNIX or NT System Compromise
• Linux Security Administrator's Guide
• Focus On Linux: Intrusion Detection on Linux
• Intrusion Detection FAQ (SANS)
• FAQ: Network Intrusion Detection Systems
• Intrusion Detection System Training

Es gibt auch etliche Distributionen welche sich als "Forensic environment" bezeichnen, aber ich persoenlich nutze ausschliesslich BackTrack, Arudius, F.I.R.E, NetSecL und/oder Pentoo