Für alle Software-Entwickler, die zwar Debuggen können, aber nicht glauben, dass für das Debugging unter Windows unter bestimmten Umständen schon normale Benutzerrechte ausreichen, folgt hier eine kleine Anleitung, wie sie sich selber oder andere von Gegenteil überzeugen können.
Bis vor etlichen Jahren dachte auch ich, dass nur Administratoren debuggen können. Genährt wird die Annahme das durch entsprechende Einträge in den Gruppenpolicies und der Tatsache, dass man zum Entwickeln oftmals Adminrechte benötigt. Tatsächlich benötigt man aber für Anwendungen, die man selber starten kann, die also im eigenen Benutzerkontext ausgeführt werden, keine Admin-Rechte. Das birgt erhebliche Sicherheitsrisiken für Fat-Client-Anwendungen, die von einer Anzahl an Mitarbeitern auf deren Rechnern ausgeführt werden.
Normale Mitarbeiter können freilich eher keine Debugger bedienen. Tracer verwenden aber teilweise ähnliche Mechanismen, um Anwendungen viel bequemer auszuforschen. Sie sind leichter zu bedienen und die Ergebnisse einfacher weiter zu verwenden. Wo man debuggen kann, da kann man auch tracen, umgekehrt nicht unbedingt.
Die folgenden Anleitung ist recht spartanisch, sollte aber für alle Softwareentwickler ausreichend sein, um es selber auszuprobieren. Das Debuggen an sich wird nicht erklärt, weil das die Zielgruppe des Artikels schon kennt. Daher plaudert die Anleitung in meinen Augen nichts Sicherheitskritisches aus. Genau genommen ist sie sogar äußerst trivial. Sie soll auch nur dazu motivieren eigene Annahmen zu überprüfen, wenn es nötig ist.
Wenn also wieder mal jemand sagt, dass für Debuggng und Tracing Administratorrechte nötig sind, dann fragt ihn mal, ob er das ausprobiert hat…
Vorbereitung
Die Schritte habe ich unter Windows 7 Professional ausgeführt. Die Transferleistung auf andere Versionen ist aber gering.
Benutzer ohne Adminrechte anlegen:
- "cmd.exe" als Administrator ausführen.
- Dort ausführen: net user /add noadminuser topsecrpwd
- Mit "net user noadminuser" kann man prüfen, dass er wirklich nur Mitglied der Gruppe "Benutzer ist.
Debugger besorgen:
- Hier nehmen wir den vergleichsweise beliebten Debugger "Ollydbg". Ich kenne und nutze ihn sonst nicht und habe ihn vor allem deswegen ausgewählt, weil er keine Installation benötigt. Das darf ein normaler Benutzer nämlich nicht.
- Wir könnten den auch im kommenden Schritt download, wenn wir uns als Benutzer "noadminuser" anmelden. Aber der erste Start des Browsers dauert immer so lange, weil er Profile einrichtet, etc…
Durchführung
Dazu melden wir uns als der Windows-Benutzer "noadminuser" an, entpacken das Archiv mit Ollydbg irgendwohin, z.B, auf den Desktop. Mit einem Doppelklick auf Ollydbg.exe wird der Debugger gestartet.
Prompt werden wir mit dem Hinweis begrüßt, dass wir keine Admin-Rechte haben und daher einige Aktionen nicht möglich sind:
Das stört uns aber weiter nicht, wir wollen weder Remote-Debugging, noch andere fortgeschrittene Dinge tun.
Anschließend starten wir über "File | Open" die zu überwachende Anwendung "notepad.exe" aus dem Verzeichnis "C:\windows\system32". Daraufhin springt der Debugger in die Startsequenz der Anwendung. Mit einen Klick auf den Run-Button kommen wir in die eigentliche Anwendung und können debuggen:
Freilich kann man auch auf andere Arten debuggen, das ist nur ein Beispiel wie ich es machen würde. Hier kann jeder selber die Möglichkeiten ausprobieren. Der Proof-of-Concept ist damit abgeschlossen. Tests mit verschiedenen erhältlichen Tracern kann jeder Interessierte selber machen.
Aufräumen nicht vergessen
Wer dazu keine VM genutzt hat, der muss den Benutzer "noadminuser" auch wieder löschen. Das ist diesmal besser über die Systemsteuerung zu erledigen, weil dann alle Profil-Dateien mitgelöscht werden können.
