Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
System SecuritySystem Security
Aurélien [email protected]
News of the week
News of the week
This Week
• Covering (Windows and )Unix security basics– Basic protections
– Privileges etc...
• That may be redundant with previous courses on Operating System, – Yet here we focus on security and practical concerns
• Then second half of the lecture is a lab:– Get you started
– Make sure everyone has access
– Start first challenge on Unix security
4
Operating Systems
• Multi-user operating systems
• Operating system functionality – Process management
– (virtual) memory management
– File system management
– I/O management
• Structure– Operating system kernel
– User-space programs (daemons, applications, shell)
5
Operating Systems
• Why do we care about operating system (OS) security:– Protect different applications that run at the same time
– Applications may belong to different users, have different privileges
– Keep buggy/malicious apps.• From crashing each other
• From tampering with each other
• From crashing the OS
• OS provides security services– Isolation (between processes)
– Access control (regulates who can access which resources)
XKCD #1200
• Even if nowadays...
Operating Systems
• Kernel– Provides an hardware abstraction layer for user-space programs– Complete access to all (physical) resources– Trusted computing base
• Dual mode operation– Hardware (processor) support– When in kernel-mode, restricted access
– Typically, mode of operation is indicated by processor status bit– Of course, this bit can only be directly manipulated in kernel
mode
Operating Systems
• Transition between different modes– This crosses the border between two security domains– Clearly, a security relevant action
• System calls– Performs a transition from user mode to privileged (kernel) mode
• Processor interrupt (int 0x80)
• X86 call gates (far call)
• Fast system call features (sysenter)– Ensure that only specific kernel code can be invoked
• Why not allow arbitrary calls into kernel code?
Kernel control flows
• System calls – Need to check arguments for correctness– Sometimes involves copying data from user program to kernel – Opens up the problem of race condition bugs
• Long list of exploits (will see next week)
• Hardware Interrupts / Exception– Transition from user to kernel mode– In response to program misbehavior
• Illegal memory access, illegal instruction, etc.
• Kernel → User– For starting process (allocate memory, load code + data from file)– Load registers, clear privilege bits, return to code
• Hypervisors calls ‘hypercalls’ and traps on some events
Operating Systems Memory
• Memory protection– Through virtual memory abstraction
– Every process gets its own virtual memory space– No direct access to physical memory
– Page tables and memory MMU perform translation
• Programs are isolated and cannot directly talk to each other
• Inter-process communication– In some cases, shared memory can be requested
– Pipes, messages (packets) → input validation necessary– File system (which is shared state) → race conditions
Operating Systems
• Access control– Determine the actions that a process (subject) may perform on
resources (objects)– Requires to establish “identity” of subjects
– Implemented as Access Control Lists (ACL) on objects; or capabilities carried by subjects
• Establishing identity– Process of authentication
– Via something that one has, that one knows, or that one is (does)– Should be protected by a trusted path
Operating Systems
• Discretionary access control– Common model for contemporary operating systems – Subject (owner) can change permission of objects– (e.g., unix permissions)
• Mandatory access control– Less common, but gains popularity– Enforced by the OS when subject cannot change permissions of
objects– Often associated with multi-level security (MLS) systems and Bell-
LaPadula model • Modern version see ANSSI Clip OS (2 levels of security)
User authentication
• Authentication the “Theory”– What you have
• Tokens, smartcard, private key
– What you know • passwords
– Who you are• Fingerprint...
• Passwords still the best way to authenticate on a system
• Other mechanisms becoming more popular– Fingerprint readers– Two Factor authentication
14
Passwords
• But retina checks are not deployed everywhere, so guard your password ;-)– NEVER give your password to anyone– Make your password something you can remember – Make your password difficult for others to guess
• Easy to break passwords:– Words in any dictionary, Your user name, Your name,
Names of people you know, substituting some characters (a 0 (zero) for an o, or a 1 for an l), words from book or movies, sequences of keys on a keyboard (QWERTY), all the previous + some numbers (aurel223)
– http://www.openwall.com/john/ (John the ripper, password cracker)
15
Breaking Passwords 101
• Password should never, ever, be stored in clear
• Hash passwords: – easy to check the password– hard to recover it (hard to revert the hash)
• Brute force passwords attacks– Online: Try all possible passwords to login – Offline: hash all possible passwords and compare it to stored hash
• Better Password cracking– dictionary attacks, rainbow tables
– Tools exist: Crack, JohnTheRipper
• Defending against brute force– Slow algorithm (e.g. apply modified DES multiple times)
– Salt (concatenated with the password)• Random but not secret (stored with the hash)
• Prevent same passwords to map onto same string
• Makes dictionary attacks more difficult (increases the password space)
Choosing a good password
• Guidelines…– at least 8 characters long – mix of lower- and upper-case characters, numbers, and
punctuation marks– take a phrase and try to squeeze it into eight characters
(e.g., this is an interesting lecture == tiail), Throw in a capital letter and a punctuation mark or a number or two (== 0Tiail4)
– Something that no one but you would ever think of. The best password is one that is totally random to anyone else except you. It is difficult to tell you how to come up with these, but people are able to do it. Use your imagination!
17
Password Examples
• The “Bad”– acmilan1– mymusic2– bermuda6– konrad4868
• The “Good”– #bdiBuM1a
– Qa56Fge(/
– sdFOiKqw”=
18
Password managers
• Create random passwords for each use (website)• Encrypt the password database with a passphrase • Can be performed with a file in gnupg or with
integrated tools • Some are cross platform (phone+laptop
synchronized)
• Helps to avoid sharing passwords across services:– Many leaks recently
Rainbow Tables
• Make brute force attacks feasible– Compute each hash every time
• Problem – too slow !
– Ideally – store complete mapping between passwords and hashes• Problem – too much space needed !
– Rainbow tables provide space/time trade-off• Slower than lookup table but considerably smaller to store
– Based on the idea of hash chains
• Hash chain– Introduce reduction function r that maps hash to (some) password– And we only store the start and the end (PWD1 and Hashes3) – Applying r and h to a hash leads to the end of a chain– Looking up the head and apply again
Rainbow Tables
• Hash chains– Problem can have many collision that remain unnoticed
• Typically, two passwords maps to same hash• Happens very frequently
– Solution – rainbow tables
• Rainbow tables– Use different reduction functions for each of the k steps– Requires to follow multiple (k) chains for cracking
Rainbow Tables: construction
Rainbow Tables: construction
Rainbow Tables: construction
Rainbow Tables: construction
Rainbow Tables: storage
Rainbow Tables: Lookup
Is the hash “h” I'm looking for at the end of a chain?- Yes: recompute the chain from start, find the predecessor. Done- No: h'= H(R(h)), restart with h'
Unix Security Unix Security ArchitectureArchitecture
Unix / Linux
• Started in 1969 at AT & T / Bell Labs
• Split into a number of popular branches – BSD, Solaris, HP-UX, AIX
• Inspired a number of Unix-like systems– Linux, Minix, MacOS
• Standardization attempts – POSIX, Single Unix Specification (SUS), Filesystem Hierarchy
Standard (FHS), Linux Standard Base (LSB), ELF
UNIX
• Code running in user mode is always linked to a certain identity– Security checks and access control decisions are based on the user
identity
• User– Identified by user name (UID), group name (GID)
– typically authenticated by password (stored encrypted)
• User root– Superuser, system administrator
– Special privileges (access resources, modify OS)– Cannot decrypt user passwords
Process Management
• Process– implements user-activity
– entity that executes a given piece of code– has its own execution stack, memory pages, and
file descriptors table– separated from other processes using the virtual memory– abstraction
• Thread– separate stack and program counter– share memory pages and file descriptor table
Process Management
• Process Attributes– process ID (PID)
• Uniquely identified process
– lots of management information • Scheduling
• Memory management, resource management
• Process user ID – (real) user ID (UID)
• ID of owner of process
– effective user ID (EUID)• ID used for permission checks (e.g., to access resources)
– saved user ID (SUID)• To temporarily drop and restore privileges
• Same for group IDs
User IDs and Dropping Privileges
• Drop privilege temporarily:– removes the privileged user ID from its effective uid
– stores it in its saved uid
• Restore privileges:– restoring the privileged user ID in its effective uid
• To drop privilege permanently, – Remove the privileged user ID from all three (UID, EUID,
SUID) – After that the process can not restore privileges
For more details see : http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
Process Management
• Switching between Ids– Uid-setting system calls
• Int setuid(uid_t uid)• Int setresuid(Uid_t ruid, uid_t euid, uid_t suid)
• Can be tricky– POSIX 1003.1:
• If the process has appropriate privileges, the setuid(newuid) function sets the real user ID, and the [saved user ID] to newuid.
– What are appropriate privileges?• Solaris EUID = 0; FreeBSD: newuid = EUID; Linux: SETUID
capability
• Refer to man pages (e.g., $man setuid)For more details see : http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
Capabilities
• Apart from user IDs privileges can be linked to capabilities
• We just saw CAP_SETUID there are a lot more– CAP_SYS_ADMIN– CAP_SYS_CHROOT– CAP_SYS_PTRACE– CAP_SYS_TIME– …
• See man capabilities
User Authentication
• Shadow passwords in /etc/shadow– password file is needed by many applications to map user ID to user names
– encrypted passwords are not
• Hashed passwords (Originally)– user passwords are used as keys for crypt() function– runs DES algorithm 25 times on a block of zeros
– 12-bit “salt”• 4096 variations
• chosen from date, not secret (but should be random)
• prevent same passwords to map onto same string
• make dictionary attacks more difficult
• Also account information– Last change date
– Expiration (warning, disabled)
– Minimum change frequency
– Readable only by superuser and privileged programs
User Authentication
• Shadow passwords Today– Many algorithms, e.g., SHA-256 – Up to 16 Bytes of salt
• Other authentication means possible– Linux PAM (pluggable authentication modules)– Kerberos– Active directory (Windows)
• see also http://www.openwall.com/presentations/PHDays2012-Password-Security/
Group Model
• Users belong to one or more groups– Primary group (stored in /etc/password)– Additional groups (stored in /etc/group)
– Possibility to set group password– And become group member wit newgrp
• /etc/group– groupname : password : group id : additional users
– root:x:0:root
– bin:x:1:root,bin,daemon
– users:x:100:andrew
• Special group wheel– Protect root account by limiting user accounts that can perform su
File System
• File tree– Primary repository of information
– Hierarchical set of directories– Directories contain file system objects (FSO)– root is denoted “/”
• File system object– Files, directories, symbolic links, sockets, device files– Referenced by inode (index node)
File System
• Access Control– Permission bits
– Chmod, chown, chgrp, umask– File listing:
• - (file type)
• rwx (user)
• rwx (group)
• rwx (other)
– Special mode for executables x can be replaced by s• Setuid setgid bit
SetUID Programs
• Each process has real and effective user/group ID– Effective ID can be set to the executable
– setuid/setgid bits• To start process with effective ID different from real ID
• Attractive target for attacker– Privilege escalation
• Never use SUID shell scripts (multiplying problems)– Impossible under Linux
Shell
• Shell– One of the core Unix application– Both a command language and programming language– Provides an interface to the Unix operating system– Rich features such as control-flow primitives, parameter
passing, variables and string substitution – Communication between shell and spawned programs via
redirection and pipes
– Different flavors• Bash and sh, tcsh and csh, ksh, zsh
Shell Attacks
• Environment Variables
– $HOME and $PATH can modify behavior of programs that operate with relative path names
– $IFS – internal field separator• Usually set to [\t\n] can be changed to “/”
• “/bin/ls“ is parsed as “bin ls” calling bin locally
• Used to parse tokens
• IFS now only used to split expanded variables
– Example : preserve attack (/usr/lib/preserve is SUID)
• called “/bin/mail“ when vi crashes to preserve file
• change IFS, create bin as link to /bin/sh, kill vi
Shell Attacks
• Control and escape characters– Can be injected into command string – Modify or extend shell behavior– User input used for shell commands has to be rigorously sanitized– easy to make mistakes– classic examples are `;’ and `&’
• Applications that are invoked via shell can be targets as well– Increased vulnerability surface
• Restricted shell– Invoked with -r – More controlled environment
Shell Attacks
• System (char *cmd)– Function called by programs to execute other commands
– Invoke shell– Executes string argument by calling /bin/sh -c string– Makes binary program vulnerable to shell attacks– Especially when user input is utilized.
• Popen(char *cmd, char *type)– Forks a process, opens a pipe and invokes shell for cmd
File Descriptor Attacks
• SUID program opens file
• Forks external process– Sometimes under user control
• On-execute flag– If close-on-exec flag is not set, then new process inherits file
descriptor– Launching a program works exactly like this– Attacker can often exploit such weakness
Resource Limits
• File system limits– Quotas– Restrict number of storage blocks and number of i-nodes– Hard limit
• Can never be exceeded (operations fails)– soft limit
• Can be exceeded temporarily– Can be defined per mount-point– Defend against resource exhaustion (denial of service)
• Process resource limits– Number of child processes, open file descriptors
• Cgroup – Limits resources by a group of processes
Signals
• Signal– Simple form of interrupt– Asynchronous notification– Can happen anywhere for process in user space– Used to deliver segmentation faults, reload commands– Kill command
• Signal handling– Process can install signal handlers– When no handler is present, default behavior is used
• Ignore or kill process– Possible to catch all signals except SIGKILL (-9)
Signals
• Security issues– Code has to be re-entrant
• Atomic modifications
• No global data structures– Race conditions– Unsafe library calls, system calls– Examples
• Wu-ftpd 2001, sendmail 2001 + 2006
• Secure Signals– Write handler as simple as possible– Block signals in handler
Shared Libraries
• Library– Collection of object files
– Included into (linked) program as needed
– Code reuse
• Shared library– Multiple processes share a single library copy– Save disk space (program size is reduced)– Save memory space (only a single copy in memory)– Used by virtually all Unix applications (at least libc.so)– Check binaries with ldd
• Don't use LDD on untrusted programs ! http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
Shared library
• Static shared library– Address binding at link-time– Not very flexible when library changes– Code is fast
• Dynamic shared library– Address binding at load-time
– Uses procedure linkage table (PLT) and global offset table (GOT)– Code is slower (indirection)
– Loading is slow (binding has to be done at run-time)– Classic .so or .dll libraries
• PLT and GOT entries are very popular attack targets– More when discussing buffer overflows
Shared Libraries
• Management– Stored in special directories (listed in /etc/ld.so.conf)
– Manage cache with ldconfig
• Preload– Substitute a library with another– Use /etc/ld.so.preload – or LD_PRELOAD environment variable– Possible security hazard– Now disabled for SUID programs (old Solaris vulnerability)
Address space
See for example: http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory
Advanced Security
• Address space protection– Address space layout randomization (ASLR)– Non-executable stack (based in NX bit or PAX patch)
• Mandatory access control extensions– SELinux
– Role-based access control extensions– Capability support
• Miscellaneous improvements– Hardened chroot jails
– Better auditing
Windows Security Windows Security ArchitectureArchitecture
Windows History
• > 90% of all computers run Windows– When dealing with security issues, it is important to have
(some) knowledge of Windows
– Good example of non-open source system and security issues
• Started in 1985– Graphical add-on to MS DOS
• Two main families– Building on DOS legacy
• Windows 3.11, Windows 95, Windows ME
– NT line (true 32-bit, multi-user OS)• Started with NT 3.1 NT 4.0, Windows 2K, XP, Vista, etc
Windows 3.11 – Windows ME
• Conceived as a single user OS• Basically no security
– Protected mode introduced with Windows 95– Full access to registry and file system objects– Authentication process just to select profiles
• Profiles– Desktop preferences– Access to saved password (stored in a .pwl file)– User password unlocks password list file
Windows 3.11 – Windows ME
• Password list files– Windows 95 (very easy to break algorithm)
– Windows 98 (better protection) – but files are world readable– Guessing attacks possible (also, password are converted
into uppercase)
• Many vulnerabilities found
Windows NT
• Competitor to UNIX– True multi-user.
– Emphasis on portability and object-oriented design.– Isolation for applications and resources access control.– Similar to Unix, Kernel and user mode.
Versions
Windows NT
• Security Components
– Security Reference Monitor (SRM)
• Kernel process
• Performs access control decisions
• Generates security context
– Local Security Authentication (LSA)
• User process
• Manages security policies (permission settings)
• User authentication
– Windows Logon
• User process
• Gather login information
Access Control Decision
• Object– Windows is object-oriented, everything is an object– Each object has security settings (security descriptor)
• Subject– threads/processes– Have a security context
• Operation– Determines desired access (read, write, delete...)
• Access Control Decision– Determines whether object permits certain operations for security context– Implemented by SRM functionality (SeAccessCheck)– If access is permitted, typically an object handle is returned.
Security Context
• Security Context– Stored in (access) token– Associated with every thread/process
• Access token– Kernel data structure that determines rights of a subject
– Important fields
• User SID
• Group SIDs
• Privileges
• Default permissions (used for files that are created)
• Management information
Security Identifiers (SID)
• Security Identifiers– Used to uniquely identify entities (users, groups...)– Immutable– Similar concept to UID/GID in Unix, but unified– Variable length, numeric values
• Structure– SID structure revision number – 48-bit authority value –variable number
of 32-bit sub-authority– Administrator has S-1-5-21-XXX-XXX-XXX-500
• Administrator– Account similar to the root in Unix
Access Token
• It is created at the authentication time
• It defines the security context of the application
• Winlogon assigns the token to the user
• By default every application inherits the token of the application that creates it.
Security Descriptors
• Security descriptor– Security information associated with objects– Important fields
• Owner SID
• Primary group SID (only used by POSIX)
• Discretionary Access Control List (DACL) – relevant for access control
• System Access Control List (SACL) - relevant for logging
• Access Control List– header + list of access control entries (ACE)
Security Descriptors
• Access control entry (ACE)– Contains a SID (e.g., for user aurel)– Corresponding operations (e.g. write, read)– Type (that specifies either allow or deny)
• Access assignment– Complex set of rules:
• Either directly set
• Or determined via “inheritance” – e.g., from the current directory
• or default taken from access token
Security Descriptors
• Access decision– Traverse the DACL until
• Either all requested permissions are granted , or a requested permission is denied
• this implies that the order of the ACE might matter!
• typically, deny entries appear first.
• Owner of resource always gets right to modify the DACL
• In principle, concepts are more powerful that Unix – Permissions for many groups can be defined
– Fine-grain control via allow and deny rules possible
Privileges
• Recall that access token also stores privileges
• Privileges– Not all (security-relevant) operations are associated with
objects examples: shut down computer, set system time, ..– Other privileges might disable or bypass access control checks
examples: backup files, debug processes,....
• Super privileges– Some privileges are so powerful that they basically grant full
access “Act as part of the OS,” “Debug Program,” “Restore files” ...
Mimikatz
• Recover plaintext passwords from Lsass• Usually requires a compromised windows machine
where another user is (administrator) is logged in– Abuses Kerberos ticket management in windows domains – Pass the Hash technique (PtH)– Allows to login on another machine
• Generate golden tickets– Needs to compromise an administrator account – Allows to impersonate anyone – 10 years validity, hard to clean
Authentication
• Stores hashed passwords– Similar to /etc/passwd (and /etc/shadow)
• Two formats– LM (LAN Manager) hash (deprecated)– NTLM
• LM hash– Uses DES to encrypt static string– However, a few flaws
• No salt
• Splits 14 characters into 2 blocks of 7 characters (hashed separately) all characters converted to uppercase (further reduces key space)
Authentication
• LM hash– Can be cracked trivially (ophcrack)
– Disabled by default since Vista (or when password > 14 characters)
• NTLM– Better security (MD5)– Still no salt, thus effective rainbow table attacks possible.
Advanced Security Features
• Generic exploit mitigation– Address space layout randomization– Data execution prevention (DEP)– Secure heap manager– Safe she (structured exception handling)
• Kernel integrity– Code integrity and driver signing
• System integrity and user-mode defenses– UAC – User account control– MIC – Mandatory integrity control– Windows Defender, updates, firewall
System Integrity
• Mandatory integrity control (≥Vista)– Picks up on the idea of mandatory access control
– Assigns one of four integrity levels to processes– Restricts interaction between processes of different levels– Internet Explorer in protected mode
•
System Integrity
• Windows Defender– Integrated anti-malware program
• Windows firewall– checks outbound connections (compromise detection).
• Microsoft Security Development Lifecycle – Started in 2002, as Trustworthy Computing – Microsoft-wide initiative to improve software quality– Code audits, static analysis, fuzz testing etc.
• Kernel code signatures, modification detection
Kernel integrity
• DSE Driver Signing Enforcement– prevents non signed kernel modules to load
• Many software/malware patch DSE to deactivate it– Win7 simple bool value– 8.1 similar but patchguard ...
• Patchguard:– Windows kernel self cheking – Regular (every +/- 10 min)
– Chicken and egg problem, but can be made hard enough to bypass
– Possible to patch it in 8.1– Hard in 10 (no public bypass)
Virtualization
• Virtualization– Has become increasingly popular– Adds an additional layer under the operating system– Allows to run multiple guest operating systems in user mode– Popular solution are Vmware and Xen
– VM-based rootkits (SubVirt or Blue Pill)
• X86 virtualization problems– Platform contains privileged instructions that do not trap– Simply different behavior between user and kernel mode– Interpret each instruction (very slow)– Restrict / adapt operating system (Xen uses this approach)– Dynamic recompilation
Conclusion
• We have covered most important security relevant features of Unices and Windows– Privilege separation– Some practical considerations
• Next week Lab session for setting up the challenges servers and first challenges
81