CSE484/CSE584 SECURE DESIGN PRINCIPLES, OS, AND RUNTIME SECURITY - PowerPoint PPT Presentation

CSE484/CSE584 SECURE DESIGN PRINCIPLES, OS, AND RUNTIME SECURITY Dr. Benjamin Livshits

Some of f the Common Principles Minimize attack Secure by surface area Default Principle of Fail-Safe Least Stance Privilege Secure the Defense-in- Weakest Depth Link

Minimize Attack Surface 3

Minimize the Attack Surface  Expose only limited, well documented interfaces from your application  Turn everything else off

ILOVEYOU Worm 5  Use only the services that your application requires  The Slammer and CodeRed viruses would not have happened if certain features were not on by default  ILoveYou (and other viruses) would not have happened if scripting was disabled  "LOVE-LETTER-FOR- YOU.txt.vbs“ email attachment  The latter file extension (in this case, 'VBS' - a type of interpreted file) was most often hidden by default on Windows computers of the time, leading unwitting users to think it was a normal text file. Opening the attachment activated the Visual Basic script

Least Privilege 6

Principle of Least Privilege  Just enough  Highly elevated authority to get the privileges job done unnecessary  Ex: valet key shouldn’t open glove  Real world compartment example: Valet Keys:  Web server Ex: can valets can only start read, not modify, car and drive to html file parking lot  Attacker gets more power, system more vulnerable

Example: qmail Th The e qm qmai ail se securit ity guar uarantee  Compartmentalize  In March 1997, I offered $500  Nine separate modules to the first person to publish a verifiable security hole in the  If one module latest version of qmail  For example, a way for a user compromised, others not to exploit qmail to take over  Move separate functions another account.  My offer still stands. into mutually untrusting  Nobody has found any programs security holes in qmail.  Always validate input http://cr.yp.to/qmail/guarantee.html from other modules

Structure of qmail qmail-smtpd qmail-inject qmail-queue Other incoming mail Incoming SMTP mail qmail-send qmail-rspawn qmail-lspawn qmail-remote qmail-local

Contrast with sendmail 10 10

Web Server Example  If the server is run under root account, clients could access all files on system!  serveFile () method creates FileReader object for arbitrary pathname provided by user  GET ../../../../etc/shadow HTTP/1.0  Traverses up to root, / etc/shadow on UNIX contains list of usernames & encrypted passwords!  Attacker can use this to launch a dictionary attack  Need to canonicalize and validate pathname  Obey Least Privilege: Don’t run server under root!

Apache 12 12

Or www-data 13 13 Why multiple processes?

Defense-in in-Depth 14 14

Defense-in in-Depth in Roman Times 15 15  In the 3rd and early 4th centuries, the Imperial Roman army's defense strategy mutated from "forward defense" (or "preclusive defense") during the Principate era (30 BC-AD 284) to "defense-in-depth" in the 4th century  "Forward-" or "preclusive" defense aimed to neutralize external threats be before they breached the Roman borders  The barbarian regions neighboring the borders were envisaged as the theatres of operations.  In contrast, "defense-in-depth" would not attempt to prevent incursions into Roman territory, but aimed to neu eutr tralize them on Rom oman soil oil

Prevent, Detect, Contain, and Recover  Should have mechanisms for  preventin ing attacks  detectin ing breaches  contain inin ing attacks in progress, and  recoverin ing from them  Detection particularly important for network Most of our focus thus far security since it may not be clear when an attack is occurring

Failed Login Attempts with aureport 17 17 http://www.golinuxhub.com/2014/05/how-to-track-all-successful-and-failed.html

Auditing Account Activity 18 18

Ongoing Attack: Shellshock 19 19 http://www.dunbarcybersecurity.com/blog/what-does-a-shellshock-attack-look-like-to-your-website

Ongoing Attack 20 20 http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html

Monitor Attack Attempts 21 21

Large-Scale Monitoring 22 22

Don’t Forget Containment  Preventive techniques not perfect; treat malicious traffic as a fact, not exceptional condition  Should have containment procedures planned out in advance to mitigate damage of an attack that escapes preventive measures  Design, practice, and test containment plan  Ex: If a thief removes a painting at a museum, the gallery is locked down to trap him.

Containment 24 24

Removal 25 25

Defense-In-Depth: Password Security Example  Sys admins can require users to choose strong passwords to prevent guessing attacks  To detect, can monitor server logs for large # of failed logins coming from an IP address and mark it as suspicious  Contain by denying logins from suspicious IPs or require additional checks (e.g. cookies)  To recover, monitor accounts that may have been hacked, deny suspicious transactions

Weakest Link 27 27

Securing the Weakest Link  One-third of users choose a password that could be found in the dictionary  Attacker can employ a dictionary attack and will eventually succeed in guessing someone’s password  By using Least Privilege, can at least mitigate damage from compromised accounts

Password Cracking Tool 29 29 Not all passwords can be recovered in a reasonable time using these approaches. If you have difficulties, use the guaranteed password reset function from commercial software.

Social Engineering Attacks  Employees could fall for phishing attacks  (e.g. someone calls them pretending to be the “sys admin” and asks for their password)  Especially a problem for larger companies

Back-Doors 31 31  Malicious developers (aka insider threats )  Can put back doors into their programs  Should employ code review  Or static analysis  Untrustworthy libraries  Is open source better here?

Fail-Safe 32 32

Fail-Safe Stance  Expect & Plan for System Failure  Common world example: Elevators  Designed with expectation of power failure  In power outage, can grab onto cables or guide rails  Ex: If firewall fails, let no traffic in  Deny access by default  Don’t accept all (including malicious), because that gives attacker additional incentive to cause failure

Fail Safely, Not Like This 34 34 isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole ( “Administrator” ); ... } catch (Exception ex) { log.write(ex.toString()); }

Security Through Obscurity 35 35  Security Through Obscurity  Security through obscurity (STO) is the belief that a would be bury ryin ing your money system of any sort can be under a tree. secure so long as nobody outside of its implementation  The on only th thin ing that makes it safe group is allowed to find out anything about its internal is no one knows it's there. mechanisms.  Real security is putting it behind a loc lock or in in a a sa safe.  Hiding account passwords in binary files or scripts with the  You can put t th the sa safe on on th the presumption that "nobody str treet corner because what will ever find it" is a prime makes it secure is that no one case of STO. can get inside it but you.

Key Design Principles  Avoid elevated privileges  Use layered defense (prevention, detection, containment, and recovery)  Secure weakest links  Have fail-safes, i.e. crash gracefully  Don’t enable unnecessary features  Keep design simple, usable  Security features can’t compensate for bugs

Break 37 37

Unix Security 38 38

Access Control in Unix  Process has user id  Inherit from creating process  Process can change id File 1 File 2 …  Restricted set of options User 1 read write -  Special “ root ” id User 2 write write -  Bypass access control restrictions User 3 - - read …  File has access control list (ACL) User m Read write write  Grants permission to user ids  Owner, group, other

Unix File ACLs  Each file has an owner and a gr group setid  Permissions set by owner  Read, write, execute - rwx rwx rwx  Owner, group, other ownr grp othr  Represented by vector of four octal values  Only owner, root can change permissions  This privilege cannot be delegated or shared

Unix File Permissions and Owner 41 41

setuid programming  Be Careful with Setuid 0 !  Root can do anything; don’ t get tricked  Principle of least privilege – change EUID when root privileges no longer needed  "sudo" (super user does operations) is used widely  This is a key limitation of the model main limitation  Too tempting to use root privileges  No way to assume some root privileges without all root privileges

Java Security Basics 43 43 (based on slides from John Mitchell)