![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Themen
Buffer overflows gehören mit zu den gefährlichsten Angriffen überhaupt. Betroffen sind vornehmlich Internet-Server (WWW), DIAL-IN Router, PROXY-Caches, Newsserver, Mailserver, FAX-Server, SQL-Server, SSL-Server und viele Sicherheitsprogramme, wie z.B. PPTP, SSH.... Zunehmend benutzen Angreifer buffer overflows auf Angriffe von Servern in Unternehmen.
Grund sind mangelhafte Längenabfragen bei den an ein Programm übergebenen Daten. Hat ein Programm eine bestimmte Anzahl von Bytes für z.B. die Annahme eines Paßwortes oder einer URL (http://www.xyz.de/index.asp?Name=text.....) reserviert, so führt die Übergabe eines überlangen Strings zu einer Schutzverletzung in der Speicherverwaltung des Servers/Clients. Ein Angreifer übergibt dann als String Daten, die mit NOP Befehlen (No Operation) beginnen, und danach ein paar Byte zum Aufruf eines Programms (z.B format c:) enthalten. Dieser String überschreibt dann im Speicher andere Programmteile, die dann evtl. nicht mehr funktionieren. Da ein Server jedoch gewöhnlich viele unwichtige Programmroutinen im RAM hält, die wenig oder nie gebraucht werden, fällt dieser Angriff zunächst nicht auf. Irgendwann springt der IP (Instruction Pointer) eines Programms in diejenige Routine, die von dem buffer overflow überschrieben wurde. Da die genaue Adresse meist unbekannt ist, wurden mit einigen hundert oder tausend NOP dafür gesorgt, daß der IP an jeder Adresse einspringen kann. Danach trifft er unweigerlich auf das eingeschleuste Programm und führt es aus.
Im Internet finden sich hunderte von vorgefertigten Programmen, auch »exploits« genannt, die diese Fehler in Betriebssystemen ausnutzen. Security Scanner fragen auf dem Betriebssystem Versionsnummern ab und warnen, falls ein Problem bekanntgeworden ist.
Das bedeutet, daß Security Scanner nicht die Sicherheit eines Betriebssystems testen, sondern nur darauf, ob ein bereits bekannter exploit an diesem Server/Programm Schaden anrichten könnte. Security Scanner testen allerdings noch viele zusätzliche Dinge, vornehmlich bekannte Konfigurationsfehler, die natürlich immer sehr betriebssystemspezifisch sind. Unbekannte »exploits« können Security-Scanner nicht testen.
Genaue Recherchen haben aber gezeigt, daß oft schon bis 6 Monate vor dem Erscheinen eines exploits Gerüchte über einen möglichen buffer overflow auf einem Betriebssystemen, Router, u.s.w in NEWSGROUPS aufgetaucht sind (www.dejanews.com).
Es sind aber auch schon Fälle bekanntgeworden, wo buffer overflow Angriffe aus der ehemaligen SU erfolgreich waren, die erst ca. 2 Jahre später in den Mailing-Listen von BUGTRAQ aufgedeckt wurden.
Fleißiges Mitlesen der Listen und einspielen von Sicherheits-Patches hilft nur und ausschließlich gegen den MOB, der sich im Internet breitmacht und exploits testet, gegen professionelle Angreifer müssen sichere Betriebssysteme und Filter eingesetzt werden.
Es gibt nur 2 Betriebssysteme, die erwiesenermaßen gegen einen solchen Angriff schützen können. Solaris 2.6/2.7 und SecureLINUX (Canary Stackguard / MemGuard). In Solaris 2.6+ muß hierzu, geht man von einer »normalen« Installation aus, erst ein Schalter aktiviert werden, der verhindert, daß Programme in »stack« und »heap« ausgeführt werden können (noexec_user_stack, noexec_user_heap).
Danach sind alle von SOLARIS mitgelieferten Programme, die zumindest ohne besondere Privilegien gestartet sind, nicht mehr gefährdet. SecureLINUX erfordert einen Patch im Standard - Kernel und den Einsatz eines speziell angepaßten Compilers mit welchem alle Programme neu kompiliert werden müssen.
Im Gegensatz zu SOLARIS ist es so mit LINUX möglich, alle Programme, die im Quellcode vorliegen, gegen alle bekannte und noch unbekannten »buffer overflows« abzusichern, das bedeutet auch, daß SQL-Server, WWW-Server......gesichert werden können. Unter SOLARIS sind alle Programme von Zulieferern nicht gegen diese Angriffe gesichert. Solange SUN nicht die Quellcodes des Compilers, Programme und Kernel veröffentlicht, haben andere Hersteller auch keine Möglichkeit, Ihre Programme entsprechend zu sichern.
Schaut man sich die Struktur aller im Internet veröffentlichten expoits einmal genauer an, so wird man feststellen, daß fast alle zu einer "rootshell" führen. Erkennbar ist das daran, daß irgendwo im Quellcode "/bin/csh" oder ähnliche Shells gestartet werden. Wenn man einfach alle Shells umbenennt und dazu noch in der /etc/passwd die Namen entsprechend ändert, so hat man zumindest die Möglichkeit, einen buffer overflow direkt scheitern zu lassen. Ersetzt man csh durch einen Befehl, wie "mail -s "Angriff!!!!" user@domain", so wird man automatisch via E-Mail informiert, wenn ein "buffer overflow" stattfindet. In der Praxis hilft dies zumindest, einen Angriff stark zu verzögern, da der Angreifer erst einmal eine Alternative ausknoblen muß. Im Grunde kann man ein freies UNIX, zu dem man die Quellcodes besitzt völlig umkrempeln - "root" wird zu "toor", u.s.w. Mit einem einfachen Befehl "find /usr/src/ -name "*" -print -exec sed s/.....{} \" kann man den kompletten Quellcode von z.B. FreeBSD umkrempeln, und mit "make world" neu kompilieren. Da ein Angreifer stets gewisse Konventionen bei der Namensgebung von Usern, Gruppen und Files erwartet, ist diese Variante doch relativ erfolgreich, und hält zumindest einige Zeit stand, um den Angriff bemerken zu können. Generell gilt: Je mehr die Konfiguration vom Standard abweicht, um so schwieriger hat es ein Angreifer. Toor findet man übrigens nach einem Angriff mit einem bestimmten Toolkit in der Datei /etc/passwd
Besonders erwähnenswert sind die Programmierer von OpenBSD, die in jahrelanger Arbeit »code review« »tausende!« von solchen fehlenden »Längenabfragen« in die Standardprogramme von OpenBSD eingebaut haben. Hierzu sind aber Änderungen im Quellcode der Programme und des Kernels notwendig gewesen.
OpenBSD ist binärkompatibel zu BSDI, FreeBSD, NetBSD, LINUX und auch SOLARIS Programmen. Da bedeutet aber nicht, daß die Anwendungsprogramme auf »buffer overflows« überprüft wurden. Leider kann der »code review« nicht eine 100%ige Sicherheit vor diesen Angriffen garantieren, OpenBSD gehört aber zu denjenigen Betriebssystemen, die äußerst stabil ohne große Probleme durch Angreifer laufen, genauso wie SOLARIS 2.5, 2.6, 2.7.
SUN hat aufgrund der langen Internet-Tradition inzwischen erhebliche Mühen in eigene »code reviews« gesteckt. Das zahlt sich aus. FreeBSD und NetBSD sind ebenfalls als relativ sicher zu betrachten, da diese ebenfalls von dem »code review« bei OpenBSD profitiert haben. Die kommerzielle Version der BSD-Betriebssysteme, BSDI konnte ebenso davon profitieren, sodaß man sagen kann, alle BSD-Varianten sind inzwischen weitestgehend »bullet proof«. Es gibt zwar auch Ausnahmen, die sind aber relativ selten. Aus diesem Grund setzen ausnahmslos große Content-Anbieter (Yahoo, HotMail, Netscape, ftp.cdrom.com, tucows.com.....) BSD 4.4 UNIX oder Solaris ein.
LINUX hat inzwischen alle Negativ-Rekorde gebrochen. Die größte Anzahl aller Exploits sind auf LINUX für LINUX geschrieben worden, ein Tribut an die große Verbreitung und die rasanten Entwicklungsfortschritte. Es gibt aber erhebliche Unterschiede bei den Distributionen. Während RedHat viel Wert auf schnell verfügbare Patches legt, und dort, wo es geht, BSD-Dämonen einsetzt (qpop exploit unter RedHat 5.0+ war nicht anwendbar, unter S.u.S.E. - 5.3 LINUX schon), legt S.u.S.E. erheblich mehr Aufwand in die Funktionalität, insbesondere von ISDN. Security Patches werden von S.u.S.E. oft erst ein paar Tage nach RedHat bereitgestellt. Grundsätzlich sind die Unterschiede zwischen allen Distributionen aber eher klein. Ein großer Vorteil von LINUX ist, daß schon wenige Stunden nach der Meldung eines Sicherheitsproblems (PING ´o Death: 30 Minuten) die Fehlerkorrektur im Internet verfügbar ist. Auch das ist Rekord. Insbesondere ISP´s leiden unter diesen Angriffen auf LINUX. Angesichts der schnellen Verfügbarkeit von Patches ist der Einsatz von LINUX im Internet noch zu rechtfertigen, gewissenhafte Pflege vorausgesetzt.
Schwieriger wird die Aussage bei Windows NT 4.0. Windows NT hat eine Unzahl von Fehlern, die von Microsoft erst nach Monaten korrigiert wurden, speziell aber funktionierende »exploits« sind allerdings selten. Windows NT fällt auch noch mit SP5 diversen DoS Angriffen zum Opfer. Viele "Lamer" (so werden Hacker bezeichnet, die mit vorgefertigten Werkzeugen Das liegt zum einen daran, daß Angreifer NT-Server in der Vergangenheit durch den sehr schlechten, instabilen TCP/IP-Stack einfach stillegen konnten und sich damit zufrieden gaben. Das betrifft vor allem eine Unzahl von »Lamern«, so werden Hacker genannt, die die »exploits« anderer nur anwenden und sich toll dabei fühlen. Andererseits besitzt NT soviele Fehler, daß es oft keiner buffer overflows bedarf, um die Festplatte eines Internet-Servers einzusehen. »buffer overflows« für NT zu schreiben, ist allerdings kein größeres Problem, als einen für LINUX oder andere Betriebssysteme zu schreiben, wie l0pht gezeigt hat. Was das ganze für einen »echten« Angreifer schwieriger macht, ist, daß Microsoft so viele verschiedene Varianten von NT 4.0 im Umlauf hat, daß es eine längere Zeit dauert, bis man die korrekte Version des Betriebssystems und die richtigen Programme installiert hat, um einen exploit schreiben zu können. Geringe Abweichungen schon können verhindern, daß ein exploit gleichermaßen auf allen Servern anwendbar ist. Ein professioneller Angreifer wird sich den Server möglichst bis auf das I-Tüpfelchen genau nachbauen, den berühmten SoftIce-Debugger benutzen, um mangelhafte Längenabfragen ausfindig zu machen. SoftIce ist ein hervorragendes Werkzeug, um professionell in Binary-Code nach speziell solchen Problemen zu suchen. Windows NT DLL´s strotzen geradezu vor Warnmeldungen des Debuggers, die einen möglichen »buffer overflow« anzeigen. Bis ein Security- Patch für die einzelnen Sprachversionen vorliegen, kann bei Microsoft durchaus ein Jahr vergangen sein. (SYN-flood und SP4)
HP UNIX hat aufgrund der eigenen CPU und der geringen Verbreitung wenig zu fürchten, im Grunde gilt aber dasselbe, wie für NT. Highlight ist die Geschwindgkeit, mit der HP auf Sicherhheitsprobleme reagiert. Es wurden Sicherheitskorrekturen für den Mailer-Dämon an die Kunden verteilt, obwohl für diese gepatchte Version schon wieder Informationen über neue Sicherheitslöcher vorlagen. Weitere Kommentare überflüssig.
Jede Übergabe von Daten an irgendeinen Dienst (Dämon) eines Betriebssystems muß überprüft werden. Das erfordert genaue Detailkenntnisse über Befehle, Befehlsparameter und maximale Länge. Man sollte sich also genau überlegen, welche Befehle eines welchen Dämons/Dienstes gebraucht werden. Danach müssen Syntax der Befehle und sinnvolle und sinnlose Kombinationen aus Befehlen ermittelt werden. Im Anschluß daran muß man die Längen der Übergabeparameter ermitteln, die z.T. von Datenbankinhalten oder Längen von Dateinamen abhängen können. Nun kann man mit z.B. PERL oder JAVA einen geeigneten Filter schreiben. PERL eignet sich hervorragend zur Erstellung von Filtern, sofern es im »tainted mode« gestartet wird. In diesem Modus werden alle Variablen, die Daten von »außen« übergeben bekommen, als »verdorben« markiert. Übergibt man Parameter von »verdorbenen« Variablen an Programme oder Betriebssystemroutinen, so werden diese nicht ausgeführt. Ein sinnvoller Schutz. Daüber hinaus ist PERL eine interpretierte Sprache, die selber keine »buffer overflows« kennt, da es keine Längenbegrenzung bei Variablen gibt. Alle Speicheranforderungen für Variablen erfolgen dynamisch. JAVA ist ebenfalls eine Interpreter-Programmiersprache, die so designt wurde, daß alle Operationen völlig vom Betriebssystem abgeschirmt werden können.(SANDBOX) Versuche mit C, C++ oder Visual Basic sind mit Vorsicht zu betrachten, schließlich kann der Filter auch Angriffsziel sein, wenn auch nicht für einen funktionierenden »exploit«, aber in den meisten Fällen reicht es dann für einen DoS Angriff aus. Es ist also erhöhte Vorsicht beim Programmieren eines solchen Filters geboten. Überlegenswert ist es, ob man dedizierte Hardware hierfür einsetzt und diese mit Firewalls noch einmal sichert. Alternativ kann man auch einen Dämon/Dienst einsetzen, dessen Fehler stets veröffentlicht werden, sodaß man präventiv stets die neuesten Patches einspielen kann. Eine Garantie kann prinzipiell nur bei Software gegeben werden, die auch im Quellcode verfügbar und somit überprüfbar ist. Einige Hersteller haben die Neigung, nur dann Fehler zu korrigieren oder zuzugeben, wenn sie massiv damit konfrontiert werden. Hierzu gehört insbesondere Microsoft. Auch dann ist es noch eine Frage, wann die Fehler korrigiert werden. Eine Konsequenz daraus hat IBM gezogen. IBM supportet nun offiziell z.B. den Apache WWW-Server, der u.a. auch in LINUX und BSD-UNIX eingesetzt wird. Die Netfinity-Serie wird im Prinzip mit vielen LINUX Softwarekomponenten ausgeliefert (GNU Software). Hersteller, wie HP, DEC u.s.w. setzen diese Software auch ein. Software, die Datenströme filtern kann, gibt es in großer Zahl. Sie unterscheiden sich erheblich in Qualität und Funktionalität. Sie sind zumeist in PERL oder in JAVA geschrieben. Fast alle sind im Quellcode verfügbar, aus nachvollziehbaren Gründen. Einige Firewalls haben Filtersprachen eingebaut, es muß aber vorher abgeklärt werden, ob diese für alle Dienste anwendbar sind. Application level Gateways (PROXY´s) besitzen manchmal nur minimale Filtermöglichkeiten, die nur einzelne Befehle einiger Dienste (www,ftp..) filtern können. Es sollte unbedingt darauf geachtet werden, daß diese Filter sowohl die Befehlssyntax, als auch die Länge der übergebenen Parameter filtern können. Nur beide Eigenschaften zusammen können ausreichend Schutz gegen »buffer overflows« bieten. SUN geht andere Wege und ersetzt successive alle Dämonen unter UNIX durch deren JAVA Pendants. Diese Konzeption ist so vielversprechend, daß es auch eine größere Zahl von freien JAVA Dämonen gibt, die teilweise Filtermöglichkeiten direkt eingebaut haben, und so in der Lage sind, auch SQL-Server zu sichern. (Jigsaw)
Völlig neu mag der Hinweis erscheinen, bei Servern, die sensible Daten hosten, eine nicht übliche CPU einzusetzen. Viele Angriffe könne sogar von Laien mittels fertiger Angriffswerkzeuge aus dem Internet ausgeführt werden. Diese finden sich zumeist in Form von "buffer/heap overflows" schon fertig kompiliert für INTEL/ ALPHA/ SPARC-Prozessoren auf einschlägig bekannten Servern. Nur wenige Personen jedoch verfügen über die nötigen Kenntnisse, einen "buffer overflow" derjenigen Art, wie sie monatlich zu dutzenden verbreitet werden, auf andere Prozessoren, z.B. ARM, MIPS o.ä. zu portieren. Hierzu sind weitreichende Assemblerkenntnisse und Praxis im Umgang mit Debuggern notwendig. Kommt z.B. NetBSD oder LINUX auf ARM-Prozessoren zum Einsatz, so ist das Risiko, daß ein Angriff direkt beim ersten Versuch zum Erfolg führt, äußerst gering. Der Angreifer benötigt dann mehrere Versuche, um erfolgreich zu sein, was das Risiko der Entdeckung stark erhöht. Auch sollten in einer Kaskade von Firewalls niemals dieselben Prozessoren zum Einsatz kommen. Dasselbe trifft auch auf die (fast noch wichtigeren) Log-Server zu, da ohne diese "Dokumente" ein Einbruch nicht bemerkt werden kann.
Wrapper, wie sie unter UNIX häufig eingesetzt werden, installieren sich zwischen Kernel und Dämonen. Hauptgrund ist, daß unter BSD-UNIX Ports unterhalb von 1024 als »priviligierte Ports« definiert wurden, und alle Dämonen mit Supervisor-Rechten starten mußten. Vielfach wurden diese Restriktionen aufgeweicht, und inzwischen ist es möglich, daß Dämonen mit minimalen Rechten als User auf den privilegierten Ports laufen. Wrapper können den Zugriff für bestimmte IP - Nummern sperren, und Dämonen mit Userrechten starten. Betrachtet man z.B den »smapd«, einem Wrapper aus dem TIS FWTK, der sich zwischen Kernel und Mailerdämon setzt, so basiert dieser auf einem klaren Konzept: Der »smapd« läuft zwar mit Administratorrechten, ist aber so klein und übersichtlich, daß es möglich war, diesen sicher zu programmieren. Er nimmt die Daten entgegen und leitet diese an einen Mailer-Dämon weiter, der dann »nur« mit minimalen Rechten läuft. Gelingt einem Angreifer ein »buffer overflow«, so ist es möglich, daß Programme mit minimalen Userrechten gestartet werden. Man geht dabei davon aus, daß ein User auf einem UNIX-Betriebssystem keinen Schaden anrichten kann. Auch ist das Starten eines Netzwerksniffers mit Userrechten nicht so einfach möglich, da hierzu Zugriff auf RAW SOCKETS erforderlich ist. Diese Möglichkeit ist aber nur dem »root« User zugestanden. Nun lehrte die Erfahrung, daß es sehr wohl möglich ist, mit Tricks sich vom User zum Superuser zu befördern. Das gelingt durch Ausnutzung einiger der vielen internen Fehler von UNIX. Kein Hersteller hat es inzwischen geschafft, diese Probleme zuverlässig in den Griff zu bekommen. Die chroot() Umgebung begrenzt Dateizugriffsrechte auf ein Unterverzeichnis. Der Zugriff auf übergeordnete Verzeichnisse bleibt verwehrt. So erhoffte man sich, daß wenn ein Dämon, der mit minimalen Userrechten in einer »chroot()« Umgebung gestartet wird, daß ein Angreifer höchstens in einem begrenzten Bereich und mit minimalen Rechten sein Unwesen treiben kann. Diese Maßnahmen haben sich hervorragend bewährt, und halten die allermeisten erfahrenen Angreifer schon fern. Einige findige Experten haben auch dagegen ein Mittel gefunden: Sie kopieren den Befehl »mknod«, »mkfifo« und »mount« in die »chroot()« Umgebung hinein, legen das Device, z.B. /dev/kmem an, welches der aktiven Festplatte entspricht und »mounten« dieses. Dieses ist das RUNTIME- Abbild des Systemkernels in das Filesystem eingeblendet. Mit einem Editor und Suchfunktionen kann man so nach unverschlüsselten Paßworten im gesamten RAM-Bereich suchen lassen. Dieser Trick funktioniert neben UNIX auch unter NT. In anderen Fällen war es möglich, bestimmte Dämonen durch einen DoS Angriff »abzuschießen« und statt dessen ihren eigenen zu starten, der Paßworte genau dann entführt, wenn jemand mit gültigem Paßwort sich authentifiziert. Mit diesen können sich Angreifer von außerhalb normal einloggen. Es soll aber nicht verschwiegen werden, daß diese Tricks nur unter LINUX gut dokumentiert sind. Entscheidend für die Wirksamkeit dieser Maßnahmen sind die Sicherheitsmechanismen des Kernels, und hier gibt es gravierende Unterschiede. FreeBSD, OpenBSD und NetBSD besitzen (in den neuesten Versionen) einen äußerst restriktiven Sicherheitsmechanismus. So können z.B. einfache User niemals Supervisorrechte erlangen. Es ist auch nicht selbstverständlich, daß ein Administrator-Account beliebig Zugriff auf Logfiles hat. Erreicht wurde dieses u.a. dadurch, daß erweiterte Rechte eingeführt wurden, z.B »append only« - Files. D.h auch wenn jemand Administrator - Rechte besitzt, kann er niemals Logfiles verändern, oder Paßworte verändern. Er könnte jedoch ohne Probleme weitere Accounts hinzufügen, jedoch keine löschen. Ohne diese Sicherheits -Mechanismen ist ein Dämon, der in einer chroot() Umgebung und mit nur minimalen Userrechten läuft, ein Sicherheitsrisiko. Das betrifft insbesondere LINUX - Server. Bei anderen Betriebssystemen sind diese Eigenschaften in den jeweiligen »trusted« Varianten der Betriebssysteme bekannt (Trusted Solaris, Trusted Xenix....) Diese verfügen neben diesen Eigenschaften auch über erweiterte Logging-Funktionen. Unter NT 3.50 (nicht 3.51 oder 4.0) existiert eine C2-Zertifizierung. Diese hat keinen Aussagewert bezüglich möglicher »buffer overflows«
Genaugenommen liegt es an der Sorgfalt der Programmierer, überlange Strings bei der Übergabe von Daten heraus zu filtern. Man darf aber nicht vergessen, daß schon ein einfacher Dienst (pop3) eine größere Zahl von Befehlen unterstützt. Die veröffentlichten exploits beziehen sich immer nur auf einen Befehl. Wie bei dem qpopper passiert, wurde kurz nachdem QUALCOMM das Problem beseitigt hatte, ein neuer exploit veröffentlicht. Es ist unbedingt damit zu rechnen, daß stets neue buffer overflows entdeckt werden. Da einige Dämonen auch Informationen an andere weiterleiten (DNS oder POP3 an MAILSERVER), so ist es auch möglich, daß eingeschleuste Informationen, z.B. im Mail-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.
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.
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.
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:
SUN Solaris 2.6 kann man als relativ stabiles, aber keinesfalls als sicheres Betriebssystem bezeichnen. Die Firewall ist ein bewährtes Produkt und installiert sich zwischen Kernel und Anwendungsprogramme. Mitgeliefert ist HAYSTACK Software, die z.B. Zugriffe auf den Server protokolliert und entsprechend der Uhrzeit auch einzelnen Usern den Zugriff verbieten kann. Da aber ein Angreifer auch tagsüber angreifen kann, ist dieses Werkzeug nicht als Sicherung geeignet. Beschreiben wir also eine Standard-Installation von Solaris 2.6 mit Firewall 1st , mit Netscpe SuitSpot 3.5 und SUN Netra-I, einem Administrationswerkzeug, bestehend aus einer Sammlung von CGI-Skripten. Eingesetzt werden soll dieser Server in Verbindung mit einem CISCO Router zur Anbindung an das Internet, als PROXY-Cache, als WWW-Server nach außen und als Intranet-Server nach innen. Abgesichert ist dieser durch Firewall 1st, installiert auf dem »bastion host« selber. Als weitere Software wird Netscape SUITSPOT Pro, einer Sammlung von WWW-Server, Mailserver, NEWS-Server, Kalender-Server, Netscape Cache-Server installiert, erreichbar von innen und außen. Der Netscape Enterprise-Server basierend auf dem Code von Apache-Server und der Netscape Proxy ist identisch mit dem SQUID-PROXY-Cache. Über Netra-I lassen sich diese Dämonen (weniger komfortabel) konfigurieren. Netra-I besteht aus einfachen CSH CGI-Skripten ohne jedwelche Absicherung, die unter UNIX entsprechend der Bedeutung geboten wäre (chroot(), UserAccount). Es sind ohne weiteres »buffer overflows« ausführbar. Angesichts der bekannten »buffer overflows« für den Apache-Server und der Lücken in SQUID ist dies ein gravierendes Sicherheitsproblem. Solaris 2.6 ist per default nicht so eingestellt, daß »stack/heap execution« untersagt ist, ein weiteres Problem, welches zudem schlecht dokumentiert ist. Die Firewall kann auch den Zugriff von außerhalb auf Dämonen des Servers erlauben, was schwerwiegende Folgen haben kann. Mit einem »buffer overflow« ist somit ein Angreifer in der Lage, die Firewall in »nichts« aufzulösen. Weitere Angriffpunkte ergeben sich durch eingeschleuste Attachments an E-Mail, die direkt bekannte »buffer overflows« gegen gestartete Dämonen auf der Firewall ausführen. Insgesamt ist es sogar einem erfahrenen Systemadministrator nicht zuzutrauen, das Betriebssystem dieser Firewall genügend abzusichern, angesichts der schlechten Dokumentation, unsicheren Defaulteinstellungen und fehlenden Warnhinweisen der Firewall selber. Für SUN als Träger der Firewall spricht nur die Qualität der Software, die Stabilität und Leistungsfähigkeit des Betriebssystems und die Tatsache, daß man dieses System sicher machen kann, mit entsprechender Vorbildung und Erfahrung im »cracken« von UNIX, aber wer hat die schon. Schließlich muß die Sicherheit ja auch nachgewiesen werden können.........bzw. die Unsicherheit der Default-Installationseinstellungen. Insgesamt ist das Konzept eines »bastion hosts« der sich selber durch die Firewall sichert, äußerst fragwürdig.
Zahlreiche kleinere Unternehmen besitzen Windows NT 4.0 Server. Installiert sind Fakturierungsprogramme für Windows Clients. Aus Sparsamkeitsgründen wurde in den Windows NT-Server eine ISDN-Karte installiert und WinGate/MS-PROXY als PROXY-Server installiert. Ein E-Mail-Server holt zeitgesteuert E-Mails von draußen herein und zur Auslieferung bereit liegende werden simultan ausgeliefert. Ein Portscan ergibt, daß Ports des PROXY´s nach außen hin geöffnet sind. Eine Recherche im Internet ergibt, daß ein »buffer overflow« existiert und zudem der PROXY keine Absicherung gegen »spoofing« hat. Ein Angreifer, der genügend nahe (bis auf wenige Hops) an den DIAL-IN- Router herankommt, um diesem beim Abholen seiner E-Mail gespoofte Pakete zuzusenden, ist so in der Lage, jeden beliebigen Server innerhalb des Netzwerkes zu erreichen, durch den PROXY hindurch. Ein »buffer overflow« wäre leicht möglich, aber wenn es schon »spoofing« tut. Mit »gespooften« Paketen ist es einem Angreifer möglich, interne IP-Adressen durch das äußere Gateway in das Netz hinein zu schicken, vorausgesetzt, daß er nahe genug an den DIAL-IN Router herankommt. Gespoofte Pakete werden normalerweise von Providern nicht weitergeleitet. So kann er z.B den Microsoft PROXY, Wingate o.ä. durchtunneln, und im Unternehmen großen Schaden anrichten (ein bekannter Fehler). Die Bezeichnung PROXY für diese Software ist gerechtfertigt, jedoch fehlen die wesentlichen Eigenschaften eines Firewall-Routers. Theoretisch ist es möglich, die PROXY´s unter NT so einzurichten, daß ein solcher Angriff nicht möglich ist. Wird dieser PROXY von einem Nicht-Fachmann für Security installiert, sind Einbrüche nicht zu verhindern. Diese Server sind fast nicht gegen viele Arten von DoS Angriffen zu sichern und auch für »buffer overflows« empfänglich. Es gibt zahlreiche Anbieter von PROXY-Firewalls für Windows 95/98 oder NT 4.0. Alle setzen auf dem TCP/IP-Stack von Microsoft Windows auf. Die Administration erfolgt entweder über die Arbeitsstation selber, oder aber »remote«, entweder über Zusatzsoftware oder über den Browser. In diesem Moment ist die Gefahr existent, daß ein Angreifer mit einem überlangen String schon bei der Paßwortabfrage einen »buffer overflow« initiieren kann, auch wenn diese über SSL- oder SSH-Verschlüsselung läuft. Die Arbeitsstation gehört in diesem Moment nämlich logisch gesehen zur Firewall hinzu. Während der gesamten anderen Zeit wird diese Arbeitsstation häufig von dem Systemadministrator zum »surfen« und zum Lesen von E-Mails benutzt. Ein Angreifer ist während dieser Zeit in der Lage, diese Arbeitsstation mit einem trojanischen Pferd unter seine Kontrolle zu bringen, oder zumindest das »shared secret«, z.B den SSH-Schlüssel und das Paßwort in seinen Besitz zu bringen. SSH und vermutlich auch andere Verschlüsselungs/Authentifizierungssoftware ist gegen »buffer overflows« anfällig. Mit Kenntnis des Schlüssels, des Paßwortes und unter Anwendung von »spoofing« ist der Angreifer in der Lage, die Firewall auszuschalten.
S.u.S.E zeichnet sich stets durch einfache Installation und die besonders in Deutschland gefragte ISDN-Unterstützung aus. Seit Version 5.3 (6.0) hat S.u.S.E eine Firewall - Konfiguration und eine Installationsanleitung mitgeliefert. Wie schon oben erwähnt, ist diese Firewall erwiesenermaßen von innen her, z.B über den SSH-Dämon anzugreifen. Katastrophal sind aber die vorgeschlagenen Installationshinweise und der dort vorgeschlagene Aufbau, der gegen alle Regeln verstößt, die in Standardbüchern, z.B »Einrichten von Internet Firewalls« als gefährlich bezeichnet werden. Die LINUX Firewall arbeitet hier als »bastion host«, was angesichts der großen Probleme mit »buffer overflows« von LINUX schon ein Problem darstellt. Die Firewall ist hier zwischen Router zum Internet und dem Intranet angesiedelt. Bei entsprechender Einstellung der Variablen »FW_FRIENDS«, »FW_MAILSERVER«, »FW_DNSSERVER«, »FW_WWWSERVER«......werden Server, die im Intranet zusammen mit den Arbeitsstationen stehen, für den Zugriff aus dem Internet freigegeben. Im Falle, daß dort ein Server mit bekannten Sicherheitsproblemen installiert ist, z.B LINUX Server oder Windows NT Exchange-Server, kann ein Angreifer aus dem Internet direkt einen »buffer overflow« dort initiieren, und diesen dann als »trojanisches Pferd« für weiteres gebrauchen. (Es wird völlig übersehen, daß es »reverse proxies« gibt, die eine ähnlichen Aufbau erlauben, deren Technik ist aber eine völlig andere. Diese ist so nicht in LINUX verfügbar.) Ein Hinweise auf einen internen Router, also eine zweite Absicherung gegen Zugriffe auf das Intranet fehlt völlig. Die DMZ ist nicht existent. Es wird auch nicht darauf hingewiesen, daß LINUX auch in der S.u.S.E Version 6.0 gegen »buffer overflows« nicht geschützt ist, und Dämonen weder in »chroot() « Umgebung gestartet sind, noch es verboten ist, auf der Firewall X-Windows u.ä zu starten. Einige kleinere »spoofing« Fehler in der Konfiguration bezüglich der MASQUERADING-Dämonen (FTP, VDO_LIVE, CU-See-Me, IRC, Quake....) addieren sich zu der Tatsache, das überhaupt keine Firewall jemals einen IRC/Quake-Client zulassen sollte. Alle IRC-Clients lassen sich »remote fernsteuern« , ein großes Sicherheitsrisik o. Sowohl IRC als auch Quake sind bekannt dafür, daß sie unbekannten aus dem Internet Zugriff auf die Arbeitsstation hinter der Firewall geben. LINUX ist bekannt für seine Fehler im TCP/IP-Stack, die in DoS Angriffe enden können. Die im Kernel eingebaute Firewall basiert auf dem TCP/IP-Stack, ist also gegen TCP/IP DoS Angriffe nicht abgesichert. In der Installationsanleitung findet sich auch keinerlei Hinweis darauf. Insgesamt kann man diesen Firewall - Aufbau nur als »katastrophal« bezeichnen. Diese Firewall sollte man auch nicht »zusätzlich« zu einer bestehenden einsetzten. Die Gefahr, daß diese Firewall einem DoS Angriff zum Opfer fällt, ist sehr groß.
Der DFN-CERT in Hambung hat seit einigen Jahren eine äußerst einfache und scheinbar unüberwindbare Sicherheitslösung im Einsatz, die weder eine Firewall noch einen Proxy einsetzt. Wie besteht aus einem alten Paketfilter (DRAWBRIDGE), der die Arbeitsstationen von dem Internet abtrennt. Über diesen Paketfilter wird über einen SSH-Kryptokanal der externe WWW-Server administriert. Der WWW-Server ist ein in einer chroot() Umgebung laufender und mit minimalen Userrechten ausgestatteter und minimal modifizierter CERN-HTTPD Server. Als Betriebssystem arbeitet ein einfaches FreeBSD- UNIX, dessen Funktionsumfang auf ein Minimum reduziert wurde. Diese Maßnahmen wurden notwendig, da dieser Server wichtige Software zur Sicherung von Betriebssystemen anbietet. Ein Einbruch hätte fatale Folgen. Eine Suchmaschine, die die Inhalte des WWW-Servers indiziert, besitzt eine dedizierte Hardware. Sie ist zwar ähnlich abgesichert, es konnte aber aufgrund der Komplexität keine Garantie für die Sicherheit gegen »buffer overflows« gegeben werden. Da ist insofern nicht weiter wichtig, als das ein Angreifer höchtens die Suchausgabe verfälschen, nicht aber die Dokumente auf dem WWW-Server verändern kann. E-Mails werden von den Arbeitsstationen (kein Windows) über den Paketfilter hinweg direkt von einem E-Mail-Server des DFN geladen. E-Mails werden bei CERT wegen der Vertraulichkeit der Informationen generell verschlüsselt. (PGP) Damit sind die Arbeitsstationen im Netzwerk nicht gegen trojanische Pferde gesichert. E-Mails mit Attachments werden separat auf eine Floppy kopiert und auf einem dedizierten Arbeitsplatzrechner ohne Netzwerkanschluß untersucht. Diese Konfiguration, die über lange Jahre von Wolfgang Ley betreut und verbessert wurde, hat jahrelang jedem Angriffsversuch standgehalten. Die Zahl der registrierten Angriffe geht in die Tausende. Dies zeigt, daß ein vernünftiges Sicherheitskonzept, äußerst strenge Sicherheitsvorschriften ein vielfaches mehr an Sicherheit bietet, als der Einsatz einer Firewall in Verbindung mit einem beliebigen Server.
Genau kann man das nur sagen, wenn der Quellcode vorliegt. Das TIS FWTK (Gautlet) hatte z.B ein solches Problem, welches über Jahre bestanden hat - es ist inzwischen korrigiert. Betrachtet man die Aufgaben und Funktionsweisen einer modernen Firewall: Authentifizierung, Filter, ....so ist klar, daß theoretisch im Falle, daß ein Programmierfehler vorliegt, eine Firewall ebenso verletzbar ist, wie ein normales Betriebssystem. Fast alle Firewallhersteller trennen den Firewalldämon, der sich zwischen 2 Netzwerkinterfaces im Data-Link-Layer einklinkt von dem Administrations - Programm. Der Firewalldämon (Filter...) selber ist nicht empfindlich, da er ja nur Pakete auf einem Netzwerkinterface entgegennimmt, und nach einer Inspektion diese weiterleitet oder verwirft. Problematisch ist stets die Administration aus der Ferne. Probleme, die z.B. bei SSH oder PGP aufgetreten sind, zeugen davon, daß auch Dämonen, die eigens für starke Verschlüsselung und Authentifizierung programmiert wurden, anfällig gegen buffer overflows sind. Jede Art Fernadministration ist mit einem Risiko verbunden. Firewalls, die remote über WWW-Browser mit SSL - Verschlüsselung administriert werden, sind evtl. verletzbar. Das Sicherheitsproblem könnte dann beim WWW-Server liegen. Um sicherzugehen, sollte auf einer Firewall neben dem Firewall - Programm und dem dazugehörigen Konfigurationsprogramm kein anderer Dienst oder Programm aktiviert sein. Dazu gehört auch die remote Administration. Es gibt allerdings auch Firewalls, die (SPLIT)DNS Dienste und SMTP - Dienste anbieten (keine PROXY´s) Prinzipiell ist auch hier ein buffer overflow möglich. Aus diesem Grunde sollten stets mehrere Firewalls von unterschiedlichen Herstellern zum Einsatz kommen.
Ein Angriff mit »buffer overflow« ist nicht zu entdecken, da er im Idealfall nur ein paar »^P^P^P« oder andere wirre Buchstaben in Logfiles hinterläßt. Diese »Relikte« werden von allen Angreifern (die mir bisher untergekommen sind) beseitigt. Ein Einbruch kann nur bemerkt werden, wenn man diese Buchstaben »trappt« und z.B, falls diese im Logfile erscheinen, sofort, bevor der Angreifer die Spuren verwischen kann, den Server anhält »halt« Dann kann man sich »post mortem« an die Spuren - Auswertung machen. Hierzu muß man jedoch die Angriffe selber einmal »ausprobiert« haben. Angriffe mit unbekannten »buffer overflows« kann man nicht »trappen«, da diese evtl. keine auffälligen Spuren in Logfiles hinterlassen. Eine Netzwerküberwachung kann aber Aufschlüsse darüber geben, wer und wann größere Datenmengen wohin geschickt hat.
UNIX ist ein modulares Betriebssystem, jeder Dienst (Dämon) kann abgeschaltet werden. Darüber hinaus erlaubt UNIX die Abschaltung von Protokollen. Im Falle von OpenSource - Software ist es sogar möglich, sämtliche Protokolle aus dem Kernel zu entfernen oder zu ersetzen. So lassen sich z.B. mit Hilfe der Pakete ENSkip oder IPSec der Kernel so aufbauen, daß er normale Protokolle nicht mehr erkennen kann. Hierbei werden nicht einzelne Protokolle, sondern sämtliche Datenpakete einer oder aller Netzwerkkarten komplett verschlüsselt. Der Einsatz eines solchen Systems erfordert keinerlei Eingriffe in die Software, um von den starken Authentifizierungsmechanismen profitieren zu können. Von Außen ist ein Angreifer auch nicht mehr in der Lage, einen buffer overflow auf einem IPSec Server auszuführen. Für Anbieter von Datenbank-Servern ist dies eine Möglichkeit, ihren Server abschußsicher (gegen DoS Angriffe) und gegen buffer overflows zu schützen. Angriffe können nur noch von denjenigen WWW-Servern aus gestartet werden, die direkt über IPSec an den Datenbank-Server angebunden sind. Diese lassen sich relativ gut überwachen.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |