Build it, Break it, Fix it Break it Today Build It Presentations - - PowerPoint PPT Presentation

▶
build it break it fix it
SMART_READER_LITE
LIVE PREVIEW

Build it, Break it, Fix it Break it Today Build It Presentations - - PowerPoint PPT Presentation

Sep 06, 2022 13 likes •580 views

Build it, Break it, Fix it Break it Today Build It Presentations Theoretical Part: How to Approach Vulnerability Finding Hints for Break It Prof. Eric Bodden Build It, Break It, Fix It SS 17 2 How to Approach Vulnerability

slide-1
SLIDE 1

Break it

Build it, Break it, Fix it

slide-2
SLIDE 2

Today

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

2

Build It Presentations

Theoretical Part: How to Approach Vulnerability Finding

Hints for Break It

slide-3
SLIDE 3

How to Approach Vulnerability Finding

slide-4
SLIDE 4

Concept: Attack Surface

Most exploits enter in through the UI

Often the same interface the users see

Hence: input validation & sanitisation

Attack surface

The number & nature of the inputs for a given system

Can be quantified

Usually compared

Attack surface increases with…

More inputs e.g. new input fields, new features

Larger input space for a given input e.g. allowing a markup language instead of plaintext

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

4

slide-5
SLIDE 5

Vulnerability finding implies code analysis

slide-6
SLIDE 6

Analysing Code

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

6

Functional Analysis

Make sure everything behaves as it should

Security Analysis

Make sure nothing behaves as it should NOT

slide-7
SLIDE 7

goto fail

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

7

exit and report success leap over sslRawVerify: TLS certificate check return “ok”: certificates not checked properly

slide-8
SLIDE 8

What are Security Code Reviews?

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

8

 Code Reviews

Auditing an application’s source code by people other than the author

Goal: to identify faults

 Benefits

Get another perspective Find faults early Transfer knowledge Reduce rework and testing effort

slide-9
SLIDE 9

Testing ≠ Code Review

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

9

Testing Code Review

Fault-finding

Done by other person than developer

(Semi) Automated

Can be done early

Failure-finding

Often done by the original developers

(Fully) Automated

Code must compile

slide-10
SLIDE 10

Code Review - Styles

10

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

Code Analysis Manual Code Reviews Code Analysis with Analysis Tools

slide-11
SLIDE 11

Manual Code Reviews

slide-12
SLIDE 12

Who’s at the Code Review?

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

12

 Author

Can answer any specific questions, or reveal blind spots

 Inspection Leader (Moderator)

Responsible for planning and organizational tasks

Moderates review meeting

Organizes follow-up on issues

 Recorder

Documents faults, actions, decisions made in the meeting

IEEE Standard for Software Reviews and Audits," in IEEE Std 1028-2008 , Aug. 2008.

slide-13
SLIDE 13

Who’s at the Code Review?

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

13

 Reader (not the author)

Leads through the review

 People with readability, but objectivity

e.g. close colleagues, system architect

e.g. developer working on the same project, but different team

People experienced with security, e.g., consultants, experienced developers

IEEE Standard for Software Reviews and Audits," in IEEE Std 1028-2008 , Aug. 2008.

slide-14
SLIDE 14

Code Review Processes

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

14

 Code Review Processes vary widely in their formality  e.g., Inspection – most formal process

Separated roles

Usage of Checklists

Formal collection of metrics defects

 e.g., Walkthrough – less formal process

Author = Moderator, Reader

Driven by author’s goals

Think about what is appropriate for Break It

slide-15
SLIDE 15

Make an Inspection Checklist

 What will you talk about?  Identify relevant aspects  Walk through the functionality of the code

Initially, look for missing code more than wrong code

“If they missed this, then they probably missed that”

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

15

slide-16
SLIDE 16

More for the checklist

 Look for too much complexity, functionality  Look for common defensive coding mistakes  Common Vulnerabilities (depending on application context)

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

16

slide-17
SLIDE 17

Implementation (unsafe)

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

17

private static String auth(String u, String pwd, Connection conn) throws SQLException { ResultSet resultSet; //get results for user input resultSet = conn.createStatement().executeQuery( "SELECT * FROM Users WHERE Username='"+ u +"' AND Password='"+ pwd +"'"); if (resultSet.next()) // any rows? return "Authenticated!!"; else return "Not authenticated!!"; }

slide-18
SLIDE 18

SQL Injection

Example

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

18

“Since the days of Albert Gonzalez, SQL injection attacks have grown dramatically to become the leading attack vector for successful database breaches. According to IBM ISS X-Force research, the number of daily SQL injections jumped by 50 percent from Q4 of 2008 to Q1

  • f 2009, then nearly doubled during Q2 of 2009.”

https://www.minds.com/blog/view/39946/sql-injection-attack

“[Albert] Gonzalez, is alleged to have masterminded an international operation that stole a staggering 130 million credit and debit cards from those companies. […] Gonzalez and his accomplices used SQL injection attacks to break into Heartland's systems and those of the other companies.”

http://www.computerworld.com.au/article/315418/sql_injection_attacks_led _massive_data_breaches/

slide-19
SLIDE 19

Example: Checklist for SQL Injection

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

19

Michael Howard, “A Process for Performing Security Code Reviews.” IEEE Security & Privacy, July 2006. Query use string concat? DB access? Query use string replacement? Fix! Move on SQL, Query, Select, Insert, Password

Yes Yes Yes No No No

slide-20
SLIDE 20

Manual Code Reviews – Key Points

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

 Assign different roles for a review

Moderator, Reader, Recorder…

 Decide for a process and adhere to it  Double-Check your Checklist  Faults (hardly) identifiable via testing, e.g., design flaws

22

slide-21
SLIDE 21

Code Reviews with Analysis Tools

slide-22
SLIDE 22

Dynamic Analysis

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

24

 Analysis of a program during execution  Passive Observing  Active Interaction  Reports only confirmed results  Requires a wide range of inputs to be effective  Cannot cover the whole attack surface  Finds issues in configurations, runtime privileges

slide-23
SLIDE 23

Static Analysis

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

25

Analyzing code without executing it

Able to scan the whole codebase

Requires access to the code

Often many false positives

Provide warnings of common coding mistakes (dead code, hardcoded credentials, null pointer, API misuse…)

Variety of methods

Fancy grep searches

Model checking

Data flow analysis

slide-24
SLIDE 24

Why using Static Analysis Tools?

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

26

Code reviews require expertise in secure programming Humans are fallible and miss faults Manual code reviews are slow Can be part of nightly builds (automated solutions)

slide-25
SLIDE 25

Tools?

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

27

 Free ready-to-apply tools:

FindBugs

SpotBugs

Error Prone by Google

 Commercial “ready”-to-apply tools:

Fortify

Coverity

 Research tool:

CogniCrypt

 Static analysis frameworks:

Soot,

FlowDroid

  • Prof. Bodden’s groups:

Uni Paderborn TU Darmstadt Contact us if you want to try it!

slide-26
SLIDE 26

Static Analysis Internals

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

28

Source Code Build Model Perfom Analysis Results Security Knowledge Master Course: Designing code analyses for large-scale software systems (DECA) Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.

slide-27
SLIDE 27

Build Model

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

29

y=x; if(p) x=y; else z=2; b=y; a=z;

Parse method (as source code or bytecode) and convert into control-flow graph (CFG)

Nodes: Simplified statements

Edges: Possible control flow between such statements

slide-28
SLIDE 28

Perform: Taint Analysis

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

30

Track flow of data from source to sink Source: where data comes into program Sink: function that consumes the data

 Report Vulnerability if

Data comes from an untrusted source

Data consumed by a dangerous sink

No sanitize function between source and sink

slide-29
SLIDE 29

Example: taint analysis for SQL injections

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

31

protected void proc

  • ces

essRe Requ ques est(Htt ttpS pSer ervle letR tReq eques est re requ quest st, Ht HttpS pSer ervl vlet etRes espo pons nse res espo pons nse) thr hrow

  • ws Ser

ervl vletE tExc xcep epti tion, IOE OExce cept ptio ion { try { PrintWriter out = response.getWriter(); (); String studentId = request.getParameter("stu tudId Id"); ); Connection conn = null; try { Class.forName(driver). ).newInstance(); (); conn = DriverManager.getConnection(url + dbName, userName, password); ); Statement st = conn.createStatement(); (); String query = 'SEL ELEC ECT * * F FRO ROM S Stu tude dent nts w whe here re st stud udId Id=' ='' + + stu tuden entI tId + ' + ''' '';

  • ut.println('Qu

Quer ery y : : ' + query); ); ResultSet res = st.executeQuery(query); ); while (res.next()) { String s = res.getString('classes'); );

  • ut.println('\t\t' + s);

); } conn.close(); (); } catch (Exception e) { e.printStackTrace(); (); } } finally {

  • ut.close();

(); } }

Does user input go into SQL query directly?

slide-30
SLIDE 30

Example: taint analysis for SQL injections

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

32

protected void proc

  • ces

essRe Requ ques est(Htt ttpS pSer ervle letR tReq eques est re requ quest st, Ht HttpS pSer ervl vlet etRes espo pons nse res espo pons nse) thr hrow

  • ws Ser

ervl vletE tExc xcep epti tion, IOE OExce cept ptio ion { try { PrintWriter out = response.getWriter(); (); Str trin ing stu tude dentI tId = re reque uest st.ge getP tPar aram amet eter("stu tudId Id"); ); Connection conn = null; try { Class.forName(driver). ).newInstance(); (); conn = DriverManager.getConnection(url + dbName, userName, password); ); Statement st = conn.createStatement(); (); String query = 'SEL ELEC ECT * * F FRO ROM S Stu tude dent nts w whe here re st stud udId Id=' ='' + + stu tuden entI tId + ' + ''' '';

  • ut.println('Qu

Quer ery y : : ' + query); ); ResultSet res = st st.executeQuery(query); ); while (res.next()) { String s = res.getString('classes'); );

  • ut.println('\t\t' + s);

); } conn.close(); (); } catch (Exception e) { e.printStackTrace(); (); } } finally {

  • ut.close();

(); } }

slide-31
SLIDE 31

Example: taint analysis for SQL injections

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

33

Str trin ing stu tude dentI tId = req reque uest st.ge getP tPar aram amet eter("stu tudId Id"); ); Class.forName(driver). ).newInstance(); (); conn = DriverManager.getConnection(url + dbName, userName, password); ); Statement st = conn.createStatement(); (); String query = 'SEL ELEC ECT * * F FRO ROM S Stu tude dent nts w whe here re st stud udId Id='' ='' + + stu tuden entI tId + + ''' '';

  • ut.println('Qu

Quer ery y : : ' + query); ); Res esul ultSe Set re res = st st.ex execu cute teQu Query ry(que uery ry); );

tainted={studentId} tainted={studentId} tainted={studentId} tainted={studentId} tainted={studentId, query} tainted={studentId, query}

slide-32
SLIDE 32

Intra- & Interprocedural Analysis

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

34

main main() () { a = secret(); ); b = id(a); leak(b); ); } id(x) id(x) { y = x; return y; }

SQL Example – Analysis of one function

Intraprocedural Analysis: Analysis of an individual function

Interprocedural Analysis: Follow control and data flow across functions

slide-33
SLIDE 33

Security Knowledge

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

 Security knowledge required for configuring static analysis tools

What are the data sources?

What are the data sinks?

What sources are untrusted?

Which sinks are dangerous?

Which functions sanitize data?

 Interpretation of results wrt. domain

35

slide-34
SLIDE 34

Results

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

36

 False Positives

Static analysis reports faults that don’t exist

Complex control or data flow may confuse analysis

 False Negatives

Static analysis fails to discover faults

Code complexity or missing rules

 Manual review of reported results necessary

Design flaws hard to identify

Security knowledge to rate results

slide-35
SLIDE 35
  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

37

Vulnerabilities to look out for

slide-36
SLIDE 36

Types of Vulnerabilities

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

38

Four types of vulnerabilities:

Correctness

Crash

Integrity

Confidentiality

slide-37
SLIDE 37

Crash: Log overflow

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

39

also known as CWE-400:Uncontrolled Resource Consumption

slide-38
SLIDE 38

Crash: Log overflow

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

40

Question: Why is a log overflow problematic? How can an attacker exploit it?

slide-39
SLIDE 39

Crash: Log overflow – possible mitigation

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

41

Much better!

Rolling log

Max 1 MB

slide-40
SLIDE 40

Crash: Real-world Log overflow

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

42

Beware:

Attackers can exploit rolling logs as well!

Cover their tracks by deliberately causing log overwrite

Mitigation to this problem: limits on number of allowed requests per user, etc.

General point to take away:

Always restrict the resources a user can cause the system to use!

slide-41
SLIDE 41

None of this is proper exception handling

Neither is this by the way:

All four: Insufficient Exception Handling

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

43

slide-42
SLIDE 42

Crash: Null Dereference

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

44

Null dereference immediately results in NullPointerException and therefore crash

Take away: Check code for methods that may return null and whether these are properly guarded

slide-43
SLIDE 43

Confidentiality: Use of a System Output Stream

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

45

Check all calls System.out.* and System.err.* for sensitive information

slide-44
SLIDE 44

Confidentiality: Self-made encryption algorithms

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

48

How long did it take you to reverse this „encryption“ algorithm?

Don‘t implement your own crypto!

Initially distrust StackOverflow & Co!

slide-45
SLIDE 45

Confidentiality: Secure Encryption

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

50

Attacker (with certain capabilities) shall not be able to learn anything from an encrypted message

Chosen Plaintext Attacker (CPA): Attacker can encrypt (polynomically) many messages

Very common capability!

Chosen Ciphertext Attacker (CCA): Attacker can encrypt (polynomically) many messages and decrypt (polynomically) many other messages

Almost always you want CPA security. In many cases you also want CCA security.

slide-46
SLIDE 46

Confidentiality: Secure Encryption

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

51

Are encryption primitives (RSA, AES, …) on their own CPA secure?

They are deterministic.

Additional randomness needs to be put into plaintext.

Modes of operation – allow encryption of plaintexts with arbitrary length using a block encryption primitive

ECB, CBC, CFB, CTR, …

ECB is not CPA secure!

CBC, CFB, CTR are, if random IV and good encryption primitive (e.g. AES)

No!

Original image by Larry Ewing, lewing@isc.tamu.edu, created with The GIMP

slide-47
SLIDE 47

Integrity, Authenticity: Message Authentication Code

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

52

Attacker (with certain capabilities) shall not be able to modify ciphertext in a way the receiver will not notice.

Hash does not ensure authenticity. Only, if a secret is hashed along with the message!

This is called Message Authentication Code (MAC)

CCA secure encryption achieved with CPA secure encryption + MAC over ciphertext

Possible Attacks against integrity and authenticity without MAC

Add content to the beginning, the middle, the end

Reorder Content

Modify content

Delete content

slide-48
SLIDE 48

Confidentiality: Hardcoded Credentials

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

53

Question: Where is the problem?

 Mitigation

Never store clear text passwords anywhere, use hashing

Extract credentials to external file with proper permissions

slide-49
SLIDE 49
  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

54

https://blogs.uni-paderborn.de/sse/2015/05/27/baas/

slide-50
SLIDE 50

Real-world Hardcoded Credentials

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

55

 Beware

Attackers can reverse engineer your code

Obfuscation is not an option (attackers have time and are creative)

Similar for license keys, encryption keys…

Think about what happens when you commit to version control systems…

 Point to take away

You cannot keep secrets in your source code!

slide-51
SLIDE 51

Plain Hashing: Dictionary Attack & Brute Force Attack

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

56

Brute Force Attack: Trying every possible password

Dictionary Attack: Trying a list of common passwords

Plain hashing of secrets is most often just bad!

slide-52
SLIDE 52

Plain Hashing: Rainbow Tables

What if an attacker steals the hashes?

common passwords + common hashing algorithms = common hashes

Thus, attackers have large databases of pre-computed hashes called rainbow tables

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

57

slide-53
SLIDE 53

Solution: Salting

Salting: Random string (=salt) is appended to a password

Each password gets a different salt

Salts should be at least 32 bits

Salts stored in plaintext along with the hashed + salted password

Implementation-wise: Employ key deriviation functions

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

58

slide-54
SLIDE 54

Insecure generation of random numbers in PRNGs

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

59

Security code often uses random numbers. Why?

Randomness used to create a secret value the attacker cannot possibly guess

Examples: IVs, secret keys

There is No real randomness in a normal computer!

We need “good” pseudo-randomness. Good means: practically indistinguishable from real randomness

Shannon Entropy

Calculated over an alphabet of given input

Denotes, how much information a given input actually contains, e.g. per byte

Shannon Entropy != Randomness!

Low Entropy => Low Randomness

High Entropy could still be something being predictable!

Entropy is an upper bound for randomness – “How much information do I need to derive the secret?”

− ෍

𝑗=0 𝑜

𝑞 𝑦𝑗 ⋅ log2 𝑞 𝑦𝑗

slide-55
SLIDE 55

Insecure generation of random numbers in PRNGs

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

60

“Good” pseudo-randomness is hard to achieve

Always use Cryptographically Secure Pseudo Random Number Generators (CSRPNG) e.g. Java.Security.SecureRandom

Don’t come up with your own “clever” idea to generate “random” data

Pseudo Random Function

Create more randomness from (pseudo-)random seed

Deterministic!

With (pseudo-)random input, a “large” amount of output shall be unpredictable (and undistinguishable from real randomness)

slide-56
SLIDE 56

Insecure generation of random numbers in PRNGs

  • Prof. Eric Bodden – Build It, Break It, Fix It SS 17

61

Problem: Insufficient Entropy

Java.util.Random is predictable

… so is rand() of C/C++

Even worse:

Random numbers must be kept secret.

Best practice:

In programming, treat seeds just as secret keys

Ideally: generate and forget

Never store or share seeds!

Regenerate seeds whenever needed