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.

Web Application Defense, Breaking the Kill Chain

2,424 views

Published on

Advanced Web Defense using CAPEC data, Behavioral Analysis and Strategic Security Controls
DRAFT

  • Be the first to comment

Web Application Defense, Breaking the Kill Chain

  1. 1. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 1 of 9         Web  Application  Defense,  Breaking  the  Kill  Chain     Advanced  Web  Defense  using  CAPEC  data,  Behavioral  Analysis  and  Strategic  Security   Controls                               Jerome  Athias   DRAFT   March  2014                                     Trademarks  are  property  of  their  respective  owners      
  2. 2. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 2 of 9   Introduction     Web  Applications  are  subject  to  a  large  exposure,  and  so  high  risk  of  attacks  (exploitation  of   vulnerabilities  resulting  of  exposed  weaknesses).     A  proper  SDLC  is  mandatory,  including  Best  Practices  of  Secure  Web  Development.   https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet   https://www.owasp.org/index.php/Secure_Coding_Principles   https://www.cert.org/secure-­‐coding/   https://www.owasp.org/index.php/Cheat_Sheets   https://www.owasp.org/index.php/Security_Code_Review_in_the_SDLC   This  is  part  of  a  Secure  Web  Applications  Strategy.   http://www.opensamm.org     Reducing  the  attack  surface  is  a  must  for  Web  Application  Security.   https://www.owasp.org/index.php/Identify_attack_surface   https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet   http://websec.io/2013/01/28/Core-­‐Concepts-­‐Attack-­‐Surface.html   http://www.slideshare.net/OWASP_Ottawa/pierre-­‐ernst-­‐xml-­‐attack-­‐surface-­‐owasp-­‐ottawa   http://publications.drdo.gov.in/ojs/index.php/dsj/article/view/1291     The  Threat  Modeling  SDLC’s  activity  is  a  highly  efficient  process.   http://en.wikipedia.org/wiki/Threat_model   https://www.owasp.org/index.php/Application_Threat_Modeling   https://www.owasp.org/images/7/79/AppSecEU09_OWASP_EU_Threat_Modeling.ppt   http://imi.nku.edu/security/Powerpoints/Marco_Morana.pdf     As  part  of  all  Information  Security  Management  System  (or  in  Risk  Management),  a  selection  of   relevant  and  applicable  Security  Requirements  has  to  be  performed.   e.g.    OWASP  ASVS   https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard _Project   Based  on  the  Security  Requirements  (Confidentiality,  Integrity,  Availability),  appropriate  and   efficient  Security  Controls  (see  the  Orange  Book)  must  be  used.   The  Security  Controls  (safeguards)  must  be  selected  correctly  (ROI  can  play  a  role  here),  applied,   checked  and  monitored  efficiently.     Methodologies  exist  for  Secure  Code  Review  and  Web  Application  Security  Assessment  (Web   Vulnerability  Assessment,  Web  Application  Penetration  Testing).   https://www.owasp.org/index.php/OWASP_Testing_Project   http://www.isecom.org/research/osstmm.html     Common  Weaknesses  (root  cause  of  breaches)  are  now  well  defined.   https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project   http://projects.webappsec.org/Threat-­‐Classification   https://cwe.mitre.org     However,  there  is  not  too  much  available  regarding  an  effective  strategic  methodology  for   technical  security  controls  selection.      
  3. 3. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 3 of 9   CAPEC™     A  Common  Attack  Pattern  Enumeration  and  Classification  repository,  managed  by  MITRE.   http://capec.mitre.org     CAPEC  is  directly  mapped  to  CWE,  WASC  and  OWASP  Top  10,  making  it  easy  to  use.     Attack  Execution  Flow     Inside  the  various  useful  information  of  CAPEC,  there  is  the  Attack  Execution  Flow,  described  as   progressive  Attack  Step  Techniques.         One  familiar  with  Threat  Modeling  could  directly  think  about  of  mapping  this  to  an  Attack  Tree  or   complement  of  a  Data  Flow  Diagram.     Going  further,  the  dissection  of  the  Attack  Execution  Flows  described  in  CAPEC  offer  an   opportunity  for  Intelligence-­‐Driven  Web  Application  Defense  by  Analysis  of  Adversary  Tactics,   Techniques  and  Procedures  (TTP)  and  Intrusion  Kill  Chains.     Reference:  Intelligence-­‐Driven  Computer  Network  Defense  Informed  by  Analysis  of  Adversary   Campaigns  and  Intrusion  Kill  Chains,  Lockheed  Martin  Corporation   http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-­‐White-­‐ Paper-­‐Intel-­‐Driven-­‐Defense.pdf        
  4. 4. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 4 of 9   Kill  Chain     As  part  of  Cyber  defense  strategy  against  Advanced  Persistent  Threats,  an  objective  could  be  a   Defensible  Security  Posture.   http://nigesecurityguy.wordpress.com/2013/06/04/defensible-­‐security-­‐posture/     A  kill  chain  defines  the  progressive  steps  of  an  attack.   People  familiar  with  forensics  and  incident  response  will  easily  understand  the  analogy  between   the  Kill  Chain  and  the  Attack  Execution  Flow.     In  the  context  of  Web  Applications,  a  defensible  actions  matrix  (technical  security  controls  per   attack  step)  could  be  defined  using  the  CAPEC’s  attack  scenarios.   The  goal:  breaking  the  kill  chain  in  its  earlier  stages,  by  using  appropriate  countermeasures   slowing  down  an  attack.     A  top-­‐down,  or  waterfall,  approach  could  be  used  to  perform  a  security  controls  selection  and  use   of  defensive  programming  techniques  for  proactive  detection  and  mitigation  of  attacks.   Following  the  defense-­‐in-­‐depth  security  principle,  these  mechanisms  will  help  to  extend  the   intrusion  detection  window.   For  the  implementation,  and  prioritization,  CAPEC  offers  also  information  about  the  Typical   Likelihood  of  Exploit,  the  CIA  Impact  (Attack  Motivation-­‐Consequences).   Furthermore,  the  Effectiveness  and  Cost  of  the  security  controls  will  be  evaluated  (tip:  see  the   CWEs  corresponding  to  a  CAPEC  entry).     In  terms  of  Threat  Assessment/Analysis  or  Threat  Intelligence,  CAPEC  is  also  interesting,  for   example  providing  information  related  to  the  Attacker  Skills  or  Knowledge  Required,  which  is   interesting  for  the  characterization  of  the  Threat  Actors  and  could  be  valuable  for  Computer   Incident  Response  Teams.  (e.g.  using  STIX  http://stix.mitre.org/)          
  5. 5. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 5 of 9   Strategy     For  effective  detection  and  mitigation  of  the  attack  techniques,  particular  attention  will  be  paid  to   the  Probing  Techniques  listed  in  CAPEC.   These  can  be  mapped,  for  example,  to  the  OWASP  Testing  Guide  methodology  for  effective   prioritization  and  maximizing  the  effectiveness  of  our  defense  strategy.   Some  of  our  defensive  programmatic  mechanisms  will  take  this  into  account  to  perform  a   contextual  and  behavioral  analysis,  making  them  more  intelligent  and  effective  (less  prone  to   false-­‐positives),  and  could  lead  attackers  to  sinkholes  or  honeypots  while  generating  alerts.   This  will  be  useful  for  continuous  monitoring  and  situational  awareness.     Remark:  the  various  CAPEC  Indicators  and  Warning  of  Attacks  are  useful  as  Indicators  of   Compromise  (IOC)     Note:  of  course,  as  per  the  defense-­‐in-­‐depth  principle,  all  the  listed  mechanisms  must  come  with  a   defense  of  the  perimeter,  boundaries  protected  by  a  layered  security  such  as  at  the  network  level.      
  6. 6. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 6 of 9   CAPEC™  Data  Usage     CAPEC  is  not  easily  usable  as  is.   To  be  more  practical,  we  will  perform  a  transformation  of  the  CAPEC  XML  feed,  by  extraction,  to  a   database.   As  part  of  the  XORCISM  project  (eXpandable  Open  Research  on  Cyber  Information  Security   Management),  a  tool  is  available  to  achieve  this  step.   https://github.com/athiasjerome/XORCISM     With  CAPEC  parsed  and  imported  into  an  XORCISM  database,  it  becomes  more  convenient  to   manipulate  the  data.     Checklist     Using  the  Attack  Steps  in  the  form  of  a  checklist  is  interesting  and  valuable.   This  could  be  used  into  a  simple  spreadsheet,  or  better  using  OCIL.   Examples:   • For  the  definition  of  security  requirements   • For  the  development  team  self-­‐assessment   Similarly  to  OWASP  ASVS,  the  data  will  be  turned  into  the  question  “Do  you  have  proper  security   requirements/controls  in  place  to  prevent  or  mitigate  the  following  attack  steps?”     Example:   Selection  of  CAPEC  Attack  Step  Techniques     Fingerprinting  of  the  operating  system   In  order  to  create  a  valid  file  injection,  the  attacker   needs  to  know  what  the  underlying  OS  is.     Spider   Using  a  browser  or  an  automated  tool,  an  attacker   follows  all  public  links  on  a  web  site.  He  records  all   the  entry  points  (input)  that  becomes  part  of   generated  HTTP  header  (not  only   GET/POST/COOKIE,  but  also  Content-­‐Type,  etc.)   Forceful  browsing   When  the  attacker  targets  the  current  application   or  another  one  (through  CSRF  vulnerabilities),  the   user  will  then  be  the  one  who  perform  the  attacks   without  being  aware  of  it.  These  attacks  are  mostly   targeting  application  logic  flaws,  but  it  can  also  be   used  to  create  a  widespread  attack  against  a   particular  website  on  the  user's  current  network   (Internet  or  not).   Attempt  well-­‐known  or  guessable  resource   locations   Using  an  automated  tool,  an  attacker  requests  a   variety  of  well-­‐known  URLs  that  correspond  to   administrative,  debugging,  or  other  useful  internal   actions.  He  records  all  the  positive  responses  from   the  server.   Survey  the  Application  to  Identify  User-­‐controllable   Inputs   The  attacker  surveys  the  target  application  to   identify  all  user-­‐controllable  inputs,  possibly  as  a   valid  and  authenticated  user   Probe  identified  potential  entry  points  for  XSS   vulnerability   The  attacker  uses  the  entry  points  gathered  in  the   "Explore"  phase  as  a  target  list  and  injects  various  
  7. 7. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 7 of 9   common  script  payloads  to  determine  if  an  entry   point  actually  represents  vulnerability  and  to   characterize  the  extent  to  which  the  vulnerability   can  be  exploited.  He  records  all  the  responses  from   the  server  that  include  unmodified  versions  of  his   script.  The  attacker  tries  also  to  inject  extra-­‐ parameter  to  the  HTTP  request  to  see  if  they  are   reflected  back  in  the  web  page  or  in  the  HTTP   response.   Attempt  well-­‐known  or  guessable  resource   locations   Using  an  automated  tool,  an  attacker  requests  a   variety  of  well-­‐known  URLs  that  correspond  to   administrative,  debugging,  or  other  useful  internal   actions.  He  records  all  the  positive  responses  from   the  server.   View  unauthorized  data   The  attacker  discovers  and  views  unprotected   sensitive  data.   Vary  inputs,  looking  for  malicious  results.   Depending  on  whether  the  application  being   exploited  is  a  remote  or  local  one  the  attacker   crafts  the  appropriate  malicious  input,  containing   OS  commands,  to  be  passed  to  the  application   Execute  malicious  commands   The  attacker  may  steal  information,  install  a  back   door  access  mechanism,  elevate  privileges  or   compromise  the  system  in  some  other  way.   Steal  session  IDs,  credentials,  page  content,  etc.   As  the  attacker  succeeds  in  exploiting  the   vulnerability,  he  can  choose  to  steal  user's   credentials  in  order  to  reuse  or  to  analyze  them   later  on.   Determine  Application's  Log  File  Format   The  first  step  is  exploratory  meaning  the  attacker   observes  the  system.  The  attacker  looks  for  action   and  data  that  are  likely  to  be  logged.  The  attacker   may  be  familiar  with  the  log  format  of  the  system.   Manipulate  Log  Files   The  attacker  alters  the  log  contents  either  directly   through  manipulation  or  forging  or  indirectly   through  injection  of  specially  crafted  input  that  the   target  software  will  write  to  the  logs.  This  type  of   attack  typically  follows  another  attack  and  is  used   to  try  to  cover  the  traces  of  the  previous  attack.   Explore  legitimate  website  and  create  duplicate   An  attacker  creates  a  website  (optionally  at  a  URL   that  looks  similar  to  the  original  URL)  that  closely   resembles  the  website  that  he  or  she  is  trying  to   impersonate.  That  website  will  typically  have  a   login  form  for  the  victim  to  put  in  their   authentication  credentials.  There  can  be  different   variations  on  a  theme  here.   Convince  user  to  enter  sensitive  information  on   attacker's  site.   An  attacker  sends  an  e-­‐mail  to  the  victim  that  has   some  sort  of  a  call  to  action  to  get  the  user  to  click   on  the  link  included  in  the  e-­‐mail  (which  takes  the   victim  to  attacker's  website)  and  log  in.  The  key  is   to  get  the  victim  to  believe  that  the  e-­‐mail  is   coming  from  a  legitimate  entity  with  which  the   victim  does  business  and  that  the  website  pointed  
  8. 8. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 8 of 9   to  by  the  URL  in  the  e-­‐mail  is  the  legitimate   website.  A  call  to  action  will  usually  need  to  sound   legitimate  and  urgent  enough  to  prompt  action   from  the  user.   Use  stolen  credentials  to  log  into  legitimate  site   Once  the  attacker  captures  some  sensitive   information  through  phishing  (login  credentials,   credit  card  information,  etc.)  the  attacker  can   leverage  this  information.  For  instance,  the  attacker   can  use  the  victim's  login  credentials  to  log  into   their  bank  account  and  transfer  money  to  an   account  of  their  choice.        
  9. 9. Web  Application  Defense  using  CAPEC  data.  Jerome  Athias   Page 9 of 9   Security  Controls     Starting  from  the  list  of  Attack  Steps,  it  becomes  easy  to  think  about  them  and  defines  security   mechanisms  at  the  Web  Application  level.   Examples:   Fingerprinting  of  the  operating  system   Chances  are  high  that  this  would  be  performed  in  the  early  stages  of  an  attack.   https://www.owasp.org/index.php/Fingerprint_Web_Server_%28OTG-­‐INFO-­‐002%29   Proper  Configuration  Management,  with  the  use  of  Hardening  Guidelines  should  prevent   information  leakage  from  the  Web  Application  Framework,  Web  Server  and  Operating  System.   !  Firewall  ACLs,  limiting  allowed  HTTP  methods,  IDS/IPS  detecting  a  port  scan  (nmap)   https://benchmarks.cisecurity.org/downloads/benchmarks/   This  is  a  basic  and  mandatory  activity  to  reduce  the  attack  surface.     Spidering   Attempt  well-­‐known  or  guessable  resource  locations   A  brute  force  enumeration  of  the  web  resources  (i.e.  pages)  accessible  into  the  web  application  is  a   common  preliminary  step  of  not  well  skilled  attackers.   Indicators  would  be:   • User  agent  of  known  tools  (e.g.  DirBuster,  w3af,  sqlmap)   • Number  of  HTTP  requests  in  a  short  period  of  time  (eventually  coming  from  the  same  IP   address)   • Requests  coming  from  a  suspicious  IP  address  range  (IP  Geolocation,  use  of  a  proxy,  IP   reputation/blacklist)   Implementing  programmatic  functions  to  analyze,  detect,  log,  prevent,  alert  when  these  events   occur  is  a  relatively  easy  and  inexpensive  task.   It  represents  cost  effective  defensive  controls,  even  if  the  effectiveness  is  disputable.     Probe  identified  potential  entry  points  for  XSS  vulnerability   Vary  inputs,  looking  for  malicious  results.   Execute  malicious  commands   Common  injection  patterns  could  easily  be  detected  (in  the  meantime  they  are  blocked  by   whitelisting  or  blacklisting)  at  the  application  level,  logged  and  reported.   The  Web  Application  could  include  self-­‐defense  mechanisms  (e.g.  fail2ban  approach).   Web  Application  Firewall  rules  could  be  improved,  IP  reputation  database  updated,  firewall  rules   enhanced,  defects  identified,  potential  unknown  vulnerabilities  (0day)  detected  faster,  etc.     Explore  legitimate  website  and  create  duplicate   This  is  a  common  technique  that  is  somehow  detectable  (for  example  by  financial  CERTs)  by   searching/monitoring  the  web  for  duplicated  images  or  content.   https://www.tineye.com/     Steal  session  IDs,  credentials,  page  content,  etc.   A  common  outcome  of  databases  leakage  is  for  attackers  to  disclose  the  stolen  information,  for   example  on  pastebin.   As  part  of  continuous  monitoring  and  threat  intelligence  activities,  APIs  or  tools  could  be  used  to   help  detecting  such  information  disclosure.   https://github.com/xme/pastemon   https://en.mention.com/  

×