© Christian Redolfi, Photocase.com
Host-basierte Authentifizierung hat einen Vorteil: Admins richten sie schnell ein. Als Nebenwirkung lassen sie allerdings schnell ungebetene Gäste auf ihre Fileserver, sofern sie noch NFS benutzen, das nicht ernsthaft authentifiziert. Doch das ist nicht das einzige Problem. Zum Schaudern, aber kein Märchen.
Der IT-Leiter einer renommierten Bausparkasse war sich relativ sicher, an alles gedacht zu haben: Virenschutz auf neuestem Stand, eigene Zonen für Desktops und Server, Firewalls an neuralgischen Punkten und regelmäßige Updates für die Betriebssysteme. Großen Wert legte er auf "stabile Versionen" von Betriebssystemen, Anwendungen und Protokollen, denn die seien besser auf Sicherheitsprobleme überprüft.
Meist stimmt das auch. Dennoch gilt es, die Augen offenzuhalten. Bekannt ist nämlich, dass NFS in der Version 3 nach wie vor inhärent unsicher ist - und das seit mehr als zehn Jahren. 1995 veröffentlichte Sun Microsystems das Protokoll als RFC 1813 [1], entwickelt hatte die Firma die Version sogar noch früher.
Schon damals kritisierten Experten das Protokoll, das Datenblöcke unverschlüsselt übermittelt (siehe Abbildung 1), nur rudimentär authentifiziert und dessen Autorisierung leicht zu umgehen ist (siehe Kasten "Sicherheitsfunktionen von NFS"). In den 1990er Jahren bauten viele Sicherheitsmodelle darauf, dass jeder Systemverwalter zu den Guten gehöre. Wer also IP-Adressen setzen oder beliebige, insbesondere privilegierte Ports öffnen konnte, führte per definitionem nichts Böses im Schilde. War die Annahme damals schon fragwürdig, so beweist heute jede Live-CD, dass nicht viel dazu gehört, auf jedem Rechner Root zu sein.
Abbildung 1: NFSv3 überträgt Daten unverschlüsselt. Im Bild hat Wireshark einen NFS-Zugriff auf eine Textdatei mitgeschnitten.
|
Sicherheitsfunktionen von |
|---|
| Im klassischen NFS authentifizieren Server nur beim Mounten eines Volume anhand der IP-Adresse des Clients und seines privilegierten Ports. Beide sind leicht zu fälschen. NFS nennt dem, der sich ausweist, ein Handle. Wer es präsentiert, erhält Zugriff auf Daten. Zugriffsrechte prüft nur der Client. Da das Protokoll nicht verschlüsselt, lassen sich sowohl Handles als auch Daten einfach abhören (siehe Abbildung 1). Es ist für einen Angreifer allerdings aufwändig, von den Handles zu profitieren, dazu ist Programmieraufwand nötig. Einfacher sind die im Artikel beschriebenen Methoden, für die Bordmittel ausreichen. Um NFS zu verbessern, plante Sun ursprünglich die RPC-Verbindungen per Secure RPC abzusichern. Doch bereits 1995 erschienen Dokumente, die dessen Tauglichkeit anzweifelten [2]. War damals noch ein großer Rechner mit dem Angriff einige Tage beschäftigt, löst ein heutiger PC die Aufgabe in Stunden. Daher verwarfen die NFS-Architekten letztlich Secure RPC und konzentrierten sich ab 2000 auf NFSv4, das mehr Sicherheitsfunktionen eingebaut hat. Weil es ausschließlich TCP nutzt, lässt es sich auch besser mit Firewalls und VPNs absichern. Es verwendet mit RPCSEC_GSS ein API, das auch gestandene Sicherheitsarchitekturen wie Kerberos zur Authentifizierung erlaubt. Alternativ sichern Admins NFS, indem sie es komplett vom sonstigen öffentlichen Bereich trennen, etwa über VLANs. |
So musste auch der eingangs genannte IT-Leiter lernen, dass ein NFSv3 ohne besondere Schutzmaßnahmen - und diese Konfiguration trifft auf viele der Installationen zu, wie die Umfrage bei NFS-Admins in diesem Heft zeigt - ein überraschend großes Loch in interne Sicherheitsmechanismen reißt. Ob die ebenfalls dort gemachte Beobachtung, dass IT-Verantwortliche der internen Sicherheit generell weniger Beachtung schenken, Trost spendet, darf bezweifelt werden.
Das Linux-Magazin stellt einen typischen Angriff auf eine NFS-Konfiguration nach und erklärt die einzelnen Schritte, die einen Angreifer zu den Kronjuwelen einer IT-Abteilung führen. Der Angriff setzt voraus, dass der Blackhat Zugriff auf das interne Netz hat. Über das Internet erlangt heute kaum noch ein Angreifer diesen Zugang, da Unternehmensfirewalls das meist erfolgreich verhindern. Man denke jedoch an Netzdosen in Besprechungsräumen, den Zugang, den häufig wechselndes Reinigungspersonal hat, oder an einen kleinen WLAN-Router. Den könnte ein Angreifer bei einem konspirativen Besuch an unverfänglicher Stelle hinterlassen haben. So ist er mitten im Geschehen. Für die weiteren Schritte benötigt er nicht einmal administrative Rechte auf seinen Angriffszielen.
Als Erstes sucht der Angreifer nach NFS-Servern, die ihre Dienste im Unternehmensnetz anbieten. Ist deren IP noch nicht bekannt, ist seit über einer Dekade der Scanner Nmap [3] das Mittel der Wahl: Nachdem der Angreifer mögliche IP-Bereiche seines Angriffsziels herausgefunden hat - etwa durch Blick in ein Sniffer-Log -, startet er seine Suche gezielt. Nach RPC-Portmappern unter TCP-Port 111 forscht »nmap -n -v -sS -P0 -p111 Bereich«. Im Vergleich zum vollen Scan nach mehreren Tausend Ports pro System ist dieser entsprechend schnell abgeschlossen. Treffer notiert sich der Cracker in der Datei »upips.txt«. So kann er im zweiten Schritt gleich genauer hinschauen:
nmap -n -v -sSVR -O -i upips.txt
Als Scanmethode »-s« fordert er einen Half-Open-Scan an (»S«), den er im Erfolgsfall mit einem Versionscan (»V«) und einer Abfrage der RPC-Aufrufe (»R«) ergänzt. Das Ergebnis bei einem NFS-Server sieht ähnlich wie in Listing 1 aus.
|
Listing 1: Scanergebnisse bei |
|---|
01 Interesting ports on 192.168.1.200: 02 PORT STATE SERVICE VERSION 03 21/tcp open ftp ProFTPD 1.3.0 04 22/tcp open ssh OpenSSH 4.3p2 Debian 8ubuntu1.4 (protocol 2.0) 05 111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000) 06 143/tcp open imap Cyrus IMAP4 2.2.13-Debian-2.2.13-1 07 869/tcp open mountd (mountd V1-3) 1-3 (rpc #100005) 08 2049/tcp open nfs (nfs V2-4) 2-4 (rpc #100003) 09 MAC Address: 00:aa:ff:ee:01:23 (Fortytwo Systems) 10 Service Info: Host: alpha.example.com; OSs: Unix, Linux |
Die NFS-Entwickler haben das OSI-Schichtenmodell voll ausgereizt, neben der Verbindungs- (IP) und der Transportschicht (TCP) verwalten sie eine Sitzung auch noch mittels RPC und führen mit der External Data Representation (XDR) eine eigene Datenkodierung ein. Zumindest die RPC-Aufrufe zeigt der Nmap-Scan gut an. Der Rpcbind in Zeile 5 vermittelt RPC-Anfragen an andere Ports weiter, etwa den »mountd« in Zeile 7, der für den Verbindungsaufbau zuständig ist, oder den eigentlichen »nfsd« in Zeile 8, der die Daten ausliefert oder entgegennimmt. Abbildung 2 verdeutlicht diesen Aufbau.
Abbildung 2: Die Sicherheit von NFSv3 leidet darunter, dass sich das Dateisystem beim Zugriff auf authentische Identitäten verlässt. Das Protokoll stützt sich nämlich auf Angaben des anfragenden Clients.
Von diesen Diensten erhält der Angreifer wertvolle Informationen. Dazu benötigt er nicht einmal besondere Hackerwerkzeuge, die mitgelieferten Admin-Tools reichen. Eines heißt Showmount und zeigt mit »showmount -e alpha« die exportierten Freigaben des NFS-Servers an:
Export list for alpha: /opt/someapp * /mnt/cdrom everyone(ro) /home *.example.com,192.168.1.66
Die erste Spalte enthält das freigegebene Verzeichnis auf dem Server »alpha«, das NFS auch Volume nennt [4]. In der zweiten Spalte führt das Kommando auf, welche Clients auf das Volume zugreifen dürfen. Je nach NFS-Server gibt es unterschiedliche Schreibweisen für zugelassene Clients, auf jeden Fall sind aber IP-Adressen und DNS-Namen darunter. Ein Sternchen oder der Text »everyone« zeigen an, dass keine Beschränkungen für das Volume bestehen. Oft nutzen Admins dies für CD-ROMs oder statische Daten, die nur lesbar sind. Die Ergänzung »(ro)« in runden Klammern zeigt das an.
DNS-Namen löst der NFS-Server selbst in IP-Adressen auf, sodass er anfragende Clients letztlich anhand von IP-Adressen authentifiziert. Leider lassen sich IP-Adressen in lokalen Netzen besonders einfach fälschen. Im Beispiel sind etwa alle DNS-Namen der Domäne »example.com« erlaubt. Eine Abfrage des internen DNS-Servers mit »dig example.com axfr« könnte bereits eine vollständige Liste aller bekannten Hostnamen und ihrer zugehörigen IP-Adressen liefern. Alternativ hilft dem Angreifer gezieltes Raten weiter, wenn er bereits einige Hostnamen kennt oder er sie durch einen Sniffer aufgefangen hat. In jedem Fall stellt er eine Liste der zugehörigen IP-Adressen zusammen und prüft, welche er davon unter seine Kontrolle bringen kann.
Die Adressen sollten im gleichen Segment liegen, in dem sich der Angreifer bereits befindet. Wenn viele Anwender-Clients ihre Homedirectories vom NFS-Server beziehen, ist das oft der Fall. Nun gilt es, eine berechtigte IP-Adresse zu finden, die gegenwärtig unbenutzt ist. Gerade in den Abendstunden schalten viele Mitarbeiter ihre Computer aus. Das Kommando
ping -c3 192.168.1.66
prüft, ob der angegebene Host aktiv ist. Dazu verschickt das Tool drei ICMP-Pakete an ihn (siehe Listing 2). Wer sichergehen will, dass das Ziel nicht einfach ICMP blockiert, prüft zusätzlich, ob der Aufruf von »arp -na« die Adresse auflösen kann:
? (192.168.1.1) auf 00:31:42:42:42:13 eth0 ? (192.168.1.66) auf <unvollständig> eth0
Während für die Adresse 192.168.1.1 eine MAC-Adresse bekannt ist, konnte ARP das anvisierte Ziel nicht auflösen. Die Adresse ist also frei. Auf einem Linux-System lassen sich IP-Adressen ganz leicht fälschen. Root konfiguriert sie einfach auf das Interface:
ifconfig eth0 192.168.1.66 up
Pech hat ein Angreifer, der nicht weiß, dass dieser Hack mit virtuellen Interfaces wie »eth0:1« fehlschlägt: NFS-Clients verwenden die erste Adresse ihres Interface für Anfragen und keine zusätzlich konfigurierten IPs. Mit dieser Vorbereitung versucht der Angreifer als Root mit
mkdir /tmp/MNT mount -t nfs 192.168.1.200:/home /tmp/MNT
einen lokalen Mountpoint anzulegen und dann das exportierte Volume »/home« per NFS einzubinden. Erscheint nur der Prompt, steht die Verbindung.
Der lokale Root erlebt auf der eingehängten Platte meist eine kleine Enttäuschung: Gewohnt als Superuser alles lesen zu dürfen, ist ihm auf dem NFS-Volume plötzlich vieles verwehrt. Letztlich ist dieses Verhalten, das in der Konfiguration gelegentlich »root_squash« heißt, allerdings leicht zu umgehen. Mit »ls -ln« schaut sich der Angreifer die numerischen User-IDs der Dateibesitzer an. Für diese legt er Einträge in seiner lokalen »/etc/passwd« an und ändert mittels »su - Opfer« seine Identität - Root darf das.
|
Listing 2: Prüfen, ob die |
|---|
01 # ping -c3 192.168.1.66 02 PING 192.168.1.66 (192.168.1.66) 56(84) bytes of data. 03 From 192.168.1.175 icmp_seq=1 Destination Host Unreachable 04 From 192.168.1.175 icmp_seq=2 Destination Host Unreachable 05 From 192.168.1.175 icmp_seq=3 Destination Host Unreachable 06 07 --- 192.168.1.66 ping statistics --- 08 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms |
Umfang: 3 Heftseiten
Preis € 0,99
(inkl. 19% MwSt.)
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
