4. About Me
@mimeframe
▪ Started as a traditional developer
▪ Movedon to Application Security
(coding + pentesting)
▪ Started
doing some
Corporate Security in H2 2012
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
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
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. Code Review Benefits
▪ Code quality (why it was deployed)
▪ Culture
▪ you are not your code
▪ feedback loops should be
beneficial, expected, and fun ---->
▪ Security
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. (3) Lint
▪ Herald rules work well, but there are scalability problems
▪ count(engineers) > count(security engineers)
▪ Solution: Lint during development and code review
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. (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] https://github.com/facebook/xhp
19. URI signing
Integrity
▪ URI signing is nothing new (HMAC)
▪ http://fb.com/?amount=5.00&user_id=x&sig=bd67k9…
▪ sig ~= hash_hmac(‘sha256’, $_GET, $secret)
▪ Done to prevent tampering (block action is taken)
▪ Hash is computed and verified on the server
22. Overview
URI “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. Basic Details
1. 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. 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. 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. Features
▪ Killswitch (on/off)
▪ Per-URI configuration (on/off)
▪ Block-mode for emergency attacks
▪ Threshold alerting
▪ Easily
modifiable ‘token’ algorithm
(iterate when discovered)
29. Origin Header
Context
▪ 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. Origin Header
Details
▪ 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] tools.ietf.org/html/draft-abarth-origin
[2] http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method
[3] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLRequestHeader.html
[4] http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-and-profit.html
31. Origin Header
Browser 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>
** wiki.mozilla.org/Security/Origin is the goal, not the current truth
33. Origin Header (Implementation)
1. Define a whitelist of approved origins
2. Validate incoming origin’s during CSRF validation
3. Block and log untrusted requests
4. Monitor for spikes in total volume or per-origin volume
▪ via internal tools/sql or something like Etsy’s statsd [1]
[1] https://github.com/etsy/statsd#readme
34. Origin Header (Results)
violations with a *valid* CSRF token youtube google twitter
ebay reddit
6928
4134
762
165 107
October 4th, 2012 (blocked violations)
35. Origin Header (Results Cont’d)
VPN endpoints Active CSRF holes
(origin = vpn url) (none, yet)
Conclusion: A great signal for detecting ‘untrusted requests’
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
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] http://blogs.technet.com/b/msrc/archive/2010/04/19/guidance-on-internet-explorer-xss-filter.aspx
[2] https://media.blackhat.com/bh-eu-10/presentations/Lindsay_Nava/BlackHat-EU-2010-Lindsay-Nava-IE8-XSS-Filters-slides.pdf
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] https://www.facebook.com/help/?faq=242017349201874
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
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] http://blog.skepticfx.com/2011/09/facebook-graph-api-access-token.html
[2] http://blog.kotowicz.net/2012/08/how-facebook-lacked-x-frame-options-and.html
50. PoC
http://evil.tld/slurp_dom.php
view-source:https://www.facebook.com
Two components at play here:
1. view-source: URI
2. cross-domain drag-n-drop capabilities
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. 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] https://bugzilla.mozilla.org/show_bug.cgi?id=605991
[2] http://trac.webkit.org/changeset/71925
[3] http://support.microsoft.com/kb/2581921
[4] http://dev.opera.com/articles/view/drag-and-drop/
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
56. XFO - Scope
▪ FB Goal: Serve DENY vs. SAMEORIGIN
▪ Limit current (and future) risk
▪ Issue: We do intentional iframing
▪ upload.facebook.com vs. facebook.com
▪ This impacts DENY and SAMEORIGIN
57. Solution for intentional framing
▪ A user-bound, time-bound token
1. Compute the token
2. Store it in JS global space
(or your JS data container)
3. Append to request parameters
for iframe endpoints
4. Validate the token server-side
58. Conclusions
1. Use X-Frame-Options (XFO) (> JS Framebusting)
2. Use user+time bound tokens if you can’t
3. 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 it
4. w/o XFO, attackers can do cross-origin drag-n-drop on IE
▪ limited to text, images, links & view-source is not supported
60. Cookie Monster
Goal: Identify attacks that create new, untrusted facebook.com cookies
“I’ve sent X untrusted requests, wait Y mins before starting again”
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 CPU
We started doing this for local/session storage too J
67. Mac host-based IDS
You’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] https://citizenlab.org/2012/10/citizen-lab-senior-security-analyst-seth-hardy-at-sector-conference/
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] http://www.f-secure.com/v-descs/backdoor_osx_sabpab_a.shtml
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. 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
74. TLS MITM Detection
Background
▪ Great
for detecting attacks against our employees
(hotel/home/etc)
▪ Greatfor detecting attacks against our users too
(large-scale or targeted)
75. TLS Handshake
We want the server’s key and certificate data
Client Hello
Server Hello
Server Certificate
Server KeyExchange
Client Certificate
Request
Server Hello Done
…
…
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 (http://www.linshunghuang.com/)
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] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html
[2] http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
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. Results (production)
▪ Benign things like security products (AV, DLP, …)
Figure: Kaspersky’s AV client
Figure: Our web UI for viewing violations
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] http://w3techs.com/technologies/overview/client_side_language/all
[2] http://www.microsoft.com/security/sir/default.aspx
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. 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_hostname
3. Iterate on whitelisting “trusted” domains
▪ maven.org, sourceforge.net, eclipse.org, apache.org, …
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] http://malware.dontneedcoffee.com/2012/09/blackhole2.0.html
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. 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)
93. These techniques are actively used by attackers
This is why we’re covering mitigation and detection
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
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. 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] http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656
[2] http://computer-forensics.sans.org/blog/2012/03/09/protecting-privileged-domain-accounts-disabling-encrypted-passwords
[3] http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx
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] http://openwall.info/wiki/john/MSCash2
[2] http://www.passcape.com/domain_cached_passwords
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] http://support.microsoft.com/kb/172931
[2] http://support.microsoft.com/kb/911605
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] http://blogs.technet.com/b/askds/archive/2008/01/11/what-s-in-a-token-part-2-impersonation.aspx
[2] http://computer-forensics.sans.org/blog/2012/03/21/protecting-privileged-domain-accounts-access-tokens
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] http://msdn.microsoft.com/en-us/library/bb756993.aspx
[2] http://labs.mwrinfosecurity.com/blog/2012/07/18/incognito-v2-0-released/
[3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379596(v=vs.85).aspx
[4] http://computer-forensics.sans.org/blog/2012/03/21/protecting-privileged-domain-accounts-access-tokens
[5] http://technet.microsoft.com/en-us/library/cc780217(WS.10).aspx
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] http://technet.microsoft.com/en-us/sysinternals/bb963905.aspx
[2] http://www.passcape.com/index.php?section=docsys&cmd=details&id=23
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] http://www.passcape.com/index.php?section=docsys&cmd=details&id=23
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] http://technet.microsoft.com/library/cc772108.aspx
[2] http://technet.microsoft.com/en-us/library/cc738318(v=ws.10).aspx
[2] http://technet.microsoft.com/en-us/library/cc778868(v=ws.10).aspx
[3] http://blog.gentilkiwi.com/securite/pass-the-pass
[3] http://blog.gentilkiwi.com/securite/re-pass-the-pass
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] http://technet.microsoft.com/en-us/library/cc738318(v=ws.10).aspx
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] http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf
[2] http://technet.microsoft.com/en-us/library/cc753112(v=ws.10).aspx
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: http://bit.ly/uZWdHf
(from http://bernardodamele.blogspot.com/)
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.