![[Inhalt]](toc.gif)
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Ein professioneller Angreifer sucht sich stets die schwächste Stelle einer Firewall aus. Das können fehlerhafte Firewall Regeln sein, Mängel im Design des Firewallaufba us, Fehler in PROXY´s....u.s.w. Um diese ausnutzen zu können, benötigt ein Angreifer möglichst präzise Angaben über verwendete Hardware, Betriebssystem Versionsnummern, Patch-Level, eingesetzte Software, Informationen über Netzwerkinfrastruktur, Know-How der Administratoren, u.s.w. Ziel ist es, einen Angriff möglichst präzise vorausplanen zu können und Werkzeuge zu schreiben, die die Firewall durchlässig machen. Eventuelle Fehlversuche erhöhen das Risiko, entdeckt zu werden, da Firewalls gut kontrolliert werden. Die Wahrscheinlichkeit, ein Sicherheitsproblem zu finden, ist relativ hoch, jedoch befinden sich in der Praxis mögliche Schwachstellen immer auf dem inneren Interface der Firewall. Ein Angreifer wird also immer entweder auf das Konfigurations-Interface der Firewall zielen, oder was viel mehr von Erfolg gekrönt sein wird, auf den Server in der DMZ, oder Server im Netzwerk des Unternehmens. Ein Angriff auf einen Server in der DMZ könnte durch die screened subnet/host vereitelt oder entdeckt werden. Somit konzentriert sich die volle Aufmerksamkeit eines Angreifers stets auf Server oder Arbeitsstationen hinter der Firewall, um mit deren Hilfe eine Art Tunnel durch die Firewall erstellen zu können. Besser jedoch ist, wenn der Angreifer im Netzwerk hinter der Firewall einen Weg findet, die Firewall umgehen zu können. Dies könnten Arbeitsstationen mit ISDN-Karte sein, Fax-Server o.ä. Ein Angreifer benötigt somit immer die Hilfe von Mitarbeitern im Unternehmen, ohne jedoch Mißtrauen zu wecken. Er muß den Einsatz von »trojanischen Pferden« möglichst präzise vorausplanen, da diese Angriffe von Mitarbeitern ausgeführt werden müssen. Er hat also keinerlei Steuerungs - oder Korrekturmöglichkeiten mehr. Diese Art Angriffe nennen sich blinde Angriffe. Um jedoch auf irgendeine Art eine Rückmeldung zu erhalten, ist es notwendig, Rückmeldungen über Erfolg/Mißerfolg oder weitere Informationen unauffällig aus dem Unternehmen heraus zu schleusen, vornehmlich über E-Mail oder das WWW-Interface. Hierzu muß er die interne Infrastruktur der Informationsflüsse kennen, evtl. sogar die Portnummer des Proxy-Servers, um eine direkte Verbindung, also einen Tunnel über die Firewall hinweg aufbauen zu können. Ist ihm das gelungen, so ist die Firewall überwunden. Damit es etwas anschaulicher wird, einige »teilweise« erfundene Beispiele, die vielleicht etwas »phantasievoll« anmuten, sich jedoch so abspielen könnten.
Der Angreifer, der sich telefonisch im Sekretariat davon überzeugt hat, daß Herr Mitarbeiter vom 24.12.2000 auch wirklich Zeit hat, schickt diesem eine E-Mail:
Sehr geehrter Herr Mitarbeiter !
Zur Eröffnung unserer neuen Filiale möchten wir Sie gerne persönlich einladen. Neben Vorstellungen neuer Internet-Technologien durch unsere Referenten XY, Microsoft und WV, SUN möchten wir Sie gerne auch mit leiblichen Überraschungen verwöhnen. Wir bitte Sie daher, uns mitzuteilen, ob wir Sie am 24.12.2000, 10 Uhr, in unserer neuen Filiale begrüßen dürfen. Elektronische Anmeldung bitte auf http://www.little-idiot.de/cgi-bin/test.cgi (diese URL liefert u.a. Informationen)
Mit freundlichen Grüßen,
gez. Boss
Herr Mitarbeiter, sichtlich erfreut angesichts der leiblichen und geistigen Überraschungen, sagt via Mail zu. Kurze Zeit später ist der Angreifer im Besitz folgender Informationen:
REMOTE_ADDR = 212.53.238.2 REMOTE_HOST = 212.53.238.2 QUERY_STRING = Name=Mueller HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) HTTP_ACCEPT = */* HTTP_ACCEPT_ENCODING = gzip, deflate HTTP_X_FORWARDED_FOR = 212.53.238.130 HTTP_VIA = 1.0 cache:8080 (Squid/2.0.PATCH2)
Was sagt dem Angreifer das ? Er weiß, bei welchem Provider die Firma einen Internet-Zugang besitzt, wer gerade zugesagt hat, daß er mit Windows 98 in der Standardversion und dem Internet-Explorer (kein Fehler!) arbeitet, daß er mit einem LINUX-Router als PROXY (SQUID) an das Internet angeschlossen ist, WINZIP so installiert hat, daß ZIP-Files automatisch ausgepackt werden, seine IP-Adresse hinter dem Router 212.53.238.130 ist und keinerlei HTTP-Filter o.ä. eingesetzt werden. Er weiß weiterhin, daß jedes Programm über die IP - Nummer 212.53.238.2 und Port 8080 als Gateway Daten aus dem Intranet an einen beliebigen Server im Internet senden kann, sowohl mit HTTP und FTP-Protokoll. Ein Netzwerk - Scanner wird zeigen, daß alle Ports, außer Port 25 (sendmail) auf dem Router geschlossen worden sind. Weiterhin ist mit Sicherheit eine LINUX Version mit Kernel < 2.0.34 und allen bekannten Sicherheitlücken aktiv, diese sollen aber den Angreifer (noch nicht) interessieren. Weiterhin ist die Firma über einen Provider mit reserviertem Subnetz an das Internet angebunden.
Was braucht ein Angreifer also, um die Festplatte dieses Users zu durchforsten ? Ersteinmal VC++, Bibliotheken für den PROXY Mechanismus, und den Quellcode von Tetris. Heraus kommt, nach ein paar Tagen Arbeit, ein Tetris - Spiel, welches ein paar Geheimnisse birgt.
Es fragt nach der IP - Nummer des Rechners, auf dem es gestartet wird. Ist die IP - Nummer = 212.53.238.130 dann baut es über die IP - Nummer ....2 und Port 8080 eine FTP-Verbindung in das Internet auf, und versendet alle ".doc" Files aus "C:\Eigene_Dateien" in das Internet, installiert einen Tastatursniffer und einen Netzwerkscanner, welches es von einem FTP-Server im Internet holt. Nach einigen Tagen wird es folgende Informationen auf die Festplatte geschrieben haben: Sämtliche Telnet - Paßworte, die an 212.53.238.130 gesandt worden sind, sämtliche Paßworte die an ...130, Port 110 gesandt worden sind.....sämtliche Paßworte, die an den NOVELL/NT-Server gesandt worden sind........Bei jedem Start des Tetris -Spiels verschwinden diese Informationen in das Internet und werden gelöscht.
Kurze Zeit später bekommt Herr Mitarbeiter via E-Mail einen Geburtstagsgruß, eine animierte Grafik von einem Kollegen, ein paar Türen weiter. Er startet dieses .exe Programm und freut sich über Glückwünsche. In diesem Moment wird eine Telnet-Verbindung zum Router aufgebaut, alle externen Firewallregeln ausgeschaltet, und eine E-Mail versandt. Der Router ist völlig offen, der Angreifer ist in Besitz einiger oder sogar aller User-Accounts und des Administrator-Paßwortes. Er stoppt mit dem Signalhändler (kill) alle Logdämonen, installiert das Protokoll IPX und NCPFS während der Laufzeit, ein Neustart ist unter LINUX nicht notwendig. Da er einige/alle Paßworte des NOVELL-Server, die IP - Nummern, IPX-Nodenummern und die Hardware-Adressen der Netzwerkkarten der Mitarbeiterrechner kennt, kann er im Prinzip den NOVELL-Server komplett in das Filesystem von LINUX einklinken. Er hat dabei nur wenige Hindernisse zu überwinden: 1. Kopplung Login/Paßwort an eine MAC-Adresse 2. Der Mitarbeiter darf seine Arbeitsstation nicht gestartet haben.
Also wartet der Angreifer bis zur Mittagspause, vergewissert sich, daß Mitarbeit er XY nicht vor seinem Rechner sitzt und arbeitet, startet einen kleinen DoS Angriff auf den Rechner des Mitarbeiters. Der Rechner ist abgestürzt, die Netzwerkkarte deaktiviert. Nun fährt er in LINUX ein virtuelles Interface hoch, mit derselben IP - Nummer und MAC-Adresse, die vorher der Windows 98 Rechner von Mitarbeiter XY besaß. Der Angreifer loggt sich mit LINUX in den NOVELL-Server ein und beginnt, DOC-Files auf den LINUX-Recher zu übertragen. Nach 2 Minuten ist er fertig, loggt sich wieder aus und beginnt, mit einem Winword -> ASCII Konverter die Datenmenge zu reduzieren. Mit ZIP komprimiert er diese und versendet sie an eine E-Mail Adresse im Internet. Er "korrigiert" die Firewallregeln, bereinigt die LOG-Files, aktiviert die Logdämonen und verschwindet ungesehen.
Der Systemadministrator ist ein gewissenhafter Mensch, er kontrolliert sorgfältig alle Logfiles auf NOVELL-Server und Router. Da er nichts ungewöhnliches bemerkt, fährt er beruhigt um 18.00 Uhr nach Hause.
Welche anderen Informationen hätte der Angreifer erhalten können ?
HTTP_USER_AGENT = Mozilla/4.06 [de]C-QXW0310E (WinNT; I) HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* HTTP_ACCEPT_ENCODING = gzip
Es hätte sich nichts geändert, der o.a. Angriff wäre auch so erfolgreich gewesen, Trotz des Einsatzes von NT. Netscape 4.06 hätte wegen eines BUGS in JAVASCRIPT es dem Angreifer ermöglicht, den CACHE auszulesen, um festzustellen, wohin der Mitarbeiter gerne "surft". Ein neuer Angriff, hier die Daten:
REMOTE_ADDR = 195.211.212.134 REMOTE_HOST = 195.211.212.134 HTTP_USER_AGENT = Microsoft Internet Explorer HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* HTTP_ACCEPT_ENCODING = gzip HTTP_ACCEPT_CHARSET = iso-8859-1,*,utf-8 HTTP_X_FORWARDED_FOR = 192.168.99.5 HTTP_VIA = 1.0 fv-router.firma.de:8080 (Squid/2.1.RELEASE)
Was liest ein Angreifer hieraus ? Im Gegensatz zur vorgergehenden Netzwerkanbindung ist hier der Systemadministrator offensichtlich sehr engagiert und viel erfahrener in Netzwerktechnik. Woran sieht man das ? HTTP_USER_AGENT = Microsoft Internet Explorer ist eine Irreführung des Squid 2.1 über die verwendeten Browser im Netz. Die Information HTTP_X_FORWARDED_FOR zeigt, daß hier auf einem LINUX-Router (wahrscheinlich S.u.S.E 5.3 oder 6.0 mit den Firewall und Masquerading - Regeln installiert wurde. Es muß ein Systemadministrator sein, der sich hervorragend mit UNIX auskennt, da er Squid 2.1 neu kompiliert und installiert hat. Weiterhin kennt sich dieser gut im Routing aus, da er die 192.168.x.x Netzwerkadresse im Intranet verwendet, welche per Definition nicht in das Internet geroutet wird, er setzt Masquerading (also NAT) ein. Im Gegensatz zu dem ersten Beispiel besitzt diese Firma keine Anbindung über eine feste IP - Nummer, sondern benutzt einen preiswerten Account mit SYNC-PPP, d.h., das sich die IP - Nummer von mal zu mal ändert. Ein Scan des Class-C Netzes zeigt, daß nur ca. 30 IP - Nummern in Frage kommen. Falls der Angreifer also diesen LINUX-Router wiederfinden möchte, muß er ständig diese 30 IP - Nummern auf das Vorhandensein von Port 8080 scannen, was sich evtl. etwas Zeit kosten würde, oder dem Systemadminitrator eine E-Mail schicken, die ihn veranlaßt, eine bestimmte Seite im Internet zu besuchen. Hier wird er dann "getrappt", also ihm eine Falle gestellt. Die sieht folgendermaßen aus: Es besucht jemand die WWW-Seite. Der WWW-Server erzeugt einen Eintrag in das "access_log" File. Dieses File wird mit "tail -f access_log|grep 195.211.212" (UNIX oder NT+UNIX Toolkits) ständig abgefragt. Tritt ein "Event" auf, so wird automatisch ein "ping 195.211.212.xxx (mit der vom "Event" übergebenen IP-Adresse) ausgeführt. Das ist von jedem Anfänger zu bewältigen und eignet sich hervorragend auch für riesige Netze, wie z.B. der Telekom mit Millionen von IP - Nummern oder großen Firmen, wie Siemens, DEBIS, Daimler.....Duch den "ping" wird die ISDN-Leitung des Routers offengehalten, zwecks Untersuchung. Er kann auch sicher sein, daß er das richtige Opfer gefunden hat, da sonst niemand diese bestimmte WWW-Seite kennt. Der Angreifer kann also in Ruhe irgendwann in der Nacht den Server untersuchen. Ein Scan wird zeigen, daß hier keinerlei Port offen ist. Da diese Firma so, wegen der dynamischen IP - Nummer und wegen der völlig geschlossenen Ports keine E-Mail erhalten würde, muß also ein Programm die E-Mail aktiv in das Netzwerk holen, aber wie und von wo ? Eine kurze Abfrage des MX - Eintrages dieser Firma XY mit nslookup zeigt, daß die E-Mail auf einem Außenserver gelagert wird. Es ist zu vermuten, daß zu bestimmten Zeiten E-Mail geholt und gesendet wird, dieses Verfahren dient der Vermeidung von Telefonkosten.
Was würde ein Angreifer unternehmen, um in dieses Netzwerk vorzudringen ? Im Prinzip würde auch der o.a. Angriff funktionieren, es ist aber mit etwas höherem Widerstand bei einem Angriff von innen her zu rechnen. Z.B. würde ein erfahrener Administrator einen SSH-Client benutzen, oder via WWW-Interface (Webmin) oder SSL den Server administrieren. Normale Useraccounts könnten für telnet deaktiviert sein, sodaß ein Einloggen unmöglich ist. Paßworte würden in diesem Falle nur über Port 110 übertragen, mit Sicherheit werden es unverschlüsselte Paßworte sein. Genau hier wird also ein Netzwerksniffer ansetzen (z.B. BO). Da bei neueren LINUX - Versionen POP3 gut gesichert ist, bleibt nur noch ein Angriff über PORTMAP, MOUNTD, INETD....HTTP von innen heraus übrig. Dem Angriff müsste also ein Security- Scan des Gateways von innen vorausgehen. Ein Blick auf "BUGRAQ" verrät schon einige Exploits, die in S.u.S.E. LINUX 5.3 und 6.0 (aber auch anderen Distributionen) noch nicht aktuell gepatcht sein können, es sei denn, der Systemadministrator hat diese Sicherheitsprobleme beseitigt. Die Wahrscheinlichkeit, von Innen heraus einen erfolgreichen "exploit" zu starten, ist relativ hoch. Nachteil ist, daß dieser auf Windows 95/98 oder NT portiert werden muß. Dank der neuen Winsock 2.0+ ist dies kein Problem mehr, der Aufwand, ein Programm, welches "RAW sockets" anspricht, ist gering. Der SSH, MOUNTD oder SAMBA - »exploit« würde mit hoher Wahrscheinlichkeit erfolgreich sein, vorausgesetzt, daß der Router als Fileserver und E-Mailserver eingesetzt wird. Ist zudem noch X-Windows installiert (was bei LINUX - Routern meistens so ist), ist auch hier ein großes Sicherheitsloch gegeben. Da aber Angriffe auf Applikationsebene (Tetris....) gut funktionieren, besteht ein Anlaß, sich weiter Gedanken zu machen.
Der Einsatz von SQUID auf dem Router (Firewall??) hat es überhaupt erst ermöglicht, daß der Angreifer in Kenntnis der internen IP - Nummer kam, um den Angriff besser vorbereiten zu können. Ohne SQUID, also nur als Router mit Masquerading installiert, ergeben sich geringfügig andere Informationen, die der Angreifer nutzen kann:
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 4.0; Windows 95) HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/v nd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Ohne SQUID kommt der Angreifer in Besitz von Informationen über viele Anwendungsprogramme, welche auf der Arbeitsstation installiert sind. Powerpoint, Excel und Winword sind Programme, die VBasic als Programmiersprache nutzen, mit allen Möglichkeiten, die ein VC++ Programm auch besitzt. Man könnte also ein Programm (Netzwerkscanner, Keyboard- Sniffer) in ein Makro einbauen, und dem arglosen Mitarbeiter als WinWord/Excel/Powerpoint-Datei senden. Diese Angriffe sind noch nicht beschrieben worden......kommt noch....:) Die Tatsache, daß MSIE 4.0 und Windows 95 eingesetzt wird, erleichtert die Suche nach funktionierenden "exploits".
REMOTE_HOST = 195.99.32.6 HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 4.0; Windows 95) HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Für einen Angriff sind die Informationen etwas mager, daher lassen wir uns eine E-Mail aus dem Netzwerk senden:
Received: by ns.nobbelazzo.com (8.8.4/8.6.12) id PAA00634; Wed, 6 Jan 1999 15:18:19 +0100 (MET) Message-Id: <199901061418.PAA00634@ns.nobbelazzo.com> Received: by ns.nobbelazzo.com via smap (V1.3) id sma000480; Wed, 6 Jan 99 15:18:04 +0100 Received: by ahmnag.ahm-nl.nobbelazzo.nl with Internet Mail Service (5.5.1960.3) id <CM97R19X>; Wed, 6 Jan 1999 15:18:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Status:
Und schon ist der Angreifer ein wenig schlauer: Die Firma setzt also intern Microsoft Exchange 5.5 ein, hat eine Firewall installiert, wahrscheinlich LINUX mit dem TIS - FWTK 2.0/2.1, installiert auf ns.nobbelazzo.com, dem "bastion host" und Gateway zum Internet. Er kennt außerdem den internen DNS Namen des Mail-Gateways, welches die Arbeitsstationen als Relay benutzen. Zur Vorbereitung eines automatisierten Angriffs durch ein trojanisches Pferd sind diese Informationen elementar wichtig. Also weiter mit den Untersuchungen:
NSLOOKUP liefert folgende Informationen:
nobbelazzo.com nameserver = NS.nobbelazzo.com nobbelazzo.com nameserver = NS2.EU.CONCERT.NET nobbelazzo.com origin = NS.nobbelazzo.com mail addr = postmaster.NS.nobbelazzo.com serial = 99010611 refresh = 10800 (3 hours) retry = 1800 (30 mins) expire = 3600000 (41 days 16 hours) minimum ttl = 86400 (1 day) nobbelazzo.com preference = 5, mail exchanger = NS.nobbelazzo.com Authoritative answers can be found from: nobbelazzo.com nameserver = NS.nobbelazzo.com nobbelazzo.com nameserver = NS2.EU.CONCERT.NET NS.nobbelazzo.com internet address = 195.99.32.6 NS2.EU.CONCERT.NET internet address = 195.99.65.212
Ok, ein "bastion host", aber welche Ports sind geöffnet ?
[root@www stepken]#./portscan ns.nobbelazzo.com 1 1024 No route to host ! [root@www stepken]#./portscan ns.nobbelazzo.com 25 26 25 No route to host ! [root@www stepken]# ./portscan ns.nobbelazzo.com 53 54 53 No route to host ! [root@www stepken]# ./portscan ns.nobbelazzo.com 55 56 No route to host ! [root@www stepken]# ./portscan ns.nobbelazzo.com 8080 8081 8080 No route to host !
Was soll uns das sagen ? Aus dem E-Mail Header entnimmt der Angreifer, daß SMAP V1.3 unter UNIX installiert wurde, also das TIS FWTK in der Version (V1.3) installiert wurde. Der erste Test "portscan ...1 1024" wird abgeblockt, ein Hinweis auf Firewall-1, die vorgeschaltet wurde. Fängt der Angreifer aber an, von dem vermutlich aktiven Port aus zu scannen, bekommt er doch einen eindeutige Aussage (Man achte auf das Echo bei portscan ...25 26) Auf dem "bastion host" sind ein PROXY-CACHE, Ein E-Mail-Dämon, und ein DNS-Server installiert (Port 25, 53, 8080). Der Angreifer hat also Informationen mit Hilfe des Portscanners erhalten, obwohl die Firewall angeblich Portscans verhindert. Mit Sicherheit hat aber der counter intelligence Mechanismus verhindert, daß der Systemadministrator entdecken könnte, daß die Ports tatsächlich geöffnet sind. So führen Firewalls Portscanner in die Irre und verhindern, daß Sicherheitslücken entdeckt werden können. Für einen unerfahrenen Administrator ist dieses unmöglich zu durchschauen.
Ein Traceroute sagt vielleicht mehr aus:
13 access2-fa2-1-0.nl1.concert.net (195.99.66.3) 65.666 ms 43.910 ms 47.275 ms 14 194.73.74.110 (194.73.74.110) 84.096 ms 84.434 ms 85.156 ms 15 ns.nobbelazzo.com (195.99.32.6) 60.055 ms 82.062 ms 65.236 ms
Es scheint, daß 194.73.74.110 der Übeltäter zu sein, der die Portscans verhindert, eine genauere Analyse des TCP Inkrements, z.B., wird einem erfahreneren Angreifer genau sagen, welche Firewall auf welchem Betriebssystem installiert ist. Hierfür benötigt man aber tiefere Kenntnisse. Offensichtlich ist es aber möglich , sowohl Port 25 (SMAP), Port 53 (DNS) und sogar Port 8080 (eine Sicherheitslücke?) von außen zu erreichen. Die Wahrscheinlichkeit, das ein "buffer overfow" auf Port 8080 und 53 erfolgreich ist, ist hoch. Port 25 mit SMAP ist "bullet proof", hat also kaum Chancen auf Erfolg. Der Aufbau entspricht der "screened host" Architektur, d.h. selbst wenn der "buffer overflow" Angriff erfolgreich wäre, so müßte ein Angreifer doch erhebliche "Umwege" in Kauf nehmen, um nicht entdeckt zu werden. Spezielle Angriffe, die "source routing" und "spoofing" erfordern, sind somit schon einmal erschwert. Soweit zu den Chancen, die Firewall direkt anzugreifen. Viel kommunikationsfreudiger sind die Mitarbeiter, die E-Mail - Anschluß haben. Sie freuen sich über jeden neuen Gruß, eine kleine Animation, einen Weihnachtsmann, ein Spiel, einem trojanischen Pferdchen z.B o.ä. Da Attachments in dieser Firma nicht heraus gefiltert werden, sollte klar sein, wie z.B. ein Tunnel aufgebaut werden kann. Von einer beliebigen internen IP-Adresse über Port 8080 des Internetgateways. Das Unternehmensinterne »routing« wird den Weg schon finden. Was der Angreifer nun nachprogrammieren muß, ist ein Tunnelprogramm, welches mit dem PROXY- Mechanismus des Gateways, Port 8080 kommuniziert, und die Eigenschaften von NetBus oder BO besitzt. Danach wird es mit einem Spiel versehen, und an alle Mitarbeiter des Unternehmens verschickt, die »surfen« dürfen. Nachdem die wichtigsten Werkzeuge schon geschrieben sind, müssen nur noch ein paar Tage investiert werden, um ein allgemein anwendbares Werkzeug zur Verfügung zu haben. Auch ein Angriff auf Anwendungsebene würde hier aber äußerst erfolgreich sein, E-Mails mit Attachments (Weihnachtsgrüße o.ä.) kommen stets an. Ein Angreifer muß nur irgendeinen "Dummen" aus dem Bereich Sekretariat oder Verkauf nach seiner E-Mail - Adresse fragen und schon läßt sich ein trojanisches Pferd genau plazieren. Der offene Port 8080, der existiert, jedoch von Außen nicht nutzbar ist,läßt vermuten, daß von vielen Arbeitsplätzen aus über Port 8080 und ns.nobbelazzo.com als Gateway ein Herausschleusen von Informationen möglich ist. Die Firewall dient dann nur noch zur Aufzeichnung eines Angriffs, um hinterher genau feststellen zu können, daß die Informationen an irgendeinen Host im Internet (z.B. in Japan) gesendet wurden, von welchem aus sich die Spur verliert. Die Information, daß innerhalb des Netzwerkes Exchange 5.5 zum Einsatz kommt, spielt weniger eine Rolle. Es läßt vermuten, daß hier Virenscanner u.ä. installiert sind, welche allzu schnell einem DoS Angriff zum Opferfallen könnten, ebenso wie ns.nobbelazzo.com wahrscheinlich, da es auf LINUX basiert, mit einem älteren TCP/IP-Stack Problem konfrontiert, schnell seine Arbeit einstellen würde. Es spielt heute für einen Angreifer kaum noch eine Rolle, ob eine Firewall installiert ist, oder nicht, das eigentliche Problem sind die Windows NT Arbeitstationen und die Anwendungsprogramme, Office und der Internet-Explorer.
LINUX wird immer wieder gerne als Kompaktlösung , also als E-Mail Gateway, PROXY-Cache, ISDN- Router und Firewall eingesetzt. Perfekt sind die Firewall-Regeln aufgesetzt, es ist kein Port nach außen geöffnet, E-Mails werden stündlich via fetchmail von einem Sammelaccount im Internet auf den Server geladen. Soweit ergeben sich keine Angriffspunkte für einen Einbruch in das System von außen. Das System ist von innen heraus einfach mit webmin via Netscape zu konfigurieren. Installiert wurde es auf Port 10000, wie als default vorgegeben. 4 Wochen nach Installation war das System geknackt, und der User root gelöscht.
Was war passiert ?
Ein Surfer im Netzwerk hatte eine Seite geladen, die aus 2 Frames bestand und durch JAVA(SKRIPT) ergänzt war. Netscape baute 2 Verbindungen auf, eine in das Internet, und eine zur Firewall. Hier öffnete ein JAVA-Applet den Port 10000, loggte sich als admin mit dem Paßwort admin ein und startete das PerlSkript, welches für User-Administration zuständig ist und löschte so den User root. Ein Zufallstreffer, aber sicher ist dieser Trick häufiger anwendbar, als allgemein vermutet.
Mit größerer Wahrscheinlichkeit gelingt aber ein von innen initiierter buffer overflow, z.B. auf den POP3 Dämon. Hierzu muß man wissen, daß S.u.S.E. LINUX 5.2 ein Problem mit dem QUALCOMM POP-Dämon hatte. Alternativ könnte man auch einen aktuellen Exploit auf mountd, inetd oder portmap nehmen. Auf dieser Firewall ist mit hoher Wahrscheinlichkeit dieser POP-Dämon installiert und nach innen hin aktiv. Also wird ein Angreifer diesen exploit namens QPOP ein wenig umschreiben: Erstens wird er /bin/bash in /sbin/ipfwadm -If; ping www.domain.com ändern, anstelle der Parameterübergabe in der Shell feste IP - Nummern einstellen und dieses Programm mit Microsoft VC++ oder DJGPP kompilieren. Nun wird er auf dem Server www.domain.com einen ICMP-Scanner installieren und starten, um aufgrund der ping Pakete (ICMP) die (eventuell dynamische) IP - Nummer es Firewallrouters feststell en zu können. Der ICMP-Scanner ist ein wenig modifiziert - er reagiert auf ein ping mit einem kontinuierlichen back-ping (ähnlich backfinger), um die ISDN-Verbindung offenzuhalten. Nun verpackt der den Exploit als Attachment in eine E-Mail und adressiert es an einen beliebigen Benutzer hinter der Firewall. In der sicheren Hoffnung, daß ein Benutzer diese E-Mail lesen wird, und neugierig das Programm startet, lehnt er sich zurück und wartet. Nach einiger Zeit schaut er nach, ob sein Back-Ping angeschlagen hat. Ist das der Fall, so wird sein Portscanner zeigen, daß der Firewall-Router alle internen Ports nach außen geöffnet hat (ipfwadm -If). Die ISDN-Leitung bleibt also solange geöffnet, bis der Angreifer Zeit hat, sich um sein Opfer zu kümmern. Mit Hilfe des QPOP exploits wird er ein zweites mal den POP-Dämon bemühen, um vollen root Zugriff auf die Firewall zu haben. Um keine Spuren zu hinterlassen, muß er mit dem Signalhändler (kill) den SYSLOGD vorübergehend anhalten. Mit Hilfe des vi, weil er I-Node-Echt (wichtig!) und überall zu finden ist, wird er seine Spuren in den Logfiles verwischen. Die Inode - Echtheit ist deswegen besonders wichtig, weil man während der LOG-Dämon in die Datei schreibt, Teile aus dieser gleichzeitig löschen kann. Editoren, die nicht I-Node-Echt sind, würden diese Datei zuerst kopieren und dann öffnen, während der LOG-Dämon fleißig in die andere Datei schreibt. Beim speichern wird die originale Datei umbenannt und gelöscht. Danach wird die veränderte Kopie in die originale Datei umbenannt. Diese neue Datei besitzt dann eine neue I-Node Nummer, die der LOG-Dämon nicht automatisch erkennt. Dieser schreibt fleißig in die Datei (wie auch immer diese nun heißt) hinein. Erst nach einem Neustart würde er die Veränderung der I-Node Nummer bemerken und mit dem Schreiben der LOG-Datei fortfahren. (Hackerwissen !!!)
^P^P^P^P.....^P
, und den SYSLOGD wieder weiterlaufen lassen. In den Logfiles werden sich keinerlei Spuren eines Angriffs finden lassen. Da der Systemadministrator keinerlei Informationen darüber erhält, ob ein User im Netzwerk nun diesen exploit oder nur normal seine E-Mails abgeholt hat, kann auch ein IDS-System nichts ungewöhnliches entdecken. Diese Firewall hätte genauso ein NT - Server mit WINGATE, WINPROXY, oder SAMBAR.... sein können. Das Schema wäre dasselbe gewesen.
Ein Unternehmen besitzt einen Multi-Homed Internet Server im Netz, auf dem sich hunderte Kundensites befinden. Ich als Systemadministrator, stellte an einem Wochenende nach der Fußball-WM 1998, es war der 12.07.1998, fest, daß ich aus irgendwelchen Gründen nicht mehr im Besitz des Administrator Paßwortes des LINUX Servers bin. Der Useraccount funktionierte jedoch noch. Beim Durchsuchen einiger WWW-Seiten auf Veränderungen stellte ich fest, daß hier Seiten verändert wurden: "Dieser Server wurde gehackt und komplett übernommen", stand auf der Frontpage groß und breit. Das Problem ist nur, daß von diesen WWW-Sites ebenfalls die Paßworte verändert waren. Es schien, daß die peinichen Veränderungen bis zum Montag morgen so stehen bleiben mußten. Die Frage war aber, wie der Hacker in den Server einbrechen konnte. Also wurde die Site http://www.rootshell.com durchsucht. Der EXPLOIT war schnell gefunden, es war der QPOP2 Exploit für den POP3 Server, und auf den WWW-Server in das User-Verzeichnis kopiert. Der Exploit wurde kompiliert, und auf den eigenen Server angesetzt. Ich falle direkt in eine ROOT-Shell hinein, und besitze nun die Supervisor-Rechte. Zuerst muß einmal das Rootpaßwort wiederhergestellt werden. Das Kommando passwd root funktioniert nicht, aus irgendeinem unverständlichen Grund. Als Alternative bleibt also nur, einen Eintrag eines anderen Accounts mit dem verschlüsselten Paßwort in die Zeile von root in der Datei /etc/shadow zu kopieren. Ich kopiere also das verschlüsselte Paßwort meines Useraccounts in die Zeile des Users root und versuche mich über meinen Useraccount als ROOT einzuloggen. Es funktioniert. Nun durchsuche ich alle betroffenen Homepages auf Veränderungen (find /home -mtime 1 ....). Einige WWW-Seiten wurden verändert, und zwar schon am Vortag. Das erste, was ich nun mache, ist das Sicherheitsloch zu beseitigen. Ich suche mir vom Hersteller des POP3 Server die neue Version des POP-Dämons, kompiliere ihn neu, und installiere ich ihn anstelle des Alten. Ich teste den Exploit nocheinmal, zur Sicherheit. Diesmal falle ich nicht mehr in eine ROOT-Shell, fein. Nun spiele ich die Backups wieder zurück, damit die Veränderungen des Hackers weitestgehend rückgängig gemacht werden. Inzwischen sind seit der Entdeckung des Einbruchs ca. 2 Stunden vergangen. Anhand des Datums und der Uhrzeit der Veränderungen durchsuche ich die Logfiles des Apache-Servers und stelle fest, daß diese Seiten ein paar Stunden zuvor über einen öffentlich zugänglichen Proxy zuerst geladen, und dann nach ein paar Stunden wieder zurückgespielt wurden. Ich durchsuche nun die typischen Log-Dateien auf Veränderungen:
Alle Log-Dateien, die hätten verwertet werden können, waren gelöscht worden. Mir bleiben also nur noch die Log-Dateien des Apache Servers, die auf einen frei zugänglichen PROXY-Server zeigen.
Ich versuche es mit der Wiederherstellung der Datei /var/log/messages mit einem UNDELETE Befehl, der in einigen Fällen aus dem Filesystem ext2 Dateien wiederherstellen kann. Fehlanzeige ! Der Einbrecher verwendete offensichtlich den VI Editor, der I-Node echt ist. Dieser legt keine zweite, temporäre Datei an, die dan später gelöscht wird, (... - Dateien) sondern dieser kann eine Log-Datei in Echtzeit verändern, während der SYSLOGD diese weiter beschreibt. Das einzige, was hier nun eventuell noch geholfen hätte, ist das byteweise Auslesen der gesamten Festplattenpartition mit dd if="/dev/sda1" of="/dev/..." Dieses hätte vielleicht noch Reste hervorgebracht, ich denke aber, daß der SYSLOGD gerade dabei war, diese zu überschreiben.....Tja, ohne Beweise keine Möglichkeit, den Täter zu finden. Die Polizei wird also nicht verständigt.
Am nächsten Morgen führt auch ein Anruf bei dem Betreiber des PROXY zu keinem Ergebnis, da dieser nicht nur einen PROXY betreibt, sondern auch noch Analog-Zugänge, in die man sich ohne Paßwort einloggen darf, halt Testzugänge.
Am Abend dieses Montages beschlagnahmt die Staatsanwaltschaft diesen Server. Es ist angeblich von diesem aus in den Server des Bundesverkehrsministeriums eingebrochen worden. Die Festplatte dort wurde gelöscht. Im Radio wird zufälligweise genau an diesem Montag aus berichtet, daß auch in den FDP Server eingebrochen wurde. Es stand dort auf der ersten Seite geschrieben: 4.9 % sind genug !
Die nachfolgende Untersuchung im Landeskriminalamt Düsseldorf ergibt auch keine neuen Ergebnisse - Keine Befunde eines Einbruchs in und von diesem Server aus, da die Festplatte mit dem Betriebssystem aus irgendwelchen unerfindlichen Gründen von der Polizei zerstört wurde.
Hätte eine Firewall diesen Angriff verhindert ? Ganz sicher nicht, da die Ports 21 (FTP), 80 (WWW), 23 (TELNET) und 110 (POP3) hätte freigeschaltet sein müssen, damit der Betrieb nicht gestört worden wäre. Der Exploit verwendet den Port 110, um eine Telnet Session zu starten (die ROOT-Shell). Eine Sperrung des Port 23 (TELNET) hätte ebenfalls nichts gebracht, da der Angreifer ja ebenfalls eine Telnet-Session über den Port 110 gestartet hatte. Hätte die Firewall eventuell diejenigen Informationen liefern können, die der Einbrecher aus den Logfiles gelöscht hat ? Nein, da der Angreifer für seine Angriffe einen PROXY verwendet hat, also niemals direkten Kontakt mit dem Server hatte. Die Firewall hätte dieses ebenfalls so aufgezeichnet.
Hätte die Verwendung eines anderen Betriebssystems diesen Angriff verhindert ?
Bedingt, da auch andere Betriebssysteme Sicherheitslücken besitzten, allerdings andere, die vielleicht nicht so bekannt sind. Einen professionellen Angreifer hätte diese nicht gehindert. Viele Angriffe auf LINUX werden jedoch von Hackern durchgeführt, die zum Spaß herumspielen. Die Mehrzahl dieser Hacker sucht sich LINUX Server aus. Dementsprechend ist die Ausfallrate bei LINUX höher, wenn der Systemadministrator nicht regelmäßig und gewissenhaft immer die neuesten Patches aufspielt. Das versteht sich aber auch bei anderen Betriebssystemen von selber, daß stets die Patches oder Service Packs aufgespielt werden. Am wenigsten Ausfälle sind also bei gut und gewissenhaft betreuten Systemen zu beklagen.
Ganz sicher hätte aber der Einsatz von LINUX mit einem anderen Prozessor, z.B. MIPS oder ARM den Angriff vereitelt. Buffer Overflows sind nämlich speziell auf den Intel-Prozessor zugeschnitten. Anpassungen für andere Prozessoren findet man nie. Der Systemadministrator hat also immer etwas mehr Zeit, die Security Patches einzuspielen. Einige der von mir betreuten LINUX Server, die mit SPARC, MIPS, DEC ALPHA oder ARM - Prozessoren laufen, wurden schon häufiger angegriffen, allerdings niemals erfolgreich. Aus ca. 150 bekannten und in Log-Dateien registrierten Angriffen kann ich nun abschätzen, daß ich auf den Intel basierten Servern ca. 95 % aller Einbrüche nicht bemerkt habe ......peinlich .... Lösungen für Sicherheitsprobleme
Siehe hierzu das Unterkapitel DoS - Angriff mit einem Visual Basic Makro
Zahlreiche Unternehmen besitzen eine E-Mail Adresse, jedoch keinen WWW-Server oder Firewall. Sie rufen die E-Mails über einen T-Online Account oder einen Account bei AOL über einen Arbeitsplatzrechner ab. Es gibt Firmen, die auf vielen Arbeitsplätzen ISDN-Karten installiert haben, um so Bandbreitenprobleme zu vermeiden und einen Faxserver einzusparen. Ein möglicher, gezielter Angriff erscheint den Systemadminitratoren völlig unwahrscheinlich. Es gibt Millionen AOL und Telekom - Kunden, wie sollte ein Angreifer zu einem genauen Zeitpunkt die DIAL-IN IP - Nummer derjenigen Arbeitsstation ausfindig machen können, die zu diesem Unternehmen gehört ? Unmöglich ? Mitnichten !
Eine telefonische Anfrage bei einem Mitarbeiter dieser Firma, ein gewöhnliches Gespräch:
Angreifer: Ich habe da eine Anfrage. Kann ich Ihnen unsere Ausschreibung zusenden ? Mitarbeiter: Ja, meine Faxnummer ist 0xxxxyyyyy Angreifer: Haben Sie auch E-Mail ? Das ist bequemer ! Mitarbeiter: Ja, schicken Sie´s an Mitarbeiter23.Firma@t-online.de Angreifer: Können Sie gezippte WinWord- Files lesen ? Mitarbeiter: Auch das können wir ! Angreifer: OK ich verpack´s dann sicherheitshalber in ein selbst extrahierendes EXE - File, falls wir unterschiedliche Versionen haben. Mitarbeiter: Wenn Sie meinen ...... ...
Diese Kurze Zeit später ist die E-Mail in der Firma angekommen, der Mitarbeiter extrahiert das Dokument, läßt es nach Viren durchsuchen, und macht sich an die Arbeit. Die ISDN-Verbindung bleibt noch ein paar Minuten bestehen, danach beendet die Software die Verbindung. Am nächsten Tag schaltet der Mitarbeiter seinen PC wie gewohnt an, ruft seine E-Mail ab, surft, faxt.
Was der Mitarbeiter nicht bemerkt hat, ist, daß in der Autoexec.xxx - Datei stets ein kleines Programm als Treiber mit gestartet wird, welches im Taskmanager nicht weiter auffällt, da es auch findfast (findfast erscheint auch so öfter mal mehrmals...) genannt wurde. Das eingeschleuste Programm kontrolliert die routen des Kernels (DOS-SHELL: route_-print ), stellt fest, daß eines oder mehrere Gateways aktiv sind, und sendet in dem Moment, wenn eine ISDN-Verbindung besteht, fleißig WinWord und Excel Dokumente als gezippte ASCII Datei zu einem unbekannten Server im Internet. Das EXE-File ist zwar ein Selbstextrahierendes ZIP-File, nur kommt es aber nicht von PKWARE. Es ist ein Eigenbau, welcher auf freien Quellen basiert. Dieses Programm könnte sich auch z.B. an Netscape.exe oder explorer.exe angehängt haben, sodaß es stets mit startet. Es wartet, wenn die ISDN-Verbindung unterbrochen wird. Es wäre auch möglich gewesen, ein kleines Programm, wie BO mit Plugins oder NetBUS zu installieren, welches sich stets zu den Zeiten meldet, wenn der User online ist, und somit unauffällig Fernadministration zulässt. Da nur bekannte trojanische Pferde von den Virenscannern erkannt werden, bleibt die Installation unentdeckt. Durch Hinzufügen einer Löschroutine lassen sich sämtliche Spuren wieder beseitigen
Die Erstellung eines solchen trojanischen Pferdes ist relativ einfach, sofern man die Quellen kennt, und ein wenig programmieren kann, und genügend Einfallsreichtum besitzt. Dank ausgereifter Compiler und umfangreichen, freien Bibliotheken ist noch nicht einmal der Einsatz von original Microsoft - Software notwendig. (http://www.cyrus.com) Da Fa. Microsoft mit der Einführung der winsock 2.0/2.1 die Kompatibilität zu UNIX weitestgehend hergestellt hat, reduzieren sich die Entwicklungszeiten besonders im Bereich Netzwerk erheblich. Ebenso einfach ist auch die Einbindung eines Makro´s in die Benutzeroberfläche von Windows 95/98/NT 4.0, dem Internet - Explorer. Diese Oberfläche ist beliebig umprogrammierbar. Da in relativ vielen Unternehmen Mitarbeiter einen eigenen Anschluß besitzen, ist die Wahrscheinlichkeit relativ hoch, daß ein Angreifer mit diesen Tricks eine Firewall umgehen oder sogar unauffällig ausschalten kann. Vielfach betroffen sind auch Behörden.
Es gibt in Deutschland bald 4 Millionen User mit Internet - Anschluß. Kaum jemand fühlt sich durch Hackerangriffe bedroht, da ja Kontakte über Internet weitestgehend anonym bleiben können. Es gibt aber mit rasant wachsender Anzahl Hacker , die mit z.B. SMB- Scannern riesige Listen von IP - Nummern von DIAL-IN Anschlüssen von Providern tagelang durchforsten. Wer es nicht glaubt, der möge sich einen Scanner installieren und die Pakete, die am PC ankommen genauer betrachten. Es sind pro Stunde einige Dutzend Einschläge zu verzeichnen. Wer´s nicht glaubt, installiere sich einen Scanner, und warte. (http://www.signal9.com) Diese Hacker sind auf der Suche nach PC´s, auf denen das Laufwerk C: zum Schreiben freigegeben ist. Haben sie einen gefunden, so installieren sie schnell BO und durchforsten die Festplatte nach Briefen u.s.w. Sehr viele Pädophile oder Homosexuelle Surfer benutzen IRC - Clients, um untereinander zu kommunizieren, oder, was weit häufiger der Fall ist, gesetzlich verbotene Bilder auszutauschen. Diese IP - Nummern von IRC- Mitgliedern werden routinemäßig von Hackern auf Verletzbarkeiten überprüft, um evtl. BO zu installieren. Man kann davon ausgehen, daß tausende von Lehrern, Professoren, Angestellte u.s.w. auf diesem Wege Opfer von Erpressungen werden. Andererseits gibt es im Internet einige zwielichtige Personen, die als selbsterklärte Polizisten auf diesem Wege die Kinderpornografie bekämpfen. Diese geben nach solchen Angriffen Tips an die Polizei.
Im Kapitel Geschichten zum Nachdenken werden Nachlässigkeiten von Systemadministratoren beschrieben, die zu einem erheblichen Schaden führen können... Die Informationen sind natürlich frei erfunden, zeigen aber, was so passieren kann....:)
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |