[dante]

Hallöchen!

Hab ein interessantes Progrämmchen gefunden. Mit diesem kann man als Benutzer best. Programm als Admin ausführen (so wie runas). Das Passwort wird in einer verschlüsselten Datei aufbewahrt. Somit muss es nicht jedesmal eingegeben werden Aber lest es euch selbst durch:

http://robotronic.de/runasspc/

Was haltet ihr davon, zwecks Komfort und Sicherheit? Ich arbeite zwar schon lange als normaler Benutzer, aber dennoch brauchen einfach bestimmte Funktionen Adminrechte.

greetings from dante

[BadAss]

Habe irgendwie nicht das Gefühl, das die Verschlüsselung wirklich was taugt, zumal der Schlüssel im Programm ist?

Aber wie gesagt, ist ein Gefühl, bin mal gespannt was andere sagen...

[Rika]

Wenn das Programm funktionieren soll, dann muss das Passwort auch wieder entschlüsselbar sein und entschlüsselt werden - und damit kommt man letztendlich immer heran. runas /savecred verschlüsselt übrigens auch.

Wesentlich interessanter ist eher die Frage, wie das Ding reagiert, wenn ich die Verknüpfung ändere und/oder das Executeable austausche.

Gibt's eigentlich ein gutes Tool für ein Pseudo-Runas über den Impersonation-Mechanismus?

[dante]

N'Abend!

Dass ein Passwort immer entschlüsselt werden kann ist klar. Die Frage ist nur mit welchem Aufwand Mein Passwort kann auch (z.B. durch einen Keylogger) bereits wärend der Eingabe während der Anmeldung bzw. im Betrieb abgefangen werden. Aber dazu muss das System ja erst mal durch einen Bösewicht befallen sein. Auch muss das Admin-Passwort irgendwo in Windows (verschlüsselt) gespeichert sein. Auch dort müsste man rankommen.

Zum Austausch der exe sagt der Autor:

Zitat

damit nicht jede Anwendung mit diesem Namen ausgeführt werden darf überprüft runasspc
die aufgerufene Anwendung mit der Anwendung die vom Ersteller der Cryptdatei berechtigt
wurde anhand des Bitmusters der aaufgerufenen Datei. Beipiel: Es gibt viele Anwendungen mit dem namen setup.exe. Runasspc führt aber
nur diese setup.exe aus welche vom Ersteller der Cryptdatei berechtigt wurde.
Der Trick eine nicht berechtigte Anwendung durch einfaches umbenennen zu berechtigen
funktioniert also nicht.

Ich finde, dass der Autor sein Konzept gut begründet und sehr kompetent wirkt.

dante

[Rika]

Zitat

Die Frage ist nur mit welchem Aufwand

Null. Das Runas-Tool wird ja stets zunächst im Kontext des Benutzers gestartet.

Zitat

Mein Passwort kann auch (z.B. durch einen Keylogger) bereits wärend der Eingabe während der Anmeldung bzw. im Betrieb abgefangen werden.

Nein. DU mögest dich über LSA+GINA informieren.

Zitat

Auch muss das Admin-Passwort irgendwo in Windows (verschlüsselt) gespeichert sein.

Nein. Es wird nur ein Hash zusammen mit einem Salt gespeichert.

Zitat

Der Trick eine nicht berechtigte Anwendung durch einfaches umbenennen zu berechtigen funktioniert also nicht.

Das heißt nur, daß er eine bekannte offensichtliche Macke nicht implementiert hat. Toll, das kann ich auch.

[Kr1x]

Zitat (Rika: 15.06.2005, 21:24)

Wesentlich interessanter ist eher die Frage, wie das Ding reagiert, wenn ich die Verknüpfung ändere und/oder das Executeable austausche.

anscheinend nicht wirklich genug: kein CRC checkup

Hi list,


Just found an implementation bug in MAST RunAsP.exe v3.5.1 and below,
that allows local privilege escalation.


Vendor: MAST-Computer
Homepage of product : http://www.mast-computer.com/c_9-s_7-l_en.html


Description of product:
For Windows 2000, Windows XP
RunAs Professional is a substitute for Microsoft's command runas.
RunAs Professional solves the problem that
normal runas does not support the commandline
parameter password.


Now you can use RunAs Professional to install
software, use it in batch scripts and much more.


Bug description:
This software uses a crypted .rap file to store
the parameters such as DOMAIN NAME/USERNAME/PASSWORD,
PATH and EXE name
in order to do a "runas" from a script.


A normal user is able to see the exe filename just by double clicking runasp.exe and load the .rap file
(here password is hidden)


It seems that the called exe is not CRC checked,
so it's possible for example to rename cmd.exe to the name of the original exe, so when running
the original script ("runasp test.rap" , you'll get a nice DOS box with administrator rights.


Workaround :
Modify code to embed CRC sum in crypted file


Can anyone confirm, thx ?


Vendor not yet contacted


Regards
traxx
=======================================
==> Visit us @ www.knowledgecave.com <==
=======================================

Original post: http://www.securityfocus.com/archive/1/402234/30/0/threaded

[Rika]

Aber dann doch lieber eine SHA1SUM, denn ist nun wirklich trivial, etwas an eine andere Dateien anzuhängen, sodaß sie die gleiche CRC-Prüfsumme wie eine bereits vorhandene Datei hat. Ebenso trivial ist die Modifikation der vorhandenen Datei, ohne die CRC-Prüfsumme zu ändern.

[sidan.maler2]

Da ich Runasspc seit 5 Monaten in einer Schule einsetze und immer wieder gelangweilte Hackerkids versuchen das System auszuhebeln, hatte ich vor dem Einsatz des Tools den Autor einmal direkt auf die Sicherheit von Runasspc angesprochen.

Hier mal ein paar Antworten vom Autor.

- Es wird nicht nur eine Prüfsumme in der verschüsselten Datei angelegt, sondern ein ganzes Bitmuster des freigegebenen Programmes wird verschlüsselt abgelegt und beim Aufruf gegengeprüft.
- Der Schlüssel wird zur Laufzeit aus der ausführbaren Datei, zusammen mit einem errechneten Passwort erzeugt. Jede Anwendung erhält dadurch einen eigenen Schlüssel kombiniert mit enem festen Schlüssel. Beide Schlüssel stehen deshalb auch nicht irgendwo fest codiert.
- Das Tool wurde nach Vorgaben ursprünglich für eine Firma entwickelt welche sich an BSI Normen hält.
...

Früher hatte ich den Parameter savecred von runas verwendet. Die Kids haben nach 2 Tagen gemerkt dass Sie dadurch jedes beliebige Proggi starten können. Bis jetzt aber beissen Sie sich noch die Zähne aus.

Gruss

[dante]

@Rika: Du sagts also, dass man eine Datei mit der selben Prüfsumme generieren kann. Da mag ich dir zustimmen, aber dazu muss man diese Datei erst mal abändern. Wie soll das denn von Außen möglich sein (ohne schon befallen zu sein)? Auch von Innen muss ich erst mal Admin-Rechte haben, um eine Datei abzuändern bzw. zu löschen.

dante

[Rika]

Zitat

Es wird nicht nur eine Prüfsumme in der verschüsselten Datei angelegt, sondern ein ganzes Bitmuster des freigegebenen Programmes wird verschlüsselt abgelegt und beim Aufruf gegengeprüft.

Das ist unsicherer auf auwendiger als einfache kryptographische Prüfsummen.

Zitat

- Der Schlüssel wird zur Laufzeit aus der ausführbaren Datei, zusammen mit einem errechneten Passwort erzeugt. Jede Anwendung erhält dadurch einen eigenen Schlüssel kombiniert mit enem festen Schlüssel. Beide Schlüssel stehen deshalb auch nicht irgendwo fest codiert.

Ja und? Berechnen kann man sie trotzdem.

Zitat

- Das Tool wurde nach Vorgaben ursprünglich für eine Firma entwickelt welche sich an BSI Normen hält.

Und welche? Die Normen für IT-Grundschutz gemäß BSI sagen über solche Sachen genau gar nix aus.

Zitat

Früher hatte ich den Parameter savecred von runas verwendet. Die Kids haben nach 2 Tagen gemerkt dass Sie dadurch jedes beliebige Proggi starten können. Bis jetzt aber beissen Sie sich noch die Zähne aus.

Hm... warum nimmst du nicht einfach Software Restriction Policies? Und sorgst dafür, daß überhaupt kein chroot nötig ist?
Wenn du Daten nur halbherzig verstecken möchtest, dann reicht auch die ZAN-Verschlüsselung aus (Zip And Rename).

Zitat

Du sagts also, dass man eine Datei mit der selben Prüfsumme generieren kann. Da mag ich dir zustimmen, aber dazu muss man diese Datei erst mal abändern. Wie soll das denn von Außen möglich sein (ohne schon befallen zu sein)? Auch von Innen muss ich erst mal Admin-Rechte haben, um eine Datei abzuändern bzw. zu löschen.

Nein, du erzeugst einfach eine zweite Datei mit der gleichen Prüfsumme und führst diese aus.

[sidan.maler2]

Sorry Rika,
Aber einige Kommentare von Dir verstehe ich nicht ganz.
- Warum z.B. ist es unsicherer Zusätzlich zur Prüfsumme das Bitmuster der Anwendung abzuprüfen. Allein Deine Kommentare hier schreiben doch etwas von einer unsicherer Prüfsumme. Abgesehen davon liegt der ganze Senf auch noch verschlüsselt vor.

Kann es sein das Du öfter einfach ein letzes Wort brauchst?

[dante]

Zitat

Hm... warum nimmst du nicht einfach Software Restriction Policies? Und sorgst dafür, daß überhaupt kein chroot nötig ist?

Würd ich ja gerne machen (gpedit.msc), kann aber mein (blödes) Home nicht. Mein Anliegen an den Admin-Benutzer ist eigentlich nur, dass ich die System-Uhr als Benutzer stellen darf.

Sicherer ist da natürlich, den Admin bei der Arbeit ganz zu vermeiden. Wie könnte ich dann aber solch ein Problem (oder andere) sinnvoll lösen?

dante

[Rika]

Zitat

- Warum z.B. ist es unsicherer Zusätzlich zur Prüfsumme das Bitmuster der Anwendung abzuprüfen.

Weil ich dann immernoch einfach die Programmfunktionen außerhalb des Bitmusters ändern kann. Das Problem wäre mit einer kryptographisch sicheren Prüfsumme erledigt und würde auch das Bitmuster überflüssig machen.

Zitat

Abgesehen davon liegt der ganze Senf auch noch verschlüsselt vor.

Und? Der Schlüssel ist trivialerweise berechenbar.

Zitat

Würd ich ja gerne machen (gpedit.msc), kann aber mein (blödes) Home nicht.

Rechteverwaltung kann XP Home, und man kann es sogar trivial freischalten.

Zitat

Mein Anliegen an den Admin-Benutzer ist eigentlich nur, dass ich die System-Uhr als Benutzer stellen darf.

Das geht einwandfrei per Group Policy oder per Local Policy, nur daß man sich halt das MSC-Applet selbst zusammenstellen muss.
Ja, besser wäre natürlich ein date-Mechanismus wie in Unix, wo RTC != system_time != time gilt.

Zitat

Sicherer ist da natürlich, den Admin bei der Arbeit ganz zu vermeiden. Wie könnte ich dann aber solch ein Problem (oder andere) sinnvoll lösen?

Kommt auf die anderen Problem an.

[dante]

Zitat

Rechteverwaltung kann XP Home, und man kann es sogar trivial freischalten.

Ich kenn nur die Möglichkeit der "Rechteverwaltung von NTFS". Oder meinst du etwas anderes?
Wenn ich die Zeit ändern möchte, meldet mir Windows:

Zitat

"Sie haben keine ausreichenden Rechte, um die Systemziet zu ändern"

Dann hab ich mit Reg- und Filemon mal nachgeschaut, aber es gibt nichts, welches den Zugriff verwehrt.

dante

[Lofote]

Zitat

Ich kenn nur die Möglichkeit der "Rechteverwaltung von NTFS". Oder meinst du etwas anderes?

Das sind Berechtigungen, keine Rechte. Berechtigungen sind auf Objekte (wie Dateien, Registrykeys, ActiveDirectory-Objekte, ...) bezogen. Rechte sind auf Systemrechte bezogen, z.B. das Recht, den Besitztum einer Datei, auf das man keine Berechtigungen hat, zu übernehmen. Oder halt die Zeit einstellen zu dürfen. Unter XP Pro: Start, Ausführen, secpol.msc, dann "Lokale Richtlinien" und dort "Zuweisen von Benutzerrechten". Es gibt auch Kommandozeilentools, die die verändern können für Batchdateien, z.B. ntrights.exe aus dem Windows Resource Kit.

Zitat

Kann es sein das Du öfter einfach ein letzes Wort brauchst?

Sagen wir so, ja, Rika ist ein Besserwisser, aber man muss ihm eins lassen: Über viele Dinge weiss er wirklich bescheid und das Thema Verschlüsselung und Sicherheit sind solche Dinge. Aber er wirkt oft... nunja... besserwisserisch. Zudem ist er recht festgefahren in vielen Punkten, sehr unflexibel. Aber so müssen wir ihn einfach hinnehmen, wie gesagt, verstehen tut er schon was davon, von was er redet ...

Dieser Beitrag wurde von Lofote bearbeitet: 16. Juni 2005 - 16:31