( G O T Y O U R NO S E ) ( How Attackers steal your - - PowerPoint PPT Presentation

g o t y o u r no s e
SMART_READER_LITE
LIVE PREVIEW

( G O T Y O U R NO S E ) ( How Attackers steal your - - PowerPoint PPT Presentation

( G O T Y O U R NO S E ) ( How Attackers steal your precious Data without using Scripts ) A Presentation by Mario Heiderich ~ Hack in Paris 2012 ( g o t y o u r no s e ) ( O u r D e a r S p e a k e r) Dr.


slide-1
SLIDE 1

( g

  • t

y

  • u

r no s e )

( G O T Y O U R NO S E )

( How Attackers steal your precious Data without using Scripts)

A Presentation by Mario Heiderich ~ Hack in Paris 2012

slide-2
SLIDE 2

( g

  • t

y

  • u

r no s e )

( O u r D e a r S p e a k e r)

 Dr. Mario Heiderich

 Twitter @0x6D6172696F  Researcher and PhD Student, Ruhr-Uni Bochum

 Thesis on Client Side Security and Defense

 Security Researcher contracting for MS, Redmond  Founder of Cure53 Penetration Test Firm  Published author and international speaker

 Specialized in HTML5 and SVG Security  JavaScript, XSS and Client Side Attacks

 FUD Peddler and Prophet of Doom  HTML5 Security Cheatsheet

slide-3
SLIDE 3

( g

  • t

y

  • u

r no s e )

( B a c k g ro u nd )

slide-4
SLIDE 4

( g

  • t

y

  • u

r no s e )

( C ro s S ) ( S i t e S c ri p t i ng )

 Lots of Talks have been held  Plenty of Research has been done

 Traditional injections  Attacks from outer space  XSS, XAS, XDS, XSSQLI, SWXSS, … you name it!  Defense mechanisms on multiple layers  Network, Server, Client and what not...

 CSP

, NoScript, AntiSamy and HTMLPurifier, Browser XSS Filters

 mod_security, PHPIDS, some nonsense WAF products

 But why use scripting at all?

slide-5
SLIDE 5

( g

  • t

y

  • u

r no s e )

( T

  • p

i c s T O D A Y )

 Scriptless Attacks in your Browser

 Attacks bypassing NoScript  Attacks bypassing Content Security Policy  No Scripting allowed  No Scripting necessary  Attacks working in Thunderbird  Attacks stealing your data without XSS

slide-6
SLIDE 6

( g

  • t

y

  • u

r no s e )

( O f f e ns i v e T a l k )

 We'll mainly see attack vectors today

 Starting simple – using cheap HTTP tricks  Stealing passwords with CSS

 Almost like the Sexy Assassin back in 2009  Just without any bruteforcing

 Playing with a user's perception  Time and Measure, Log and Steal

 Focus is stealing data by using the browser

 Passwords, tokens, sensitive data is general

slide-7
SLIDE 7

( g

  • t

y

  • u

r no s e )

( T h e ) ( M a rk u p B ro t h e rs )

( S V G S a nc h e z ) ( H T M L H a rry ) ( C l i v e S S t y l e s h e e t )

slide-8
SLIDE 8

( g

  • t

y

  • u

r no s e )

( A ri v e r f

  • r

s

  • m e

)

slide-9
SLIDE 9

( g

  • t

y

  • u

r no s e )

( D e f e ns e )

 Defense is possible but tough

 Benign features combined to be attacks  No possibility to easily build signatures  Attacker utilizes solicited content  CSS, SVG images, Links and Images  No scripting allowed!  „Thanks for the injection!“

slide-10
SLIDE 10

( g

  • t

y

  • u

r no s e )

( H a p p y I nj e c t i

  • ns

)

slide-11
SLIDE 11

( g

  • t

y

  • u

r no s e )

( E x p l

  • i

t s )

 Three Chapters to be presented

 Chapter 1: The simple tricks  Chapter 2: Advanced Class  Chapter 3: For Science!

slide-12
SLIDE 12

( g

  • t

y

  • u

r no s e )

( C h a p t e r

  • ne

)

< Those simple Tricks >

slide-13
SLIDE 13

( g

  • t

y

  • u

r no s e )

( A l i c e a nd t h e c a p t c h a )

 Let's assume the following situation

 Alice visits a website she frequently uses  She has a login there, password stored

 Let's further assume her password is „secret“

 The site seems to have a new security feature!  Now the login needs a CAPTCHA to be solved  And that is how it looks like!

slide-14
SLIDE 14

( g

  • t

y

  • u

r no s e )

( C A P C T H A O f d

  • m )

 Seems legit?  See it live: http://heideri.ch/opera/captcha/

slide-15
SLIDE 15

( g

  • t

y

  • u

r no s e )

( a na l y s i s )

 What really happens

 The attacker, Clive, injects CSS...

 input[type=password]{content:attr(value)}

 Then he includes a custom SVG font

 @font-face {font-family: X;src: url(x.svg#X)

format("svg");}

 The attacker simply flips characters

 s becomes x, e becomes w, c becomes @ …

 By thinking it's a CAPTCHA...  … Alice submits her password to the attacker

slide-16
SLIDE 16

( g

  • t

y

  • u

r no s e )

( v a l i d a t i

  • n)
slide-17
SLIDE 17

( g

  • t

y

  • u

r no s e )

( c s s a nd re g e x )

 Old but gold – brute-forcing passwords

 But this time with CSS3 and HTML5  The secret ingredient here is „validation“  Brute-force with RegEx!  Let's have a look  DEMO

 Good thing it works on all browsers

 Limited by smart password managers though

slide-18
SLIDE 18

( g

  • t

y

  • u

r no s e )

( C h a p t e r T WO )

< Advanced Class >

slide-19
SLIDE 19

( g

  • t

y

  • u

r no s e )

( I re a d y

  • u

)

 Bob is security aware

 His online banking webite? No scripts allowed!  His browser? Top-up-to-date!  His emails? PGP

, SMIME – you name it!

 Bob isolates stuff, knows his security

 Even if an attacker XSS'd his bank website...  Nothing could happen – no JavaScript, Flash or Java

 How can we still pwn Bob then?

slide-20
SLIDE 20

( g

  • t

y

  • u

r no s e )

( s m a rt b

  • b

)

slide-21
SLIDE 21

( g

  • t

y

  • u

r no s e )

( d e f i ne g

  • a

l s )

 We cannot XSS Bob  We cannot easily get his cookies  Neither simply access sensitive data  But we want his login data  So we oughta „jack“ the login form!

slide-22
SLIDE 22

( g

  • t

y

  • u

r no s e )

( D i rna m e I nj e c t i

  • n)

 If Bob used Chrome, it'd be gotcha!

slide-23
SLIDE 23

( g

  • t

y

  • u

r no s e )

( L e g i t

  • r

no t )

 DEMO http://html5sec.org/dirname  Looked legit – or did it?  So what happened here?

 We have one injected attribute  That's HTML5 dirname – a Unicode „helper“  dirname sets a field to a value depending on a Unicode

code-point in a different field

 But it also overwrites existing form field values.  In case the names match

 Like.. WTF!?

slide-24
SLIDE 24

( g

  • t

y

  • u

r no s e )

( L u c k y b

  • b

)

 He uses Firefox with NoScript  ...and Thunderbird with Enigmail  Unpwnable?

slide-25
SLIDE 25

( g

  • t

y

  • u

r no s e )

Re b u t t a l

 Let's stay admantine

 And develop a targeted exploit  Working on Firefox and Thunderbird  Latest versions, bypassing NoScript

How can we do that?

 And can we do it at all?  Let's have a look!

slide-26
SLIDE 26

( g

  • t

y

  • u

r no s e )

( k e y l

  • g

g e r)

 Just a harmless login page  Behaving strange on closer inspection though...

 Let's check that http://html5sec.org/keylogger

slide-27
SLIDE 27

( g

  • t

y

  • u

r no s e )

( L e a v i ng l a s v e g a s )

 If it works in Firefox w/o JavaScript  Can it also work in...

slide-28
SLIDE 28

( g

  • t

y

  • u

r no s e )

( t h u nd e rb i rd )

 Mother of God!  Stealing and exfiltrating keystrokes  Right in your favorite email client  Demo time!

slide-29
SLIDE 29

( g

  • t

y

  • u

r no s e )

( H

  • w

i s i t d

  • ne

)

 Attacker injected some inline SVG code

 SVG knows the <set> element  The <set> element can listen to events  Even keystrokes  The feature is called accessKey() (W3C)  JavaScript is turned off – it's „no script“ anyway  But the keystroke scope is hard to define  In Firefox it's the whole document

slide-30
SLIDE 30

( g

  • t

y

  • u

r no s e )

( t h a nk s s v g s a nc h e z )

Now, what's next?

slide-31
SLIDE 31

( g

  • t

y

  • u

r no s e )

<l e t s t a k e a b re a t h >

slide-32
SLIDE 32

( g

  • t

y

  • u

r no s e )

( C h a p t e r t h re e )

< For Science!!! >

slide-33
SLIDE 33

( g

  • t

y

  • u

r no s e )

( C S RF T

  • k

e ns )

 Everybody knows CSRF

 One domain makes a request to another  The user is logged into that other domain  Stuff happens, accounts get modified etc.

 How to we kill CSRF?

 Easily – we use tokens, nonces  We make sure a request cannot be guessed  Or brute-forced – good tokens are long and safe

slide-34
SLIDE 34

( g

  • t

y

  • u

r no s e )

C S RF a nd X S S

 CSRF and XSS are good friends

 JavaScript can read tokens from the DOM  Bypass most CSRF protection techniques  But can we steal CSRF tokens w/o JS?

slide-35
SLIDE 35

( g

  • t

y

  • u

r no s e )

( A l re a d y d

  • ne

)

 SDC, Gaz and thornmaker already did it  Check out http://p42.us/css/  They used CSS

 Basically a brute-force via attribute selectors  input[value^=a]{background:url(?a)}  If the server catches GET /?a...  The first character is an a

 But then what?  There's no „second or Nth character selector“  They had to go input[value^=aa]{background:url(?aa)}

slide-36
SLIDE 36

( g

  • t

y

  • u

r no s e )

( e f f e c t i v e ne s s )

 We're attackers who don't have much

time!

 So we cannot bruteforce like that  We need a quicker approach!  Also, this time we want to attack Webkit :-)

 Let's cook ourselves some crazy CSS!

slide-37
SLIDE 37

( g

  • t

y

  • u

r no s e )

( i ng re d i e nt s )

 Some links with a secret CSRF token  A CSS injection

 height  width  content:attr(href)  overflow-x:none  font-family  And another secret ingredient

slide-38
SLIDE 38

( g

  • t

y

  • u

r no s e )

( D E M O )

 http://html5sec.org/webkit/test

slide-39
SLIDE 39

( g

  • t

y

  • u

r no s e )

( c

  • k

i ng m e t h )

 The secret ingredients

 Custom SVG font – one per character  An animation – decreasing the box size  The overflow to control scrollbar appearance  And finally...  Styled scrollbar elements – Webkit only

div.s::-webkit-scrollbar-track-piece :vertical:increment {background:red url(/s)}

slide-40
SLIDE 40

( g

  • t

y

  • u

r no s e )

( t h

  • s

e f

  • nt

s )

 There's more we can do with custom fonts

 HTML5 recommends WOFF  All done via @font-face

 WOFF supports an interesting feature

 Discretionary Ligatures  Arbitrary character sequences can become one character  Imagine.. C a t become a cat icon. Or... d e e r a lil' deer

slide-41
SLIDE 41

( g

  • t

y

  • u

r no s e )

( l i g a t u re s )

 http://ie.microsoft.com/testdrive/graphics/opentype/opentype-monotype/index.html

slide-42
SLIDE 42

( g

  • t

y

  • u

r no s e )

( f

  • nt

f

  • rg

e )

slide-43
SLIDE 43

( g

  • t

y

  • u

r no s e )

( A t t a c k f

  • nt

s )

 We can thus build dictionary fonts!

 One character per password for example  No problem for a font to handle 100k+ items

 Map the string s u p e r s e c r e t into one char  Make everything else invisible  If the character is visible, we have a hit

 If not the password is not in the list/font

 But how to activate this ligature feature?

 With CSS3! -moz-font-feature-settings:'calt=0'; -ms-font-feature-

settings:'calt' 0;

 How can we find out if nothing – or just one char is visible?

slide-44
SLIDE 44

( g

  • t

y

  • u

r no s e )

( g

  • C

S S )

 Remember the smart scrollbars?

 Same thing all over again  But this time for all browsers please

 CSS Media Queries to the rescue!

 We can deploy selective CSS depending on:

 Viewport width, viewport height  @media screen and (max-width: 400px){*{foo:bar}}

 Every character gets a distinct width, and/or height  Once scrollbars appear, the viewport width gets reduced  By the width of the scrollbar  Some Iframe tricks do the job and allow universal scrollbar

detection

 That's all we need _:D

slide-45
SLIDE 45

( g

  • t

y

  • u

r no s e )

{ D e m o }

DEMO

slide-46
SLIDE 46

( g

  • t

y

  • u

r no s e )

( t h e p e rf e c t l e a k )

slide-47
SLIDE 47

( g

  • t

y

  • u

r no s e )

{ A l m o s t d

  • ne

}

slide-48
SLIDE 48

( g

  • t

y

  • u

r no s e )

( C O NC L U S I O N I )

Everything is a side-channel nowadays

( Oh my!)

slide-49
SLIDE 49

( g

  • t

y

  • u

r no s e )

( C

  • nc

l u s i

  • n

I I )

 Scriptless Attacks versus XSS  Not many differences in impact  More common injcetion scenarios  Affecting sandboxes with HTML5  Information leaks by design  Hard to detect and fix  Timing and Side-Channel  NoScript to the rescue!

slide-50
SLIDE 50

( g

  • t

y

  • u

r no s e )

( d e f e ns e )

 How to protect against features?  How to protect against side-channels

 Reduce data leakage?  Change standards?  Build better sandboxes?  Extend SOP to images and other side channels,

 Use CSP?

 XFO and Framebusters ftw?  Use NoScript if you can!

slide-51
SLIDE 51

( g

  • t

y

  • u

r no s e )

( F u t u re wo rk )

 There's a lot more in this

 CSRF

, injections and side-channels

 Challenging attacker creativity  Application and App specific bugs  Scriptless attacks and mobile devices?

 Exciting times to come without XSS

slide-52
SLIDE 52

( g

  • t

y

  • u

r no s e )

( T h e e nd )

 Questions?  Discussion?  Thanks for your time!

Oh – and I just published a new XSS challenge: http://html5sec.org/noid – enjoy! :)