</CLOUD>

Aa6b7d3a12a61bfe0ce9c8a12405bd75?s=47 Rich Smith
September 19, 2013

 </CLOUD>

A high level talk on some aspects of 'Cloud' security given with Ýmir Vigfússon to a financial services security interest group in Iceland.

Aa6b7d3a12a61bfe0ce9c8a12405bd75?s=128

Rich Smith

September 19, 2013
Tweet

Transcript

  1. Ýmir Vigfússon Rich Smith </CLOUD>  

  2. •  Ýmir  Vigfússon,  PhD   – Now:  Prof.  of  Computer  Science,

     Reykjavík   University  &  Chief  Science  Officer  of  Syndis   – Prior:  IBM  Research,  Yahoo  Research,  ...   – Where:  Reykjavík   •  Rich  Smith   – Now:  Principal  Researcher  and  CEO  of  Syndis   – Prior:  VP  at  Morgan  Stanley,  HP  Labs,  ...   – Where:  NYC  &  Reykjavík  
  3. Who  are  Syndis?     •  Group  of  offensive  security

     professionals  who   use  aHack  simulaJons  against  our  clients  to   help  them  understand  real-­‐world  threats   •  We  focus  on  bespoke  aHack  technology  for   clients  who  need  deep  security  insight  
  4. •  Rapidly  changing  area  of  technology   •  Example  of

     how  aHack  opportuniJes  are  created   •  ARackers  understand  more  about  the  security   implicaJons  of  a  technology  change  than  you  do   CLOUD  SECURITY  
  5. CLOUD  

  6. None
  7. Before  the  cloud   Reality   Capacity   Requests  

    Time   Your  users  flee   Bad  uJlizaJon   Capacity  does   not  track  reality  
  8. —  Maximum  capacity  should  track  reality   ElasScity   Reality

      Capacity   Requests   Time  
  9. Up  to  the  clouds   Pros   Lower  capital  and

      operaSng   expenditures   Simple  to  use   AHributes   Reliability   ElasScity   Virtual  environment   Distributed  hosSng   Types   IaaS   PaaS   SaaS  
  10. Up  to  the  clouds   Clouds  are  an  elasJc,  reliable

      operaSng  environments  that  share     common  resources  and  meter  usage   (as  well  as  quality)   Pros   Lower  capital  and   operaSng   expenditures   Simple  to  use   AHributes   Reliability   ElasScity   Virtual  environment   Distributed  hosSng   Types   IaaS   PaaS   SaaS  
  11. Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail  

    • Salesforce   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • MicrosoX  Azure  /  365   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system   Virtual  machines   Equipment   Data  storage   Networking  equipm.   Security  team  
  12. Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail  

    • Salesforce   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • Heroku   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system   Virtual  machines   Equipment   Data  storage   Networking  equipm.   Security  team  
  13. ApplicaJons   Data   Run-­‐Jme  environment   OperaJng  system  

    Virtual  machines   Equipment   Data  storage   Networking  equipm.   Cloud  layers   SoXware-­‐as-­‐a-­‐Service   • Google  Docs  /  Gmail   • Capsule   Pla\orm-­‐as-­‐a-­‐Service   • Google  App  Engine   • Amazon  Beanstalk   • Heroku   Infrastructure-­‐as-­‐a-­‐Service   • Amazon  EC2   • Rackspace.com   Security  team  
  14. DelegaSon  of  trust   —  The  cloud  has  many  layers

     –  it  is  not  flat     ◦  What  if  Capsule  uses  Heroku,  which  in  turn  uses   Amazon  EC2?   —  It  may  not  even  be  possible  to  know  where  data   is  geographically  stored   ◦  Can‘t  dictate  data  locaJon  for  cloud  providers   ◦  Historic  knowledge  of  where  it  is  does  not  predict   where  it  will  be  in  the  future  
  15. DelegaSon  of  trust   —  Do  trust  concerns  stop  companies

     from   migraSng  to  the  cloud?   ◦  „More  than  33%  of  company  budgets  spent  on  cloud   services“  (Forbes  [1])   ◦  „79%  of  cloud  providers  allocate  less  than  <10%  to   security“  (Ponemon  InsStute  [2])   ◦  100%  of  aRackers  approve!   [1]  hRp://blogs.wsj.com/tech-­‐europe/2011/04/29/cloud-­‐providers-­‐not-­‐concerned-­‐by-­‐security   [2]  hRp://www.ca.com/us/~/media/Files/IndustryAnalystReports/2012-­‐security-­‐of-­‐cloud-­‐computer-­‐users-­‐final1.pdf  
  16. •  Rapidly  changing  area  of  technology   •  Example  of

     how  aHack  opportuniJes  are  created   •  ARackers  understand  more  about  the  security   implicaJons  of  a  technology  change  than  you  do   CLOUD  SECURITY  
  17. SECURITY  

  18. None
  19. None
  20. None
  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. None
  35. ATTACKING IS AN ENTERPRISE Found the original bug by fuzzing

    Wrote a proof-of- concept exploit Wrote a DEP- resistant exploit Weaponized the exploit Created post- exploitation framework Sponsored the attacks Administered deployment
  36. None
  37. •  <The  situaSon  is  highly  asymeRric>   ASYMMETRY

  38. So,  how  do  you  aRack  the  cloud  ?   • 

    You  are  using  the  cloud  for  a  reason   – Lowering  barriers  to  entry:  a  startup  can  have  a   full  IT  setup  without  upfront  costs   – DelegaJng  responsibility  for  saving  on  costs  and   complexity   – Technology  is  complicated  and  a  distracJon.             Let  someone  else  worry  about  that   – All  of  these  advantages  also  have  trade-­‐offs  
  39. So,  how  do  you  aRack  the  cloud  ?   • 

    ARackers  take  advantage  of  these  features     – Focus  on  those  tradeoffs  and  compromises   – IdenSfy  the  features  of  the  cloud  you  rely  on  that   also  provide  them  aRack  advanatage   •  What  are  the  opportuniJes  for  aHackers?   – We‘ll  give  real-­‐world  examples   – Flaws  -­‐  not  bugs  
  40. FLAW   BUG  

  41. #0  Clouds  are  opaque   •  Log  availability  is  limited

      –  IaaS:  Amazon  S3  does  not  provide  connecSon  logs   –  PaaS:  Logs  in  Google  Apps  (e.g.  Gmail)  have  no  ‘SLA’   could  arrive  0-­‐48  hours  later   •  Thus  you  will  likely  not  see  either  successful  or   failed  log-­‐in  aHempts  at  all  or  in  a  Smely  manner   •  You  are  at  the  mercy  of  your  provider    
  42. #1  Clouds  are  accessible   •  Different  requirements  for  access

     control   – Clouds  &  OpenAPIs  go  hand  in  han   – API  tokens  /  certs  are  the  keys  to  the  kingdom   – Opaque  with  respect  to  logging   •  Example:  Amazon  S3  credenSals   – Full  remote  access  via  API  keys  /  cerSficates   – We‘ve  found  AWS  admins  keys  on  publicly   accessible  websites,  giving  access  to  everything  
  43. #1  Clouds  are  accessible   •  But  what  about  two-­‐factor

     authenJcaJon?   •  User  interface  Vs.  ProgramaSc  Interface   – Different  security  models  &  requirements   •  Example:  Gmail  servers.   – May  enforce  2-­‐factor  authenScaSon  for  users   – But  the  API  allows  you  to  sidestep  them  
  44. #2  Clouds  are  leaky   •  The  cloud  is  foundaJonal

     to  many  companies   and  organizaSons   – Tech  companies  are  very  fast  adopters   •  Lots  of  trust  placed  in  cloud-­‐based  services  
  45. #2  Clouds  are  leaky   •  Example:  HipChat   – Private

     group  chat  and  team  collaboraSon   – All  files  or  images  are  stored  in  Amazon  S3   – ProtecSon  is  based  on  not  knowing  the  URL   – Google  search  for  “site:s3.amazonaws.com  inurl:/ uploads.hipchat.com”  
  46. #2  Clouds  are  leaky   •  Example:  GitHub  /  Gist

      –  The  social  network  of  soXware  developers   –  Companies  and  individuals  push  their  code  into  these   services     –  We‘ve  found  lots  of  sensiJve  data  pushed  unwizngly   •  CredenSals  (SSH    keys,  database  credenSals)   •  Internal  documentaSon   •  Internal  infrastructure  informaSon   –  What  applicaSons  are  being  used?   –  Internal  network  set-­‐up  and  structure   –  ARackers  care  about  ROI  –  we  hired  a  summer  intern!  
  47. #3  Clouds  get  everywhere   •  Even  if  you  think

     you‘re  not  using  the  cloud,   you  may  sSll  be   •  Example:  MacOS  X:  Unsaved  docs  &  iCloud   – Enter  AppleID  at  install  Sme,  iCloud  auto-­‐enabled   – Your  documents  are  stored  locally...   – ...but  unsaved  files  in  apps  supporSng  the  iCloud   API  are  automaScally  pushed  into  iCloud   – This  is  unexpected  to  most  !   hRp://support.apple.com/kb/TS4372  
  48. OS   Cloud   App  

  49. #3  Clouds  get  everywhere   •  This  a  trend  which

     is  ongoing  &  not  just  OS  X   •  Has  significant  impact  to  long  established   security  models  and  boundaries   •  Not  just  network  de-­‐perimiterisaSon  but  the   break  of  the  OS  perimeter   hRp://support.apple.com/kb/TS4372  
  50. ARackers‘  takeaways   •  In  the  cloud,  your  tracks  are

     harder  for   people  to  see   •  Cloud  users  don’t  understand  the  changes  to   their  security  boundaries  of  the  new  model   •  API  keys  are  everywhere  and  are  the  keys  to   many  kingdoms   •  RegulaJons  fail  to  keep  up  !=  security  
  51. None
  52. None
  53. None
  54. None
  55. HOW MUCH DO I SPEND ON DEFENSE X? HOW MUCH

    DOES AN ATTACKER HAVE TO SPEND TO BYPASS X? HOW MUCH IS DEFENSE X ACTUALLY WORTH TO ME? WHAT IS BYPASSING DEFENSE X WORTH TO AN ATTACKER ?
  56. None
  57. If  you  take  nothing  else  away     Tradeoffs  

      Asymmetries      
  58. Clouds  trade  off  control  for  lower  costs   Caveat:  Also

     reduces  security  granularity   Clouds  reduce  operaSonal  complexity   Caveat:  Increase  security  complexity   Cloud  environments  constantly  evolving   Caveat:  Security  understanding  must  evolve  also  
  59. Ýmir Vigfússon ymir@syndis.is Rich Smith rich@syndis.is #TheSyndis