IT-Security

Wie in meinem letzten Blog-Eintrag ankündigt werde ich meine derzeitgen Arbeiten hier veröffentlichen. Diesmal meine Präsentation zum Thema Botnetze.

Vortrag

Die Präsentation hatte Ursprünglich noch meine ganzen Quellen enthalten, aber mit Absprache meine Professors, haben wir ausgemacht, das die Quellen in der dazugehörigen Seminararbeit genannt werden. Werde diese auch in den nächsten Wochen nach meinen Prüfungen veröffentlichen.

Im Rahmen meines Studiums konnte ich in der Veranstaltung "Penetration Testing I" Bekanntschaft mit dem Exploiting Framework Core Impact Pro V9 machen.
Im vergleich zu Metasploit besteht der große Vorteil darin, dass es in der Bedienung sehr intuitiv zu bedienen ist und trotzallem sehr detaillierte Einstellungen erlaubt. Dabei können die individuellen Konfigurationsmöglichkeiten mit Hilfe eines Assistenten erfolgen.
Core Impact arbeitet auf Basis der „patentierten Agenten Technologie“ wie Core Security selbst ihre Entwicklung beschreibt. Ein Agent ist ein Programm, welches auf dem kompromittierten System installiert wird. Es entspricht in der Funktionalität einem RAT, der ausschließlich im RAM des kompromittierten Systems arbeitet und versucht, durch anti-forensische Maßnahmen  unerkannt zu bleiben. So können über die Agenten lokale Prozesse oder über das bereits kompromittierte System weitere Ziel-Systeme angegriffen werden. Ein Agent kann jederzeit aus einem kompromittierten System entfernt werden und überleben per Default keinen Neustart (kann aber eingestellt werden).
Eine Besonderheit von Core Impact ist das automatisierte Ausführen von Penetrationstests, welche von Core Security als “Rapid Penetration Testing“ (RPT) bezeichnet wird. Hierzu wird bei der Standardkonfiguration automatisch folgender Prozess ausgeführt:

1. Enumeration (Information Gathering)
2. Angriff und Penetration
3. Lokales Information Gathering
4. Privilege Escalation
5. Cleanup
6. Reporting

Bei der “Enumeration“ werden wahlweise Information über das Ziel-Netz oder -System gesammelt. Auf Grundlage dieser Informationen wird ein Angriff auf das Ziel-System durchgeführt. Ist der Angriff erfolgreich, werden Informationen über das lokale – also das kompromittierte System – gesammelt, um die erlangten Privilegien zu verifizieren. Sofern durch den Angriff des Ziel-Systems noch nicht die höchsten Zugriffsrechte erlangt wurden, wird versucht diese auszuweiten. Der Angriff wird nach einem Cleanup beendet. Im Cleanup werden alle installierten Agenten entfernt. Ziel ist die Wiederherstellung des Ausgangszustandes vor dem Angriff. Abgeschlossen wird der Prozess mit der Generierung eines ausführlichen Reports. Neben der automatischen Standardkonfiguration besteht die Möglichkeit, per Drag and Drop eigene Prozessfolgen durchzuführen. Allerdings müssen dabei Abhängigkeiten zwischen einzelnen Prozessschritten eingehalten werden. Dabei kann auch auf externe Programme zurückgegriffen werden (z.B. bei Schritt 1).
Je nach Leistung des Systems, auf dem Core Impact ausgeführt wird, können Angriffe parallel ausgeführt werden. Zudem ermöglicht der Scheduler von Core Impact ein detailliertes Planen von Angriffen mit wählbaren Zeitpunkten. Es besteht die Möglichkeit, auch Webanwendungen auf Vulnerabilities zu testen und Phishing E-Mails zu generieren.

Die Exploits, die Core Impact zur Verfügung stellt sind in Python programmiert und können angepasst werden. Hierzu wird eine Python-Schnittstelle bereitgestellt. Die Exploit-Bibliothek von Core Impact wird stetig erweitert und durchschnittlich 10- bis 20-mal im Monat aktualisiert, um neue Vulnerabilities auszunutzen. Das hat zur Folge, dass schon wenige Tage (<= 2 Tage) nach erscheinen einer Vulnerability, ein Exploit für diese bereitgestellt wird.
Zum Suchen dieser Exploits bietet Core Impact eine umfangreiche Exploit-Suchmaschine an. Dabei kann auf bis zu 6 verschiedene Arten gesucht werden, wie in nachfolgender Tabelle zu sehen ist.

Exploits können per Drag and Drop angewendet werden. Core Impact analysiert zuvor das relevante Betriebssystem sowie die Version. Je mehr Informationen über das Ziel-System bekannt sind, desto wahrscheinlicher ist eine erfolgreiche Anwendung des Exploits. Zudem wird eine automatische Wahl der Konfigurationsparameter begünstigt. Eine manuelle Wahl der Konfigurtionsparameter ist ebenfalls möglich.

Einziges Manko an Core Impact ist der exorbitante Preis im Vergleich zu Metasploit, welches kostenlos ist.

Als kleines Kind war ich immer von den Tricks der Zauberer fasziniert, die es schaften ganze Fahrzeuge vor meinen Augen verschwinden zu lassen.
Jahre später war ich immer noch so sehr davon fasziniert, so das es mein Kinderwunsch war, auch selbiges zu vollbringen wie die großen Männer in Frack und Zylinder.
So kam es, das ich mich ein wenig mit der Kunst der Zauberei beschäftigte, wobei zu meinem Bedauern mir keines der damaligen Tricks bis heute erhalten geblieben ist. Dennoch ist mir bewusst, dass sich die Zauberei ein grundlegendes Prinzip zu Nutze macht, welches auch heute in der Informatik vielseitig Einsatz findet.

Dem Verschleiern von Informationen.

Es gibt an sich nur zwei Möglichkeiten Informationen vor anderen zu sichern.

Die erste Möglichkeit besteht darin, die Informationen vor den anderen unzugänglich zu machen - einem Safe in welcher Form auch immer.
Nur eine Person, welche dazu legitimiert ist, darf/kann an die geschützten Informationen gelangen, da diese durch den Safe (kryptographische Mittel) dem anderen verwehrt werden. Jedoch kann ein Angreifer immer noch nach Schwachstellen in der zu schützenden Methode suchen.
Da aber all diese "Schutzmethoden" von Menschenhand gemacht wurden, wird je nach Wert der Informationen bzw. der Ware ein Angreifer zum Schluss kommen, dass das schwächste Glied in der Kette hier der Mensch selber darstellt. Mit entsprechenden Druckmitteln könnte nun der Angreifer denjenigen dazu bringen, die geschützten Information preis zugeben bzw. ihm den Zugang zu diesen zu verschaffen.

Einen ganz anderen Weg geht hier die Zauberei. Durch Illusionen, optische Täuschungen sowie Verschleierung wird versucht die Aufmerksamkeit auf ein anderes Medium zu ziehen. Somit wird von dem zu schützenden Medium abgelenkt.

Mir ist durch aus das Prinzip Security through obscurity oder security by obscurity (engl. „Sicherheit durch Unklarheit“) in der IT-Sicherheit bekannt und ich bin, wie viele andere auch, der Meinung das Sicherheit nicht durch Verschleierung begründet werden sollte (Kerckhoffs’ Prinzip). Denn gerade in der Kryptographie wird davon profitiert, dass viele andere Einblick in den Algorithmus haben können, um mögliche Schwachstellen schnell zu identifizieren. Diese erreichen dann auch meist schnell die Öffentlichkeit und man kann dann als Anwender auf ein anderes Krypto-Verfahren setzen. Ebenso bin ich ein Verfechter der Open Source-Theorie, daher will ich das alles hier auch überhaupt nicht in Frage stellen.

Jedoch kann versucht werden, durch Einsatz von steganographischen Mitteln ein kryptographisches Verfahren zusätzlich zu sichern. Beispielsweise möchte man ein geheimes Treffen vereinbaren und man hat zu befürchten das der Adressat observiert wird. Um dennoch dieses Treffen zu vereinbaren, könnte man ihm eine Nachricht zu kommen lassen, welche auf ein schönes Foto vom letzten Urlaub im Anhang hinweist. In diesem unscheinbaren Urlaubsfoto ist nun eine verschlüsselte Botschaft enthalten.

Die Realisierung einer solchen Hybridlösung könnte unter Linux wie folgt aus sehen:

rsecurity blog # echo "Geheime Botschaft"> secmsg.txt
rsecurity blog # cat secmsg.txt
Geheime Botschaft
rsecurity blog #
rsecurity blog # ls
secmsg.txt  urlaub.jpg
rsecurity blog # gpg -e -r empfaenger -a secmsg.txt
rsecurity blog # ls
secmsg.txt  secmsg.txt.asc  urlaub.jpg
rsecurity blog #
rsecurity blog # sha256sum urlaub.jpg
ab3dccc0a9efc0759a881d06a7eb777d1b5cd2d49af86b7f4460f9b41f683111  urlaub.jpg
rsecurity blog # steghide embed -cf urlaub.jpg -ef secmsg.txt.asc
Passwort eingeben:
Passwort wiederholen:
Bette "secmsg.txt.asc" in "urlaub.jpg" ein... fertig
rsecurity blog # sha256sum urlaub.jpg
9571fd9645e8ed672cad8eca621051618483818a4f27864927f46b069ebc0241  urlaub.jpg
rsecurity blog # rm -f secmsg.txt
rsecurity blog # rm -f secmsg.txt.asc
rsecurity blog # ls
urlaub.jpg
rsecurity blog # file urlaub.jpg
urlaub.jpg: JPEG image data, JFIF standard 1.01
rsecurity blog #

Versenden des Urlaub-Fotos an den Adressaten

Auf Empfänger Seite:
empfaenger mail # ls
urlaub.jpg
empfaenger mail # steghide extract -sf urlaub.jpg
Passwort eingeben:
Extrahierte Daten wurden nach "secmsg.txt.asc" geschrieben.
empfaenger mail # ls
secmsg.txt.asc  urlaub.jpg
empfaenger mail #
empfaenger mail # gpg -d secmsg.txt.asc >secmsg.txt

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "empfaenger "
2048-Bit ELG Schlüssel, ID 170742AF, erzeugt 2008-02-12 (Hauptschlüssel-ID B1395460)
Passphrase:
gpg: verschlüsselt mit 2048-Bit ELG Schlüssel, ID 170742AF, erzeugt 2008-02-12
      "empfaenger "
empfaenger mail # cat secmsg.txt
Geheime Botschaft
empfaenger mail #

Das Beispiel zeigt, wie eine vertrauliche Botschaft in eine Textdatei geschrieben wird. Diese wird anschließend mit GnuPG verschlüsselt (Eine gute Anleitung zum Umgang mit GnuPG gibt es hier). Dabei wird hier der öffentliche Schlüssel des Adressaten verwendet. Mit dem Linux-Tool steghide wird die verschlüsselte Botschaft in das Bild eingebettet. Auffällig sind hier die unterschiedlichen SHA-Hashes der urlaub.jpg vor und nach dem Einbetten. Der Unterschied der Hashes macht deutlich, dass es eine Veränderung in der urlaub.jpg gegeben haben muss, nämlich die verschlüsselte Botschaft. Trotz des Eingriffes in die Datei urlaub.jpg scheint es keine offensichtliche Veränderung des Bildes gegeben haben. Nun wird die das Bild beispielsweise als Anhang an den Adressaten verschickt. Dieser kann nun, sofern er das Passwort kennt, die verschlüsselte Botschaft aus dem Bild extrahieren. Um die vertrauliche Botschaft zu lesen ist es jetzt noch erforderlich, das dieser den Textfile entschlüsselt. Aufgrund der Tatsache, das die Botschaft mit seinem öffentlichen Schlüssel verschlüsselt wurde, kann die Botschaft nur mit seinem privaten Schlüssel entschlüsselt werden. Nach erfolgreicher Eingabe seines Mantras (die Passphrase) hat dieser nun Zugriff auf die vertrauliche Nachricht.

Orginal Bild	Bild mit steganographisch hinzugefügtem Text

Natürlich existieren auch für andere Betriebssystem-Plattformen Anwendungen, die einem das Verwenden von steganographischen Mitteln ermöglichen. So gibt es z.B. für Microsoft Windows stegano oder auch stegano.Net.

Das Beispiel hier konnte natürlich nur sehr oberflächlich das Thema Steganograhpie im Alltag aufzeigen, daher sei auf einen guten Artikel vom FBI aus dem Jahre 2004 hingewiesen, um sich in dem Themengebiet zu vertiefen. Auch auf forensics.nl ist ein umfangreiches Archiv zu diesem Thema vorhanden.

Den großen Vorteil, den ich an solch einer Hybridlösung sehe ist, das die verschlüsselte Nachricht kein Aufsehen erregt, da diese durch die Steganographie, hier im Beispiel in einem Bild, versteckt wird. Dies lässt einen möglichen Dritten erst gar nicht auf dem Gedanken kommen, das der Adressat eine Nachricht erhalten hat.

Somit gelangt unbemerkt eine Nachricht zum Adressaten und selbst wenn die Steganographie enttarnt wird, so bleibt immer noch die verschlüsselte Botschaft, welche entschlüsselt werden müsste.

Gerade das richtige Zusammenspiel beider Verfahren macht es für Dritte gerade zu unmöglich an die zu schützenden Informationen zu gelangen.

Daher sollte man, um ein höst Maß an Sicherheit zu Gewinnen, die Vorteile beider Verfahren nutzen.

Das man mittels Iptables mächtige Firewall-Regeln aufstellen kann ist keine neue Sache und den meisten Administratoren auch bekannt. Doch Iptables steckt voller Überraschungen, so kann man bei ausgehenden Paketen neben den Protokoll spezifischen Eigenschaften (bei TCP wären es z.B. Quell-Port/-Adresse sowie Ziel-Port/-Adresse, TTL, FLAG, etc.) auch die User-ID(UID), die Group-ID(GID), die Process-ID(PID) sowie die Session-ID(SID) des Programms von dem das Paket stammt prüfen und Regeln dem entsprechend aufstellen.

Die Technik, die sich dahinter verbirgt wird als Owner-Match bezeichnet. Wie oben schon erwähnt greift der Owner-Match nur bei ausgehenden Pakete, welche man selber erzeugt hat, genauer nur in der OUTPUT-Kette.
Neben den oben genannten Features von Iptables, bieten neue Versionen von Iptables auch die Möglichkeit Filter auf dem Kommandonamen anzuwenden.

Die Optionen die der Owner-Match zur Verfügung stellt, sind in nachfolgender Tabelle aufgelistet:

Es sei noch darauf Hingewiesen, das die letzten drei Optionen (<pid>,<sid>,<cmd>) auf Symmetrischen Multiprozessorsystemen (kurz SMP) defekt sind und somit dort nicht laufen.

Nun sehen wir uns noch ein paar weitere praktische Beispiele des Owner-Matches an, die uns bei der täglichen Arbeit helfen sollen. Als Szenario sei die Situation gegeben, das man einen Terminalserver mit vielen verschiedenen Benutzern betreibt und nur bestimmten Benutzern der Verbindungsaufbau ins WAN (z.B. dem Internet) erlaubt werden soll. Durch den Owner-Match hat man die Möglichkeit jeden einzelnen Benutzer mittels der User-ID den Zugriffs ins WAN zu erlauben (-j ACCEPT) oder zu verwehren (-J REJECT):

Nehmen wir an, das der Benutzer mit der User-ID 314 Herr Müller ist und der Benutzer mit der User-ID 315 der Herr Maier. So wie die Regeln jetzt oben zu sehen sind, darf nur Herr Maier Verbindungen ins WAN aufbauen und führen. Herr Müller hingegen wird der Zugriff ins WAN verwehrt. Wenn man nun Herrn Maiers seine Verbindungen noch weiter einschränken möchte, z.B. das er nur noch im Internet mit dem Browser Firefox surfen darf, so kann man sich die Fähigkeiten des cmd-owner-Matches zu nutze machen:

Mit dieser Abänderung kann Herr Maier nur noch mit dem Browser Firefox TCP-Verbindungen auf den Port 80 (HTTP) sowie 443 (HTTPS) aufbauen. Nicht berücksichtigt sind hier DNS wie auch andere Kleinigkeiten, die hier aber auch nicht zur Diskussion stehen.

Hinweis:

Auch wenn der obige Ansatz auf dem ersten Blick relativ sicher aussieht, so kann man den Abgleich des Kommandonamens sehr einfach unterlaufen:

Diese einfache Kopie von netcat, ermöglicht es Herrn Maier, es für Iptables so aussehen zu lassen, als würde er wie in seiner Richtlinie festgelegt, mit Firefox surfen, doch in Wirklichkeit öffnet er einen externen Angreifer einen Zugang ins interne Netz. Der Grund wieso hier der Owner-Match (genauer der cmd-owner-Match) nicht greift liegt daran, das nur der Kommandonamen überprüft wird und dieser bleibt ja bestehen. Abhilfe schaffen hier nur genauer Restriktionen auf Dateisystemebene sowie das Verwenden der PID oder SID. Allerdings muss man bei Programmen, welche nicht als Daemon (Server-Dienst) fungieren wohl eher auf Restriktionen auf Dateisystemebene zurückgreifen, da sich PID wie auch SID beim Neustarten des Programms nicht immer gleich sein muss. Ein Beispiel für die Verwendung von der SID ist folgende:

Diese einfache Befehlsfolge, welche den Verbindungsaufbau des Apache-Webservers unterbindet (um z.B. Reverse Verbindungen wie CGI Reverse Shells zu verhindern), kann man noch ein wenig verfeinern bzw. restriktiver setzen:

Jetzt findet nicht nur der Abgleich auf die Session-ID statt, sondern auch noch zusätzlich auf die User-ID.

Wie man sieht, ist der Owner-Match von Iptables eine praktische wie auch mächtige Option, um ausgehende Pakete sehr detailliert zu filtern.