CO CO 447 SECU CURE DE DESIGN PRINCI CIPLES JAVA SECU CURITY - PowerPoint PPT Presentation

CO CO 447 SECU CURE DE DESIGN PRINCI CIPLES JAVA SECU CURITY ROP AND D ADVANCE CED D EX EXPL PLOITS Dr. Ben Livshits

Pa Password reuse 2 https://www.enzoic.com/8-stats-on-password-reuse/

Con Continued… 3

So Some Su Survey Responses 4

Su Survey Responses 5

Su Survey Responses 6

Su Survey Responses 7

Se Secu curity y Con Conce cepts 1. Authentication 2. Authorization 3. Confidentiality 4. Data/message integrity 5. Accountability 6. Availability 7. Non-repudiation

3) 3) Con Confidentiality ¨ Goal: Keep the contents of communication or data on storage secret ¨ Example: Alice and Bob want their communications to be secret from Eve ¨ Key – a secret shared between Alice & Bob ¨ Sometimes accomplished with ¤ Cryptography, Steganography, Access Controls, Database Views

4) M Messa ssage/Data I Integrity ¨ Data Integrity = No Corruption ¨ Man in the middle attack : Has Mallory tampered with the message that Alice sends to Bob? ¨ Integrity Check : Add redundancy to data/messages ¨ Techniques: ¤ Hashing (MD5, SHA-1, …), Checksums (CRC…) ¤ Message Authentication Codes (MACs) ¨ Different From Confidentiality: ¤ A -> B: “The value of x is 1” (not secret) ¤ A -> M -> B: “The value of x is 10000” (BAD) ¤ A -> M -> B: “The value of y is 1” (BAD)

5) A Accountability ¨ Able to determine the attacker or principal ¨ Logging & audit Trails ¨ Requirements: ¤ Secure Timestamping (OS vs. Network) ¤ Data integrity in logs & audit trails, must not be able to change trails, or be able to detect changes to logs ¤ Otherwise attacker can cover their tracks

6) 6) Availability ¨ Uptime, Free Storage ¤ Ex. Dial tone availability, System downtime limit, Web server response time ¨ Solutions: ¤ Add redundancy to remove single point of failure ¤ Impose “limits” that legitimate users can use ¨ Goal of DoS (Denial of Service) attacks are to reduce availability ¤ Malware used to send excessive traffic to victim site ¤ Overwhelmed servers can’t process legitimate traffic

7) 7) Non-Re Repudiation (of Tr Transactions) ¨ Undeniability of a transaction ¤ Alice wants to prove to Trent that she did communicate with Bob ¤ Generate evidence / receipts (digitally signed statements) ¤ Often not implemented in practice, credit-card companies become de facto third-party verifiers ¨ Electronic proof that will have information of the person who made any transaction. ¤ A client goes to a bank and request to change a password for her bank account ¤ the teller or the authoriser will assist the client but will have to login to the system by using biometrics, this is to ensure the identification of who was assisting the client in case anything goes wrong with the client's bank account then the investigation team can track down who was in charge of the client's bank account ¤ the authoriser cannot deny any accusations being pointed to him/her should there be any form of fraud on client's bank account

So Some of the Common Principles Principle of Secure by Least Privilege Default Fail-Safe Defense-in- Stance Depth Secure the Weakest Link

1) 1) Least privilege 15 15

Least Privileg Leas ege e for qm qmai ail 16 16 ¨ In March 1997, I took the unusual step of publicly offering $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account. ¨ My offer still stands. Nobody has found any security holes in qmail. I hereby increase the offer to $1000. ¨ How can we make progress? ¤ Answer 1: eliminating bugs ¤ Answer 2: eliminating code ¤ Answer 3: eliminating trusted code https://www.doc.ic.ac.uk/~livshits/classes/CO445H/reading/qmail.pdf

2) 2) De Defense in depth 17 17

Defense-In-Depth: Password Security Example ¨ Sys admins can require users to choose strong passw swords 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

3) 3) Securing the Weakest Link 19 19

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 mi mitigate damage from compromised accounts

So Social Engineering Attacks 21 21

Password Cracking Tool 22 22 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.

Back-Doors 23 23 ¨ 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?

4) 4) Fail-Sa Safe 24 24

Fail-Safe Stance ¨ Expect & Plan for System Failure ¨ Common world example: lifts in buildings ¤ 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 26 26 isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( “Administrator” ); ... } catch (Exception ex) { log.write(ex.toString()); }

5) Avoid Security through Obscurity 27 27

Security Through Obscurity 28 28 ¨ Security Through Obscurity ¨ Security through obscurity (STO) is the belief that a would be buryi burying ng your ur mone ney y system of any sort can be under a tree. secure so long as nobody outside of its implementation ¨ The on only thing 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 lo lock or in in a safe . ¨ Hiding account passwords in binary files or scripts with the ¨ You can put put the he safe on n the he presumption that "nobody st street 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.

6) Secure by default 29 29

Se Secure by Design 30 30 ¨ The guidelines within the Code of Practice include: ¤ Ensuring that IoT devices do not contain default passwords. ¤ Defining and implementing vulnerability disclosure policy. ¤ Ensuring software for devices is regularly updated.

National C Cyber S Security C Centre 31 31

Ke Key Design Principles and Patterns ¨ Avoid el elevated ed privileg eges es ¨ Use la layered defense (prevention, detection, containment, and recovery) ¨ Secure the we weakest links ¨ Have fa safes , i.e. crash gracefully fail-sa ¨ Don’t trust in Se Secu curity ty th through O Obscu curity ty ¨ Make design that is secure by by default , out of the box, without the need to do anything

Lan Languag ages es an and Vulner erab abilities es 33 33 ¨ Most vulnerabilities are the result of unsafe programming and unsafe programming practices and patterns ¨ Languages can do a lot to improve things ¨ We will look at Java language design ¨ We will look at advanced platform protections and their failings

Lan Languag age e des esign: C++ vs. Java 34 34 ¨ Manual memory ¨ Memory allocation is allocation and largely automatic deallocation ¨ Type safety ¨ Pointer arithmetic and ¨ Checking array bounds casts ¨ Performance suffers ¨ Focus on speed and somewhat hardware control

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

Java Implementation Principles ¨ Compiler and Virtual Machine ¤ Compiler produces bytecode ¤ Virtual machine loads classes on demand, verifies bytecode properties, interprets bytecode ¨ Why this design? ¤ Bytecode interpreter/compilers used before n Pascal “pcode” n Smalltalk compilers use bytecode ¤ Minimize machine-dependent part of implementation n Do optimization on bytecode when possible n Keep bytecode interpreter simple ¤ For Java, this gives portability n Transmit bytecode across network

Java Virtual Machine Architecture Java A.java A.class Compiler Co Compile source code Java Virtual Machine Loade Lo der Network Ne Ve Verifier B.class Li Link nker Bytecode Interpreter By

JVM Memory Areas ¨ Java program has one or more threads ¨ Each thread has its own stack ¨ All threads share same heap native method Java PC heap method area stacks registers stacks

Class Loaders ¨ Runtime system loads ¨ Define alt alternate classes as needed ClassLoader object ¨ When class is ¤ Extend the abstract ClassLoader class and referenced, loader implementation searches for file of ¤ ClassLoader does not compiled bytecode implement abstract instructions method loadClass, but ¨ Default loading has methods that can mechanism can be be used to implement replaced lo loadCla lass ss