Security ID (SID)
Security IDs (SID) werden von Windows zur internen Identifikation von Benutzerkonten und anderer Sicherheitsobjekte verwendet. Wann immer Rechte unter Windows NT / 2000 vergeben werden, wird nicht der Name des Benutzers verwendet, sondern dessen ID. Die SID wird bei Anlegen des Objekts erstellt. Jede SID ist immer nur einem Objekt zugewiesen.
SIDs werden auch von Applikationen verwendet. Ein Beispiel dafür ist Microsoft Exchange Server. Auch dort wird das Postfach nicht mittels des Benutzernamens, sondern der SID zugeordnet.
Im Active Directory spiel die SID eine große Rolle. In der ID wird auch die Domänenzugehörigkeit hinterlegt. Daraus ergibt sich dann zwangsläufig, dass ein User, der die Domäne wechselt auch seine SID wechselt. Die Verschiebung eines Users in eine andere Domäne sollte also wohl überlegt sein.
Die SID erscheint wie ein zufällig generierter Zahlencode - dahinter verbirgt sich aber ein streng systematischer Aufbau.
Die SID verrät uns 2 Dinge:
- Wer hat die SID herausgegeben
- Wer wird von dieser SID dargestellt
Die Autorität und die Subautorität stellen zusammen den Herausgeber dar.
Subautoritäten können sehr unterschiedlich aussehen oder auch komplett fehlen.
Wenn keine Subautorität vorhanden ist, sind das z.B. Gruppen, die von der SAM des Rechners verwaltet wird und keine Relativen Identifier benötigen.
Standardsubautoritäten sind z.B. 32 - die stehen für automatisch erzeugte Benutzergruppen von Windows aus. S-1-5-32-544 steht für Gruppe Administratoren.
Die 21 steht für nachträglich angelegte Benutzer und / oder Gruppen (siehe SID oben)
Die individuelle Subautorität kennzeichnet den Rechner oder die Domäne auf der dieses Objekt erstellt wurde. Dieser einmalige Zifferncode wird aus verschiedenen eindeutigen Faktoren berechnet. Im obigen Beispiel handelt es sich also um ein nachträglich erstelltes Benutzerkonto, welches auf dem Computer erstellt wurde, der durch 1715567821-179605362-839522115 gekennzeichnet ist.
Die Revisionsnummer und die Autorität ergeben die Hauptautoritäten:
SECURITY_NULL_SID_AUTHORITY | S-1-0 | noch nicht zugeordnete SIDs |
SECURITY_WORLD_SID_AUTHORITY | S-1-1 | in allen Systemen gleich. Gruppe Jeder z.B |
SECURITY_LOCAL_SID_AUTHORITY | S-1-2 | Ein User, der sich lokal anmeldet bekommt eine solche ID |
SECURITY_CREATOR_SID_AUTHORITY | S-1-3 | wird für Ersteller/Besitzer eines Objektes benutzt |
SECURITY_NT_AUTHORITY | S-1-5 | NT Autorität - zuständig für Benutzerkonten und Gruppen |
Der letzte Teil, nämlich die 500, ist der Relative Identifier (RID). Diese Zahl wird dem Ende der SIDs angehängt, um eindeutige SIDs für Benutzer und Gruppen zu erstellen. Nachträglich erstellte Benutzerkonten beginnen z.B. mit der Zahl 1.000 und werden fortlaufend vergeben.
RIDs von 500-999 sind systemeigene RIDs, die fest zugeordnet sind. Das Administratorkonto hat z.B. die 500.
Die RIDs werden niemals doppelt vergeben. Es erfolgt immer eine eindeutige Zuordnung. Selbst wenn der Benutzer Nicki gelöscht wurde und eine neuer Benutzer Nicki angelegt wird, erhält der zweite eine eigene, andere RID.
Alle schon vergebenen RIDs werden in der SAM des jeweiligen Systems gespeichert und dort auch gesperrt um sie nur einmal zu vergeben.
Darum gehört der RID-Master zu den FSMO Rollen in einer Domäne. Fällt dieser einmal aus ist eine Neuerstellung eines Benutzers unmöglich.
Vordefinierte Gruppen RIDs sind z.B.:
DOMAIN_GROUP_RID_ADMINS | 512 |
DOMAIN_GROUP_RID_USERS | 513 |
DOMAIN_GROUP_RID_GUESTS | 514 |
DOMAIN_GROUP_RID_COMPUTERS | 515 |
DOMAIN_GROUP_RID_CONTROLLERS | 516 |
DOMAIN_GROUP_RID_CERT_ADMINS | 517 |
DOMAIN_GROUP_RID_SCHEMA_ADMINS | 518 |
DOMAIN_GROUP_RID_ENTERPRISE_ADMINS | 519 |
Vordefinierte Benutzer RIDs sind z.B.:
DOMAIN_USER_RID_ADMIN | 500 |
DOMAIN_USER_RID_GUEST | 501 |
Problematik der SIDs:
So sicher wie die eindeutige Zuordnung der SIDs ist, so viele Risiken bringt sie auch mit sich.
Da auch Hacker diese systematischen Zuordnungen der SIDs kennen nutzen sie diese Struktur um die Rechner angreifen zu können.
Angriffe können ganz leicht mit Tools wie User2SID durchgeführt werden.
Beispiel: aus Sicherheitsgründen (man liest es ja überall) wurde das Administratorkonto umbenannt. Der Angreifer kann nun nicht mehr mittels einer Brute Force Attacke versuchen das Administrator Konto zu knacken.
Da aber die eindeutige SID S-1-5-xxx-xxx-xxx-500 das Administratorkonto darstellt, wird der Angreifer versuchen darüber den geänderten Namen aufzulösen.
Zunächst muss der Hacken an die Subautorität des Systems kommen. Dazu benötigt er lediglich mittels einer Null-Session den Zugang zum Gast-Konto welches keiner Authentifizierung bedarf. Nun erfragt er mit dem Tool User2SID die Subautorität.
Wenn er jetzt den Relativen Identifier (RID) auf 500 setzt, hat er das Administratorkonto - natürlich das Umbenannte ;-)
Jetzt kann er wieder mit Brute Force Attacken versuchen sich mit dem geänderten Administratorkonto anzumelden.
Mit einem einzeiligen Script kann ich so sogar sämtliche Benutzer, die angelegt worden sind, in einer Textdatei speichern und kann mit den Angriffen beginnen.
Es reicht also nicht aus, das Administratorkonto umzubenennen. Man könnte z.B. ihm diverse Rechte nehmen und die Aufgaben anderen Konten zuweisen - in entsprechende administrative Bereiche aufgeteilt. Weg von dem Gedanken der Single-Master Funktion.
Nicki Wruck
© by unterwegs-im.net, Nicki Wruck
