Domain Trust: Altbekannte Sicherheitslücke

Manchmal dauert es lange, bis die Wellen einer Erschütterung am Ufer anlangen. So etwa bei der Domain Trust Vulnerability des Windows Server, die schon seit mehreren Jahren bekannt ist, nun aber wieder zum Thema wird. Gerade an diesem Fall wird auch deutlich, wo das grösste Sicherheitsrisiko für Unternehmen liegt - nämlich bei Benutzern mit umfassenden Rechten und physischem Zugang zu Servern.

Die Grundidee von Domänen ist es, Verwaltungseinheiten unter anderem für das Benutzermanagement zu schaffen. Die Informationen werden auf sämtliche Domänencontroller repliziert - die Domäne soll dabei auch als Sicherheitsgrenze dienen. Administratoren sind jeweils für eine einzige Domäne zuständig und können andere Domänen nur verwalten, wenn ihnen dort explizit entsprechende Berechtigungen eingeräumt werden.

Für die domänenübergreifenden Zugriffe spielen dabei Vertrauensstellungen eine zentrale Rolle. Über diese wird festgelegt, welche Domäne den Zugriffen anderer Domänen vertraut. So kann sich ein Benutzer in einer Domäne anmelden und später auf eine vertrauende Domäne zugreifen: Bei diesem Zugriff vertraut die vertrauende Domäne der Anmeldedomäne und führt keine erneute Authentifizierung durch.

Gefälschte Identitäten

Dieses im Prinzip sinnvolle Konzept, mit dem Zugriffe über die Grenze von Domänen hinweg überhaupt erst möglich werden, kann aber für Angriffe missbraucht werden. Dazu wird ein modifiziertes Access Token benötigt.

Access Tokens werden bei der Authentifizierung erzeugt. Sie belegen die erfolgreiche Authentifizierung und enthalten Informationen über die Identität eines Benutzers und die Gruppen, zu denen er gehört. Diese Infos werden in Form von SIDs (Security Identifier) geliefert. SIDs bestehen aus einem Teil, der die Domäne identifiziert, und aus einem relativen Teil, dem RID (Relative Identifier), der innerhalb einer Domäne eindeutig ist. SIDs werden gleichermassen für Benutzer wie für Gruppen verwendet.

Solche Access Tokens werden schlicht akzeptiert und nicht mehr überprüft, wenn sie von einer vertrauten Domäne stammen. Das bedeutet, dass auch "gefälschte" Tokens übernommen werden. Für solche Veränderungen gibt es zwei prinzipielle Ansätze: Theoretisch kann bei physischem Zugang zum Server das Betriebssystem so modifiziert werden, dass es gefälschte Tokens erstellt. Diese Variante ist in der Praxis allerdings sehr umständlich und kaum relevant.

Dagegen ist es durchaus möglich, den Inhalt von Tokens anzupassen. Die Basis dafür bildet ein Attribut des Benutzer-Objekts, die SIDHistory. Dieses Attribut gibt es im Active Directory, wenn dieses mindestens im einheitlichen Modus von Windows 2000 betrieben wird. Es enthält frühere SIDs eines Benutzers aus anderen Domänen. Ein Angreifer - der dazu administrative Berechtigungen in der vertrauten Domäne benötigt - könnte nun dieses Attribut modifizieren und die SID eines Administrators der vertrauenden Domäne aufnehmen.

Das ist zwar nicht trivial, weil es keine offengelegte API dafür gibt. Es ist aber möglich, weil etwa Microsofts ADMT (Active Directory Migration Tool) solche Anpassungen vornehmen kann. Und es ist denkbar, dass jemand ein kleines Programm schreibt, mit dem Administratoren diese Anpassung einfach durchführen können.

Wenn ein Administrator so die SID-History eines Kontos ändert und sich damit an seiner Domäne anmeldet, kann er über die unberechtigt hinzugefügte SID des Administrators der angegriffenen Domäne in der SID-History auf eine andere, vertrauende Domäne mit administrativen Berechtigungen zugreifen.

Lösungsansätze

Das klingt kompliziert und ist in der Praxis auch tatsächlich nicht einfach durchzuführen. Es setzt voraus, dass ein Administrator andere Domänen angreifen möchte, die typischerweise im gleichen Forest sind, weil dort automatisch die Vertrauensstellungen erzeugt werden.

Um das Risiko zu verringern, dürfen administrative Berechtigungen daher nur an sorgfältig ausgewählte Mitarbeiter vergeben werden. Ausserdem müssen Domänencontroller in gesicherten Räumen stehen. Domänen, die für Angriffe von aussen besonders gefährdet sind, sollten nicht in den Forest eingebunden werden, weil dort das Risiko eines kompromittierten Administrator-Kontos besonders hoch ist.

Ab Service Pack 4 für Windows Server 2000 und beim Windows Server 2003 ist darüber hinaus auch die SID-Filterung aktiviert. Dabei werden alle SIDs in Access Tokens ausgefiltert, die nicht aus der Authentifizierungsdomäne stammen. Die Filterung wird aber nur bei expliziten Vertrauensstellungen und nicht innerhalb eines Forest genutzt, weil sie im Forest die Replikation und die Forest-weite Administration verhindern würde.

Wem diese Massnahmen nicht ausreichen, muss mit mehreren getrennten Forests arbeiten und nicht mit mehreren Domänen in einem Forest - mit allen Konsequenzen wie etwa unterschiedlichen Namensräumen für die Domänen.

Grafik: Schutz per SID-Filterung