Sikkerhet i Windows.

Sikkerheten i Windows XP blir ivaretatt av flere forskjellige komponenter, de viktigste komponentene er:

Security Reference Monitor: (SRM)
Er en komponent i Windows executive som er ansvarlig for å: definere data strukturen til såkalte Access Tokens som reprensenterer et sikkerhetskontekst, utføre sikkerhetssjekker på objekter, manipulere privlegier og generere eventuelle sikkerhets-revisjons beskjeder.

Local Security Authority SubSystem: (LSASS)
En prosess i User-mode som er ansvarlig for bla: sikkerhetspolicyen på det lokale systemet(som feks hvilke brukere som kan logge på maskinen, passord policyer, privlegier som blir gitt brukere og grupper og systemets sikkerhets-revisjons innstillinger), bruker autentikasjon, og å sende sikkerhets-revisjons beskjeder til hendelseslisten. LSA-tjenesten som lastes ved Lsasrv.dll er et biblotek som lastes inn i Lsass og som implementerer mesteparten av funksjonalitetn til LSASS.

Lsass policy database:
En database som inneholder det lokale systemets sikkerhetspolicy innstillinger. Databasen er lagret i et seperat register-hi innunder HKLM\SECURITY. Denne databasen inneholder informasjon slik som hvilke domener som kan autentisere pålogginsforsøk, hvem som har tilgang til systemet og hvordan (interaktiv, nettverks, og tjeneste pålogginger), hvem som får hvilke privlegier og hva slags sikkerhets-revidering som blir utført. Lsass policy databasen lagres også såkalte "hemmeligheter" som inkulderer påloggingsinformasjonen som blir brukt for cachede domene pålogginger og Windows Tjeneste-konto pålogginger.

Security Accounts Manager (SAM) tjensten:
Ett sett med sub-rutiner som er ansvarlige for å håndtere databasen som inneholder brukernavnene og gruppene som er definert på den lokale maskinen. SAM tjenesten er implementert innunder Samsrv.dll og er lastet i Lsass-prosessen.

SAM databasen:
En database som på systemer som ikke fungerer som domene-kontrollere inneholder de definerte lokale brukerne og gruppene i tilegg til passord og andre atributter. På maskiner som fungerer som domene-kontrollere lagrer SAM-databasen kun systemets administrator konto for gjenoppretting, dens definisjon og passord.
Databasen blir lagret i et seperat register-hi innunder. HKLM\SAM.

Active Directory:
En katalog-tjenste som inneholder en database som lagrer informasjon om objekter i et domene. Hvor et domene defineres som en samling pc'er og deres assosierte sikkerhetsgrupper som blir håndtert som en eneste enhet. Active Directory lagrer infromasjonen om objektene i domenet inkludert brukere, grupper og pc'er. Passord informasjon og privlegier for domenebrukere og grupper er lagret i Active Directory og denne informasjonen blir da kopiert over til alle domene-kontrollerne i et domene.
Active Directory Serveren er implementert i Ntdsa.dll og lastes av Lsass-prosessen.

Autentiseringspakker:
Inkluderer DLL'er som kjører både i Lsass og i sine egne klient prosesser og som er ansvarlig for å implentere autentiserings-policyen i Windows. En autentiserings DLL er ansvarlig for å undersøke et gitt passord og brukernavn og, hvis de stemmer overens, returnere Lsass informasjon som inneholder brukerens sikkerhets identitet som Lsass kan bruke for å genere en såkalt Access Token.

Logon prosessen: (Winlogon)
En prosess i user mode som er ansvarlig på å fange og svare på SAS (Secure Attention Sequence, mao Ctrl+Alt+Delete) og som håndterer interaktive pålogginger.

Graphical Identification and Authentication: (GINA)
En user-mode dll som lastes av Winlogon og som brukes av Winlogon for å hente brukernavn og passord eller evt smartcard pin kode. Windows kan håndtere forskjellige tredjeparts GINA'er men standard ginaen heter da msgina.dll

Network Logon Service: (Netlogon)
En windows tjeneste (Netlogon.dll) som setter opp en sikker kanal opp mot domene-kontrolleren slik at sikkerhetsforespørsler slik som interaktiv pålogging eller LAN-manger eller NT-LAN-manager autentisering kan bli sendt over denne kanalen.

Kernel Security Device Driver (KSecDD)
Et biblotek som kjører i kernel-mode som inneholder et biblotek med funksjoner som kan brukes for at andre sikkerhetskomponeter som kjører i kernel-mode kan kommunisere med Lsass i user mode. Dette implementeres da via et LPC-grensesnitt.

Tilgangssjekk:
Vi har tidligere snakket om Objekt-Manageren og om hvordan den bruker SRM for å sjekke om en tråd har tilgang til et objekt eller ei. La oss nå se litt nærmere på denne prosessen. Når Objekt-Manageren åpner et eksisterende objekt med et navn vil det først sjekke i sitt eget Namespace for deretter sjekke i sekundære namespace. (Slik som Configuration Managaren sitt register-namespace eller filsystemdriverens filsystem namespace)

Så lenge som objektet ikke befinner seg i dette sekundære namespacet vil da objekt-manageren kalle på funksjonen ObpCreateHandle som lager en oppføring i prosessens HandleTable som deretter vil bli assosiert med objektet. Dog vil funksjonen ExCreateHandle først bli aktiv straks ObpIncrementHandleCount indikerer at tråden har tilgang til objektet. Deretter vil ObpCreateHandle faktisk kalle ExCreateHandle som lager selve Handelen. ObCheckObjektAccess er ansvarlig for å kalle på de nødvendige rutinene for å utføre selve sikkerhetssjekken og returnerer deretter resultatet til ObpIncrementHandleCount.

ObCheckObjectAccess vil videre motta sikkerhetsakkreditivene til tråden som sendte forespørselen, akksesstypen, og sist en pointer til objektet fra ObpIncrementHandleCount. Deretter vil ObCheckObjectAccess låse objektets sikkerhetsatributter slik at ingen andre tråder kan endre sikkerhetskonteksten til objektet. Deretter vil ObCheckObjectAccess kalle på sikkerhetsmetoden beskrevet i typeobjektet. Den vanligste metoden er da default security som innebærer at sikkerhetsinformasjonen er lagret i objekt-headeren.

Security IDentifiers: (SID)
Istedetfor å bruke navn(som ikke er garantert å være unike) for å beskrive enheter som kan utføre handlinger på systemet. så bruker Windows såkalte SID'er. Både Brukere, lokale grupper, domene grupper, lokale PC'er, domener og domene-medlemmer har sine egne SID-verdier.
En SID er da en numerisk verdi av variabel lengde som består av et SID-struktur revisjons nummer, en 48 bits authorirty-identifier verdi, og et varibelt antall av 32bits subautoritære eller RID verdier(Relative Identifier)

Autoritets-nummeret beskriver agenten som gå ut SID'en, typisk Windows Local System eller et domene. Subautorithy verdiene identifiserer kompontenter som agenten som sendte ut SID'en stoler på, mens RID er bare en måte for Windows å garantere unike SID'er

Her kan vi ta en titt på en SID for min Lokale Brukerkonto:

S-1-5-21-144138694-2277693550-1939834215-1007

Alle SID'er er prefixet med S mens vi kan se at revisjonsnr er 1 og Autoritets-nummeret er 5 (Som betyr at SID'en ble gitt ut av Windows Security Authority) mens de 4 neste verdiene er subautoritæreverdier og den siste verdien er altså en RID på 1007.

Brukerkontoer og grupper har tideles en RID som starter på 1000 og øker deretter med 1 etterhvert som nye SID trenges. Mao betyr en RID på 1007 at minimum 8 SID's har blitt gitt ut på dette systemet)
Windows maskiner har også flere innebygde kontoer hvor bla Administrator kontoen bestandig har en RID på 500 mens gjestekontoen har en RID på 501.

Tokens:
SRM bruker et objekt kalt en token(Access Token) som identifiserer sikkerhetskontekstet til en prosess eller tråd. Et sikkerhetskontekst inneholder informasjonen som beskriver privlegiene, kontoene og grupenne som er assosiert med enten prosessen eller tråden.

Under påloggingsprosessen så lager Winlogon en token som representerer brukeren som logger på og fester denne til de første prosessene som startes via Winlogon (feks Userinit.exe) Siden prosesser arver tokens fra prosessen som lagde den vil alle prosesser i en gjeldende sesjon kjøre innunder brukerens token.

Sikkerhetsmekanismene i Windows bygger opp en token av to grunnleggende komponenter. Den ene komponenten består i en token består av brukerens SID og eventuelle gruppe SID. SRM bruker SID'er for å avgjøre om en prosess eller tråd har mulighet til å få den tilgangen den ber om til et sikkret objekt. (Dette betyr ikke nødvendigvis at den får det, men mer om dette senere.)
Det andre komponenten er et såkalt privlege array som er et sett med privlegier som er assosiert med tokenen.

Det finnes i tilegg to typer tokens -primary og impersonation. Primary Tokens identifiserer sikkerhetskontekstet til en prosess. Mens en impresonantion token lar en tråd midlertidlig bruke et annet sikkerhetskontekst.

Security Descriptorer og tilgangskontroll:
Datastrukturen som inneholder informasjonen over sikkerheten til et objektet kalles en "security descriptor" og består av følgende:

Revision Number: Versjonen av SRM modellen som lagde deskriptoren.
Flag: Valgfrie modifiere som definerer oppførselen eller karakterestikken ved deskriptoren. (Feks SE_DACL_PROTECTED som forbyr deskriptoren å arve sikkerhetsinnstillinger fra et annet objekt.)
Owner SID: Eieren's SID
Group SID: SID'en til hovedgruppen for objektet.
Discretionary Access Control List(DACL): Spesifiserer hvem som har hvilken tilgang til et objekt:
System Access Control List(SACL): Spesifiserer hvilke operasjoner av hvilke brukere som vil bli lagret i sikkerhetsoppføringsloggen.

En ACL er bygd opp av en header og enten ingen eller flere Access Control Entries (ACE). I en DACL så inneholder hver ACE en SID, en aksessmaske og et sett med flagg.
Fire typer ACE's kan forekomme i en DACL: Access Allowed, Access Denied, Allowed Object og Denied Object. Access allowed og Access denied forbyr eller tillater akksessrettighetene som er spesifisert i akksessmasken.

Allowed Object og Denied Object er typer som bare brukes innen Active Directory og disse ACE'ene har en GUID (Globally Unique IDentifier)som spesifiserer ar dette gjelder kun for helt spesielle objekter eller subobjekter som bruker denne GUID'en.
Flaggene i ACE'en brukes til å spesifisere hvilke arveegenskaper denne ACE'en har.

En SACL derimot inneholder to typer av ACE'S: System Audit ACE og en System Audit-Object ACE. En System Audit ACE spesifiserer hvilke operasjoner som blir utført på objektet av spesifikke brukere eller grupper som skal overvåkes. Denne informasjonen blir da lagret i Overvåkningsloggen i systemet. Mens System Audit-Object ACE spesifiser en spesiell GUID som spesifiserer hvilke objekter eller subobjekter det dreier seg om. ( På lik linje med DACL Allowed Object og Denied Object)

Hvordan tilgang beregnes:
To algoritmer brukes for å beregne tilgangen til et objekt:

*En for å beregne det maksimale settetet med rettigheter som kan gis til et objekt.

*En for å finne ut om en spesiell rettighet er tilatt til et objekt.

La oss først se på hvordan man kalkulerer seg frem til det maksimale settet med rettigheter:

1.Først sjekkes det om objektet faktisk har en DACL, Hvis objektet ikke har en DACL har alle brukere alle tilganger til objektet.

2.Hvis enheten som gjorde forspørselen har spesifisert Take-ownership (Bli eier av filer og andre objekter) privlegiet i sin token, vil systemet automatisk automatisk gi write-owner rettigheter til eieren av objektet uavhengig av hva som står i DACL.

3.Hvis enheten som gjorde forespøselen eier objektet vil den automatisk få read-control og write-dacl rettigheter til objektet uavhengig av hva som står i DACL.

4.ACE som er merket som Access Denied kommer først og om den som gjorde forespørselen har en identisk SID med den SID'en som er spesifisert i en av Access Denied ACE'ene så blir aksessmasken i ACE'en trukket ifra aksessmasken over tilatte rettigheter.

5.For hver ACE merket Access Allowed som har en SID som tilsvarer SID'en til den som sendte forespørselen vil aksessmasken i ACE'en bli lagt til i aksessmasken over tilatte rettigheter. (Om ikke disse rettighetene ble forbydd fra før)

Når disse 5 trinnene er utført vil da aksessmasken over de tilatte rettighetene bli returnert til den som gjorde forespørselen. Husk at trinnene 2 og 3 vil overstyre eventuelle rettigheter som er spesifisert i DACL. (Mao om en ACE i DACL'en nekter rettigheten read-control vil brukeren allikavel få rettigheten så lenge den eier objektet.)

La oss deretter se på hvordan man kan finne ut om en spesiell rettighet er tillatt for et objekt:

1.Hvis objektet ikke har noen DACL. Så betyr det at objektet ikke er beskyttet og dermed er alle rettigheter automatisk tillatt.

2.Hvis den som gjorde forespørselen har take-ownership privlegiet vil den automatisk få rettigheten write-owner for deretter å inspisere DACL'en. Hvis den ønskede rettigheten faktisk var write-owner er ingen inspeksjon av DACL nødvendig.

3.Hvis den som gjorde forespørselen eier objektet vil den automatisk få rettighetene read-control og write-DACL for deretter å inspisere DACL'en. Hvis en av disse rettighetene var av de ønskede er ingen inspeksjon av DACL nødvendig.

4.Hver ACE i DACL'en blir undersøkt, men de eneste relevante ACE'ene er de som tilfredstiller en av de følgende kravene:
a. En ACE er av typen Access Denied og SID'en i ACE matcher med en aktivert SID eller en deny-only SID i tokenen til den som gjorde forespørselen.
b. En ACE er av typen Access Allowed og SID'en i ACE matcher med en aktivert SID i tokenen til den som gjorde forespørselene og den ikke er merket som deny-only.
c. Andre undersøkelse sjekker for såkalte restriktve SID'er og undersøker om noen av SID'ene i ACE matcher noen av de restriktive SID'ene spesifisert i tokenen.

5.Hvis ACE'en var av typen Access Allowed og rettigetene i aksessmasken tilsvarte de rettigetene som ble forespurt så vil tilgangen bli godkjent. Hvis ACE'en var av typen Access Denied og aksessmasken dens tilsvarte de rettighetene som ble forespurtså vil tilgangen bli avslått.

6.Hvis man har undersøkt alle ACE i en DACL og den forespurte rettigheten ikke ble funnet vil tilgangen bli avslått.

La oss nå bruke Windbg for å titte på en Access Token:

La oss sjekke ut Access Tokenen til LSASS:
0: kd> !process 8a0e7470
PROCESS 8a0e7470 SessionId: none Cid: 0468 Peb: 7ffde000 ParentCid: 0428
DirBase: 0a9600e0 ObjectTable: e1c746e8 HandleCount: 447.
Image: lsass.exe
VadRoot 8a21e078 Vads 143 Clone 0 Private 724. Modified 4805. Locked 0.
DeviceMap e1009200
Token e245d030
ElapsedTime 01:41:54.234
UserTime 00:00:00.578
KernelTime 00:00:00.687
QuotaPoolUsage[PagedPool] 89180
QuotaPoolUsage[NonPagedPool] 10616
Working Set Sizes (now,min,max) (403, 50, 345) (1612KB, 200KB, 1380KB)
PeakWorkingSetSize 1903
VirtualSize 45 Mb
PeakVirtualSize 46 Mb
PageFaultCount 10664
MemoryPriority BACKGROUND
BasePriority 9
CommitCharge 1235

Som vi ser er Access Tokenen lagret på addresse e245d030 la oss se nærmere på denne ved å bruke !token kommandoen fra debuggeren:

0: kd> !token e245d030
_TOKEN e245d030
TS Session ID: 0
User: S-1-5-18
Groups:
00 S-1-5-32-544
Attributes - Default Enabled Owner
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-11
Attributes - Mandatory Default Enabled
Primary Group: S-1-5-18
Privs:
00 0x000000007 SeTcbPrivilege Attributes - Enabled Default
01 0x000000002 SeCreateTokenPrivilege Attributes - Enabled
02 0x000000009 SeTakeOwnershipPrivilege Attributes -
03 0x00000000f SeCreatePagefilePrivilege Attributes - Enabled Default
04 0x000000004 SeLockMemoryPrivilege Attributes - Enabled Default
05 0x000000003 SeAssignPrimaryTokenPrivilege Attributes -
06 0x000000005 SeIncreaseQuotaPrivilege Attributes -
07 0x00000000e SeIncreaseBasePriorityPrivilege Attributes - Enabled Default
08 0x000000010 SeCreatePermanentPrivilege Attributes - Enabled Default
09 0x000000014 SeDebugPrivilege Attributes - Enabled Default
10 0x000000015 SeAuditPrivilege Attributes - Enabled Default
11 0x000000008 SeSecurityPrivilege Attributes -
12 0x000000016 SeSystemEnvironmentPrivilege Attributes -
13 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
14 0x000000011 SeBackupPrivilege Attributes -
15 0x000000012 SeRestorePrivilege Attributes -
16 0x000000013 SeShutdownPrivilege Attributes -
17 0x00000000a SeLoadDriverPrivilege Attributes - Enabled
18 0x00000000d SeProfileSingleProcessPrivilege Attributes - Enabled Default
19 0x00000000c SeSystemtimePrivilege Attributes -
20 0x000000019 SeUndockPrivilege Attributes - Enabled
21 0x00000001c SeManageVolumePrivilege Attributes -
22 0x00000001d SeImpersonatePrivilege Attributes - Enabled Default
23 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled Default
Authentication ID: (0,3e7)
Impersonation Level: Anonymous
TokenType: Primary
Source: *SYSTEM* TokenFlags: 0x89 ( Token in use )
Token ID: dcd3 ParentToken ID: 0
Modified ID: (0, 3c67b)
RestrictedSidCount: 0 RestrictedSids: 00000000

Vi kan se da at hovedgruppen som denne kjører innunder er S-1-5-18 som er da SID'en for Systemkontoen og har da alle mulige tenkelige privlegier.

Vi kan videre titte på security descriptoren for prosess objektet for LSASS, men først må vi finne objekt headeren som har ein ponter til security descriptoren:

0: kd> !object 8a0e7470
Object: 8a0e7470 Type: (8a3b8040) Process
ObjectHeader: 8a0e7458 (old version)
HandleCount: 10 PointerCount: 215

0: kd> dt _object_header 8a0e7458
nt!_OBJECT_HEADER
+0x000 PointerCount : 215
+0x004 HandleCount : 10
+0x004 NextToFree : 0x0000000a
+0x008 Type : 0x8a3b8040 _OBJECT_TYPE
+0x00c NameInfoOffset : 0 ''
+0x00d HandleInfoOffset : 0 ''
+0x00e QuotaInfoOffset : 0 ''
+0x00f Flags : 0x20 ' '
+0x010 ObjectCreateInfo : 0x805628c0 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x805628c0
+0x014 SecurityDescriptor : 0xe1001c3d
+0x018 Body : _QUAD

Security Descriptor pointeren i object headeren bruker de tre laveste bitene som flagg så derfor for å få adgang til selve security descritoren må vi fjerne de tre laveste bitene:

0: kd> !sd 0xe1001c3d & -8
->Revision: 0x1
->Sbz1 : 0x0
->Control : 0x8004
SE_DACL_PRESENT
SE_SELF_RELATIVE
->Owner : S-1-5-32-544
->Group : S-1-5-18
->Dacl :
->Dacl : ->AclRevision: 0x2
->Dacl : ->Sbz1 : 0x0
->Dacl : ->AclSize : 0x44
->Dacl : ->AceCount : 0x2
->Dacl : ->Sbz2 : 0x0
->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[0]: ->AceFlags: 0x0
->Dacl : ->Ace[0]: ->AceSize: 0x14
->Dacl : ->Ace[0]: ->Mask : 0x001f0fff
->Dacl : ->Ace[0]: ->SID: S-1-5-18

->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[1]: ->AceFlags: 0x0
->Dacl : ->Ace[1]: ->AceSize: 0x18
->Dacl : ->Ace[1]: ->Mask : 0x00120410
->Dacl : ->Ace[1]: ->SID: S-1-5-32-544

->Sacl : is NULL

Vi ser da at dette objektet er ein av administrator gruppen (S-1-5-32-544) og dette er en gruppe kontrollert innunder systemkontoen. Vi ser også at den har to ACE oppføringer begge av typen Access Allowed. Maskene kan være litt tungvint å dechiffrere men en kjent maske er ihvertfall 0x001f0fff som betyr fullstendig tilgang-noe som ikke er overraskende siden det gjelder Systemkontoen.

La oss nå teste ut et eksperiment hvor vi lager en mappe og nekter alle rettigheter til denne fra administrator gruppen:

La oss deretter legge til alle rettigheter for denne mappen for brukeren HKB som tilhører gruppen administratorer:





Hva skjer da om vi prøver å gi inn på mappen?




Ved å gå inn på de avanserte rettighetene til mappen kan vi få en oversikt over de aktive ACE'ene for denne mappen og også en forståelse hvorfor dette skjer. Som vi ser blir de forbydende ACE oppføringene prioritert først:




Dog er ikke den beste måten for å undersøke den effektive tilgangen en bruker har til et objekt, den eneste sikre måten å vise dette på er ved å trykke på fanen "Gjeldende Tillatelser" og skrive inn brukernavnet:




Vi kan dog se at denne brukeren faktisk har to rettigheter til dette objektet, nemlig å lese og endre tillatelser. Hvor kommer så disse fra? Når DACL spesifiserte ingen tillatelser? Jo det har seg slik at medlemmer av administratorgruppen er utstyrt med privlegiet take-ownership som vi husker ville automatisk gi slik tilgang, vi kan se en oversikt over privlegiene til forskjellige brukere i den Lokale sikkerhetspolicy manageren:




Dette guiden burde gi en fin innføring i de forskjellige komponentene i sikkerhetssystemet i Windows. Dog er det en del ting som jeg ikke har forklart i detalj men dette kan man finne ut mere om andre plasser - men skulle det være noe som er uklart eller noe er det bare å spørre!