Windows Vista Security

User Mode Security

 User Account Protection (UAP)
 Mandatory Integrity Control(MIC)
 UI Privlilege Isolation (UIPI)
 Restricted Process
 Unrestricted Process (Elevation)
 Standard methods
 The Legacy Shell Trick
 Consent Prompts and Admin Brokers
 Service Isolation
 File and Registry Virtualization
 Registry Virtualization
 File Virtualization
 Low Rights IE Virtualization
 Possible Attacks
User Account Protection (UAP)
 Limited User Accounts
 Standard user accounts preferred
 Problem: software isn’t always written for
“Standard” user accounts
 Administrators start as “Protected”
 Runs programs with minimal privileges
 Must authenticate protected actions
 Can run programs unrestricted
“Unprotected”
Mandatory Integrity Control(MIC)
 Every “securable object” has an Integrity
 Children inherit integrity parents
 Interactions exist at equal or lesser
integrity
 Higher integrity can act on lower through certain
functions
 Any interaction allowed through IPC (BAD)
 Lower Integrity server can impersonate higher
integrity. (ImpersonateNamedPipeClient)
Mandatory Integrity Control Levels
Integrity
Access
Level System Privileges
High Administrative (can install files
to the Program Files folder and
write to sensitive registry areas
like HKEY_LOCAL_MACHINE)

Medium User (can create and modify

files in the user's Documents
folder and write to user-specific
areas of the registry, such as
HKEY_CURRENT_USER)
Low Untrusted (can only write to
low integrity locations, such as
the Temporary Internet
Files\Low folder or the
HKEY_CURRENT_USER\Softwar
e\LowRegistry key)
UI Privilege Isolation (UIPI)
 Added to prevent Shatter attacks
 LI process can’t send messages to a HI
Process
 SendMessage
 PostMessage
 LI process can’t hook into a HI process
 SetWindowsHookEx
 SetWinEventHook
Restricted Process
 How is it restricted
 Security token normally has all privileges
 Some are disabled (Ignored during permission
checks)
 Process can re-enable them
 Security token created with less privileges
(CreateRestrictedToken)
 Some privileges removed
 Some privileges marked deny only
 “Group used for deny only”
 Explicit denials for group propagate
 Explicit allows do not
Unrestricted Process (Elevation)

 Process are run elevated when

 Process is a .msi or .exe and a registered
installer
 Process exists in app compatibility database
 Proper registry with entry value RUNASADMIN
 <application_name>.sbd created by
CompatAdmin.exe
 Aplication Manifest (<appname>.exe.manifest)
contains requestedExecutionLevel of
requireAdministrator
 User right clicks executable and clicks “Run
Elevated…” from explorer
 Executed by an already privileged process
The Legacy Shell Trick
 Kill explorer from taskmanager.exe and
restart it with file->new task
 New shell running with highest integrity
 Why does this work?
 WinLogon.exe handles Secure Attention
Sequence (ctrl+alt+delete and ctrl+shift+esc)
 taskmanager started this way is created with
high integrity
 File->new task creates a process with
CreateProcess instead of
CreateRestrictedProcess
 Fixed in later builds of Vista
Consent Prompts and Admin Brokers
 Windows Explorer can’t launch unrestricted
apps on its own
 Restricted Token
 Medium Integrity
 AppInfo Admin Broker service (runs as
LocalSystem)
 RunAsAdminProcess
 consent.exe run by AppInfo
 Creates process
 ImpersonateLoggedOnUser
 CreateProcessAsUser (not CreateProcess)
 Security Token
User In Login Standard Full Access
Administrators User Consent
Group Token Full
Local
Security
Administrator
User In
Login Authority Standard Administrator Token
User
Users Group Credentials
Token
Service Isolation
 Services use to exist in the same session
 Vista Services run in “Isolated Session 0”
 Services can’t open dialogs on desktop
 Neither can services marked interactive
 Dialogs from interactive services are
actually a Terminal Service Context
 Consent Prompts?
 AppInfo runs consent in the user’s desktop
session with CreateProcessAsUser
File and Registry Virtualization
 Why?
 Developers don’t code applications
properly
 Assume the need for admin privileges
 Need to provide backwards compatibility
 Need to provide separation and safety
Registry Virtualization
 Implemented by kernel
 Write attempts to
HKEY_LOCAL_MACHINE\Software redirected to
HKEY_CURRENT_USER\Software\Classes\Virtu
alStore\MACHINE\Software
 Provides per-user settings in apps that used
registry for storage.
 Provides isolation between users.
File Virtualization
 Implemented as a FS filter driver (luafv.sys)
 Example: Program files
 Foo writes to c:\Program Files\foo\foo.ini
 Foo is running as unprivileged and fails
 Filter driver maps c:\Program Files\foo\foo.ini to per-
user virtualized area.
 %UserProfile%\AppData\Local\VirtualStore\C\Progra
~1\foo contains user-specific copy of foo.ini
 Certain executable types not virtualized (cmd, bat,
exe, dll, etc..)
 Provides isolation
 Provides per-user settings (in certain cases)
Low Rights IE Virtualization
 Virtualization not done by Filter
Driver, done by AppCompat shim dll
 Why?
 Low integrity process can’t even write to
the virtualized areas
 Uses special broker applications for tasks
Low Rights IE Virtualization Components
 User runs IEUser.exe (Med integrity)
 IEUser.exe spawns IExplorer.exe
(Low Integrity)
 Any admin level requests handled by
IEInstall.exe
Ex-Possible Attacks
 Low Integrity – IE Approach
 Medium Integrity
 Method 1 – Slight of Hand/Bait and
switch
 Method 2 – Slight of Hand/Bait and
switch
Low integrity – IE Approach
 Unknown IE Exploit allows injection of
arbitrary code
 Code is run at low integrity
 Low integrity code can loopback on
localhost (gains default med integrity)
 Code can now insert files into the
filesystem eg. Virtualized start menu
startup folder
 No longer valid as of Beta 2
Medium Integrity - Method 1
 User expects consent prompt
 User is slow
 User clicks through
 Malicious app checks for all instances
of consent.exe
 If called on behalf of spoof target
copy our bad version over the good
one
Medium Integrity - Method 2
 Global COM Objects
 HKEY_LOCAL_MACHINE\Software\Classes\CLSID
 User Specific COM Objects
 HKEY_CURRENT_USER\Software\Classes\CLSID
 User objects have prescient over system
 Enumerate system COM objects
 Create paths to malicious versions in
current_user
 No longer valid, only local_machine keys
are referred to for elevation
Kernel Mode Security
 Booting Vista
 Driver Signing
 Patch Guard
 Secure Bootup
 Restricted user-mode access to
\Device\PhysicalMemory
Booting Vista (Stage 1)
 Locates and runs bootmgr for legacy PC/AT Bios and
bootmgr.efi for an efi system
 “The Vista Boot Manager calls InitializeLibrary,
which in turn calls BlpArchInitialize (GDT, IDT,
etc.), … BlpTpmInitialize (TPM), BlpIoInitialize
(file systems), … BlBdInitialize (debugging),
BlDisplayInitialize, …“
 Boot.init replaced with BCD file
 Selects boot description and runs
BlImageLoadBootApplication
 Calls BlFveSecureBootUnlockBootDevice and
BlFveSecureBootCheckpointBootApp if Full Volume
Encryption is enabled.
Booting Vista (Stage 2)
 WINLOAD.EXE replaces NTLDR.EXE as
the os loader
 Performs many of the same tasks as
bootmgr
 Discovers disks and loads the hive
 Loads OS Signed catalog
Booting Vista (Stage 2) cont.
 Verifies its own integrity and that of other
system files
 Does not boot if they don’t match
 Will however boot if a debugger is attached
except on certain key files
 Loads appropriate driver for debugging
 Usb
 Firewire
 Serial
 Loads remaining drivers in order from the
hive
Booting Vista (Stage 3)
 Loads NTOSKRNL.EXE
 Responsible for code verification of
system drivers
 Runtime checks (PatchGuard and
CI.DLL)
Driver Signing
 Windows Vista 64-bit edition only
 All Kernel mode drivers must have a
class 3 cert
 Justification:
 Stability – less hackish code in kernel
 Security – Prevents root kits
 Ulterior Motives:
 DRM protection
Driver Signing (Implementation)
 WINLOAD.EXE - Boot driver checks
 NTOSKRNL.EXE – All other driver
(uses CI.DLL)
 Functions
 MinCrypL_CheckSignedFile
 MinCrypL_CheckImageHash
 MinCryptK_FindPageHashesInCatalog
Driver Signing (Implementation)
 MinCrypL_CheckSignedFile
 Used by WINLOAD.EXE and CI.DLL
 Parses certificate to check validity
 Checks certificate against a root certificate
 Hard coded list of 8 certificates in binary
 Adding certificates to system certificates
doesn’t add to this list.
 If certificate is signed by a root authority
validate it
 Parse public key info/RSA Public Key
 Convert the key to a “Safe” public key
 Verify signing according to PKCS1
Driver Signing (Implementation)
 MinCrypL_CheckImageHash
 Used by WINLOAD.exe
 Verifies driver matches images in the signed
catalog
 Walks linked list of catalogs pointed to by
g_CatalogList calling
I_CheckImageHashInCatalog on each
 MinCryptK_FindPageHashesInCatalog
 Used by CI.DLL
 Checks code pages of process or driver at
runtime.
 Binary searches for matching page hash in
ntpe.cat nt5.cat
Patch Guard
 Can not be disabled
 Polls at 5-10 minute intervals to
verify kernel structures are intact
 SSDT (System Service Descriptor Table)
 GDT (Global Descriptor Table)
 IDT (Interrupt Descriptor Table)
 System images (ntoskrnl.exe, ndis.sys,
hal.dll)
 Processor MSRs (syscall)
Patch Guard (Implementation)
 Uses Obfuscation and Misdirection
“raise the bar”
 Example:
 Initialization
 nt!KiDivide6432 (What does it do?)
 Throws divide processor exception
 Patch Guard Initialization called in
exception handler
Patch Guard (Implementation)
 Initialization
 Creates random key
 Creates random rotate number
 Picks a fake memory pool tag
 Initializes memory
 Zeroes it
 Fills it with structures
 Encrypts structures in memory
Patch Guard (Attacks)
 Exception Handler Hooking – Verification
relies on exceptions, hook the exception
and turn it into a nop
 KeBugCheckEX Hook – When called check if
bug check code is 0x109 if so reset stack
pointer and instruction pointer to the
thread and carry on
 Finding the timer – Find the timer event
and remove it. Not reliable and not portable
since it uses an unexported address
 Simulating Hotpatching – Use the Hotpatch
api to trick windows
Secure Bootup
 TPM Holds key used for full drive encryption
 Takes measurments of boot items such as
ROM images and firmware images
 Special boot code in TPM decrypts the boot
loader
 Boot loader asks for full drive encryption
key from TPM
 Boots the same as detailed in Booting Vista
Disabled user-mode access to
\Device\PhysicalMemory
 Started with Windows Server 2003
SP1
 Crazylord (p59-0x10) – showed a
method for detecting bios root kits
using \Device\PhysicalMemory
The End
Frame-Based Exception Handlers
 Every thread in a Win32 Process has at
least one frame-based exception handler.
 A list of EXCEPTION_REGISTRATION
structures can be found in the process’s
Thread Environment Block at FS: [0]
 Overwrite the exception handler with an
address which will
pop reg
pop reg
ret
Determining a valid handler
 Handler can not exist on the stack
(determined by TEB FS:[4] FS[8])
 Checked against loaded modules
 If the address exists outside of the bounds of
these addresses it is ok to call?
 If the address exists inside these it is checked
against registered handlers.
 Checks a value in the PE header if it is set to
0x04 then the module is not allowed.
 Finally checks for a Load Configuration Directory
if missing function returns 0 and no other checks
are done and handler is executed
Exploiting Frame-Based Exception
Handling (Window 2003 Server)
 Methods
 Exploit an existing handler that we can
manipulate to get us back into our buffer
 Find a block of code in an address not
associated with a module that will get us
back to our buffer
 Find a block of code in the address space
of a module that does not have a Load
Configuration Directory
Exploiting an Existing Handler
 NTDLL contains several registered
exception handlers
 Only works the first time since
sensitive data is in predictable places
77F45A3F mov ebx,dword ptr [ebp+0Ch]
..
77F45A61 mov esi, dword ptr [ebx+0Ch]
77F45A64 mov edi, dword ptr [ebx+8]
..
77F45A75 lea ecx, [esi+esi*2]
77F45A78 mov eax, dword ptr [edi+ecx*4+4]
..
77F45A64 call eax
Finding and exploiting a block of
code not associated with a module
 Windows 2003 Server Enterprise
edition contains such an address at
0x7FFC0AC5. (pop pop ret)
 Not usable since Standard addition
does not have the same issue
 However we can use the address of
our EXCEPTION_REGISTRATION
struct in the form of a call or jump
esp+somevalue
Stack Protection and Windows 2003
Server
 Security Cookies
 Authoritative copy stored in the .data
segment
 /GS Compiler Flag
 Reorders parameters
 Places overflowable buffers close to
canary values
Heap Based Buffer Overflows
 Handle to Win32 Heap through
GetProcessHeap() and through the PEB
 HeapAllocate – Win32 version of brk and
brk.
 Every heap starts with a struct and
contains pointers to the previous and next
blocks (similar to malloc).
 Use Exception Handlers to overwrite
functions such as RtlAccquitePebLock() and
RtlReleasePebLock() (Not Usable in
Win2k3Server)
Heap Overflow Fun
 The PEB in a process is fixed across all
WinNT Versions.
 Step1: Overflow heap to overwrite the PEB
+ 4 (Return address).
 Step2: Allow Program to segfault and
terminate.
 Step3: Sit back and watch ExitProcess run
your code for you.
 Make sure to set the pointer back or something
else could kill your process if its used elsewhere
in the code
Vectored Handlers
 Similar in structure to Frame based
exception handlers.
 Stored on the heap instead of stack
 Executed before frame based
handlers.
Overwritting Exception Filters
 Overwrite pointer to Unhandled
Exception Filter.
 Windows exposes a function to do this
SetUnhandledExceptionFilter().
 This function shows us where this
Handler is stored.
 By replacing the address of the function
this points to when an unhandled
exception happens we gain control.
Other Aspects of Heap-Based
Overflows
 COM Objects and the Heap
 COM Objects when instantiated are placed on the
heap
 A vtable is created to store function pointers for an
object and the object is stored above it in the
address space
 If you overflow an object you can possibly overwrite
the vtable of the object above you and redirect code
execution.
 Overflowing Program Control Data
 We don’t always want to execute arbitrary code
 Some times we just want to change data on the heap
that controls the execution flow.
 Ex. Making a directory exposed by a web server
writable so anyone can write to it.