Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

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:

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Web-­‐based  A*acks  on  Host-­‐ Proof  Encrypted  Storage   Weekly  Security  and  Privacy  Talk         Michael  Rushanan  
  2. 2. 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:  
  3. 3. Cryptography  and  the  Internet  •  “We  need  to  do  some  basic  engineering”  •  “We  need  to  educate  users”   -­‐  Steven  M.  Bellovin  
  4. 4. Thank  Your  not(Sponsors)   CloudFogger 1password SpiderOak PassPack clipperz RoboForm Wuala LastPass BoxCryptor
  5. 5. Keys  to  the  Cloud  Castle   The  economist:  h*p://  
  6. 6. 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.  
  7. 7. 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.  
  8. 8. 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.  
  9. 9. Host-­‐Proof  Web  ApplicaEons  •  Increase  in  website  a*acks.  •  Web  service  architecture  needed  a  faceli_.  
  10. 10. 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.  
  11. 11. 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.  
  12. 12. 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://  
  13. 13. 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.  
  14. 14. 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://­‐low-­‐entropy.pdf  
  15. 15. Jumping  into  the  A*acks  
  16. 16. RoboForm  Passcard  Tampering  •  The  card  format  contains  a  plaintext  URL.  •  An  a*acker  could  exploit  the  sharing  feature   and  modify  passcard  URL  to  
  17. 17. 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.  
  18. 18. To…  •  Encrypt  then  MAC?  •  Encrypt  and  MAC?  •  MAC  then  Encrypt?  
  19. 19. 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?  
  20. 20. Hmm…  •  What  is  the  same  origin  policy?  •  What  is  JSONP  used  for?  •  document.domain  property  
  21. 21. 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.  
  22. 22. CSRF  Anyone?  •  Takers?  
  23. 23. 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.  
  24. 24. 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.  
  25. 25. 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://,  it  is  possible  to  gain   our  decrypted  private  data.  
  26. 26. 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.  
  27. 27. 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*   –  This  allows  the  a*acker  to  carefully  cra_  her  JavaScript   environment  such  that  it  can  modify  intended  execuEon.  
  28. 28. 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).