Web-­‐based	  A*acks	  on	  Host-­‐ Proof	  Encrypted	  Storage	     Weekly	  Security	  and	  Privacy	  Talk	            ...
WARNING	  •  The	  views	  presented	  in	  this	  presentaEon	  are	  my	  own	  and	     do	  not	  express	  the	  view...
Cryptography	  and	  the	  Internet	  •  “We	  need	  to	  do	  some	  basic	  engineering”	  •  “We	  need	  to	  educate...
Thank	  Your	  not(Sponsors)	                                                       CloudFogger	           1password	     ...
Keys	  to	  the	  Cloud	  Castle	           The	  economist:	  h*p://www.economist.com/blogs/babbage/2011/05/internet_secu...
Dropbox	  Under	  Fire	  •  This	  economist	  arEcle	  points	  out	  that	  Dropbox	  has	     some	  shortcomings	  tha...
SpiderOak	  by	  Contrast	  •  SpiderOak	  cannot	  disclose	  user	  data	  even	  if	  it	     wanted	  to.	      –  It	...
What	  does	  this	  Mean	  for	  our	  Authors?	  •  Simple	  enough,	  the	  aforemenEoned	  provided	  the	     grounds...
Host-­‐Proof	  Web	  ApplicaEons	  •  Increase	  in	  website	  a*acks.	  •  Web	  service	  architecture	  needed	  a	  f...
Services	  &	  Managers	  •  Wuala,	  SpiderOak:	     –  Cloud-­‐based	  storage	  services	  offering	  remote	  encrypted...
Client	  Side	  EncrypEon	  •  Relies	  on	  user	  having	  an	  encrypEon	  key	  or	  knowing	  a	     passphrase	  fro...
PKCS	  #5:	  Password-­‐Based	                          Cryptography	  Standard	  •  “This	  document	  provides	  recomme...
Lots	  of	  Apps	  use	  PKCS	  #5	  •  “Secure	  Password	  Managers”	  and	  “Military-­‐Grade	     EncrypEon”	  on	  Sm...
Brute-­‐Force	  A*acks	  by	  Stretching	  the	            Low-­‐Entropy	  Password	  •  Make	  a	  weak	  password,	  say...
Jumping	  into	  the	  A*acks	  
RoboForm	  Passcard	  Tampering	  •  The	  card	  format	  contains	  a	  plaintext	  URL.	  •  An	  a*acker	  could	  exp...
1Password	  Keychain	  Tampering	  •  Same	  problem	  with	  the	  excepEon	  that	  the	  A*acker	  now	  needs	     acc...
To…	  •  Encrypt	  then	  MAC?	  •  Encrypt	  and	  MAC?	  •  MAC	  then	  Encrypt?	  
How	  to	  Protect?	  •  MAC	  it,	  duh.	  •  AuthenEcated	  EncrypEon	  would	  provide	  integrity	  to	     the	  encr...
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...
CSRF	  Anyone?	  •  Takers?	  
Wikipedia’s	  CSRF	  ExplanaEon	  •  The	  a*acker	  must	  target	  either	  a	  site	  that	  doesnt	  check	  the	     ...
Sneaky	  HTTP	  and	  Wuala	  •  “Wuala	  maintains	  an	  encrypted	  directory	  tree	  where	  each	  file	     is	  enc...
Phishing	  A*acks	  on	  Browser	                            Extensions	  •  Why	  I	  like	  this	  –	  JavaScript	  cryp...
Bookmarklets	  –	  Who	  the	  Hell	  uses	                   These?	  •  A	  good	  bookmarklet	  example	  was	  YubNub	...
Rootkits	  for	  JavaScript	  Environments	  •  This	  paper	  specifically	  targets	  cloud-­‐based	  password	     manag...
JS	  RootKits	  •  A	  JavaScript	  rootkit	  modifies	  the	  bookmarklet-­‐visible	  behavior	     of	  a	  JavaScript	  ...
Reading Group Presentation: Web Attacks on Host-Proof Encrypted Storage
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


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

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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:   michaelrushanan.org.  
  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://www.economist.com/blogs/babbage/2011/05/internet_security  
  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://tools.ieo.org/html/rfc2898  
  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://www.schneier.com/paper-­‐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  malicious.com.  
  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://www.google.com:xxx@bad.com,  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*acker.screwed.org   –  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).