Daten in HKEY_LOCAL_MACHINE ohne Adminrechte schreiben

[Assarbad]

Zitat von Luckie:

aber dann muss er auch irgendwo die Zugangsdaten hinterlegen, was wieder ein Sicherheitsrisiko bedeutet.

Mit LsaStorePrivateData (alte Methode) oder CryptProtectData sollte dies ein geringes Problem sein.

[jobo]

Wieso muss man das System unbedingt verbiegen?
Was spricht gegen User DSN und Registry Import von einer gemeinsamen Netzdatei beim Login?
Bekommt man ohne Sicherheitsprobleme und Extras und nur mit Bordmitteln.

Man könnte auch gleich mit Datei DSN arbeiten.

Remote per Admin gehts dann auch mit Regedit in die jeweiligen HKLM Einträge. Ich kenne es aber so nur interaktiv.

[skyobserver]

Erst mal danke für die Antworten,

-Also das Passwort würde ich natürlich nicht im Klartext im Code hinterlegen.
Ich würde es kodieren und erst zur Laufzeit dekodieren, wenn es benötigt wird...

-Per GroupPolicy wird nicht gehen, da je nach installierter Datenbank-Client-Version
der ODBC-Eintrag etwas anders aussehen muss. Das Programm bzw. der Service muss erst
die Client-Version ermitteln und dann die entsprechenden Registry-Daten importieren...

-Per Remote-Registry kommt nicht in Frage - wir produzieren 24 Stunden / 7 Tage die Woche
und ich werde ungern Nachts um 04:00 angerufen um einen ODBC-Eintrag zu machen

-Diese Einträge sind nicht Benutzerspezifisch sondern für alle Benutzer gleichermaßen
verbindlich. Prinzipiell ist also System-DSN der richtige Ort - natürlich funktioniert
Benutzer-DSN grundsätzlich auch...


Werde mir also "CreateProcessAsUser" bzw. "Impersonate" mal ansehen...


Danke!

[alzaimar]

Wenn Du sowieso schon eine automatische Registrierung der DSN vorgesehen hast, nutze das doch. So viele unterschiedliche Benutzer gibt es ja nicht und im Kontext der Sicherheitsphilosophie ist diese Lösung die Richtige.

Wenn Du das Kennwort im Code hast, egal ob verschlüsselt oder nicht, wird das ein Angreifer ohne große Probleme ausnutzen können.

[Luckie]

Zitat von alzaimar:

Wenn Du das Kennwort im Code hast, egal ob verschlüsselt oder nicht, wird das ein Angreifer ohne große Probleme ausnutzen können.

Weil du musst das Passwort ja im Code mitliefern, um das eigentliche Passwort wieder zu entschlüsseln. Das ist ungefähr so, als wenn du den Türschlüssel unter die Fußmatte legst und einen Zettel an die Tür klebst auf dem steht: "Der Schlüssel liegt unter der Fußmatte."

[skyobserver]

Zitat:

Das ist ungefähr so, als wenn du den Türschlüssel unter die Fußmatte legst und einen Zettel an die Tür klebst auf dem steht: "Der Schlüssel liegt unter der Fußmatte."

Ganz so schlimm ist es wohl nicht - das Kennwort steht ja nirgendwo unverschlüsselt rum.
Man müßte schon den Quellcode in die Finger bekommen um die Dekodierung, mit Hilfe des
Kodierten Kennworts und der Dekodier-Routine, durchzuführen.

Weiterhin würde man nicht das Passwort des Domänen-Administrators verwenden, sondern das
des lokalen Administratros des PCs. Sollte der unwarscheinliche Fall auftreten, daß ein
Hacker Zugang zu unseren Quellcodes bekommt, aus den über 1000 *.pas Dateien die richtige
findet und das Kennwort dekodiert kann er sich maximal an Client-PCs als Admin austoben.
Daten liegen bei uns nur auf Servern rum wofür Rechte in der Domäne notwendig wären...

Außerdem weiß der Hacker ja gar nicht, wo er suchen muß...da dürfte es einfacher sein eine
Sicherheitslücke im Windows zu finden und auszunutzen: z.B. Abbruch des Login-Scripts führt
zu lokalen Adminrechten...

[himitsu]

Zitat von skyobserver:

Außerdem weiß der Hacker ja gar nicht, wo er suchen muß

Disassambler
Decompiler
Fremdprozess debugen
usw.

und schon weiß man was man braucht.