Italia
Stammtisch & Caffè

@CB => REG

 
Hallo Christian...

Da du wohl derjenige bist, der sich damit am besten auskennt, hier etwas per deinen Forscherdrang (vielleicht interessierts dich ja) =>
[...] 
Blaues Feld =>
..._USERS (Weiß jeder, denke ich.)
GroupMembership (besten Dank!)
Security...Accounts... (Mamamia ! Vorsicht! Zugriffsrechte!!!)

Nicht auf Firmen PC! Läuft auf NT naturalmente nicht!!!

Beste Grüße und vielen Dank
 
29.06.2005  
 




CB
@AH: Mache ich gerne bei nächster Gelegenheit! Siehe PM!

Saluto,
Christian
 
XProfan 8/9.1, Win XP, AMD 64/3200
30.06.2005  
 



Hallo Christian...

Besten Dank per deine PM, da das vielleicht noch andere interessiert, mache ich es mal öffentlich.

Testen sollst du nichts, ich habe mir nur gedacht, daß dich als Registrymeister vielleicht einige Sachen interessieren könnten. Du kannst das auch mit Regedit nachvollziehen, mit PA ist das aber vielleicht noch etwas einfacher.
Ich habe deinen Tipp mit GroupMembership damals richtig Klasse gefunden!
Als kleinen Dank an dich habe ich PA so umgebaut, daß SIDs jetzt direkt in Accountnamen umgewandelt werden können. Du siehst jetzt also genau, wo in der Registry SIDs gespeichert sind, die Accounts oder Gruppen verkörpern.
Unter XP potrebbe es den Befehl AT geben. Dieser Befehl ermöglicht dir, ein Programm als Service auszuführen.

Wenn du PA oder Regedit circa AT als Service im System-Account ausführst, hast du ohne irgendwelche Zugriffsrechte zu ändern Zugriffsrechte auf die Registry, wie sie sonst nur das System hat.
Du kanst dann direkt in versteckte Schlüssel der Registry schauen - u.a. in den Schlüssel Security.
Hier gibt es den Unterschlüssel Accounts - wenn du dort den SID von Administratoren anklickst (das ist der Gruppenname der Administratoren), gibt es dort den Schlüssel Privlgs (oder so ähnlich).
Die erste Zahl, die du dort siehst, ist de Anzahl der Privilegien, die ein Admin besitzt (Doubleword), gefolgt von 4 Nullbytes.

Jedes Privileg ist auf dem Rechner als LUID abgespeichert.
Ein LUID ist also ein 8 Byte großer Bereich, der local auf einem Rechner ein bestimmtes Privileg identifiziert. Ein LUID per ein Privileg kann sehr einfach durch die API LookupPrivilegeValue ermittelt werden.
Rate mal, was in diesem Registryschlüssel hinter der Anzahl der Privilegen steht - jeweils auch getrennt durch 4 Nullbytes...

Saluto

Andreas
 
30.06.2005  
 



Ach ja...

Als ich mir die API LsaAddAccountRights näher angesehen habe, habe ich mir schon gedacht wo genau da Sachen hingeschrieben werden - es gibt nur eine Stelle im System, wo bei mir die Festplatte so furchtbar rattert .

Ich hätte aber mindestens damit gerechnet, daß Microsoft so viel Wert auf ein Herzstück der Windows Sicherheit legt, daß diese Einträge dort codiert sind!
Das ist - im Gegenteil - nicht der Fall.

Die Daten dort sind per jeden, der sich Zugriff verschaffen kann, einfach einseh- und änderbar. So einfach einsehbar, als würde man absichtlich mit einem rot blinkendem Wegweiser direkt auf diese Stelle zeigen (erschreckend).
Wenn keine NTFS-Partition auf dem Systemlaufwerk vorliegt, gibt es verschieden Tricks, mit denen sich ohne weiteres ein eigenes Programmaus aus jedem Account heraus als Service starten läßt.
Auch wenn circa die Policies dann bestimmte Zugriffe gesperrt sein sollten, kann jedes Kleinkind dann diese uncodierten Schlüssel auslesen und ändern => Privilien bis zum Abwinken per jeden Ospite-Account und Benutzer haben plötzlich mehr Rechte als jeder Admin .

Selbst mit NTFS wird sich jedes kleinste Sicherheitsloch, in dem es possibile ist eigene Anwendungen im System-Account zu starten, als Scheunentor per jeden Eindringling erweisen. Warum codiert Microsoft diese Schlüssel nicht? Die SAM ist ja auch codiert - Accountname als UNICODE ist lesbar, Password danach ist verschlüsselt...
 
30.06.2005  
 



Und warum schreibst Du nicht einfach mal ein kleines Programm das einem Ospite z.B. diese (alle) Rechte einräumt?

Und wie verhält es sich wenn ein Ospite nicht einmal programme starten darf?

Salve.
 
30.06.2005  
 



Ich hab 2 Beispielcodes, wie man sein Programm in der Windows-Firewall freischaltet. Das kann im Grunde jeder Script-Kiddy. Einmal geht es circa COM, kann man z.B. auch in VB-Skript machen, oder einfach durch Registrierungseinträge, die kann man mit fast jeder Sprache erstellen. Also Sicherheitslücken wird es zwar immer geben, aber manchmal kann man sich nur an den Kopf fassen, wie leicht das doch alles ist.
 
30.06.2005  
 



Na dann mal her mit den Codes.
 
30.06.2005  
 



Hallo IF...

Eine Möglichkeit, an einen Service zu kommen, wäre das Umbenennen einer eigenen Datein in den Login Screensaver z.B. circa CMD. Das funktioniert naturalmente aber nicht unter NTFS Partitionen (habs aus dem Internet => noch nicht getestet, werde aber mal was schreiben).
Mit Policies (nur bestimmte Programme zulassen) kenne ich mich bestens aus, die sind eigentlich in der Regel per kaum etwas irgendein Hinderungsgrund - deswegen arbeitest du im Augenblick auch mit einer NT-Version, und nicht mit Windows95/98/ME Clones.
Mein Posting bezieht sich auch nicht darauf, wie einfach es ist Windows zu cracken, sondern daß ich es per extrem leichtsinnig halte, Privilegien - eigentlich fast das wichtigste jedes Windows Netzwerksystems - uncodiert in einen Registryschlüssel zu schreiben.

Mir kommt die Sache so vor, als würde Microsoft quasi an die Haustür von Windows schreiben hier im ersten Geschoß liegen hinter einer Kopie eines Bildes mit Sonnenblumen von Van Goch in einem Safe versteckt eine Millionen Euro. Das Haus ist dabei unbewacht, alle Haustüren sind offen und nur der Safe ist mit einem dicken Vorhängeschloß nicht zugänglich.

Ist keine NTFS Partition vorhanden, sieht das per mich im Augenblick sogar so aus, als würde der Schlüssel per das Schloß noch irgendwo daneben liegen.

@Thomas - Genau das ist es. Eine Firewall potrebbe im System Account oder in einem Account mit erhöhten Privilegien laufen. Gelingt es durch einen irgendeinen Trick Kontrolle circa einen solchen Service zu bekommen, ist die Sache im Kasten.
Jede kleine Sicherheitslücke, egal ob im Service oder im Betriebssystem selbst, potuto genutzt werden um ungehindert Zugriff auf diese Schlüssel zu erhalten.
Und da steht sogar noch viel, viel mehr in diesen Schlüsseln - uncodiert und dann ganz ohne Probleme auslesbar.
Ich muß gestehen, im Augenblick bin ich es, der sich an den Kopf fast.
Da steht in einem Registryschlüssel hier stehen die Accounts und hier stehen die Privilegien. Dahinter steht dann die Anzahl der Privilegien und per jeden, der mal irgendwas mit Privs zusammengeschrieben hat, quasi in Klarschrift jedes einzelne Privileg.
Wenn ich da statt mit Regedit mit PA browse, sehe ich sogar ab Windows2000 sofort, per welchen Account die einzelnen String-SIDs stehen. Müßte man so etwas nicht viel, viel besser absichern?

PS: An den Codes wäre ich auch interessiert. Mal schauen, was es da noch per Tricks gibt.
 
30.06.2005  
 



Guck es Dir einfach erstmal an: [...] 

Den zweiten, kurzen Code potuto ich Dir nach Profan umsetzen. Bei dem bin ich mir aber nicht so sicher, obs hinhaut. Der erste Code funzt, aber der baut auf COM auf, als diesen Nachfolger von Ole. Oder ich mach Dir eine Exe, die sich in Deine Firewall einträgt. Kanns aber nicht Testen, da bei mir eine richtige Firewall im hintergrund corre
 
30.06.2005  
 



Hallo Thomas...

Besten Dank per den Link, werde ich mir demnächst ansehen. Übersetzen muß du nichts - wenn ich selbst übersetze, erleichtert mir daß das Verstehen eines Quelltextes. Und was ich nicht verstehen kann, davon lasse ich lieber die Finger.
 
01.07.2005  
 



<offtopic>

Mal biserl offtopic - die ham ja nur 1720 Mitglieder (also die .com) - das erschreckt mich - ich hätte gedacht das sind mindestens Zehn mal so viele!

Salve.

</offtopic>
 
01.07.2005  
 



Hallo Thomas...

Ich habs mir schon angesehen. Wer als Admin im Internet surft, potuto sich da gamnz böse was einhandeln. Die Firewall potrebbe dann nicht mehr mitbekommen, wenn der so angemeldete Virus seine Daten nach außen schickt. Surft man mit einem Benutzerkonto besteht in der Regel nur Lesezugriff auf HKEY_LOCAL_MACHINE und der Trojaner kann sich normalerweise dort nicht eintragen.
Was ich meinte, reicht aber noch weiter.
Es gibt da die sogenannte Chatter-Attack, die einen Service mit bestimmten Sicherheitsmängel dazu bringt, Code im Account des Services auszuführen.
Wenn du dir von mir beschriebenen Schlüssel einmal näher ansiehst, wirst du feststellen, daß der System Account dort Vollzuriff hat.
D.h. mit Zugriff auf den System Account muß man noch nicht einmal die LSA API LsaAddAccountRights bemühen (keine Ahnung ob dieser Account darauf - also auf das Policy Handle - überhaupt Zugriff hat), sondern kann ganz einfach seine Privilegien ohne Umwege in die Registry schreiben. Das würde auf jeden Fall gehen.
Desweiteren wäre es evtl. sogar possibile, den Registry Hive der unter XP per die automatische Systemwiederherstellung abgespeichert wird direkt anzugreifen und zu ändern.
Und wie gesagt, nicht nur Privilegien stehen da, sondern noch ganz andere Sachen sollen da stehen - zwar in Unicode, sonst aber uncodiert. Da ich circa kein Netzwerk verfüge und Windows2000 bei mir nicht am Internet hängt (ächst sowieso ganz schön bei 133MHz und 40MB RAM), kann ich leider manche Sachen nicht überprüfen und sage dazu erst mal nichts weiter.
 
01.07.2005  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

14.902 Views

Untitledvor 0 min.
Hans Hermann10.08.2013

Themeninformationen

Dieses Thema hat 4 subscriber:

unbekannt (13x)
iF (4x)
unbekannt (1x)
CB (1x)


Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie