7 Replies Latest reply: Mar 12, 2014 10:17 AM by rothman RSS

    HIPS 8 Expert Sub Rules

    rothman

      Beating my head against my desk here... hopefully someone can help.

       

      I'm attempting to add a custom signature to my HIPS 8 policy for our endpoints which essentially need to be locked down.  We've received some tips from our SE, but like others have mentioned... the documentation for creating expert sub rules is terrible / basically non-existant.  So, onto the issue:

       

      The sub rule I'm attempting to make is one that will block all unsigned executables, except for a list (unfortunately large) of known, unsigned, executables.  An example of the sub rules is below:

       

      Rule {

      tag "Prevent run of unknown executables (<parent folder name>)"

      Class Program

      Id 4024

      level 4

      Target_Executable { Exclude { -sdn "*=*" } }

      Target_Executable { Exclude { -path "c:\\<parent folder>\\<child folder>\\program1.exe" } }

      Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program2.exe" } }

      Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program3.exe" } }

      Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program4.exe" } }

      directives program:run

      }

       

      Now, what I've discovered is that the only way I can get the excludes to work is to shorten the path parameter to something like c:\\*\\program1.exe which is pretty bad imo.

       

      Second, and probably more important, is that we have somewhere in the range of 160 unsigned executables (I know, I know...) which need to be 'white-listed' in this signature.  We believe the javascript in the console is setting the character limit for the textbox input to only allow for about 30 excludes per sub rule.  That bit isn't so much the problem (I simply created something like 18 separate sub rules), but what is a problem is that it appears when the signature triggers, it does not compile all of the separate sub rules into one ... I'm almost thinking it steps through each sub rule individually which defeats the whole point of having mulitple sub rules.

       

      Can someone explain what is happening when the signature triggers as it relates to the sub rules?  If I were to at least understand that much, then I could perhaps work with it better to make it do what I want.

       

      I have also reviewed the following community posts, KBs and documents, but if I missed something, I would be more than gracious if someone showed me what I overlooked:

       

      https://community.mcafee.com/message/317037

      https://community.mcafee.com/message/277168

       

      https://kc.mcafee.com/corporate/index?page=content&id=KB70652

      https://kc.mcafee.com/corporate/index?page=content&id=KB71329

       

      http://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/2 2000/PD22894/en_US/Host%20Intrusion%20Prevention%20800%20Product%20Guide%20for%2 0ePO%20450.pdf

       

      Thanks to all in advance!

      -Andy

       

      Message was edited by: rothman on 2/6/14 3:02:37 PM CST
        • 1. Re: HIPS 8 Expert Sub Rules
          rackroyd

          ~ Moved to hips group for better attention.

          • 2. Re: HIPS 8 Expert Sub Rules
            greatscott

            What are you actually detecting with the signature you are trying to create? All I see is exclude rules for executables. It would seem to me that you should let the whitelisted applications run, and create exceptions for them in your IPS rules policy.

             

            However, assuming you are actually blocking something, all of your "exclude" rules would need to be in one single subrule. For example, you are trying to whitelist your C:\parentfolder file path (note, i added an include rule):

             

            Rule {

            tag "Prevent run of unknown executables (<parent folder name>)"

            Class Program

            Id 4024

            level 4

            Target_Executable { Include {-path "C:\\parentfolder\\"}

            Target_Executable { Exclude { -sdn "*=*" } }

            Target_Executable { Exclude { -path "c:\\<parent folder>\\<child folder>\\program1.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program2.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program3.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program4.exe" } }

            directives program:run

            }

             

            OR

             

             

            Rule {

            tag "Prevent run of unknown executables (<parent folder name>)"

            Class Program

            Id 4024

            level 4

            Target_Executable { Include {-path "C:\\parentfolder\\"}

            Target_Executable { Exclude { -sdn "*=*" } }

            Target_Executable { Exclude { -path "c:\\<parent folder>\\<child folder>\\program5.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program6.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program7.exe" } }

            Target_Executable { Exclude { -path "c:\\ <parent folder>\\<child folder>\\program8.exe" } }

            directives program:run

            }

             

            Looking at this, it is my assumption that program1.exe all the way through program8.exe would be blocked, since they dont all reside in one subrule.

            • 3. Re: HIPS 8 Expert Sub Rules
              rothman

              We're basically trying to block (include) every executable except for signed and unsigned which are listed specifically... essentially making IPS a white lister (though I completely understand that this functionality is not what it was really designed to do).  The reason we're trying to take this route is the endpoints we want to apply this policy to have very very low resources and their application stack is already enough to make them bog down from time to time.  Something I believe I found was that the Include was not actually required in a subrule and that if you don't specify an Include, the rule assumes everything on the system.

               

              So, with my testing, I did discover that you needed to have everything in a single subrule, and therefore am assuming that each signature looks at its subrules individually and not as a stack (similar to a firewall ruleset, though it appears that there is no precedence capabilities).  The problem we are running into is that there is a text character limitation for the input box, for some reason... and there doesn't appear to be a way to get around that.  Since that is the case, trying to include all of the unsigned executables we need into one subrule does not seem possible.  Below are my testing actions and results:

               

              1. We attempted to create a single expert sub-rule which contained the following
                • Include everything on c:\
                • Exclude any signed target executables
                • Exclude a list of ~160 target executables whichare unsigned, but required for production

                   Results:

                             discovered that we were only able to include about 30 executables due to the text limitations of the input box

                             discovered that test executables which were more than 1 folder deep would not be excluded

                             the only option was to exclude executables in this fashion: c:\\*\\program.exe

               

                   2. We attempted to create multiple expert sub-rules to accommodate for the mass number of executables needing to be ‘white listed’

                • Our top sub-rule included everything on c:\
                • Our top sub-rule included an exclude on any signed target executables
                • We kept within the text character limitations ofthe input box

                   Results:

                             after testing, it appears that the rules do not stack / combine

                             it appears that the rules are checked one by one, much like a firewall ruleset

               

                   3. We attempted to create the signature by creating the subrule via the standard UI method

                • Included all unsigned target executables
                • Excluded all signed target executables
                • Excluded a list of approximately 40 target executables as a test

                   Results:

                             after two attempts, it was found that if you exceed the text character limit, even in standard subrule creation, there must be an internal error (no notification)

                             any and all changes to the includes/excludes are completely gone

               

              tl;dr: my conclusion is that the software is not designed to do what we want it to (even though I would argue that the syntax / limited documentation makes it seem like it should).  I'm now going to wait to hear back from my SE before spending any more time on this problem.

              • 4. Re: HIPS 8 Expert Sub Rules
                greatscott

                Have you tried using signatures 6010 and/or 6011? Might prevent you from having to reinvent the wheel, but as you said, these may cause too much overhead for your systems.

                • 5. Re: HIPS 8 Expert Sub Rules
                  rothman

                  I did look into 6011 early on, but it requires a higher patch version of HIPS 8 (we're on .2588, it requires .3709) and these machines have lengthy test periods.  That's not to say that updating the patch version isn't in the realm of possibilities, we were just trying to work with what we got .  I don't think the resource load would be any greater using this signature versus one which we custom built, but all I can do is speculate.

                   

                  Otherwise, I believe you are right in saying that 6011 could potentially be the solution to what we're trying to accomplish, we would just need to go about it a different way and get a list of all known and valid processes to include in a 'trusted' list and any other processes is then blocked by default.  Just for my own knowledge and curiousity, do you know where this trusted list is configured or is it part of the 'exception rules' so that you would add a list of white listed executables (versus target executables) to be the exception to signature 6011?

                  • 6. Re: HIPS 8 Expert Sub Rules
                    greatscott

                    i am not sure that the patch level matters, i assumed it worked for all of hips 8? with regard to how to except, you would just make exceptions when you see events come in for 6011. You can also make this a ton easier by excepting via digital signer. For example, when you add exceptions for the microsoft digital signature, you eliminate most of the events right off the bat. then you can add other digital signatures, and then be left with your other 160ish applications you mentioned, which you could create exceptions for individually.

                    • 7. Re: HIPS 8 Expert Sub Rules
                      rothman

                      Well, in the end it was basically determined that this isn't the function of HIPS and that we should be using Application Control for something like this.  One of our grey-hatters developed some software to hook into the kernal of our endpoints to mitigate anything going forward (though I couldn't even begin explaining how that code works).