Transcript Operating System Security

Chapter 12
Operating System Security
Operating System
 each layer of code needs
measures in place to
provide appropriate
security services
 each layer is vulnerable to
attack from below if the
lower layers are not
secured appropriately
Measures
 the 2010 Australian Defense Signals Directorate (DSD) list
the “Top 35 Mitigation Strategies”
 over 70% of the targeted cyber intrusions investigated by
DSD in 2009 could have been prevented
 the top four measures for prevention are:
 patch operating systems and applications using auto-update
 patch third-party applications
 restrict admin privileges to users who need them
 white-list approved applications
Operating System Security
 possible for a system to be compromised during the
installation process before it can install the latest patches
 building and deploying a system should be a planned
process designed to counter this threat
 process must:
 assess risks and plan the system deployment
 secure the underlying operating system and then the key
applications
 ensure any critical content is secured
 ensure appropriate network protection mechanisms are used
 ensure appropriate processes are used to maintain security
System Security Planning Process
the purpose of the system,
the type of information
stored, the applications and
services provided, and their
security requirements
who will administer the
system, and how they will
manage the system (via local
or remote access)
the categories of users of the
system, the privileges they
have, and the types of
information they can access
what access the system has
to information stored on
other hosts, such as file or
database servers, and how
this is managed
how the users are
authenticated
how access to the
information stored on the
system is managed
any additional security
measures required on the
system, including the use of
host firewalls, anti-virus or
other malware protection
mechanisms, and logging
Operating Systems Hardening
 first critical step in securing a system is to secure the base
operating system
 basic steps
 install and patch the operating system
 harden and configure the operating system to adequately
address the indentified security needs of the system
 install and configure additional security controls, such as antivirus, host-based firewalls, and intrusion detection system (IDS)
 test the security of the basic operating system to ensure that
the steps taken adequately address its security needs
Initial Setup and Patching
system security
begins with the
installation of
the operating
system
ideally new
systems should be
constructed on a
protected network
initial installation
should install the
minimum
necessary for the
desired system
overall boot
process must
also be secured
full installation and
hardening process
should occur
before the system
is deployed to its
intended location
the integrity and
source of any
additional device
driver code must
be carefully
validated
should stage and
validate all
patches on the
test systems
before deploying
them in
production
critical that the
system be kept up
to date, with all
critical security
related patches
installed
Remove
Unnecessary
Services,
Applications,
Protocols
 when performing the initial
installation the supplied
defaults should not be used
 default configuration is set
 if fewer software packages
are available to run the risk
is reduced
 system planning process
should identify what is
actually required for a given
system
to maximize ease of use
and functionality rather
than security
 if additional packages are
needed later they can be
installed when they are
required
 system planning process should
Configure
Users, Groups,
and
Authentication
consider:
 categories of users on the
system
 privileges they have
 types of information they can
access
 how and where they are defined
and authenticated
 default accounts included as
 not all users with access to a
system will have the same
access to all data and resources
on that system
 elevated privileges should be
restricted to only those users
that require them, and then only
when they are needed to
perform a task
part of the system installation
should be secured
 those that are not required
should be either removed or
disabled
 policies that apply to
authentication credentials
configured
Configure
Resource
Controls
 once the users and groups are
defined, appropriate
permissions can be set on data
and resources
 many of the security hardening
guides provide lists of
recommended changes to the
default access configuration
Install
Additional
Security
Controls
 further security possible by
installing and configuring
additional security tools:
 anti-virus software
 host-based firewalls
 IDS or IPS software
 application white-listing
 checklists are included in
Test the
System
Security
security hardening guides
 there are programs specifically
designed to:
 review a system to ensure that
a system meets the basic
security requirements
 scan for known vulnerabilities
 final step in the process of
initially securing the base
operating system is security
testing
 goal:
 ensure the previous security
configuration steps are
correctly implemented
 identify any possible
vulnerabilities
and poor configuration
practices
 should be done following the
initial hardening of the system
 repeated periodically as part of
the security maintenance
process
Application Configuration
 may include:
 creating and specifying appropriate data storage areas for
application
 making appropriate changes to the application or service default
configuration details
 some applications or services may include:
 default data
 scripts
 user accounts
 of particular concern with remotely accessed services such as
Web and file transfer services
 risk from this form of attack is reduced by ensuring that most of
the files can only be read, but not written, by the server
Encryption Technology
is a key
enabling
technology
that may be
used to secure
data both in
transit and
when stored
must be
configured and
appropriate
cryptographic
keys created,
signed, and
secured
if secure network
services are provided
using TLS or IPsec
suitable public and
private keys must be
generated for each of
them
if secure network
services are
provided using
SSH, appropriate
server and client
keys must be
created
cryptographic
file systems are
another use of
encryption
Security Maintenance
 process of maintaining security is continuous
 security maintenance includes:
 monitoring and analyzing logging information
 performing regular backups
 recovering from security compromises
 regularly testing system security
 using appropriate software maintenance processes to patch
and update all critical software, and to monitor and revise
configuration as needed
can only inform you
about bad things that
have already
happened
automated
analysis is
preferred
generates significant volumes
of information and it is
important that sufficient
space is allocated for them
in the event of a system breach
or failure, system administrators
can more quickly identify what
happened
Logging
range of data acquired should be
determined during the system
planning stage
information
can be
generated by
the system,
network and
applications
key is to ensure you
capture the correct data
and then appropriately
monitor and analyze
this data
Data Backup and Archive
performing regular
backups of data is a
critical control that
assists with
maintaining the
integrity of the
system and user
data
•may be legal or
operational requirements
for the retention of data
backup
archive
•the process of
making copies of
data at regular
intervals
•the process of retaining
copies of data over
extended periods of time
in order to meet legal and
operational requirements
to access past data
needs and policy relating to
backup and archive should be
determined during the
system planning stage
•kept online or offline
•stored locally or transported to a
remote site
• trade-offs include ease of
implementation and cost versus
greater security and robustness
against different threats
Linux/Unix Security
 patch management
 keeping security patches up to date is a widely recognized and
critical control for maintaining security
 application and service configuration
 most commonly implemented using separate text files for each
application and service
 generally located either in the /etc directory or in the installation
tree for a specific application
 individual user configurations that can override the system defaults
are located in hidden “dot” files in each user’s home directory
 most important changes needed to improve system security are to
disable services and applications that are not required
Linux/Unix Security
 users, groups, and permissions
 access is specified as granting read, write, and execute
permissions to each of owner, group, and others for each
resource
 guides recommend changing the access permissions for
critical directories and files
 local exploit
 software vulnerability that can be exploited by an attacker to
gain elevated privileges
 remote exploit
 software vulnerability in a network server that could be
triggered by a remote attacker
Linux/Unix Security
remote access controls
logging and log rotation
• several host firewall programs
may be used
• most systems provide an
administrative utility to select
which services will be permitted
to access the system
• should not assume that the
default setting is necessarily
appropriate
Linux/Unix Security
 chroot jail
 restricts the server’s view of the file system to just a specified
portion
 uses chroot system call to confine a process by mapping the
root of the filesystem to some other directory
 file directories outside the chroot jail aren’t visible or
reachable
 main disadvantage is added complexity
Windows Security
patch management
• “Windows Update” and
“Windows Server Update
Service” assist with
regular maintenance and
should be used
• third party applications
also provide automatic
update support
users administration and
access controls
• systems implement
discretionary access controls
resources
• Vista and later systems
include mandatory integrity
controls
• objects are labeled as being of
low, medium, high, or system
integrity level
• system ensures the subject’s
integrity is equal or higher
than the object’s level
• implements a form of the Biba
Integrity model
Windows Security
Users Administration and Access Controls
Windows systems also
define privileges
• system wide and granted to user
accounts
User Account Control (UAC)
• provided in Vista and later systems
• assists with ensuring users with
administrative rights only use them
when required, otherwise accesses
the system as a normal user
combination of share and
NTFS permissions may be
used to provide additional
security and granularity
when accessing files on a
shared resource
Low Privilege Service
Accounts
• used for long-lived service
processes such as file, print, and
DNS services
Windows Security
application and service configuration
• much of the configuration information is
centralized in the Registry
• forms a database of keys and values that may
be queried and interpreted by applications
• registry keys can be directly modified
using the “Registry Editor”
• more useful for making bulk changes
Windows Security
 other security controls
 essential that anti-virus, anti-spyware, personal firewall, and other
malware and attack detection and handling software packages are
installed and configured
 current generation Windows systems include basic firewall and
malware countermeasure capabilities
 important to ensure the set of products in use are compatible
 Windows systems also support a range of cryptographic functions:
 encrypting files and directories using the Encrypting File System (EFS)
 full-disk encryption with AES using BitLocker
 “Microsoft Baseline Security Analyzer”
 free, easy to use tool that checks for compliance with Microsoft’s security
recommendations
Virtualization
 a technology that provides an abstraction of the resources
used by some software which runs in a simulated
environment called a virtual machine (VM)
 benefits include better efficiency in the use of the physical
system resources
 provides support for multiple distinct operating systems
and associated applications on one physical system
 raises additional security concerns
Virtualization Alternatives
application virtualization
full virtualization
allows
applications
written for one
environment to
execute on some
other operating
system
multiple full
operating system
instances execute
in parallel
virtual machine monitor (VMM)
hypervisor
coordinates access between each
of the guests and the actual
physical hardware resources
Native Virtualization Security Layers
Hosted Virtualization Security Layers
Virtualization Security Issues
 security concerns include:
 guest OS isolation
 ensuring that programs executing within a guest OS may only
access and use the resources allocated to it
 guest OS monitoring by the hypervisor
 which has privileged access to the programs and data in each
guest OS
 virtualized environment security
 particularly image and snapshot management which attackers
may attempt to view or modify
Hypervisor Security
 should be
 secured using a process similar to securing an operating system
 installed in an isolated environment
 configured so that it is updated automatically
 monitored for any signs of compromise
 accessed only by authorized administration
 may support both local and remote administration so must be
configured appropriately
 remote administration access should be considered and secured
in the design of any network firewall and IDS capability in use
 Access to VM image and snapshots must be carefully controlled
Linux Security
Linux Security

Linux has evolved into one of the most popular and versatile operating systems

many features mean broad attack surface

can create highly secure Linux systems

will review:





Discretionary Access Controls
typical vulnerabilities and exploits in Linux
best practices for mitigating those threats
new improvements to Linux security model
Linux’s traditional security model is:


people or proceses with “root” privileges can do anything
other accounts can do much less

hence attacker’s want to get root privileges

can run robust, secure Linux systems

crux of problem is use of Discretionary Access Controls (DAC)
Linux Security Transactions
File System Security
 in Linux everything as a file
 e.g. memory, device-drivers, named pipes, and other system
resources
 hence why filesystem security is so important
 I/O to devices is via a “special” file
 e.g. /dev/cdrom
 have other special files like named pipes
 a conduit between processes / programs
Users and Groups
 a user-account (user)
 represents someone capable of using files
 associated both with humans and processes
 a group-account (group)
 is a list of user-accounts
 users have a main group
 may also belong to other groups
 users & groups are not files
Users and Groups
 user's details are kept in /etc/password
maestro:x:200:100:Maestro Edward
Hizzersands:/home/maestro:/bin/bash
 additional group details in /etc/group
conductors:x:100:
pianists:x:102:maestro,volodya
 use useradd, usermod, userdel to alter
File Permissions
 files have two owners: a user & a group
 each with its own set of permissions
 with a third set of permissions for other
 permissions are to read/write/execute in order
user/group/other, cf.
-rw-rw-r-- 1 maestro user 35414 Mar 25
01:38 baton.txt
 set using chmod command
Directory Permissions
 read = list contents
 write = create or delete files in directory
 execute = use anything in or change working directory to
this directory
 e.g.
$ chmod g+rx extreme_casseroles
$ ls -l extreme_casseroles
drwxr-x--- 8 biff drummers 288
01:38 extreme_casseroles
Mar 25
Sticky Bit
 originally used to lock file in memory
 now used on directories to limit delete
 if set must own file or dir to delete
 other users cannot delete even if have write
 set using chmod command with +t flag, e.g.
chmod +t extreme_casseroles
 directory listing includes t or T flag
drwxrwx--T 8 biff drummers
extreme_casseroles
288
Mar 25 01:38
 only apply to specific directory not child dirs
SetUID and SetGID
 setuid bit means program "runs as" owner
 no matter who executes it
 setgid bit means run as a member of the group which owns it
 again regardless of who executes it
 "run as" = "run with same privileges as”
 are very dangerous if set on file owned by root or other privileged
account or group
 only used on executable files, not shell scripts
 setuid has no effect on directories. setgid does and causes any file
created in a directory to inherit the directory's group
 useful if users belong to other groups and routinely create files to be
shared with other members of those groups
 instead of manually changing its group
Numeric File Permissions
Kernel vs User Space
 Kernel space
 refers to memory used by the Linux kernel and its loadable
modules (e.g., device drivers)
 User space
 refers to memory used by all other processes
 since kernel enforces Linux DAC and security critical to
isolate kernel from user
 so kernel space never swapped to disk
 only root may load and unload kernel modules
setuid root Vulnerabilities
 a setuid root program runs as root
 no matter who executes it
 used to provide unprivileged users with access to
privileged resources
 must be very carefully programmed
 if can be exploited due to a software bug
 may allow otherwise-unprivileged users to use it to wield
unauthorized root privileges
 distributions now minimise setuid-root programs
 system attackers still scan for them!
Web Vulnerabilities
 a very broad category of vulnerabilities
 because of ubiquity of world wide web have big and visible
attack surfaces
 when written in scripting languages
 not as prone to classic buffer overflows
 can suffer from poor input-handling
 few “enabled-by-default” web applications
 but users install vulnerable web applications
 or write custom web applications having easily-
identified and easily-exploited flaws
Rootkits
 allow attacker to cover their tracks
 if successfully installed before detection, all is very nearly
lost
 originally collections of hacked commands
 hiding attacker’s files, directories, processes
 now use loadable kernel modules
 intercepting system calls in kernel-space
 hiding attacker from standard commands
 may be able to detect with chkrootkit
 generally have to wipe and rebuild system
Linux Hardening - OS Installation
 security begins with O/S installation
 especially what software is run
 since unused applications liable to be left in default, un-
hardened and un-patched state
 generally should not run:
 X Window system, RPC services, R-services, inetd, SMTP
daemons, telnet etc
 also have some initial system s/w configuration:





setting root password
creating a non-root user account
setting an overall system security level
enabling a simple host-based firewall policy
enabling SELinux
Patch Management
 installed server applications must be:
 configured securely
 kept up to date with security patches
 patching can never win “patch rat-race”
 have tools to automatically download and install security
updates
 e.g. up2date, YaST, apt-get
 note should not run automatic updates on change-controlled
systems without testing
Network Access Controls
 network a key attack vector to secure
 TCP wrappers a key tool to check access
 originally tcpd inetd wrapper daemon
 before allowing connection to service checks
 if requesting host explicitly in hosts.allow is ok
 if requesting host explicitly in hosts.deny is blocked
 if not in either is ok
 checks on service, source IP, username
 now often part of app using libwrappers
Network Access Controls
 also have the very powerful netfilter Linux kernel native firewall
mechanism
 and iptables user-space front end
 as useful on firewalls, servers, desktops
 direct config tricky, steep learning curve
 do have automated rule generators
 typically for “personnal” firewall use will:
 allow incoming requests to specified services
 block all other inbound service requests
 allow all outbound (locally-originating) requests
 if need greater security, manually config
Antivirus Software
 historically Linux not as vulnerable to viruses
 more to lesser popularity than security
 prompt patching was effective for worms
 but viruses abuse users privileges
 non-root users have less scope to exploit
 but can still consume resources
 growing Linux popularity mean exploits
 hence antivirus software will more important
 various commercial and free Linux A/V
User Management
 guiding principles in user-account security:
 need care setting file / directory permissions
 use groups to differentiate between roles
 use extreme care in granting / using root privs
 commands: chmod, useradd/mod/del, groupadd/mod/del,
passwd, chage
 info in files /etc/passwd & /etc/group
 manage user’s group memberships
 set appropriate password ages
Root Delegation
 have "root can to anything, users do little” issue
 “su” command allows users to run as root
 either root shell or single command
 must supply root password
 means likely too many people know this
 SELinux RBAC can limit root authority, complex
 “sudo” allows users to run as root
 but only need their password, not root password
 /etc/sudoers file specifies what commands allowed
 or configure user/group perms to allow, tricky
Logging

effective logging a key resource

Linux logs using syslogd or Syslog-NG




receive log data from a variety of sources
sorts by facility (category) and severity
writes log messages to local/remote log files
Syslog-NG preferable because it has:

variety of log-data sources / destinations. much more flexible “rules engine” to configure

Log Management………

can log via TCP which can be encryptedbalance number of log files used


manage size of log files



size of few to finding info in many
must rotate log files and delete old copies. typically use logrotate utility run by cron
to manage both system and application logs
must also configure application logging
Running As Unprivileged
User/Group
 every process “runs as” some user
 extremely important this user is not root
 since any bug can compromise entire system
 may need root privileges, e.g. bind port
 have root parent perform privileged function
 but main service from unprivileged child
 user/group used should be dedicated
 easier to identify source of log messages
Running in chroot Jail
 chroot confines a process to a subset of /
 maps a virtual “/” to some other directory
 useful if have a daemon that should only access a portion of
the file system, e.g. FTP
 directories outside the chroot jail aren’t visible or reachable
at all
 contains effects of compromised daemon
 complex to configure and troubleshoot
 must mirror portions of system in chroot jail
Modularity
 applications running as a single, large, multipurpose
process can be:
 more difficult to run as an unprivileged user
 harder to locate / fix security bugs in source
 harder to disable unnecessary functionality
 hence modularity a highly prized feature
 providing a much smaller attack surface
 cf. postfix vs sendmail, Apache modules
Encryption
 sending logins & passwords or application data over
networks in clear text exposes them to network
eavesdropping attacks
 hence many network applications now support encryption
to protect such data
 often using OpenSSL library
 may need own X.509 certificates to use
 can generate/sign using openssl command
 may use commercial/own/free CA
Logging
 applications can usually be configured to log to any level
of detail (debug to none)
 need appropriate setting
 must decide if use dedicated file or system logging facility
(e.g. syslog)
 central facility useful for consistent use
 must ensure any log files are rotated
Mandatory Access Controls
 Linux uses a DAC security model
 but Mandatory Access Controls (MAC) impose a global
security policy on all users
 users may not set controls weaker than policy
 normal admin done with accounts without authority to
change the global security policy
 but MAC systems have been hard to manage
 Novell’s SuSE Linux has AppArmor
 RedHat Enterprise Linux has SELinux
 pure SELinux for high-sensitivity, high-security
Windows Security
 Windows is the world’s most popular O/S
 advantage is that security enhancements can protect
millions of nontechnical users
 challenge is that vulnerabilities in Windows can also affect
millions of users
 will review overall security architecture of Windows
 then security defenses built into Windows
Windows Security Architecture
 Security Reference Monitor (SRM)
 a kernel-mode component that performs access checks,
generates audit log entries, and manipulates user rights
(privileges)
 Local Security Authority (LSA)
 responsible for enforcing local security policy
 Security Account Manager (SAM)
 a database that stores user accounts and local users and
groups security information
 local logins perform lookup against SAM DB
 passwords are stored using MD4
Windows Security Architecture
 Active Directory (AD)
 Microsoft’s LDAP directory
 all Windows clients can use AD to perform security
operations including account logon
 authenticate using AD when the user logs on using a
domain rather than local account
 user’s credential information is sent securely across
the network to be verified by AD
 WinLogon (local) and NetLogon (net) handle login
requests
Local vs Domain Accounts
 a networked Windows computer can be:
 domain joined
 can login with either domain or local accounts
 if local may not access domain resources
 centrally managed and much more secure
 in a workgroup
 a collection of computers connected together
 only local accounts in SAM can be used
 no infrastructure to support AD domain
Domain Login Example
 domain admin adds user’s account info (name,
account, password, groups, privileges)
 account is represented by a Security ID (SID)
 unique to each account within a domain
 of form: S-1–5–21-AAA-BBB-CCC-RRR
 Breakdown: S means SID; 1 is version number; 5 is
identifier authority (here is
SECURITY_NT_AUTHORITY); 21 means “not unique”,
although always unique within a domain; AAA-BBBCCC is unique number representing domain; and RRR is
a relative id (increments by 1 for each new account)
Domain Login Example (cont.)
 username in one of two forms:
 SAM format: DOMAIN\Username
 User Principal Name (UPN):
[email protected]
 login using username & password or smartcard
 assuming login is correct, token is generated and
assigned to the user
 contains user’s SID, group membership info, and privileges
 assigned to every process run by user, and used for access
checks
Windows Privileges
 are systemwide permissions assigned to user accounts –
over 45 total
 e.g. backup computer, or change system time
 some are deemed “dangerous” such as:
 act as part of operating system privilege
 debug programs privilege
 backup files and directories privilege
 others are deemed “benign” such as
 bypass traverse checking privilege
Access Control Lists

two forms of access control list (ACL):

Discretionary ACL (DACL)


System ACL (ACL)


grants or denies access to protected resources such as files, shared memory, named pipes etc
used for auditing and in Windows Vista to enforce mandatory integrity policy
objects needing protection are assigned a DACL (and possible SACL) that includes

SID of the object owner. list of access control entries (ACEs)

each ACE includes a SID & access mask

access mask could include ability to:


read, write, create, delete, modify, etc
access masks are object-type specific

e.g. service abilities are create, enumerate
Security Descriptor (SD)
 data structure with object owner, DACL, & SACL
 e.g.
Owner: CORP\Blake
ACE[0]: Allow CORP\Paige Full Control
ACE[1]: Allow Administrators Full Control
ACE[2]: Allow CORP\Cheryl Read, Write and Delete
 have no implied access, if there is no ACE for requesting
user, then access is denied
 applications must request correct type of access
 if just request “all access” when need less (e.g. read) some
user’s who should have access will be denied
More SD’s & Access Checks
 each ACE in the DACL determines access
 an ACE can be an allow or a deny ACE
 Windows evaluates each ACE in the ACL until access is
granted or explicitly denied
 so deny ACEs come before allow ACEs
 default if set using GUI
 explicitly order if create programmatically
 when user attempts to access a protected object, the O/S
performs an access check
 comparing user/group info with ACE’s in ACL
Application access
 Note that when an application requests access, it must
also request an access level.
 Initially (before XP), most applications just requested “all
access”, which is only given to owner or admin accounts.
 This is the reason so many applications failed on Windows
XP unless they ran at admin level – essentially, poor
coding.
Interacting with SDs
 Powershell to get an object’s SD:
 get-acl c:\folder\file.txt | format-list
 use set-acl to set DACL or SACL
 Can also use Security Descriptor Definition Language
(SDDL):
 Example function:
ConvertStringSecurityDescriptorToSecurityDescriptor()
Impersonation
 process can have multiple threads
 common for both clients and servers
 impersonation allows a server to serve a user, using their
access privileges
 e.g. ImpersonateNamedPipeClient function sets user’s token
on the current thread
 then access checks for that thread are performed against this
token not server’s
 with user’s access rights
Mandatory Access Control
 have Integrity Control in Windows Vista (and later)
that limits operations changing an object’s state
 objects and principals are labeled (using SID):
 Low integrity (S-1-16-4096)
 Medium integrity (S-1-16-8192)
 High integrity (S-1-16-12288)
 System integrity (S-1-16-16384)
 when write operation occurs first check subject’s
integrity level dominates object’s integrity level
 much of O/S marked medium or higher integrity
Vista User Account
Windows Vulnerabilities
 Windows, like all O/S’s, has security bugs
 and bugs have been exploited by attackers to compromise
customer operating systems
 Microsoft now uses process improvement called the
Security Development Lifecycle
 net effect approx 50% reduction in bugs
 Windows Vista used SDL start to finish
 IIS v6 (in Windows Server 2003) had only 3 vulnerabilities in
4 years, none critical
Security Development Lifecycle
(SDL)
 Requirements:
 Mandatory security education
 Security design requirements
 Threat modeling
 Attack surface analysis and reduction
 Secure coding
 Secure testing
 Security push
 Final security review
 Security response
Patch Management
 At first, patches were released at all times. Now, they
release on the second Tuesday of each month (Patch
Tuesday).
 More recently, they even announce the expected load the
Thursday before, which has been popular with sys admins.
Windows System Hardening

process of shoring up defenses, reducing exposed
functionality, disabling features






known as attack surface reduction
use 80/20 rule on features
not always achievable
e.g. requiring RPC authentication in XP SP2
e.g. strip mobile code support on servers
servers easier to harden:
are used for very specific and controlled purposes
2. server users are administrators with (theoretically) better
computer configuration skills than typical users
1.
Windows Security Defenses
 Have 4 broad categories of security defenses:
 account defenses
 network defenses
 buffer overrun defenses.
 browser defenses
Account Defenses
 user accounts can have privileged SIDs
 least privilege dictates that users operate with just
enough privilege for tasks
 Windows XP users in local Administrators
 for application compatibility reasons
 can use “Secondary Logon” to run applications
 also restricted tokens reduce per-thread privilege
 Windows Vista onwards reverses default with UAC
 users prompted to perform a privileged operation
 unless admin on Server
Low Privilege Service Accounts
 Windows services are long-lived processes started
after booting
 many ran with elevated privileges
 but many do not need elevated requirements
 Windows XP added Local Service and Network service
accounts
 allow a service local or network access
 otherwise operate at much lower privilege level
 Windows XP SP2 split RPC service (RPCSS) in two
(RPCSS and DCOM Server Process)
 example of least privilege in action, see also IIS6
 direct result of Blastr worm
Stripping Privileges
 another defense is to strip privileges from an account soon
after an application starts
 e.g. Index server process runs as system to access all disk
volumes
 but then sheds any unneeded privileges as soon as possible
 using AdjustTokenPrivileges
 Windows Vista can define privileges required by a service
 using ChangeServiceConfig2
Network Defenses
 have IPSec and IPv6 with authenticated network packets
enabled by default in Windows Vista
 IPv4 also enabled by default, expect less use
 E.g. Windows Xbox live network ----- ipsec
 have built-in software firewall
 block inbound connections on specific ports
 Vista can allow local net access only
 optionally block outbound connections
 default was off (XP) but now default on
Buffer Overrun Defenses
 many compromises exploit buffer overruns
 Windows Vista has “Stack-Based Buffer Overrun Detection
(/GS)” default enabled
 source code compiled with special /GS option
 does not affect every function; only those with at least 4-
bytes of contiguous stack data and that takes a pointer or
buffer as an argument
 defends against “classic stack smash”
Windows Stack and /GS flag
Buffer Overrun Defenses
 No eXecuteNamed (NX) / Data Execution Prevention
(DEP) / eXecution Disable (XD)
 prevent code executing in data segments
 as commonly used by buffer overrun exploits
 applications linked with /NXCOMPAT option
 Stack Randomization (Vista only)
 randomizes thread stack base addresses
 Heap-based buffer overrun defenses:
 add and check random value on each heap block
 heap integrity checking
 heap randomization (Vista only)
Other Defenses
 Image Randomization
 O/S boots in one of 256 configurations
 makes O/S less predictable for attackers
 Service Restart Policy
 services can be configured to restart if fail
 great for reliability but lousy for security
 Vista sets some critical services so can only restart twice,
then manual restart needed
 gives attacker only two attempts
 Encrypted File System…..EFS, Bitlocker
Browser Defenses
 web browser is a key point of attack
 via script code, graphics, helper objects
 Microsoft added many defenses to IE7 onwards
 ActiveX opt-in
 unloads ActiveX controls by default
 when any then first run prompts user to confirm
 protected mode
 IE runs at low integrity level (see earlier)
 so more difficult for malware to manipulate O/S
The End