Security vulnerabilities for grown-ups Vitaly Osipov Atlassian - - PowerPoint PPT Presentation

security vulnerabilities for grown ups
SMART_READER_LITE
LIVE PREVIEW

Security vulnerabilities for grown-ups Vitaly Osipov Atlassian - - PowerPoint PPT Presentation

Security vulnerabilities for grown-ups Vitaly Osipov Atlassian Tuesday, 22 May 1 Or: 7 product security lessons I learned @Atlassian Tuesday, 22 May 2 Disclaimer All good parts of this talk Are learned from my colleagues Any errors Are


slide-1
SLIDE 1

Security vulnerabilities for grown-ups

Vitaly Osipov Atlassian

1 Tuesday, 22 May

slide-2
SLIDE 2

Or: 7 product security lessons I learned @Atlassian

2 Tuesday, 22 May

slide-3
SLIDE 3

Disclaimer

All good parts of this talk Are learned from my colleagues Any errors Are all mine

3 Tuesday, 22 May

slide-4
SLIDE 4

Lesson 1 Sea of vulnerabilities

4 Tuesday, 22 May

slide-5
SLIDE 5

Security vulnerability?

Not a security feature - e.g. login Security of other features Bug in your code that can lead to unauthorised view / change of information downtime

5 Tuesday, 22 May

slide-6
SLIDE 6

Typical product

Web(-ish) applications >100 kloc Dozen third party libraries A couple of Web frameworks Enterprise customers

6 Tuesday, 22 May

slide-7
SLIDE 7

If you’re a mid-size software vendor You will learn your code has vulnerabilities This year... More than once… Remember, only 50% products can be “above average” The current industry average is far from good

Learned:

7 Tuesday, 22 May

slide-8
SLIDE 8

Levels of “oops”

You find the vulnerability yourself Customer reports their findings “Security researcher” contacts you You are compromised Customer is compromised

8 Tuesday, 22 May

slide-9
SLIDE 9

Clouds and silver lining

Someone gives a damn, hurray! A culture shift - “loss of innocence” Growing up Stages of grief

9 Tuesday, 22 May

slide-10
SLIDE 10

5 stages of grief

Denial: “This cannot be happening” Anger: “Why me? It is not fair!” Bargaining: “Perhaps it is not as bad as it seems?” Depression: “Man, nobody will ever buy from us again!” Acceptance: “We can fix this!”

10 Tuesday, 22 May

slide-11
SLIDE 11

Lesson 2 Small bugs, big incidents

11 Tuesday, 22 May

slide-12
SLIDE 12

Debian OpenSSL

12 Tuesday, 22 May

slide-13
SLIDE 13

Apache / JIRA 2010

“ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX” Change attachment path Install JSP shell and password interceptor... https://blogs.apache.org/infra/entry/ apache_org_04_09_2010

13 Tuesday, 22 May

slide-14
SLIDE 14

Learned:

Often one vulnerability is all it takes Several “non-critcial” issues combine into one big trouble

14 Tuesday, 22 May

slide-15
SLIDE 15

Lesson 3 But this is not my code!

15 Tuesday, 22 May

slide-16
SLIDE 16

Is this sufficient?

16 Tuesday, 22 May

slide-17
SLIDE 17

XML Bomb

Known since 2002, yet you probably have this 10^9 lols

17 Tuesday, 22 May

slide-18
SLIDE 18

XXE Local Entities

18 Tuesday, 22 May

slide-19
SLIDE 19

XXE

Other recent examples: https://issues.jboss.org/browse/RESTEASY-637

19 Tuesday, 22 May

slide-20
SLIDE 20

Aside: where to start with XXE in Java

DocumentBuilderFactory SAXParserFactory XMLInputFactory nu.xom.Builder SAXBuilder

20 Tuesday, 22 May

slide-21
SLIDE 21

OGNL - Struts

See Struts advisories

21 Tuesday, 22 May

slide-22
SLIDE 22

More OGNL

22 Tuesday, 22 May

slide-23
SLIDE 23

Ruby

/triggerpath?search[instance_eval]=%60touch %20%2ftmp%2fcommand_exec%60 touch /tmp/command_exec “Ruby on Rails from a code auditor's perspective”, Hackito Ergo Sum 2011 by @joernchen

23 Tuesday, 22 May

slide-24
SLIDE 24

...On Rails

Mass assignment is a feature http://edgeguides.rubyonrails.org/security.html

24 Tuesday, 22 May

slide-25
SLIDE 25

Learned

Past decisions will bite you ...and decisions of other people will bite you too When you least expect it

25 Tuesday, 22 May

slide-26
SLIDE 26

Lesson 4 Why all this matters

26 Tuesday, 22 May

slide-27
SLIDE 27

Here to stay

27 Tuesday, 22 May

slide-28
SLIDE 28

Do you like…

Coding features? Fixing bugs? ...bugs that are not triggered by normal use? ...rare bugs reported by people who are intentionally using your software not to the specs? Also known as security vulnerabilities

28 Tuesday, 22 May

slide-29
SLIDE 29

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” Brian Kernigan

Security is difficult

29 Tuesday, 22 May

slide-30
SLIDE 30

“Please make it go away and let me create exciting new features for my customers!” (not an actual quote)

Normal dev reaction

30 Tuesday, 22 May

slide-31
SLIDE 31

Learned:

Security is counterintuitive Most companies do not think security (or, say, architecture) until a while into the project “Fixing” security becomes much harder as the product grows

31 Tuesday, 22 May

slide-32
SLIDE 32

Lesson 5 What can we do?

32 Tuesday, 22 May

slide-33
SLIDE 33

Three things

1.Product security response 2.Priority fixing 3.“Prevention”

33 Tuesday, 22 May

slide-34
SLIDE 34

Lesson 6 Response and Validation

34 Tuesday, 22 May

slide-35
SLIDE 35
  • 1. Response

a.k.a. PSIRT Small effort that goes a long way Sanity in a crisis security@yourdomain.com

35 Tuesday, 22 May

slide-36
SLIDE 36

Learned:

Research is exciting for developers Fixing is less so Especially when patches are involved And you do not do patches as a rule

36 Tuesday, 22 May

slide-37
SLIDE 37

Learned:

Advisory / security alert? External dependencies Products Services Infrastructure Checking, double-checking, triple-checking

37 Tuesday, 22 May

slide-38
SLIDE 38

Lesson 7 Fixing

38 Tuesday, 22 May

slide-39
SLIDE 39
  • 2. Fixing

39 Tuesday, 22 May

slide-40
SLIDE 40

Learned:

Find vuln reports proactively Fix fast and keep the reporter in the loop Even if the issue does not look serious “Where else does this appear?” Be very nice “Responsible disclosure” debate

40 Tuesday, 22 May

slide-41
SLIDE 41
  • 3. “Preventing”

Difficult and endless battle Especially in Agile shops Microsoft has some papers about Agile SDL Ask me next year

41 Tuesday, 22 May

slide-42
SLIDE 42

Ideas

Use framework features if you can (auto-encoding for XSS) Stripped-down Java Security Manager (code execution, file reads) Reduce complexity of inputs (no OGNL!)

42 Tuesday, 22 May

slide-43
SLIDE 43

Ideas

Train QA in security Training a security pro in QA is harder Developers will learn from them Depends on how QA/Dev is set up “Blind spots” - missing classes of vulnerabilities

43 Tuesday, 22 May

slide-44
SLIDE 44

Ideas

Testing tools Burp Suite Only a help, not a magic scanner Many false positives and false negatives from all automated scanners - source code or web

44 Tuesday, 22 May

slide-45
SLIDE 45

Watch out

“Each of these endeavours resulted in a significant and brief improvement, which was quickly overcome by the entropy of unstructured coding.” Somewhere in PragProg mag

45 Tuesday, 22 May

slide-46
SLIDE 46

Do I have to?

Response and fixing are the basics Bad PR and stolen data are worse than any short term savings Emergency fixing is very expensive “Past results do not guarantee future success”

46 Tuesday, 22 May

slide-47
SLIDE 47

But it cannot happen to me!

47 Tuesday, 22 May

slide-48
SLIDE 48

TODO

Make someone accountable for response Set up and monitor security@ Train QA in security Prioritise fixing security issues Think about prevention / risk management...

48 Tuesday, 22 May

slide-49
SLIDE 49

http://www.atlassian.com/security @agelastic security@atlassian.com

49 Tuesday, 22 May