The CAT.NET 2.0 Configuration Analysis Engine

  • Article

Maqbool Malik here…

One of the most significant update to CAT.NET in v2.0 is the addition of a configuration engine. The goal of the engine is to identify insecure configuration at all layers of the application (configuration files, code level configuration, etc.) which should be remediated prior to deployment on a production environment. The engine is highly configurable which enables an organization to tweak the default security baseline (out of the box implementation) to cater to their own security needs by making it more stringent or relaxed. The engine is shipped with a default set of thirty three rules which can be easily tweaked due to their XML structure and more rules can be easily added by adding additional XML files in the \Rules\ConfigurationRules directory. Take a look at any XML file in this directory to get familiar with the XML structure to understand how to author additional rules.

Another important class of configuration settings is those that are omitted in the configuration file for which the defaults are considered insecure. An example is the Role Manager cookieRequireSSL attribute for which the default settings is false, meaning that SSL is not required to return the role names cookie to the server. This class of insecure configurations will also be identified by the Engine, although the current version supports only XML tags and not attributes.

Highly Configurable
Let’s walk through an example to understand the flexibility and configurability provided by the Engine. Consider the CustomErrorConfRule.xml file below which ships with CAT.NET:

Line Number

1

<?xml version="1.0" encoding="utf-8"?>

2

<ConfigurationRule xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" typeName="Microsoft.InformationSecurity.CodeAnalysis.Engines.RulesModel.ConfigurationRule, Microsoft.InformationSecurity.CodeAnalysis.Engines.RulesModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b9ded31be328441b" enabled="true" comparisionType="AttributeCheck" isAndConditions="false">

3

<Information cultureName="en-US">

4

<Category>Web Security</Category>

5

<Certainity>50</Certainity>

6

<Description>Custom error is not turned on which can lead to information disclosure</Description>

7

<Email></Email>

8

<Name>Custom Error is set to off or remote only</Name>

9

<Owner></Owner>

10

<Resolution>Set mode attribute to On </Resolution>

11

<RuleId>WEBCONFSEC01</RuleId>

12

<SeverityLevel>High</SeverityLevel>

13

<Url></Url>

14

<Problem>Mode attribute is set to Off or RemoteOnly</Problem>

15

</Information>

16

<Conditions>

17

<Condition conditionId="4E9F86AD-B000-44C2-A207-0F60686AEE2D" configurationPath="/configuration/system.web/customErrors" attributeName="mode" attributeValue="Off" comparisionOperator="Equals" />

18

<Condition conditionId="946446DF-3C83-4B72-9C07-18A8E3DAD7E6" configurationPath="/configuration/system.web/customErrors" attributeName="mode" attributeValue="RemoteOnly" comparisionOperator="Equals" />

19

</Conditions>

20

</ConfigurationRule>

The first important attribute is on line 2 called “enabled”, this indicates whether the rule will be applied by the Engine. If you would like to turn off a rule, simply change the value of this attribute to “false”.

The second important attribute on line 2 is called “isAndConditions” which describes how conditions defined on lines 17 and 18 will be applied. Since it is currently set to false which implies that OR logic will be applied, meaning that if any of the conditions match listed on lines 17 and 18, the rule will match. In this particular case, the Engine will highlight cases where custom error mode is set to “Off” or “RemoteOnly”.

Sometimes it may be necessary for all conditions to be true in order for the rule to match; an example is the Authorization Deny tag. The conditions for such a rule may be as follows:

< ConditionconditionId = " 80299E97-82BA-4ED1-8D29-FA22F0B34697 " configurationPath = " /configuration/system.web/authorization/deny " attributeName = " users " attributeValue = " * " comparisionOperator = " Not,Equals " />

< ConditionconditionId = " 1E8A5337-9C1C-4038-B359-DEF75FD92D25 " configurationPath = " /configuration/system.web/authorization/deny " attributeName = " users " attributeValue = " ? " comparisionOperator = " Not,Equals " />

Thus, the rule will only match when both conditions are true, in this case the Authorization Deny tag’s users attribute is not set to either of the values “*” and “?”. The conditionId attribute is simply a GUID that can be used by the consumer to uniquely track this issue via a bug tracking system.

Although in the above example the “Not Equals” comparison operator was used, many others are also supported by the Engine. These include:

  • Equivalency (comparisionOperator=“ Equals”)
  • Not Equivalent (comparisionOperator=“Not,Equals”)
  • Greater Than (comparisionOperator=”GreaterThan”)
  • Less Than (comparisionOperator=”LessThan”)
  • Existential (comparisionOperator=”Exists”)
  • Not Exists (comparisionOperator=”Not,Exists”)
  • Contains which allows keyword searches (comparisionOperator=”Contains”)
  • Not Contains (comparisionOperator=”Not,Contains”)
  • These operators can be used in conjunction with conditions and logical operators (AND/OR) to construct complex configuration rules. Happy Authoring!
    Features on the horizon
  • The Configuration Engine is being improved to include additional rules, the set will likely increase to 50+ rules in the next release.
  • Code level configuration will also be analyzed and insecure settings will be reported. (I.E. Page level settings <%@ Page attribute="value" [attribute="value"...] %>)
  • The ability to check for absence of XML attributes for which the defaults are considered insecure. (The current version is able to check for absence of tags but not XML attributes)

Hope this helps….