|
2.3.1 RPC und Protmapper
Das Remote Procedure Call (RPC)-Protokoll von Sun ist die Grundlage vieler neuerer Dienste. Unglücklicherweise stellen viele dieser Dienste ein potentielles Sicherheitsrisiko dar.
Der Entwickler eines neuen Dienstes definiert in einer speziellen Sprache die Namen und Parameter der externen Funktionsaufrufe. Ein Präcompiler übersetzt diese Spezifikation in sogaenannte stub-Routinen für die Clienten- und Servermodule. Diese "stubs" ragen gleichsam auf Clienten- und Server-Seite heraus und "kleben" beide Seiten über das Datennetz zusammen. Der Client ruft seinen "stub" wie ein normales Unterprogramm auf und aktiviert damit auf dem Server den zugehörigen Aufruf. Die meisten Probleme verteilter Programmierung werden durch RPC-Abstraktion umgangen.
RPC kann sowohl auf TCP als auch auf UDP aufsetzten. Die meisten grundlegenden Charakteristika des Transportmechanismus scheinen durch. Ein Subsystem, welches RPC über UDP nutzt, muß sich also mit verlornenen, duplizierten oder umsortierten Nachrichten herumschlagen.
RPC-Nachrichten haben einen eigenen Header. Er enthält die Programmnummer, die Procedurnummer, welche den gewünschten Aufruf kennzeichnet und einige Versionsnummern. Weiterhin enthält der Header eine Laufnummer, die die Zuordnung von Antworten zu Anfragen erlaubt.
Es gibt auch ein Authentifikationsfeld. Es enthält die sogenannte UNIX-Authtifikation, bestehend aus aus der Benutzer- und Gruppennummer des rufenden Prozesses und den Namen des Quellsystems. Große Vorsicht ist hier angebracht. Dem Quellsystemnamen sollte man nie trauen. Auch die Benutzer- und Gruppennummern sind nicht sehr viel wert. Auf solchen Nachrichten basierend sollte man niemals sicherheitsrelevante Aktionen einleiten.
Neuere Versionen von RPC (secure RPC) unterstützen auch kryptographische Authentifikation mittels DES, dem Data Encryption Standard. Das Distributed Computing Environment (DCE) von OSF setzt zur Authentifizierung Kerberos ein.
RPC-basierte Server sind normalerweise nicht an bestimmte Port-Nummern gebunden. Sie akzeptieren die Port-Nummern, die ihnen das Betriebssystem zuteilt, und lassen diese Zuordnung vom portmapper registrieren. Der portmapper wirkt als Vermittler zwischen RPC-Servern und -Clienten. Um einen Server zu kontaktieren, erkundigt sich der Client erst bei dem portmapper der Zielmaschine nach Portnummer und Protokoll (UDP/TCP) des Dienstes. Der eigentliche RPC-Aufruf wird auf Grundlage dieser Information ausgelöst.
Der portmapper hat weiter, nicht unbedingt zuträgliche Fähigkeiten. So gibt es beispielsweise einen Aufruf, um einen Dienst abzumelden. Dies ist ein gefundenes Fressen für Denial-of-Service-Angriffe, da der Aufruf unzureichend gesichert ist. Der portmapper teilt darüberhinaus jedem im Datennetz freudig mit, welche Dienste angeboten werden. Dies ist eine extrem nützliche Planungshilfe für den Angreifer. (In sichergestellten Hacker-Protokollen haben sich viele solcher portmapper-Tabellen gefunden, die der Freigebigkeit des normalen rpxinfo-Befehls zu verdanken sind.
Das größte Problem des portmapper ist aber seine Fähigkeit, indirekte RPC-Aufrufe zu ermöglichen. Um den Aufwand einer Anfrage nach der tatsächlichen Port-Nummer, der Antwort und dem eigentlichen RPC-Aufruf zu vermindern, kann der Vlient den portmapper beauftragen, den RPC-Aufruf an den gewünschten Server weiterzuleiten. Diese weitergeleitete Nachricht trägt aber notwendigerweise die Quelladresse des portmapper. Damit wird es den Applikationen unmöglich, diesen Auftrag von echten lokalen Aufträgen zu unterscheiden und dessen Vertrauenswürdigkeit zu beurteilen.
Es ist darauf zu achten, nur gesicherte portmapper Versionen zu verwenden.
2.3.2 NIS - Network Information Service
Eine der gefährlichsten RPC-Applikationen ist der NIS. NIS dient der Verteilung wichtiger, zentraler Konfigurationsdateien von einem Server an seine Clienten. Darunter fallen Paßwortdatei, die Tabelle der Host-Adressen sowie die öffentlichen und privaten Tabellen der Schlüsselverwaltung für secure RPC.
Eine Reihe von Risiken ist offensichtlich. Kommt ein Angreifer in Besitz der Paßwortdatei, hat er einen kostbaren Fang gemacht. Die Schlüsseltabellen sind beinahe so gut: Die privaten Schlüssel der Benutzer sind in der Regel mit ihren Paßworten verschlüsselt.
Falls der zentrale Server ausfällt, brauchen NIS-Clienten einen Stellvertreter. Bei einigen Versionen kann man die Clienten - ferngesteuert - anweisen, auf einen anderen, eventuell betrügerischen NIS - Server umzuschalten. Dieser kann dann erschwindelte Einträge für /etc/passwd, Host-Adressen usw. bereitstellen.
Die gefährlichsten Operationen lassen sich bei manchen NIS-Versionen abschalten
2.3.3 NFS - Network File System
Ursprünglich von Sun entwicklet, wird NFS haeute von den meisten Computern unterstützt. NFS basiert auf UDP-RPC. Ein NFS-Server merkt sich keinen Kontext, sondern behandelt jede Anfrage unabhängig. Damit muß auch jede Anfrage eigens authentifiziert werden.
Grundlegend ist das Konzept des File Handle, eines eindeutigen Kennzeichen für jede Datei oder jedes Verzeichnis auf einer Festplatte. Alle NFS-Aufträge bestehen aus einem File Handle, der gewünschten Operation und den notwendigen Parametern. Anfragen, die Zugriff auf eine neue Datei, wie etwa open, liefern dem Clienten einen neuen File Handle zurück. Die File Handle werden vom Clienten nicht interpretiert. Sie bestehen aus den vom Server benötigten Verwaltungsinformationen und einer zufälligen Komponente.
Wird ein Dateisystem gemountet, so erhält man das Handle für sein Wurzelverzeichnis. Der Mount-Dämon des Servers, ein RPC-Dienst, prüft den Host-Namen des Clienten, das angeforderte Dateisystem und den gewünschten Zugriffsmodus (read/write - read only) anhand einer Konfigurationsdatei. Zulässige Anfragen werden mit dem File Handle für die Wurzel des Dateisystems beantwortet.
Solange ein Client über ein solches Wurzel-Handle verfügt, hat er permanenten Zugriff auf das Dateisystem. Zwar bitten normale Clienten bei jedem Mount, also meistens beim Systemstart, erneut um Zugriffserlaubnis, aber nichts zwingt sie zu dieser freundlichen Geste. (Der Kernel könnte dies prinzipiell durch eigene Zugriffskontrollisten durchsetzten. Dies wird aus Effizienzgründen häufig unterlassen.) Die Zugriffskontrolle von NFS beim Einhängen von Dateisystemen erweist sich damit als unzureichend. Weder ist es möglich, die Befugnisse von Clienten, die schoon NFS-Zugriff hatte, nachträglich einzuschränken, noch gibt es Schutz gegen Benutzer, die File Handle für Dateisystemwurzeln bekanntgeben.
File Handle werden normalerweise bei der Erzeugung eines Dateisystems mit Hilfe eines Pseudozufallsgenerator bestimmt. (Bei einigen älteren NFS-Versionen war der Startwert unzureichend zufällig - und damit vorhersagbar.
|
