Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

Header einen buffer overflow in einem anderen Programm verursachen. Dämonen sollten
stets nach dem KISS Prinzip programmiert werden (Keep It Small and Simple). Einige
Hersteller, wie z.B. Microsoft sind weit davon entfernt, überhaupt noch einen Überblick
über den Quellcode zu haben.
Wie werden buffer overflows entdeckt?
Entweder man durchforstet systematisch den Quellcode eines Dämons, untersucht den
Quellcode von Libraries (DLL´s), oder man bemüht den Boundschecker (NUMEGA).
Dieser arbeitet wie ein logischer Disassembler und vermag Zusammenhänge von
übergebenen Parametern und Funktionsaufrufen in den DLL´s zu erkennen.
Dementsprechend gibt dieser Warnhinweise aus, wo sich ein Test lohnen könnte. Bei
Microsoft sind es unzählige, es ist also zu erwarten, das Microsoft-Server zunehmend das
Ziel von solchen Angriffen sein werden. So einfache Tests mit Zufallszahlen, die man an
einen Port sendet (cat < dev/random | netcat IP - Nummer....Port) führen schon zu
interessanten Effekten (Schutzverletzung....Bluescreen). Ist es möglich, bei einem Dienst
oder Dämon die nach außen (über das Netzwerk) verfügbaren Befehle und deren Syntax
zu ermitteln, so ist es mit netcat möglich, die Befehle einzeln auf buffer overflows zu
testen. Das läßt sich auch per Hand durchführen (telnet_IP - Nummer_25 ... HELP), nur
besteht das Risiko, daß in dieser Hilfefunktion nicht alle Befehle aufgelistet sind. Man
benötigt daher immer auch den Quellcode. Daraus resultiert, daß man sehr wohl einen
Server sicher machen kann, vorausgesetzt, daß die Befehle übersichtlich sind, der
Dämon/Dienst nicht zu komplex und das der Quellcode vorliegt. Aus diesem Grund
scheiden viele Betriebssysteme für den mission critical Einsatz aus.
Buffer overflows in Client Programmen, dynamische Angriffe
Bisher wurden nur »buffer overflows« in Servern entdeckt. Seit einiger Zeit werden
zunehmend Clientprogramme auf »buffer overflows« untersucht. Ein Beispiel ist ein (GNU)
ftp - Client unter UNIX. Angenommen, daß ein Unternehmen besonders sicher gegen
Angreifer aus dem Internet abgesichert werden soll. Man installiert die Internet-Firewall so,
daß kein Port eines internen Servers von außerhalb erreicht werden kann. Um aber z.B.
weiterhin E-Mails in dem Unternehmen empfangen zu können, wird ein Programm, z.B
»vpop« unter Windows NT oder »fetchmail« unter UNIX installiert. Diese Software öffnet,
z.B. stündlich tagsüber, die Verbindung über die Firewall hinweg zu einem äußeren
Server, der die E-Mails für das Unternehmen in einem Sammelpostfach gelagert hat.
Vorausgesetzt, daß der Angreifer auf diesem Außenserver auf die Clientverbindung
wartet, ist es ihm möglich, einen »buffer overflow« auf einem Server hinter der Firewall zu
iniitieren, einen Tunnel von diesem in das Internet aufzubauen, und in aller Ruhe im
Unternehmensnetz sein Unwesen zu treiben. Dagegen helfen dieselben Mechanismen,
die auch zur Verbesserung der Sicherheit der Serverdämonen eingesetzt werden. Unter
NT bedarf es einer gründlichen Analyse des Betriebssystems, was ohne Quellcodes leider
nicht möglich ist. Unter UNIX ist die Lösung klar.
Sind Firewalls gegen »buffer overflows« gesichert ?
Man kann davon ausgehen, daß die Firewall-Programme, weil sie relativ klein sind, gut
gesichert werden können. Ein Angriff auf das äußere oder innere Interface ist so einfach
nicht möglich, da sich keine Angriffspunkte ergeben, wo ein »buffer overflow« ansetzten
könnte. Für eine Authentifizierung aber müssen Paßworte übergeben werden, hier ist ein
»buffer overflow« möglich. Problematisch wird es, wenn eine Firewall auf einem
Betriebssystem aufsetzt, welches zudem noch andere Funktionen erfüllen soll, z.B als E-
Mail-Gateway, WWW-Proxy, u.s.w. Diese Konfigurationen finden sich in vielen
Unternehmen, wo billige PROXY-Software auf NT oder UNIX-Servern aufgesetzt wird.
Oftmals ist in diese Server eine ISDN-Karte integriert, um zusätzlich Hardware
einzusparen. Da diese Server gleichzeitig noch als SQL oder FIBU-Datenbanken arbeiten
können, ergeben sich einige sehr bedenkliche Sicherheitslöcher. Da es auch keine
weiteren Kontrollmöglichkeiten gibt, bleibt ein Angriff immer unbemerkt. Betrachten wir
einige Installationen:
Erstellt von Doc Gonzo - http://kickme.to/plugins