Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/windows-local-privilege-escalation/acls-dacls-sacls-aces.md

18 KiB
Raw Blame History

ACLs - DACLs/SACLs/ACEs


Gebruik Trickest om maklik te bou en outomatiseer werkstrome aangedryf deur die wêreld se mees gevorderde gemeenskapshulpmiddels.
Kry Toegang Vandag:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Leer AWS hakwerk van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Toegangsbeheerlys (ACL)

'n Toegangsbeheerlys (ACL) bestaan uit 'n geordende stel Toegangsbeheerinskrywings (ACEs) wat die beskerming vir 'n voorwerp en sy eienskappe bepaal. In wese bepaal 'n ACL watter aksies deur watter sekuriteitsprinsipale (gebruikers of groepe) toegelaat of ontken word op 'n gegewe voorwerp.

Daar is twee tipes ACLs:

  • Diskresionêre Toegangsbeheerlys (DACL): Spesifiseer watter gebruikers en groepe toegang tot 'n voorwerp het of nie.
  • Stelseltoegangsbeheerlys (SACL): Beheer die ouditering van toegangspogings tot 'n voorwerp.

Die proses van toegang tot 'n lêer behels dat die stelsel die sekuriteitsbeskrywing van die voorwerp teen die gebruiker se toegangstoken nakyk om te bepaal of toegang verleen moet word en die omvang van daardie toegang, gebaseer op die ACEs.

Kernkomponente

  • DACL: Bevat ACEs wat toegangsgemagtigdhede aan gebruikers en groepe vir 'n voorwerp verleen of ontken. Dit is in wese die hoof-ACL wat toegangsregte bepaal.
  • SACL: Word gebruik vir ouditering van toegang tot voorwerpe, waar ACEs die tipes toegang definieer wat in die Sekuriteitsgebeurtenisjoernaal gelog moet word. Dit kan van onschatbare waarde wees om ongemagtigde toegangspogings op te spoor of toegangsprobleme op te los.

Stelselinteraksie met ACLs

Elke gebruikersessie is geassosieer met 'n toegangstoken wat sekuriteitsinligting wat relevant is vir daardie sessie bevat, insluitend gebruiker-, groepidentiteite en voorregte. Hierdie token bevat ook 'n aanmeldings-SID wat die sessie uniek identifiseer.

Die Plaaslike Sekuriteitsowerheid (LSASS) verwerk toegangsaanvrae tot voorwerpe deur die DACL te ondersoek vir ACEs wat ooreenstem met die sekuriteitsprinsipaals wat toegang probeer verkry. Toegang word onmiddellik verleen as geen relevante ACEs gevind word nie. Andersins vergelyk LSASS die ACEs teen die sekuriteitsprinsipaal se SID in die toegangstoken om toegangsgeregtigheid te bepaal.

Gesommeerde Proses

  • ACLs: Definieer toegangsgemagtigdhede deur DACLs en ouditeringsreëls deur SACLs.
  • Toegangstoken: Bevat gebruiker-, groep- en voorreginligting vir 'n sessie.
  • Toegangsbesluit: Word geneem deur DACL ACEs met die toegangstoken te vergelyk; SACLs word gebruik vir ouditering.

ACEs

Daar is drie hooftipes Toegangsbeheerinskrywings (ACEs):

  • Toegang Geweier ACE: Hierdie ACE ontken uitdruklik toegang tot 'n voorwerp vir gespesifiseerde gebruikers of groepe (in 'n DACL).
  • Toegang Toegelaat ACE: Hierdie ACE verleen uitdruklik toegang tot 'n voorwerp vir gespesifiseerde gebruikers of groepe (in 'n DACL).
  • Stelseloudit ACE: Geplaas binne 'n Stelseltoegangsbeheerlys (SACL), is hierdie ACE verantwoordelik vir die genereer van ouditlogboeke tydens toegangspogings tot 'n voorwerp deur gebruikers of groepe. Dit dokumenteer of toegang toegelaat of ontken was en die aard van die toegang.

Elke ACE het vier kritiese komponente:

  1. Die Sekuriteitsidentifiseerder (SID) van die gebruiker of groep (of hul hoofnaam in 'n grafiese voorstelling).
  2. 'n Vlag wat die ACE-tipe identifiseer (toegang geweier, toegelaat, of stelseloudit).
  3. Oorerwingvlagte wat bepaal of kindervoorwerpe die ACE van hul ouer kan oorneem.
  4. 'n toegangsmasker, 'n 32-bis-waarde wat die verleen regte van die voorwerp spesifiseer.

Toegangsbepaling word uitgevoer deur elke ACE sekwensieel te ondersoek totdat:

  • 'n Toegang Geweier ACE die versoekte regte uitdruklik ontken aan 'n trustee wat in die toegangstoken geïdentifiseer is.
  • Toegang Toegelaat ACE(s) uitdruklik alle versoekte regte aan 'n trustee in die toegangstoken verleen.
  • Na die ondersoek van alle ACEs, as enige versoekte reg nie uitdruklik toegelaat is nie, word toegang implisiet ontken.

Volgorde van ACEs

Die manier waarop ACEs (reëls wat sê wie toegang tot iets kan hê of nie) in 'n lys genaamd DACL geplaas word, is baie belangrik. Dit is omdat sodra die stelsel toegang gee of ontken gebaseer op hierdie reëls, hou dit op om na die res te kyk.

Daar is 'n beste manier om hierdie ACEs te organiseer, en dit word "kanoniese volgorde" genoem. Hierdie metode help om seker te maak dat alles glad en reg werk. Dit gaan so vir stelsels soos Windows 2000 en Windows Server 2003:

  • Plaas eers al die reëls wat spesifiek vir hierdie item gemaak is voor diegene wat van elders kom, soos 'n ouermap.
  • In daardie spesifieke reëls, plaas diegene wat sê "nee" (ontken) voor diegene wat sê "ja" (toelaat).
  • Vir die reëls wat van elders kom, begin met diegene van die nabyste bron, soos die ouer, en gaan dan terug van daar af. Weer, plaas "nee" voor "ja."

Hierdie opstelling help op twee groot maniere:

  • Dit maak seker dat as daar 'n spesifieke "nee" is, dit geëerbiedig word, ongeag watter ander "ja" reëls daar is.
  • Dit laat die eienaar van 'n item die laaste sê hê oor wie binnekom, voordat enige reëls van ouer-mappe of verder terug in werking tree.

Deur dit op hierdie manier te doen, kan die eienaar van 'n lêer of vouer baie presies wees oor wie toegang kry, en verseker dat die regte mense kan binnekom en die verkeerde nie.

So, hierdie "kanoniese volgorde" gaan oor die verseker dat die toegangsreëls duidelik en goed werk, spesifieke reëls eerste plaas en alles op 'n slim manier organiseer.


Gebruik Trickest om maklik te bou en outomatiseer werkstrome aangedryf deur die wêreld se mees gevorderde gemeenskapshulpmiddels.
Kry Toegang Vandag:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

GUI Voorbeeld

Voorbeeld van hier

Dit is die klassieke sekuriteitstaba van 'n vouer wat die ACL, DACL en ACEs wys:

http://secureidentity.se/wp-content/uploads/2014/04/classicsectab.jpg

As ons op die Gevorderde knoppie klik, sal ons meer opsies soos erfenis kry:

http://secureidentity.se/wp-content/uploads/2014/04/aceinheritance.jpg

En as jy 'n Sekuriteitsprinsipaal byvoeg of wysig:

http://secureidentity.se/wp-content/uploads/2014/04/editseprincipalpointers1.jpg

En laastens het ons die SACL in die Oudit-taba:

http://secureidentity.se/wp-content/uploads/2014/04/audit-tab.jpg

Toegangsbeheer in 'n Vereenvoudigde Manier Verduidelik

Wanneer ons toegang tot hulpbronne, soos 'n vouer, bestuur, gebruik ons lyste en reëls bekend as Toegangsbeheerlyste (ACLs) en Toegangsbeheerinskrywings (ACEs). Hierdie definieer wie sekere data kan of nie kan benader nie.

Toegang tot 'n Spesifieke Groep Weier

Stel jou het 'n vouer genaamd Koste, en jy wil hê almal moet dit kan benader behalwe vir 'n bemarkingsspan. Deur die reëls korrek op te stel, kan ons verseker dat die bemarkingsspan eksplisiet die toegang ontneem word voordat almal anders toegang kry. Dit word gedoen deur die reël om toegang te weier aan die bemarkingsspan voor die reël wat toegang verleen aan almal te plaas.

Toegang Verleen aan 'n Spesifieke Lid van 'n Geweierde Groep

Laat ons sê Bob, die bemarkingsdirekteur, toegang tot die Koste-vouer nodig het, selfs al behoort die bemarkingsspan normaalweg nie toegang te hê nie. Ons kan 'n spesifieke reël (ACE) vir Bob byvoeg wat hom toegang verleen, en dit voor die reël plaas wat toegang aan die bemarkingsspan weier. Op hierdie manier kry Bob toegang ten spyte van die algemene beperking op sy span.

Begrip van Toegangsbeheerinskrywings

ACEs is die individuele reëls in 'n ACL. Hulle identifiseer gebruikers of groepe, spesifiseer watter toegang toegelaat of geweier word, en bepaal hoe hierdie reëls van toepassing is op sub-items (erfenis). Daar is twee hooftipes ACEs:

  • Generiese ACEs: Hierdie is breed van toepassing, wat óf op alle tipes voorwerpe van toepassing is óf slegs onderskei tussen houers (soos vouers) en nie-houers (soos lêers). Byvoorbeeld, 'n reël wat gebruikers toelaat om die inhoud van 'n vouer te sien maar nie die lêers binne-in te benader nie.
  • Voorwerpspesifieke ACEs: Hierdie bied meer presiese beheer, wat reëls toelaat om ingestel te word vir spesifieke tipes voorwerpe of selfs individuele eienskappe binne-in 'n voorwerp. Byvoorbeeld, in 'n gids van gebruikers, mag 'n reël 'n gebruiker toelaat om hul telefoonnommer op te dateer maar nie hul aanmeldingstye nie.

Elke ACE bevat belangrike inligting soos vir wie die reël geld (deur 'n Sekuriteitsidentifiseerder of SID te gebruik), wat die reël toelaat of weier (deur 'n toegangsmerk te gebruik), en hoe dit deur ander voorwerpe geërf word.

Sleutelverskille Tussen ACE-tipes

  • Generiese ACEs is geskik vir eenvoudige toegangsbeheerscenarios, waar dieselfde reël van toepassing is op alle aspekte van 'n voorwerp of op alle voorwerpe binne-in 'n houer.
  • Voorwerpspesifieke ACEs word gebruik vir meer komplekse scenarios, veral in omgewings soos Aktiewe Gids, waar jy dalk toegang tot spesifieke eienskappe van 'n voorwerp anders moet beheer.

Kortom, ACLs en ACEs help om presiese toegangsbeheer te definieer, wat verseker dat slegs die regte individue of groepe toegang tot sensitiewe inligting of hulpbronne het, met die vermoë om toegangsregte tot op die vlak van individuele eienskappe of voorwerptipes aan te pas.

Toegangsbeheerinskrywinguitleg

ACE-veld Beskrywing
Tipe Vlag wat die tipe ACE aandui. Windows 2000 en Windows Server 2003 ondersteun ses tipes ACE: Drie generiese ACE-tipes wat aan alle beveiligbare voorwerpe geheg is. Drie voorwerp-spesifieke ACE-tipes wat vir Aktiewe Gids-voorwerpe kan voorkom.
Vlae Stel van bietjievlags wat erfenis en ouditering beheer.
Grootte Aantal bytes van geheue wat vir die ACE toegewys is.
Toegangsmerk 'n 32-bis-waarde waarvan die bietjies ooreenstem met toegangsregte vir die voorwerp. Bietjies kan óf aan óf af gesit word, maar die betekenis van die instelling hang af van die ACE-tipe. Byvoorbeeld, as die bietjie wat ooreenstem met die reg om toestemmings te lees aangesit is, en die ACE-tipe is Weier, weier die ACE die reg om die voorwerp se toestemmings te lees. As dieselfde bietjie aangesit is maar die ACE-tipe is Toelaat, verleen die ACE die reg om die voorwerp se toestemmings te lees. Meer besonderhede van die Toegangsmerk verskyn in die volgende tabel.
SID Identifiseer 'n gebruiker of groep wie se toegang deur hierdie ACE beheer of gemonitor word.

Toegangsmerkuitleg

Bietjie (Reeks) Betekenis Beskrywing/Voorbeeld
0 - 15 Voorwerp Spesifieke Toegangsregte Lees data, Uitvoer, Voeg data by
16 - 22 Standaard Toegangsregte Skrap, Skryf ACL, Skryf Eienaar
23 Kan toegang tot sekuriteit ACL verkry
24 - 27 Voorbehou
28 Generiese ALLES (Lees, Skryf, Uitvoer) Alles hieronder
29 Generiese Uitvoer Alles wat nodig is om 'n program uit te voer
30 Generiese Skryf Alles wat nodig is om na 'n lêer te skryf
31 Generiese Lees Alles wat nodig is om 'n lêer te lees

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:


Gebruik Trickest om maklik te bou en werkvloei outomatiseer wat aangedryf word deur die wêreld se mees gevorderde gemeenskapsinstrumente.
Kry Vandag Toegang:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}