Matt Nelson, SpecterOps
A persistent "enlightened" attacker will invest the required resources to bypass any and all security features that might stand between them and their objective, regardless if these features are guaranteed to be serviced as security boundaries or not. This includes researching and developing attacks against Windows security features that may impose a hurdle in their attack chain. This talk will outline recent research into features such as User Account Control (UAC), the Antimalware Scan Interface (AMSI) and Device Guard and how these bypasses are useful to attackers in an operational context.
Some examples include:
UAC: If an attacker compromises a user that is running as a split-token administrator, bypassing UAC is required in order to perform any administrative actions; such as dumping credentials from memory.
AMSI: With in-memory attacks becoming more prevalent via scripting languages, AMSI is the next logical step to facilitate detection. An attacker will need to bypass AMSI in order to safely operate in memory when using PowerShell, VBScript, or JScript.
Device Guard: As organizations begin to consider whitelisting solutions, an attacker is required to adapt and develop a bypass to these technologies. One such solution is Device Guard, which can be used to heavily restrict what is allowed to execute on the system. In order to accomplish their objective, an attacker would need to bypass User Mode Code Integrity (UMCI). Such research can find novel ways to execute code in ways that are not likely to be detected.
I will also cover some of the fixes that have been implemented in newer versions of the Windows Operating System. Fixing these bypasses will not only make Windows safer, but it will begin to disrupt attackers by raising the cost associated with successfully executing an attack.
Deploying a Shadow Threat Intel Capability at Thotcon on May 6, 2016
Similar to BlueHat v17 || “_____ Is Not a Security Boundary." Things I Have Learned and Things That Have Gotten Better from Researching Microsoft Software
Similar to BlueHat v17 || “_____ Is Not a Security Boundary." Things I Have Learned and Things That Have Gotten Better from Researching Microsoft Software (20)
08448380779 Call Girls In Friends Colony Women Seeking Men
BlueHat v17 || “_____ Is Not a Security Boundary." Things I Have Learned and Things That Have Gotten Better from Researching Microsoft Software
1. “_____ Is Not a Security
Boundary."
Things I Have Learned and Things That
Have Gotten Better from Researching
Microsoft Software
Matt Nelson (@enigma0x3)
SpecterOps
3. Intro
◦ Matt Nelson (@enigma0x3)
▫ Job: Security Researcher & Red Teamer
@SpecterOps
▫ Trainer: BlackHat, AT:RTO
▫ Blog: enigma0x3.net
▫ Speaker: Various BSides, DerbyCon,
ShmooCon, WWHF, OPCDE
4. Disclaimer
◦ The following presentation is from the
perspective of an external security
researcher.
◦ Opinions are derived from first-hand
experience reporting atypical
abuse/bypasses.
6. Say What?
◦ My day job is to attack massive
organizations.
◦ I face the same hurdles that the bad
guys do.
▫ I also innovate around those
hurdles… just like the bad guys do.
7. The Problem
◦ People rely on vendors to protect them.
▫ This very often includes organizations as well…
◦ This works with serviceable bugs
▫ Not so well with security “feature” bypasses
◦ Organizations are confused on what they
need to fix and what is automatically fixed.
8. The Problem
◦ Most organizations lack basic security
posture
▫ Patching, logging, etc.
◦ Ideal scenario:
▫ Organizations use things like Application
Whitelisting, Command Line Logging, Network
Segmentation
10. The Problem
◦ Researchers face a similar issue
▫ Is this new thing I found something I should
report?
◦ Some researchers have gotten “This isn’t
a boundary” responses.
▫ This can cause hesitation
12. Security Boundary?
“What’s a security boundary? It’s a wall
through which code and data can’t pass
without the authorization of a security
policy.“ - Mark Russinovich
https://blogs.technet.microsoft.com/markrussinovich/2007/02/12/psexec-user-
account-control-and-security-boundaries/
13. Implications?
◦ I hate the phrase “Security Boundary”
◦ Historically, the deciding factor if a fix is
issued or not.
◦ Just because it isn't a boundary, doesn’t
mean it shouldn't be fixed.
14. Implications?
◦ This has gotten much better as of late
◦ We now have “Defense in Depth” fixes
▫ Pushed out Patch Tuesday or added into new Windows
builds
◦ All the while, attackers don’t care and use
everything they can in the wild.
15. “Attackers don’t care
about security
boundaries” - Jessica
Payne at MSIgniteNZ
(@jepayneMSFT)
https://twitter.com/jepayneMSFT/status/791702594309677056
16. What Does This Mean?
◦ “Security Boundaries” == touchy subject
▫ Not cut & dry what is/isn’t
◦ Security Researchers get grumpy when
hearing “Technology X is not a security
boundary”
◦ Attackers. Don’t. Care.
17. Look At It This Way...
◦ Economics
◦ Is a security feature an impediment to
an attacker? If so, investing in a bypass
is worth it.
◦ Security Boundary or not, raising the
cost for attackers is a win!
19. Outlook Forms/Rules
◦ Outlook Rule/Form attacks
▫ Remotely sync malicious Outlook rules or forms
(with scripts) for code-execution
▫ Discovered by @silentbreaksec
■ https://silentbreaksecurity.com/malicious-outlook-rules/
▫ Weaponized with Ruler from SensePost
◦ Feature of Office, not a vulnerability
▫ Fixed in KB4011091!
20. OLE
◦ Object Linking and Embedding
▫ Attackers’ favorite for smuggling in malicious
payloads via Office documents
◦ This is what I use on almost every
assessment
◦ Again, just a feature.
▫ So, not worthy of a fix, right?
22. Office 2016
◦ This is what ignoring “boundaries” and
raising the cost for attackers looks like.
◦ These 2 attacks are feature abuse only
▫ No bug is abused
▫ Yet, it was still fixed!
23. Protected View
◦ Designed to prevent various Office
components from being used when the doc
is from the internet
▫ Prevents automatic exploitation
◦ Most Office applications/file formats are
enrolled
▫ Except OneNote, Publisher and Excel
SLK files
24. Protected View
◦ Typically patched
▫ CVE-2016-3279 for example (.XLA files not
enrolled)
◦ Why are Publisher/OneNote/SLK files not?
▫ Mostly the same functionality
▫ I have used these formats to compromise clients
from the internet.
25. Protected View: DDE
◦ Dynamic Data Exchange
▫ Allows command execution
▫ It is a feature!
◦ Widely used by ITW malware, such as Locky
◦ The Response?
32. Anti-Malware Scan Interface
◦ AMSI bypass == AV-free code-execution
◦ Many exist
◦ Do we report these? Or do we save time
and publically disclose with mitigation
options?
▫ Attack service can get overwhelming...
33. Example: COM Hijacking
◦ Hijacks the AMSI COM server via the
registry
◦ Process calls CoCreateInstance() to
instantiate the AMSI COM component
◦ Calling process == Medium integrity level
▫ This results in searching HKCU for the COM
server
36. Anti-Malware Scan Interface
◦ Is this a “boundary”?
▫ No.
◦ Is this a hurdle (some) attackers have to
jump over?
▫ Yes. A massive one.
◦ Do security vendors take a dependency
on AMSI?
▫ Yes.
37. Anti-Malware Scan Interface
◦ This is where things get weird.
▫ Vendors can’t fix everything
◦ How do you defend against a process
that has full access to its own memory
space?
◦ People need to defend themselves…
▫ Constrained Language Mode, Application
Whitelisting, etc.
39. Example: AMSI DLL Hijack
◦ The AMSI DLL isn’t loaded from a safe
location
▫ So, it uses the default Windows search order
◦ Load scripting engine from place you
control, drop fake AMSI dll in same
directory
▫ Blogged about by @Cneelis
▫ Stop letting low-rep binaries execute/load
40.
41. Anti-Malware Scan Interface
◦ So, some of them were fixed and some
were not
▫ Why not fix all those that are possible? (is it cost?)
◦ This raises the bar for an attacker
▫ They will rely on techniques such as reflection
(PowerShell)
▫ Makes logging these bypasses (in WMF 5) trivial
◦ Combine these fixes with CLM/AWL
43. User Account Control
◦ Designed to break out administrative
and standard user rights
◦ Explicitly stated it isn’t a boundary
▫ I completely agree
◦ Yet, it is a barrier that already elevated
attackers have to get around
▫ Why not make it harder?
44. User Account Control
◦ UAC has a MASSIVE attack surface
▫ It is hard to keep up on it
◦ UAC bypasses were introduced in 2009
and didn’t start to get fixed until 2016…
▫ But things are getting better!!
45. Example: UAC Bypass via
EventVwr
◦ Eventvwr.exe starts mmc.exe with the
Event Viewer MSC snap-in
▫ How does it know what binary handles .msc files?
◦ Looks in HKCU for it :-)
◦ Hijack that, and you have the ability to
elevate without user interaction
48. Example: UAC Bypass via
EventVwr
◦ Populating that key with a binary +
parameters == code execution
◦ Malware authors ate this one up…
◦ Great example: UAC isn’t a boundary,
yet attackers care a lot about it
▫ Why not fix it?
50. Example: UAC Bypass via
EventVwr
◦ As mentioned before, things are getting
better...
http://www.winhelponline.com/blog/microsoft-fixes-eventvwr-exe-uac-bypass-exploit-windows-10-creators-update/
51. User Account Control
◦ Please keep it up!
◦ Many UAC bypasses have been fixed
▫ Many have not…
◦ We know it isn’t trivial
▫ It makes attacker life suck, though
53. Device Guard
◦ The best application whitelisting solution
to date
▫ But doesn’t scale…yet.
◦ You define what you trust in a CI policy
▫ Certificates, hashes, etc.
▫ Both Kernel and Usermode
◦ Requires a bypass to run unsigned code
that isn’t in allowed via the policy
54. Device Guard
◦ Is this a hurdle that (some) attackers
have to jump over?
▫ Absolutely
◦ Bypasses are *usually* serviced with
CVEs
◦ Some bugs are not though (.NET)
▫ Why not??
55. Device Guard
◦ The difference: Device Guard makes a
security guarantee
▫ If you have a policy deployed, code that doesn’t
conform to that policy can’t run
◦ If you break that guarantee, it gets a CVE
▫ Usually…
▫ http://www.exploit-monday.com/2017/07/bypassing-device-guard-with-dotnet-
methods.html
56. Case Study: CVE-2017-0007
◦ UMCI in Device Guard didn’t properly
validate the call when checking a file’s
integrity
◦ Normally, an unsigned file should be
prevented from executing
57.
58. Case Study: CVE-2017-0007
◦ So, what happens if we take an
embedded signature block from a
Microsoft signed file and apply it to our
own?
59.
60. Case Study: CVE-2017-0007
◦ As you can see, the digital signature of
that file did not validate
▫ This is expected
◦ Since that file is not legitimately signed
and doesn’t pass integrity checks, UMCI
should block it
▫ Right?
63. This Problem Isn’t Trivial
◦ How can you fix everything?
▫ It isn’t practical
◦ Security Feature bypasses take a very
low precedence
◦ Ideally, organizations would wake up
and use all the latest and greatest
▫ WDATP, ATA, etc.
64. Call to Action
◦ Attackers are going to bypass these
features regardless of their “fix” priority
◦ Vendors & Defensive teams will be left
scrambling to write detections for these
bypasses
◦ Perform internal research
65. Call to Action
◦ Consider raising the service bar
▫ Doesn’t have to be a CVE; DiD fixes work too!
◦ Issue fixes consistently
◦ Communicate with researchers!
▫ Explain the reason for not fixing instead of “It
just isn’t a security boundary”
66. Shoutouts
◦ Special thanks to Nate Warfield
(MSRC), Lee Holmes (Azure), Scott
Anderson (Device Guard), Tom
Gallagher (Office) & Ryan Kivett!