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

• n 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

• f 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 Least Privilege Defense-in- Depth Secure the Weakest Link Fail-Safe Stance Secure by Default

1) 1) Least privilege

15 15

Leas Least Privileg ege e for qm qmai ail

¨ 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 16 16

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

¨ 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?

23 23

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

¨ Security Through Obscurity

(STO) is the belief that a system of any sort can be secure so long as nobody

• utside of its implementation

group is allowed to find out anything about its internal mechanisms.

¨ Hiding account passwords in

binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO.

¨ Security through obscurity

would be buryi burying ng your ur mone ney y under a tree.

¨ The on

• nly thing that makes it safe

is no one knows it's there.

¨ Real security is putting it behind

a lo lock or in in a safe.

¨ You can put

put the he safe on n the he st street corner because what makes it secure is that no one can get inside it but you.

28 28

6) Secure by default

29 29

Se Secure by Design

¨ 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.

30 30

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

fail-sa safes, i.e. crash gracefully

¨ Don’t trust in Se

Secu curity ty th through O Obscu curity ty

¨ Make design that is secure by

by default, out

• f 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

¨ Manual memory

allocation and deallocation

¨ Pointer arithmetic and

casts

¨ Focus on speed and

hardware control

¨ Memory allocation is

largely automatic

¨ Type safety ¨ Checking array bounds ¨ Performance suffers

somewhat

34 34

(based on slides from John Mitchell)

Java Security Basics

35 35

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

A.class A.java

Java Compiler

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

Java Virtual Machine Architecture

JVM Memory Areas

¨ Java program has one or more threads ¨ Each thread has its own stack ¨ All threads share same heap

method area heap Java stacks PC registers native method stacks

Class Loaders

¨ Runtime system loads

classes as needed

¨ When class is

referenced, loader searches for file of compiled bytecode instructions

¨ Default loading

mechanism can be replaced

¨ Define alt

alternate ClassLoader object

¤ Extend the abstract

ClassLoader class and implementation

¤ ClassLoader does not

implement abstract method loadClass, but has methods that can be used to implement lo loadCla lass ss

JVM Linker and Verifier

¨ Lin

Linker

¤ Adds compiled class or

interface to runtime system

¤ Creates static fields and

initializes them

¤ Resolves names

¤ Checks symbolic

names and replaces with direct references

¨ Ve

Verifier

¤ Check bytecode of a

class or interface before loaded

¤ Throw VerifyError

exception if error occurs

Verifier Design

¨ Bytecode ma

may no not come from standard compiler

¤ Evil hacker may write dangerous bytecode

¨ Verifier checks co

correctness of bytecode

¤ Every instruction must have a valid operation code ¤ Every branch instruction must branch to the start of some

• ther instruction, not middle of instruction

¤ Every method must have a structurally correct signature ¤ Every instruction obeys the Java type discipline ¤ This is fairly complicated and tricky

Verifier Issues: CVE-2012-1723

42 42 ¨ CVE

CVE-2012 2012-1723: 1723: This is a vulnerability in the HotSpot bytecode verifier that has been present since at least Java 1.4.

¨ Vulnerable version of the HotSpot compiler will perform an in

invalid alid

• p
• ptimization
• n when verifying deferred

GETSTATIC/PUTSTATIC/GETFIELD/PUTFIELD instructions (hereafter referred to as "field access instructions") in preparation of JIT-compiling a method

¨ To exploit this vulnerability, you need to craft a method with at

at least st two di different f field a d access i ins nstruc ructions ns r referri rring ng t to t the he s same f field, and have to force the method to be JITed while their verification is still deferred (i. e. you have to call the method a lot of times but make sure none of these executions touch those instructions, for example by passing a parameter that makes sure the method will end early in those executions). Then call it again for the effect.

¨ http://schierlm.users.sourceforge.net/CVE-2012-1723.html for more

details

Towards Memory Safety

¤ Perform run-time checks

such as ar array bounds

¤ All ca

casts are checked to make sure type safe

¤ All ar

array references are checked to make sure the array index is within the array bounds

¤ References are tested to

make sure they are not nul null before they are dereferenced.

¤ No pointer arithmetic ¤ Automatic garbage

collection

If program accesses memory, that memory is allocated to the program and declared with correct type

Java and Native Interactions

¨ Possible to compile

bytecode class file to native code

¨ JITs are used for

performance

¨ Java programs can call

native methods, typically functions written in C

¨ C# and .NET take C/C++

interop very seriously

44 44

class PlatformInvokeTest { [DllImport("msvcrt.dll")] public static extern int puts(string c); [DllImport("msvcrt.dll")] internal static extern int _flushall(); public static void Main() { puts("Test"); _flushall(); } }

Java Security Mechanisms

¨ Sandboxing

¤ Run program in restricted

environment

¤ Analogy: child’s sandbox with

• nly safe toys

¤ This term refers to features of

loader, verifier, interpreter that restrict program

¨ Code signing

¤ Use cryptography to establish

• rigin of class file

¤ This info can be used by security

manager

¨ Class loader

¤ Separate namespaces for separate class loaders ¤ Associates protection domain with each class

¨ Verifier and JVM run-time tests

¤ NO unchecked casts or other type errors ¤ NO buffer/array overflows ¤ Preserves private, protected visibility levels

¨ Security Manager

¤ Called by library functions to decide if request is

allowed

¤ Uses protection domain associated with code, user

policy

¤ Coming up in a few slides: stack inspection

Security Manager

¨ Java library functions call Security Manager ¨ Security manager object answers at run time

¤ Decide if calling code is allowed to do operation ¤ Examine protection domain of calling class

n Signer: organization that signed code before loading n Location: URL where the Java classes came from

¤ Uses the system policy to decide access permission

Sample Security Manager Methods

checkExec Checks if the system commands can be executed. checkRead Checks if a file can be read from. checkWrite Checks if a file can be written to. checkListen Checks if a certain network port can be listened to for connections. checkConnect Checks if a network connection can be created. checkCreate ClassLoader Check to prevent the installation of additional ClassLoaders.

Stack Inspection

¨ Permission depends on

¤ Permission of calling

method

¤ Permission of all

methods above it on stack

¤ Up to method that is

trusted and asserts this trust

java.io.FileInputStream method f method g method h