ruxc0n 2012


Published on

Questions? email me, mimeframe ^at^ gmail ^dot^ com

Published in: Technology

ruxc0n 2012

  1. 1. Homebrew Defensive SecurityTake matters into your own handsmimeframeruxcon 2012
  2. 2. Agenda 1 Introduction 2 Culture 3 Appsec 4 CorpSec 5 Conclusions
  3. 3. Introduction
  4. 4. About Me@mimeframe▪  Started as a traditional developer▪  Movedon to Application Security (coding + pentesting)▪  Started doing some Corporate Security in H2 2012
  5. 5. Goals of this talk<a lot>▪  Demonstrate deployable, real-world solutions▪  Demonstrate how coding plays a crucial role in this ▪  AppSec, InfoSec, CorpSec, etc▪  Have you walk away with actionable data
  6. 6. Our culturemove fast and break things
  7. 7. Move fast and break things▪  Emphasis is placed on ‘moving fast’ J▪  The ability to quickly iterate provides security benefits▪  Archaic security models and thinking are not welcome
  8. 8. How we do this
  9. 9. (1) Code Reviews▪  Code commits require peer reviews (we use Phabricator)▪  Reviewers are assigned by: ▪  (a) the author manually ▪  (b) git blame (who touched this last) ▪  (c) Herald (grep-based rules)
  10. 10. Code Review Benefits▪  Code quality (why it was deployed)▪  Culture ▪  you are not your code ▪  feedback loops should be beneficial, expected, and fun ---->▪  Security
  11. 11. (2) Herald (grep-based rules)(Note: this is a feature in Phabricator)
  12. 12. Herald - Details▪  We have alerts for: 1.  Modifications of security libraries 2.  Disabling of CSRF/XSS validation 3.  ‘Access-Control-Allow-*’, etc 4.  New URI endpoints▪  TLDR: we get notified of ▪  Potential security bugs ▪  New endpoints or projects
  13. 13. (3) Lint▪  Herald rules work well, but there are scalability problems ▪  count(engineers) > count(security engineers)▪  Solution: Lint during development and code review
  14. 14. (4) Bug Bounty▪  100+ bugs confirmed and fixed▪  Resultsin ~24/7 security auditing (not a replacement for reviews/audits)▪  New hires (intern/full-time/contractor)▪  Enables and rewards security researchers▪  Notas easy to manage as you might think (locale, personalities, photoshop’d bugs, …)
  15. 15. (5) Security “Frameworks”▪  Arguably the most important (secure by default)▪  Examples: ▪  GET requests are not allowed to make state change ▪  Encoding/escaping is handled for you (XHP [1]) ▪  CSRF/X-Frame-Options/etc are enabled by default▪  Attempts at overriding these defaults result in lint warnings and alerting (Herald) ▪  Real-world, in-time education and prevention (RE @daveaitel)[1]
  16. 16. Our Focus & Projects (AppSec)
  17. 17. Untrusted Requests2012 focus▪  Untrusted requests = unintended user actions initiated by an attacker▪  Goal: detect and block ‘untrusted requests’, regardless of vector
  18. 18. First, lets look at URI signing
  19. 19. URI signingIntegrity▪  URI signing is nothing new (HMAC) ▪… ▪  sig ~= hash_hmac(‘sha256’, $_GET, $secret)▪  Done to prevent tampering (block action is taken)▪  Hash is computed and verified on the server
  20. 20. Limitations of URI signing▪  What about AJAX flows that take user input?
  21. 21. AJAX URI Signing
  22. 22. OverviewURI “signing” for AJAX requests▪  We want to detect ‘untrusted requests’ to our async endpoints▪  So, we send a token w/each AJAX request that is: a)  user-bound and time-bound b)  lightly-bound to HTTP POST data c)  Dynamically generated on the client (JS)
  23. 23. Basic Details1.  Write a JS abstraction for AJAX requests ▪  Beneficial for numerous non-security reasons (abstract away browser quirks and impl details)2.  Append a lightweight token in the AJAX send() wrapper ▪  Simple example: time() + user + URI.implodePostQuery().length ▪  req.append(token).send()3.  Validate and log (do not block) invalid tokens
  24. 24. Wait a second….▪  The token has no real integrity…▪  The token is constructed via JS…▪  Can’t the attacker construct the token?!?▪  Yes, but our aim isn’t 100% integrity.▪  Our aim is a configurable, light-weight, performant, stealthy signal
  25. 25. Wait a second….▪  You won’t be blocking invalid tokens?▪  Why:block-action’s provide an immediate, change-provoking response to the attacker▪  We want a good quality signal that will (a) alert us of attacks (b) help us tune our existing systems
  26. 26. Features▪  Killswitch (on/off)▪  Per-URI configuration (on/off)▪  Block-mode for emergency attacks▪  Threshold alerting▪  Easily modifiable ‘token’ algorithm (iterate when discovered)
  27. 27. ResultsA great signal for detecting ‘untrusted requests’
  28. 28. Origin header (AppSec)
  29. 29. Origin HeaderContext▪  We started seeing ‘untrusted requests’ w/valid CSRF tokens▪  The AJAX URI tokens were invalid▪  The Referer was blank▪  Where were these requests really coming from?▪  Did we have a CSRF token leak somewhere?
  30. 30. Origin HeaderDetails▪  Syntax: Origin: <scheme>:<host>:<protocol>▪  Request header that designates where the request came from ▪  Sent by browsers when certain conditions are met▪  It’s a bit stickier than the Referer header [1] [2] [3] [4] [1] [2] [3] [4]
  31. 31. Origin HeaderBrowser implementations (09/28/2012) API (cross origin) Chrome Firefox Internet Explorer 10 XHR GET XHR POST <form> GET <form> POST <script> <iframe> CSS (external) <embed>/<object>** is the goal, not the current truth
  32. 32. Origin Header (Goal) additional coverage CSRF Origin token header additional context
  33. 33. Origin Header (Implementation)1.  Define a whitelist of approved origins2.  Validate incoming origin’s during CSRF validation3.  Block and log untrusted requests4.  Monitor for spikes in total volume or per-origin volume ▪  via internal tools/sql or something like Etsy’s statsd [1][1]
  34. 34. Origin Header (Results)violations with a *valid* CSRF token youtube google twitter ebay reddit 6928 4134 762 165 107October 4th, 2012 (blocked violations)
  35. 35. Origin Header (Results Cont’d) VPN endpoints Active CSRF holes (origin = vpn url) (none, yet)Conclusion: A great signal for detecting ‘untrusted requests’
  36. 36. XSS (AppSec)
  37. 37. XSS (cross-site scripting)▪  Another cause of ‘untrusted requests’ ▪  Real-world exploitation usually relies on propagation ($$$) (chat, status updates, …)▪  We’renot covering how you should “sanitize your [in/out]puts” ----------->▪  We’re covering detection and blocking J
  38. 38. Enter browser XSS auditors…
  39. 39. Browser XSS protections▪  By default, IE8+ attempts to de-fang/cleanup reflective XSS attacks▪  This led to UXSS exploits in 2009/2010 [1][2]▪  There were also false positives (UEX concerns)▪  2010 conclusion: disable IE’s XSS filter via ‘X-XSS-Protection: 0’[1][2]
  40. 40. But it’s 2012…?
  41. 41. X-XSS-Protection (http response header)▪  X-XSS-Protection: {0 | 1 | 1; mode=block} ▪  ‘0’ => disable the browser’s XSS auditor Chrome 4+ IE8+ WIP [1] ▪  ‘1’ => de-fang (IE) / block suspicious markup (Chrome) ▪  This is the enabled default for Chrome and IE ▪  ‘1; mode=block’ => do a full-page block ▪  Alleviates future UXSS concerns and gives you attack coverage[1]
  42. 42. Seems simple enoughtime to start blocking
  43. 43. Deployment (X-XSS-Protection)▪  No phone home for violations (deployment nightmare)▪  How we reduced deployment risk: 1.  Internal wiki; ensured the header name, header values, and console errors would come up in triage searches 2.  Repeat for our public wiki w/a contact form [1] 3.  Gatekeeper (gradual rollout)▪  Result: We’re serving ‘1; mode=block’ ▪  We’re blocking most XSS and any potential UXSS filter bugs [1]
  44. 44. XSS cont’d<detection>
  45. 45. XSS detection mechanisms1.  Override JS’ native alert() [1] (FB = deprecated now, etsy = do it offline by replaying suspected XSS attacks against NodeJS [2])2.  Deploy Content Security Policy (CSP) in monitor mode 1.  Define your domain whitelist & allow inline scripts and eval() 2.  You now receive alerts for XSS attacks using externally referenced JS J[1][2]
  46. 46. Framing attacks (AppSec)
  47. 47. Framing attacks▪  Our users were coerced into typing, pasting, or dragging their CSRF token in a “CAPTCHA” or “verification” box▪  Attackers made ‘untrusted requests’ using these CSRF tokens
  48. 48. How it works
  49. 49. Cross-origin drag-n-drop attack▪  Developed by Nafeez Ahamed (@skeptic_fx)▪  Improvements by Krzysztof Kotowicz (@kkotowicz) Drag the ball into the trash[1][2]
  50. 50. PoC http://evil.tld/slurp_dom.php view-source:https://www.facebook.comTwo components at play here:1.  view-source: URI2.  cross-domain drag-n-drop capabilities
  51. 51. view-source (component 1)▪  view-source exposes sensitive artifacts (csrf token, userid, …)▪  view-source bypasses framebusting JS▪  view-source honors X-Frame-Options Browser view-source (support) view-source (iframe) Firefox Chrome Safari Internet Explorer (not since IE6) Opera
  52. 52. cross-origin drag-n-drop (component 2)▪  Risk is dependent on impl, ‘is enabled’ default, and view-source support Browser cross-origin drag-n-drop Fix/Details Firefox 07/17/12 - Mozilla14+ [1] Chrome 11/12/10 [2] Safari 11/12/10 [2] Internet Explorer * MS11-057 (per zone control) [3] * uses FixIt (they were in the wrong order) Opera * .allowTargetOrigin() model [4] [1] [2] [3] [4]
  53. 53. Solution?
  54. 54. X-Frame-Options (http response header)▪  X-Frame-Options: {value} ▪  DENY => no one can iframe Chrome 4.1+ IE8+ FFv3.6.9+ Opera 10.50 Safari 4+ ▪  SAMEORIGIN => only same origin Hint: Do not use <META> to serve the header, its ignored▪  This protects against: ▪  Cross-origin drag-n-drop attacks ▪  view-source + iframe attempts ▪  Clickjacking
  55. 55. X-Frame-Options (XFO)implementation
  56. 56. XFO - Scope▪  FB Goal: Serve DENY vs. SAMEORIGIN ▪  Limit current (and future) risk▪  Issue: We do intentional iframing ▪ vs. ▪  This impacts DENY and SAMEORIGIN
  57. 57. Solution for intentional framing▪  A user-bound, time-bound token1.  Compute the token2.  Store it in JS global space (or your JS data container)3.  Append to request parameters for iframe endpoints4.  Validate the token server-side
  58. 58. Conclusions1.  Use X-Frame-Options (XFO) (> JS Framebusting)2.  Use user+time bound tokens if you can’t3.  w/o XFO, attackers can trick users to give up their CSRF tokens ▪  Firefox still supports view-source + iframe(diff_origin) ▪  ^ drag-n-drop doesn’t work, but you can ask users to type/copy it4.  w/o XFO, attackers can do cross-origin drag-n-drop on IE ▪  limited to text, images, links & view-source is not supported
  59. 59. Cookie Monster (AppSec)
  60. 60. Cookie MonsterGoal: Identify attacks that create new, untrusted cookies“I’ve sent X untrusted requests, wait Y mins before starting again”
  61. 61. When looking at the logs…
  62. 62. Results (CookieMonster)▪  A lot of violations…▪  This has helped us find a good amount of badness▪  Our user’s requests are now faster and we save some CPUWe started doing this for local/session storage too J
  63. 63. Corporate Security<context switch/>
  64. 64. Why ProdSec & Corp/InfoSec?Background▪  Overlapexists in terms of solutions (rate-limiting, logging, alerting, auth, …)▪  Opportunities exist for code and infrastructure reuse▪  Combining both worlds increases capability, stability, and scalability Wikimedia Commons (© Vincent Jones)▪  No need to reinvent the wheel… work with each other
  65. 65. Lets start off with some projects
  66. 66. Mac host-based IDS (CorpSec)
  67. 67. Mac host-based IDSYou’re on your own▪  Very few tools exist▪  Mac adoption is on the rise▪  Mac malware (APT or otherwise) is on the rise (Flashback, MacControl, Revir/Imuler, Sadpab) [1]▪  Maybe we can hack up a quick tool? J[1]
  68. 68. Enter BigMac
  69. 69. BigMacEasy, cheap, and does it’s job well▪  Fitting that we named our tool this J▪  Checks most basic persistence options …/LaunchAgents/ …/LaunchDaemons/ /Library/StartupItems/ /Library/ScriptingAdditions …/loginwindow.plist Image from Wikimedia Commons (© Kici) DYLD_INSERT_LIBRARIES LSEnvironment … *Not intended to catch rootkits; this is intended to catch the basics
  70. 70. BigMac - Logging▪  Entries are encoded and sent to our secure logging endpoint▪  Our logging endpoint saves the results to a DB ▪  entry = {name, size, permissions, …}▪  We now have reactive capabilities J SELECT * FROM logs where launch_agents like ‘%PubSabAgent%’ [1]▪  Butwe want proactive capabilities too… (a Bigmac w/o special sauce, lettuce, and cheese?!?)[1]
  71. 71. BigMac – ‘proactive’ processing▪  We want to identify unknown and untrusted entries ▪  Ex: Only one person has entry XYZ▪  Steps 1.  Whitelist trusted entries for each persistence option 2.  Blacklist known bad (ex’s: %checkvir%, ‘%PubSabAgent, %FolderActionxsl%’) 3.  Surface unknowns for analyst classification 4.  Create real-time handlers on the logging endpoint 5.  Create post-processing handlers to run as a cron-like job
  72. 72. BigMac – Results▪  The amount of logs is relatively low▪  You have increased visibility▪  You can proactively and reactively find bad▪  We used prod code and infrastructure▪  It works well for us; give it a try
  73. 73. TLS MITM Detection (CorpSec)
  74. 74. TLS MITM DetectionBackground▪  Great for detecting attacks against our employees (hotel/home/etc)▪  Greatfor detecting attacks against our users too (large-scale or targeted)
  75. 75. TLS HandshakeWe want the server’s key and certificate data Client Hello Server Hello Server Certificate Server KeyExchange Client Certificate Request Server Hello Done … …
  76. 76. TLS MITM Detection▪  Flash can give you this data J▪  Steps: 1.  Send ClientHello via raw Socket 2.  Parse the response (certificate) 3.  POST the results via URLLoader to your logging endpoint▪  Great work by our intern David Huang (CMU), paper coming soon J (
  77. 77. Difficulties (MITM Detection)▪  “…asocket policy file is required for any socket connection. That is, a socket policy file on the target host is required no matter what port you are connecting to, and is required even if you are connecting to a port on the same host that is serving the SWF file.” [1]▪  Ugh, more work… blame Peleus (speaking Sunday J)[1][2]
  78. 78. Setup (MITM Detection) 10 servers socket policy logging / web ui For policy requests PHP logging endpoint (see appendix) (dst_port 843) PHP Web UI
  79. 79. Results (production)▪  Benign things like security products (AV, DLP, …) Figure: Kaspersky’s AV client Figure: Our web UI for viewing violations
  80. 80. Results (production)▪  MITM attacks▪  You will find some interesting stuff; deploy this!
  81. 81. Java (CorpSec)
  82. 82. Background (Java) 0.2% of websites use it as a client-side technology [1] ~75% of users browse with it enabled 2 million exploit detections every 3 months (M$) [2][1][2]
  83. 83. Solution? (Java)▪  Remove it entirely ▪  Not always viable (development)▪  Remove/disable it in the web context ▪  Not always viable (intranet apps)▪  Ensure it’s always up to date ▪  Not always viable (IT upgrade SLA, 0day attacks, …)▪  Run EMET? ▪  Not always viable (CVE-2012-4681, Type confusion, …)
  84. 84. Solution (Java)1.  Look for outbound *.jar requests in your logs ▪  L7 firewall/Netwitness/Solera/Splunk/<whatever>2.  Aggregate by domain and hit_count ▪  SQL: select dst_hostname, count(*) … ▪  Splunk: | top dst_hostname3.  Iterate on whitelisting “trusted” domains ▪,,,, …
  85. 85. Solution Results (Java) ▪  ~25 unique domains/day (90%+ whitelisted) ▪  The domain name is usually signal enough ▪  You’re alerting on real exploitation ▪  Blackhole serves you exploits that you’re actually vulnerable to… [1] ▪  You get coverage for all assets on your network[1]
  86. 86. Finding IOCs(indicators of compromise)
  87. 87. really high-level overview(of our implementation) alerts correlation & context events Appliance X rules framework Appliance Y raw logs
  88. 88. Events Wikipedia commons; © Theornamentalist▪  You want your analysts to see events that are “just right” (e.g. correlation and context; for another talk)▪  Most of us have appliances that attempt to generate these events▪  Very few of us generate our own events L (from raw logs or from appliance logs)
  89. 89. Enter SecRules frameworklets generate events
  90. 90. SecRules framework▪  Core logic is abstracted and components are modular ▪  Datasources: ->queryHive(), ->queryMySQL(), ->queryApplianceX()… ▪  Notifications: ->notifySMS(), ->notifyEmail(), ->pingAgain(), …▪  abstract functions enforce structure ▪  getAssignee(), getCCs(), getAlertDesc($alert_obj), …▪  Analysts focus on the “when to generate an event” logic
  91. 91. SecRules framework (2)▪  Rules are configured to run hourly, daily, or weekly ▪  Depends on how much data you need to make a decision ▪  We also made real-time handlers▪  Uses nearly 100% of preexisting product infrastructure (lots of time saved in terms of coding and hardware config/deployment)▪  You should build something like this (just making sure you have logs when you are notified of a breach is sooo 2010)
  92. 92. Lateral movement (CorpSec)
  93. 93. These techniques are actively used by attackers This is why we’re covering mitigation and detection
  94. 94. Lateral movement (auth) (high level)▪  We’re covering this in two phases 1.  Phase 1: when your M$ password is ~ a hash or token equivalent ▪  Hashes are crackable and replayable (pass-the-hash) ▪  Tokens are replayable 2.  Phase 2: when your M$ password is stored and encrypted ▪  Encrypted passwords can be decrypted▪  Each phase will have it’s own solutions slide
  95. 95. Phase 1: hashes and tokenspuff puff pass
  96. 96. [NT]LM Hashes – Overview▪  [NT]LM hashes exist on disk and in memory and are easily dumped ▪  Ex LM: 855c3697d9979e78ac404c4ba2c66533 ▪  Ex NTLM: $NT$7f8fe03093cc84b267b109625f6bbf4b▪  LM hashes can be cracked in minutes ▪  Vista+ doesn’t store the LM on disk, but it stores it in memory L▪  Multi-GPU support is making NTLM cracking faster (hashcat)▪  LM/NTLM hashes are static and replayable ▪  Ex: psexec X.X.X.X -u mimeframe –p <hash> …
  97. 97. Solutions (LM Hashes)▪  Upgrade to Vista+ (no LM hashes on disk) ▪  You can do manually for older OS’ [1]▪  Use 15+ character passwords for domain admins / priv accounts ▪  Prevents LM (not NTLM) hash creation in memory [2] ▪  Actually enforceable in Win2k8 environments [3] (win2k8 allows for multiple, fine-grained password policies)[1];EN-US;q299656[2][3]
  98. 98. Domain Cached Credentials (DCC)▪  DCC’s allows domain users to log on even if DC’s are unreachable▪  DCC’s can be dumped from the disk or memory▪  DCC’s must be cracked before use in pass-the-hash attacks [1] [2]
  99. 99. Conclusions (DCC’s)▪  Upgrade to Vista+ x64 if possible ▪  Stronger hashes and less x64 support in public tools os algorithm crack-time XP h1 = MD4(user+ MD4(pass)) 0 -> 81 days Vista+ h2 = PBKDF2_SHA1 ( 0 -> ? 10240 /* iterations */, h1, user) (intelligent brute forcing)▪  Disable (or reduce #) cached credentials [1] ▪  See CachedLogonsCount: ▪  Win2k8 = 25, XP/Win7/… = 10 [2] [1] [2]
  100. 100. Access Tokens▪  Reside in memory, used for future auth requests (~SSO)▪  Can be dumped and replayed (it’s not an LM/NTLM hash)▪  Interactive logon (RDP/RunAs/PsExec –u) creates: ▪  Delegate tokens: local and remote capabilities ▪  Impersonation tokens: local (privilege escalation)[1][2]
  101. 101. Solutions (Access Tokens)▪  Upgrade to Vista+ (if possible) ▪  Base processes (explorer.exe+) are launched with a filterered standard user token versus the admin token [1] ▪  Incognito doesn’t handle deny-only SIDs well? [2][3]▪  Use local admin vs. domain admin when remote’ing (when possible)▪  Disable delegation tokens for domain admins / priv accounts* [5] [1] [2] [3] [4] [5]
  102. 102. Phase 2: encrypted passwordsthe crown jewels
  103. 103. LSA Secrets▪  HKLM/Security/Policy/Secrets▪  Passwords are encrypted and stored here if: 1.  Services running under an account (not Local Service, Local System, or Network Service) 2.  Autologon is enabled [1]▪  The passwords can be easily decrypted [2] [1] [2]
  104. 104. Conclusions (LSA Secrets)▪  Audit (and remove) services running under domain accounts ▪  These can usually run as Local System or as the current user▪  Disable interactive logon for service accounts (where possible)▪  Block autologon (GPO to control AutoAdminLogon)▪  Upgrade to Win7 if possible ▪  Stronger password encryption is used [1] [1]
  105. 105. Security Support Providers (SSP)▪  TsPkg (SSP) provides SSO support for remote sessions [1] ▪  Defaultly enabled in Vista+▪  Wdigest (SSP) provides digest auth support [2] ▪  Defaultly enabled in XP+▪  SSP’s store decryptable interactive logon pw’s in memory [3] ▪  RDP, RunAs, PSExec –u, …[1][2][2][3][3]
  106. 106. Solutions (SSP’s)▪  You can remove TsPkg if you don’t use remote SSO functionality ▪  HKLMSYSTEMCurrentControlSetControlLsa -> Security Packages▪  You can remove Wdigest if you don’t use digest authentication ▪  <same location> If you’re using digest auth, you have other problems.. (ex: it requires that you store pw’s via reversible encryption) [1]▪  But, the above is fruitless because other often required SSP’s (like Kerberos) store it and it can be dumped[1]
  107. 107. Solutions (SSP’s)▪  So…▪  Educate your admins that closing out of an RDP session results in their passwords staying in memory ▪  Only “Log Off” actually purges the credentials from memory [1]▪  For cases where they may forget, you can use a GPO to specify the max amount of time that a disconnected session is kept active [2]▪  Traditional advice applies as well (use the least privileged account to get the task done, RBAC, …)[1][2]
  108. 108. Tool Chart Dump Dump Dump Access Tool [NT]LM [NT]LM cached PTH LSA Secrets SSP Kerberos (reg/disk) (memory) Tokens creds Mimikatz (x64, w7/2k8) Incognito WCE (x64, w7/2k8) PTH Suite fgdump (x64, w7) gsecdump (x64, w7/2k8)To see a comprehensive list, see Bernardo Damele’s spreadsheet:
  109. 109. Detection example(since we covered mitigation)
  110. 110. Pass-the-hash detection 1.  Create a domain account that looks enticing 2.  With this account, use your vulnerability scanner to ‘interactively’ logon to a set of assets 3.  Schedule this at a static time/day 4.  Using your logs, alert on auth requests occurring outside of that static window▪  Note: Not a replacement for jumphosts/containment/rbac/etc, it supplements.
  111. 111. That’s it.Questions? Bugs? Comments?Twitter: @mimeframe
  112. 112. Appendix
  113. 113. Socket Policy<?xml version="1.0"?>!<!DOCTYPE cross-domain-policy SYSTEM
 "">!<cross-domain-policy>! <site-control permitted-cross-domain-policies="master-only"/>! <allow-access-from domain="" to-ports="443" />!</cross-domain-policy>!