Wie werde ich lokaler Administrator?
Oder auch: Wie mache ich mich als
Benutzer zum Administrator?
Offline Angriffe auf das System mit einer
WinPE, einer Linux Boot CD oder dem Microsoft eigenem DaRT kann jeder, das ist
langweilig.
Ich mach mich zum Admin und bleibe in meinem Benutzerkontext.
Warum kann ich das? Weil der Admin nicht aufgepasst hat, oder weil ich miese
Software einsetze.
Siehe auch
TROST-(Tja,
Rein Optisch
Super
Tool)-Preis
Ein
wenig Hintergrundinformationen
Das Benutzerkonzept von Microsoft ist da sehr
eindeutig: Nur Administratoren oder gleichwertige Konten können Benutzer in die
Gruppe der Administratoren aufnehmen.
Hauptbenutzer können maximal neue
Hauptbenutzer erstellen, allerdings gibt es abWindows 7 diese Gruppe nicht mehr.
Genaugenommen, waren und sind Hauptbenutzer nur Benutzer, die etwas mehr dürfen
als der normale Standardbenutzer.
Sie dürfen z.B.: in %programfiles%,
%systemroot% und HKLM\Software ändern. Gewähre ich diese Rechte einem Benutzer,
dann ist er praktisch Hauptbenutzer, ohne daß er explizit in die Gruppe der
Hauptbenutgzer aufgenommen wurde.
Die wichtigste Frage vorweg:
Wie
kann ich mich als normaler Standardbenutzer zum Administrator machen?
Antwort: Aus eigener Kraft erst mal garnicht. Zum Glück. Dann würden ja
sämtliche Sicherheitskonzepte zusammenbrechen. Das darf nicht gehen.
Aber, es
geht doch, wenn ...
Klären wir das "wenn" und die Bedingungen, die ich
brauche.
Einziger Weg und damit die Lösung:
Ich brauche einen Account,
ein Konto, daß über die notwendigen Rechte verfügt und am Besten wäre es, wenn
es keiner mitkriegt.
Schritt für Schritt Anleitung:
1. Ich
erstelle eine eigene EXE Datei (Scripte würden auch gehen, aber executable hat
Vorteile), die mich zum lokalen Admin machen kann.
"net localgroup
Administratoren MeineDom\MeinBenutzer /add" in einer EXE verpackt reicht völlig
aus.
Eine eigene EXE zu erstellen ist nun wirklich keine Herausforderung,
man nehme z.B.: AutoIT
AutoIT Script:
----- admin.aut -----
Run (
"net localgroup Administratoren MeineDom\MeinBenutzer /add,"",@SW_HIDE)
-----
admin.aut -----
2. Ich ersetze die Programm EXE eines Dienstes mit meiner
EXE
Im Falle eines Dienstes muss ich abgesichert starten, denn dann ist der
Dienst nicht aktiv und kann ausgetauscht werden.
Im Laufenden Betrieb darf
ihn ja nur ein Admin stoppen.
3. Das System startet neu, startet den
Dienst mit meiner EXE und führt diese mit SYSTEM Rechten und damit VOLLZUGRIFF
auf dem Rechner aus.
3b. Alternativ nutze ich keinen Dienst, sondern ein
Programm auf dem Rechner, das regelmässig auch von einem Administrator verwendet
wird.
Nenne meine wie das Programm, benne die orginale um, dann sollte ich
unbedingt zu dem "net localgroup Administratoren MeineDom\MeinBenutzer
/add noch eine 2te Zeile packen, die das Programm selber startet ...
Hm
... sollte das so einfach sein? Wo ist der Haken?
Der Haken ist:
Ich
habe als Benutzer keine Schreibrechte an Programmen und Diensten. Ohne
Schreibrechte kann ich die EXE nicht austauschen. Mein System ist also vor dem
Angriff sicher.
Die Schreibrechte kann ich mir selber nicht gewähren. Das
kann nur ein Konto, das dazu berechtigt ist.
Das Problem und der Haken
sind also die Schreibrechte, die ich benötige.
Sicherheitsloch No.1:
Hauptbenutzer
Wer als Administrator mit Hauptbenutzern arbeitet hat praktisch
schon alle Bedingungen erfüllt. Denn ich habe in allen relevanten Systemordner
und sogar der Registry per Design Schreibrechte.
Sicherheitsloch
No.2: Programme, die nicht als Benutzer laufen
Ein erneuter Hinweis auf
TROST-(Tja,
Rein Optisch
Super
Tool)-Preis
Damit ein normaler Benutzer schlecht programmierte Programme ausführen kann,
muss ich als Administrator oft zusätzliche NTFS Berechtigungen definieren. In
den seltensten Fällen aber macht sich der Administrator die Arbeit, es
"feingranular" auf eine einzelne Datei runterzubrechen. Meist kommt die
Holzhammermethode zum Einsatz und das Streuprinzip "Viel hilft viel". Der ganze
Ordner %programfiles%\NamederAnwendung wird mit ändern Rechten bestückt.
Oft ist das auch garnicht anders möglich. Da sind wir auf die Wilkür des
Entwicklers angewiesen, der sich dort ausgetobt hat.
Es kann manchmal nur
eine Konfigurationsdatei sein, ich habe aber auch schon temporäre Dateien und
Ordner dort gefunden ... als ob %temp% nicht existieren würde.
Am Ende
habe ich das Dilemma: Ich gewähre Schreibrechte an einer ausführbaren Datei, die
unter %programfiles% liegt, in einem Pfad der eigentlich per Definition als
sicher gilt, da eben ein Benutzer dort NICHT schreiben darf.
Wenn ich als
Benutzer meine EXE ausführe, die ich anstelle des Programms hinterlegt habe
läuft sie logischerweise ins Leere. Der Befehl ergibt ein Zugriff verweigert. Im
Gegensatz zum Dienst, der ja mit SYSTEM Rechten läuft. Wie kann ich also nun
diese Datei mit Adminrechten ausführen?
Ich, als Benutzer garnicht. Aber
dafür gibt es ja den Level 1 Support und meine netten Helfer-Kollegen.
Ich
rufe dort an und melde ein Problem mit dem besagten Programm und sage den Jungs,
es wäre nett, wenn sie sich das mal in der Mittagspause anschauen könnten, dann
könnten sie an mein System ran.
Was wir normalerweise passieren? Der Helfer
wird sich mit seinem AdminAccount an meinem System anmelden und das Programm
starten. Er wird feststellen, daß alles funktioniert und mich für einen Idioten
halten, denn bei ihm gehts. Freundlicherweise hat er gerade mit seinen
Berechtigungen meine EXE ausgeführt, das weiss er aber nicht, denn wer schaut
sich schon die Eigenschaften einer ausführbaren Datei an und vor allem, wer
kennt schon die Eigenschaften der Orginalen? Er wird mal wieder auf die Anwender fluchen und mir
nach meiner Mittagspause mitteilen, daß ich das "Problem" mal bitte beobachten
möge, er kann nichts feststellen. Ich bedanke mich freundlich, lasse ein paar
Sätze über okultes PC Verhalten und Eigenleben fallen und alles ist gut.
Der
Supporter geht weg, ích bin Admin.
Fazit:
Bin ich Hauptbenutzer, bin
ich Admin.
Kann ich einen Dienst manipulieren bin ich beim nächsten Neustart
Administrator
Habe ich nur ein Programm zur Manipulation, bin ich
Administrator, muss aber etwas Zeit
mitbringen.
(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright