• Save
Reading Group Presentation: Web Attacks on Host-Proof Encrypted Storage
Upcoming SlideShare
Loading in...5
×
 

Reading Group Presentation: Web Attacks on Host-Proof Encrypted Storage

on

  • 1,522 views

This presentation exposes the current threat model to host-proof encrypted storage, details of vulnerability exploitation per application, and multiple pointers to relevant academic research in web ...

This presentation exposes the current threat model to host-proof encrypted storage, details of vulnerability exploitation per application, and multiple pointers to relevant academic research in web security. I presented these works to a weekly Security and Privacy reading group.

The academic proceeding can be found here:
https://www.usenix.org/conference/woot12/web-based-attacks-host-proof-encrypted-storage

Statistics

Views

Total Views
1,522
Views on SlideShare
1,483
Embed Views
39

Actions

Likes
0
Downloads
0
Comments
0

8 Embeds 39

http://michael-rushanan.blogspot.com 23
http://michael-rushanan.blogspot.jp 5
http://michael-rushanan.blogspot.co.uk 4
http://michael-rushanan.blogspot.ca 2
http://michael-rushanan.blogspot.fr 2
http://michael-rushanan.blogspot.com.es 1
http://michael-rushanan.blogspot.gr 1
http://michael-rushanan.blogspot.tw 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Reading Group Presentation: Web Attacks on Host-Proof Encrypted Storage Reading Group Presentation: Web Attacks on Host-Proof Encrypted Storage Presentation Transcript

  • Web-­‐based  A*acks  on  Host-­‐ Proof  Encrypted  Storage   Weekly  Security  and  Privacy  Talk         Michael  Rushanan  
  • WARNING  •  The  views  presented  in  this  presentaEon  are  my  own  and   do  not  express  the  views  of  the  Johns  Hopkins  University.  •  The  content  presented  in  this  presentaEon  was  extracted   from  mulEple  academic  conference  proceedings.  •  Most  pictorial  references  were  shamelessly  collected  from   the  internet  and  presented  without  reference.  If  you  find   your  image  and  wish  to  request  that  I  provide  a  reference,   please  email  me  at  the  address  provided  on  my  website:   michaelrushanan.org.  
  • Cryptography  and  the  Internet  •  “We  need  to  do  some  basic  engineering”  •  “We  need  to  educate  users”   -­‐  Steven  M.  Bellovin  
  • Thank  Your  not(Sponsors)   CloudFogger 1password SpiderOak PassPack clipperz RoboForm Wuala LastPass BoxCryptor
  • Keys  to  the  Cloud  Castle   The  economist:  h*p://www.economist.com/blogs/babbage/2011/05/internet_security  
  • Dropbox  Under  Fire  •  This  economist  arEcle  points  out  that  Dropbox  has   some  shortcomings  that  really  shook  up  the   community:   –  Mobile  Apps  were  only  encrypEng  in  transit.   –  A  vulnerability  allowed  the  inserEon  of  one  configuraEon   file  to  allow  the  sync  of  an  enEre  users  Dropbox  to   another.   –  Any  employee  at  Dropbox  could  decrypt  a  users  file.   –  Metadata,  such  as  filenames,  are  le_  unencrypted  for  easy   searching,  indexing,  and  structure  management.  
  • SpiderOak  by  Contrast  •  SpiderOak  cannot  disclose  user  data  even  if  it   wanted  to.   –  It  doesn’t  maintain  individual  user  keys  that  are  used  to   encrypt  data  prior  to  sending  it  to  the  cloud.   –  However,  if  the  user  forgets  that  secret  passphrase,  that   data  is  as  good  as  gone.  
  • What  does  this  Mean  for  our  Authors?  •  Simple  enough,  the  aforemenEoned  provided  the   grounds  in  which  to  further  explore  the   implementaEon  of  cloud-­‐based  storage  (and   password)  managers.   –  EsEmated  25  million  Dropbox  users  with  third  party   services  available  for  client  side  encrypEon/decrypEon.   –  Numerous  cloud-­‐based  storage  providers  offering   “advanced  security”.   –  Many  of  these  clients  are  implemented  both  as  a  naEve   and  web  based  applicaEon.  
  • Host-­‐Proof  Web  ApplicaEons  •  Increase  in  website  a*acks.  •  Web  service  architecture  needed  a  faceli_.  
  • Services  &  Managers  •  Wuala,  SpiderOak:   –  Cloud-­‐based  storage  services  offering  remote  encrypted   storage  with  the  ability  to  synchronize  across  all   authorized  devices,  with  the  addiEonal  ability  to  share   specific  files.  •  LastPass,  1Password:   –  Password  managers  that  offer  to  store  confidenEal  data   (credenEals,  credit  card  info)  to  websites.  
  • Client  Side  EncrypEon  •  Relies  on  user  having  an  encrypEon  key  or  knowing  a   passphrase  from  which  the  key  is  derived.  •  All  applicaEons  analyzed  in  this  paper  support   PBKDF2  password-­‐based  key  derivaEon  funcEon   specificaEon.  •  (ApplicaEon  Dependent)  EncrypEon  schemes  used   tend  to  be  symmetric,  AES,  and  if  integrity  is   protected  (SpiderOak/Wuala)  a  Hash  MAC  is  used.  
  • PKCS  #5:  Password-­‐Based   Cryptography  Standard  •  “This  document  provides  recommendaEons  for  the   implementaEon  of  password-­‐based  cryptography,  covering   key  derivaEon  funcEons,  encrypEon  schemes,  message-­‐ authenEcaEon  schemes,  and  ASN.1  syntax  idenEfying  the   techniques.”  •  PBKDF2  applies  a  pseudorandom  funcEon  to  derive  keys.     1.  Inputs:  password,  salt,  iteraEon  count,  intended  length  of  the  derived  key.   2.  If  length  of  the  derived  key  is  greater  than  2^32-­‐1*length  of  PRF  -­‐  key  is  too  long.   3.  For  each  block  of  the  derived  key  apply  the  following  funcEon  F:   B_1  =  F(Password,  Salt,  IteraEon  Count,  Block  Index)   4.  The  funcEon  F  is  defined  as  the  xor  sum  of  the  first  count  iterates  of  the  underlying   PRF  applied  to  the  (password  ||  salt  ||  block  index).           5.  Concatenate  the  blocks  and  extract  the  first  required  length  of  required  key.   6.  Output:  derived  key.   Incase  you  want  to  read  the  whole  specificaEon  @  Internet  Engineering  Task  Force:  h*p://tools.ieo.org/html/rfc2898  
  • Lots  of  Apps  use  PKCS  #5  •  “Secure  Password  Managers”  and  “Military-­‐Grade   EncrypEon”  on  Smartphones:  Oh,  Really?   –  Paper  analyzes  the  security  concerns  of  current  mobile   applicaEons  offering  password  management.   –  Example  1:  iOS  user  configurable  backup  encrypEon.   •  Backup  encrypEon  key  is  computed  by  performing   10,000  iteraEons  of  PBKDF2-­‐SHA1  funcEon  with   password  as  an  input.   –  If  the  iteraEve  count  isn’t  significant,  you  allow  an  a*acker   to  more  easily  complete  an  exhausEve  search.     –  Another  problem  is  low  entropy  passwords.  
  • Brute-­‐Force  A*acks  by  Stretching  the   Low-­‐Entropy  Password  •  Make  a  weak  password,  say  “tesEng,”  more   secure  by  applying  a  salt.    •  A  similar  technique  is  used  for  key  stretching.  •  Re-­‐visiEng  the  iteraEon  count,  it’s  important   to  note  that  one  property  of  key  stretching  is   to  apply    a  hash  funcEon  or  block  cipher  in  a   loop.   Secure  ApplicaEons  of  Low  Entropy  Keys  h*p://www.schneier.com/paper-­‐low-­‐entropy.pdf  
  • Jumping  into  the  A*acks  
  • RoboForm  Passcard  Tampering  •  The  card  format  contains  a  plaintext  URL.  •  An  a*acker  could  exploit  the  sharing  feature   and  modify  passcard  URL  to  malicious.com.  
  • 1Password  Keychain  Tampering  •  Same  problem  with  the  excepEon  that  the  A*acker  now  needs   access  to  Dropbox  where  keychains  are  typically  shared.  •  Remember  when  we  menEoned  this  config  a*ack  earlier?  Here  are   the  specifics:   –  When  installing  Dropbox  it  creates  a  config.db  SQLite  database  file   that  is  used  to  idenEfy  the  device  to  the  Dropbox  account.  This  file  is   of  course  read/writeable  because  it  is  SQLite  a_erall,  and  is  easily   relocatable.  Thus,  if  an  a*acker  can  grab  the  said  config.db,  she  can   sync  all  of  the  vicEm  files  to  her  computer.  
  • To…  •  Encrypt  then  MAC?  •  Encrypt  and  MAC?  •  MAC  then  Encrypt?  
  • How  to  Protect?  •  MAC  it,  duh.  •  AuthenEcated  EncrypEon  would  provide  integrity  to   the  encrypted  private  data.  •  Also,  authenEcaEng  the  metadata  would  be  useful  in   these  cases  to  provide  integrity.  The  authors   recommend  an  encrypted+MAC  approach.  Do  you   think  that’s  overkill?  
  • Hmm…  •  What  is  the  same  origin  policy?  •  What  is  JSONP  used  for?  •  document.domain  property  
  • SpiderOak  and  JSONP  •  JSONP  is  usually  used  to  get  past  cross-­‐domain  problems  (i.e.,   geung  past  same  origin  policy).  •  This  creates  a  bit  of  heartache  for  SiderOak  as  it  allows  for  a   CSRF.  •  If  the  user  is  logged  into  the  SpiderOak  website  and  browsing   a  malicious  website,  the  a*acker  might  guess  the  user  name   and  retrieve  the  JSONP  object  containing  a  list  of  her  full   directory  structure.  
  • CSRF  Anyone?  •  Takers?  
  • Wikipedia’s  CSRF  ExplanaEon  •  The  a*acker  must  target  either  a  site  that  doesnt  check  the   referrer  header  (which  is  common)  or  a  vicEm  with  a  browser  or   plugin  bug  that  allows  referer  spoofing  (which  is  rare).  •  The  a*acker  must  find  a  form  submission  at  the  target  site,  or  a   URL  that  has  side  effects,  that  does  something  (e.g.,  transfers   money,  or  changes  the  vicEms  e-­‐mail  address  or  password).  •  The  a*acker  must  determine  the  right  values  for  all  the  forms  or   URLs  inputs;  if  any  of  them  are  required  to  be  secret   authenEcaEon  values  or  IDs  that  the  a*acker  cant  guess,  the   a*ack  will  fail.  •  The  a*acker  must  lure  the  vicEm  to  a  Web  page  with  malicious   code  while  the  vicEm  is  logged  in  to  the  target  site.  
  • Sneaky  HTTP  and  Wuala  •  “Wuala  maintains  an  encrypted  directory  tree  where  each  file   is  encrypted  with  a  different  key.”  •  Wuala  also  runs  a  lightweight  HTTP  server  used  for  status   reporEng.  •  By  browsing  to  the  /js/  path,  you  can  actually  get  to  the   defaultuser  directory  where  the  master  key  file  is  maintained.   An  a*acker  could  access  said  file  by  simply  providing  a  Java   applet  in  which  to  access  Wuala  encrypted  files  on  her  site.  
  • Phishing  A*acks  on  Browser   Extensions  •  Why  I  like  this  –  JavaScript  crypto  being  used!  •  Why  I  don’t  like  this  –  URL  parsing  is  a  pain  and  as  the  authors   have  shown  that  by  specifically  cra_ing  links  like,   h*p://www.google.com:xxx@bad.com,  it  is  possible  to  gain   our  decrypted  private  data.  
  • Bookmarklets  –  Who  the  Hell  uses   These?  •  A  good  bookmarklet  example  was  YubNub  who  a*empted  to   provide  a  “web  command  line.”    •  Bookmarklets  are  executed  within  the  scope  of  the  page  and   thus  are  vulnerable  to  a  variety  of  threats.  •  This  is  problemaEc  for  LastPass  bookmarklet.  
  • Rootkits  for  JavaScript  Environments  •  This  paper  specifically  targets  cloud-­‐based  password   managers  and  is  another  work  by  our  web  security   hero,  Adam  Barth.  •  Bookmarklets  are:   –  Easy  to  develop,  install,  and  run  on  all  browsers.   –  Are  a  part  of  the  “mashup”  ecosystem.   –  When  acEvated  it  runs  in  the  context  of  the  currently   viewed  webpage…  even  if  that’s  holycrap-­‐I-­‐am-­‐totally-­‐ malicious.a*acker.screwed.org   –  This  allows  the  a*acker  to  carefully  cra_  her  JavaScript   environment  such  that  it  can  modify  intended  execuEon.  
  • JS  RootKits  •  A  JavaScript  rootkit  modifies  the  bookmarklet-­‐visible  behavior   of  a  JavaScript  environment  and  escapes  detecEon  by   overriding  the  naEve  JavaScript  objects.  •  Shadowing:  Take  the  names  of  naEve  objects  and  emulate   their  behavior.  •  Prototype  Poisoning:  Alter  the  semanEcs  of  built-­‐in  types  by   altering  their  prototype  objects.    •  ReflecEon:  Apply  techniques  to  JS  ReflecEon  API  to  hide   modificaEons  from  bookmarklets  (if  a*emping  introspecEon).