Thursday, January 12, 2017

Consider Application Whitelisting with Device Guard

A while back, I posted this question on Twitter.


I realize that Twitter is a difficult medium to articulate full discussions, so I wanted to engage the topic with a blog post. Over the last couple years, I have focused a fair amount of time drawing attention to the use/misuse of trusted binaries to circumvent Application Whitelisting (AW) controls.  What I have not often discussed, is the actual effectiveness that I have seen of using AW. I would like to take the time to describe what I see are the strengths of AW, and encourage organizations to consider if it might work for their environments.
The genesis of this discussion came from my colleague, Matt Graeber (@mattifestation).  We’ve spent a fair amount of time looking at this technology as it applies to Microsoft’s Device Guard. And while we agree there are bypasses, we also believe that a tool like Device Guard can dramatically reduce the attack surface and tools available to an adversary.
One question you must ask yourself and your organization is this… How long will you allow the adversary to use EXE/DLL tradecraft to persist and operate in your environment? I have heard a great deal of discussion and resistance to deploying AW. However, I personally have not heard anyone who has deployed the technology say that they regret whitelisting.
When the organization I used to work for deployed AW in 2013, it freed up our team from several tasks.  It gave us time to hunt and prepare for the more sophisticated adversary.  There are many commodity attacks and targeted attacks that take various forms.  However, one commonality they all often share is to drop an EXE or DLL to disk and execute. It is this form of attack that you can mitigate with AW.  With whitelisting, you force the adversary to retool and find new tradecraft, because unapproved, unknown binaries will not execute…
How long will you continue to perform IR and hunt C2 that is emitted from an unapproved PE file?
Here are some of the common reasons I have heard for NOT implementing AW. There are probably others, but this summarizes many.


1.     Aren’t there trivial bypasses? It doesn’t stop all attacks.
2.     Too much effort.
3.     It doesn’t scale.
I’ll take each of these and express my opinion. I’m open to dialogue on this and if I’m wrong, I would like to hear it and correct course…
1.     Aren’t there trivial bypasses to AW?  It doesn’t stop all attacks.
There are indeed ways to bypass AW.  I have found a few.  However, most of the bypasses I have demonstrated require that you have already obtained access to, and have the ability to execute commands on the target system. How does the attacker gain that privilege in the first place if you deny them arbitrary PE’s?  Most likely it will be from a memory corruption exploit in the browser or other application.  How many exploit kits, macros, or tools lead to dropping a binary and executing it?  Many do…
Most of the bypasses I have used are rooted in misplaced trust.  Often administrators of AW follow a pattern of “Scan A Gold Image & Approve Everything There”.  As Matt Graeber has pointed out to me several times, this is not the best approach.  There are far too many binaries that are included by default that can be abused. A better approach here is to explicitly trust binaries or publishers of code.  I can’t think of a single bypass that I have discovered that can’t be mitigated by the whitelist itself.  For example, use the whitelist to block regsvr32.exe or InstallUtil.exe.
Don’t fall victim to the Perfect Solution Fallacy.  The fact that AW doesn’t stop all attacks, or the fact that there are bypasses, is no reason to dismiss this as a valid defense.


“Nobody made a greater mistake than he who did nothing because he could do only a little.” –Edmund Burke
AW, in my opinion, can help you get control of software executing in your environment. It actually gives teeth to those Software Installation Policies. For example, it only takes that one person trying to find the Putty ssh client, and downloading a version with a backdoor to cause problems in your network.  For an example of how to backdoor putty see this recent post. Or use The Backdoor Factory (BDF). The thing is, it doesn’t matter that putty has a backdoor.  The original file has been altered, and will not pass the approval process for the whitelist, and the file will be denied execution. Only the approved version of putty would be able to execute in your environment.
2.     Too much effort.
Well… I’ve heard this, or some variation of it.  I understand that deploying and maintaining AW takes tremendous effort if you want to be successful.  It actually will take training multiple people to know how to make approvals and help with new deployments.
You will actually have to work very closely with your client teams, those in IT that manage the endpoints.  These partnerships can only strengthen the security team’s ability to respond to incidents. You can leverage tools like SCCM to assist with AW approvals and deployments.
The level of effort decreases over time.  Yes, there will be long hours on the front end, deploying configurations, reviewing audit logs, updating configs, etc… Some admins are so worried they will block something inadvertently; they are paralyzed to even try.  I think you’ll find out, Yes, you will block something legitimate.  Accept that this will happen, it’s a learning process, take it in steps.  Use that as an opportunity to get better.
I’ll say it again; I haven’t met anyone who has made the effort to deploy AW say that they regret the decision…
If you think it’s too hard, why not try 10% of the organization and see what you learn?
Stop telling me you aren’t doing this because it’s too hard… Anything worth doing well is going to require some effort and determination.
3.     It doesn’t scale.
Nope, it may not in your environment.  I never said it would… You must decide how far to go.  You may not get AW everywhere, but you can still win with it deployed in critical locations.  The image below describes how I think about how AW applies to different parts of your organization.  It is not a one-size-fits-all solution.  There are approaches and patterns that affect how you will deploy and configure whitelists. I think you should start with the bottom, and work your way up the stack.
Start to think of your environment in terms of how dynamic the systems are.  At the low end of the are those fixed function systems.  Think about systems similar to Automated Teller Machines.  These often only need to be able to apply patches.  New software rarely ever lands here.  Next, you have various department templates, each department will be unique, but likely fits a pattern.  Then IT Admins, who often need to install software to test or have more dynamic requirements.  At the top of the environment, are Developer workstations.  These are systems that are emitting code and testing.  I’m not saying you can’t whitelist here.  You can, I’ve done it.  But it will require some changes to build processes, code signing etc…


Yes, this is an overly simplified analogy, but I hope it helps you see where you can begin to prioritize AW deployments.
So, begin to reorient how you think about your systems to how dynamic they are.  You will have your quickest wins and earliest wins by starting at the bottom and moving your way up the hierarchy.


Conclusion


I am curious for open debate here.  If AW sucks, then let me hear why.  Tell me what your experience has been.  What would have made it work?  I’m interested in solutions that make a long term actual difference in your environment.  It is my opinion that AW works, despite some flaws.  It can dramatically reduce the attack patterns used by an adversary and increase the noise they generate.  I also believe that by implementing AW, your security teams can gain efficiencies how they operate. I am open to learn here.
If you are tasked with defending your organization, I’m asking you, as you begin to roll out Windows 10, to consider using Device Guard.


Ok, that’s all I have today.  Sincere feedback welcome.  If you think I’m wrong, I’d like to hear why...

Cheers,

Casey
@subTee

11 comments:

  1. Great article, Casey. People need to hear this. Yes application whitelisting wont stop EVERYTHING but it is another layer.

    Question: You touch upon the putty backdoor. If I create a device guard policy with Level set to publisher, wouldn't the backdoor'd putty still run since the publisher hasn't changed? Now if it was based on Hash it shouldn't since it was modified.

    Thanks for the amazing work you do! I hope more to come.

    ReplyDelete
  2. Thats a great question. The answer is no. When you approve the publisher, the binary must be signed by the publisher, as well as pass the integrity check. So, not it will not execute

    ReplyDelete
  3. Thanks Casey, great article. I am new to AW; can you expand on this list or point me to a resource? "For example, use the whitelist to block regsvr32.exe or InstallUtil.exe"

    ReplyDelete
    Replies
    1. I've tried to catalog all files I am ware of here:
      https://github.com/subTee/ApplicationWhitelistBypassTechniques
      Hope that helps.

      Delete
    2. I've tried to catalog all files I am ware of here:
      https://github.com/subTee/ApplicationWhitelistBypassTechniques
      Hope that helps.

      Delete
  4. Okay, so, FWIW, here's an initial reaction to your counter-arguments to the arguments you posit for critics of application whitelisting:

    Right off the bat, I don't really think anything you said is really incorrect or invalid (IMO). That said, I do think you left out what is (to my mind) the most compelling argument against doing robust whitelisting in a very broad way across an organization. That is: Application Whitelisting is resource intensive (which you discussed), *and* most organizations will benefit more from using those resources for other security priorities. Or, put in numbered bullet form:

    4. Most organizations have an uncorrected array of shortcomings in security such that using the resources that would be needed to do widespread, robust application whitelisting instead to remedy those weaknesses can be more efficient and effective at improving an organization's overall security.

    (Okay, so not exactly a catchy or succinct title...)

    Let's illustrate by a hypothetical example. Suppose I'm a CISO who has just be hired at an organization as part of a management shake-up. Soon after I begin my tenure, some major issues become jarringly apparent:

    - Patching is often done on a quarterly basis, and patch management practices and tools are so poor that finding machines & applications in my networks that go unpatched for years is not all that hard.

    -In general, company networks are of ancient, often haphazard, flat design; little regard is evident for network segmentation/defense-in-depth.

    -Active Directory security practices are often poor. (Way too many privileged accounts, use of privileged accounts isn't limited to hardened Privileged Account Workstations, local admin accounts are enabled and have shared passwords, basically everything that adsecurity.org says not to do.)

    -The most sensitive data and systems that are in my organization's control are not protected by any kind of auditing/monitoring systems to detect insiders who have gone rogue or intruders who have gotten past other layers of security.


    -The organization's approach to centralized log collection, monitoring, correlation, retention, etc. is woefully ineffective at contributing to intrusion detection and needs substantial reworking to fix that.

    -And so on...

    In sum, I have a ton of identified major weaknesses that I need to get filled ASAP and probably (very probably) insufficient resources to get them all remedied in a timely manner. A decision to widely deploy application whitelisting would likely require shunting away resources from some of those address-ASAP priorities. Which shouldn't necessarily be an automatic deal-breaker, but should definitely cause a decision-maker to ask the question of whether doing a high-impact, high-cost thing like application whitelisting would be taking resources away from high-impact, lower-cost priorities. [cont.]

    ReplyDelete
    Replies
    1. I feel like this isn't a argument against application whitelisting, but an argument against the prioritization of it. If there are even more low-hanging fruit in said hypothetical organization, then yes, IMO I would start there. But once those low-hanging fruits are remediated, Device Guard or application whitelisting is a worthwhile investment to implement vs. just disregarding it as being too hard.

      Delete
  5. [cont.]
    The argument that I'm articulating in all this? Let me put in a very simplistic but more succinct way: Doing robust application whitelisting on a widespread basis may well make sense as an investment of resources if an organization has "good security" and wants to get to "very good security". But for organizations that currently fall short of having "good security" there will often be things to allocate resources to that will get more "bang for the buck". (We're largely talking about resources as man hours here. But indulge the formulation.) Moreover, the further security resources fall short of security needs for an organization, the more acute the need to get the maximum efficiency and effectiveness you can get (in terms of security risk reduced) out of a given amount of resources becomes.

    (Note: I acknowledge that you already get at some of this in your discussions on points #2 and #3 in post. I think the difference/addition I'm getting at is expressly calling out the "bang for the buck" aspect of things.)

    And we all know very well what proportion of organizations have many critical security gaps to close and yet can't or won't allocate anything close to a level of resources appropriate to do so.

    So that, to my eye, is best argument many organizations will have for not doing widespread deployment of robust application whitelisting. And also, I think, one of big actual reasons that uptake of robust application whitelisting hasn't been better than it has been to this point.

    To the three arguments you set out in your post, you offered counter-arguments. And there is definitely at least one major counter-argument to that that comes to mind off the top of my head. (It's one that you sort of already allude to in parts of your post.) To put it briefly:

    "Deploying application whitelisting" is, in fact, not a binary, black-and-white (no pun intended) thing. As you said, you can deploy to "critical" systems but not every machine & device your organization has and still get meaningful security gains from doing so. Indeed, I'd argue that doing very robust application whitelisting as an integral part of addressing priorities like hardening your domain controllers, moving all your administrators to using PAWs (and hardened jump servers, perhaps), hardening servers to handle particularly sensitive data, hardening devices used by VIPs, etc. is often going to be necessary to serve those purposes and make a lot of sense from an efficiency standpoint. Though I think we look at critical/highest-priority targets for places to deploy using somewhat different models.


    And, of course, once you have robust application whitelisting deployed on some parts of your networks, it is often easier to gradually expand the range of machines/devices where it is deployed, billing each expansion as an incremental change that has lower cost--and lower risk of project failure--than doing a larger, more concerted, more complex effort. Get Windows 10 with Device Guard properly setup on your administrative jump servers, then your Exchange servers, then your then your file servers, and finally all your Windows servers.

    Ultimately, how broadly to deploy robust application whitelisting comes down to complex factors and the specific situation that each organization is in. But, in all likelihood, you should probably be doing it in at least *some* places.

    So that's my somewhat off-the-cuff, definitely not revised-for-conciseness view. Take it for whatever it is or isn't worth.

    Cheers,
    B.

    ReplyDelete
  6. P.S. I'm currently working on a side project exploring ways to emulate some of the more sophisticated capabilities with Office macro attacks that higher-end bad guys are now really beginning to bring to bear (for eg.,the macro + process hollowing combo used by Hancitor) Some of your recent work that you've posted to Twitter and GitHub has proved very helpful indeed, and given me a few ideas I probably wouldn't have come up with on my own. You have my thanks.

    ReplyDelete
    Replies
    1. Great comments. Thanks for the feedback. I think this would be well articulated in a blog post on its own. As far as resource prioritization. I'll take a bit to process your comments and likely come up with a follow up.

      -Cheers

      Casey

      Delete
  7. The last NSS Labs Advanced Endpoint Protection test has shown that only Application Whitelisting (Cb) was 100% effective, no AI, machine learning or other wizardry necessary.I don't expect it to be 100% effective always but it is without doubt extremely effective and its simplicity gives confidence to trust it. Can we say that about other solutions where you really have no clue what it is they actually do?

    Btw. I published a list of Living of the Land examples that have been seen in the wild The list can be useful to get some control over them with application whitelisting. Check it out here: https://github.com/OSUso/LivingOffTheLand

    ReplyDelete