Custom Error Page vulnerability

by Scott Muniz | Aug 24, 2020 | Uncategorized

This article is contributed. See the original author and article here.

IIS comes with default error pages. In order to help troubleshooting issues, these error pages may provide detailed information about the application and server. Therefore, some penetration testing tools may flag this situation as a vulnerability. An example pentest report:

Missing Custom Error Page (CWE ID 756)
The software fails to return custom error pages to the user, possibly resulting in an information leak.

Solution

Unless detailed error pages are enabled for remote requests in IIS, I wouldn’t classify this situation as a critical vulnerability.

If you want to have a clean security scan report (and you want your users to see more meaningful error pages), you can create custom error pages.

In the case I worked on, the tool brought up this report for a folder that doesn’t have a default page. For this situation, there are a few easy workarounds:

1. Add an index.html file to the folder. This should prevent that URL to be flagged again
2. Customize IIS defaullt page for 403 error (C:inetpubcusterren-US403.html). Pentest tool is likely to mark the URL pass if that page is customized
3. Enforce custom error pages in web.config

Web.config file maximum size and count

by Scott Muniz | Aug 24, 2020 | Uncategorized

This article is contributed. See the original author and article here.

Web.config file includes of crucial information for your website to work such as server and application specific settings. Depending on your website and environment, this file can grow quickly. IIS refuses to read it if it exceeds a threshold. This check is in place to prevent possible vulnerability attacks.

Maximum size for web.config file

The default maximum limit is 250 KB. You can change this value by editing the registry key below (Reference). Make sure to restart the server after this change.

HKLMSOFTWAREMicrosoftInetStpConfigurationMaxWebConfigFileSizeInKB

It’s a (REG_DWORD) type. More information about this key is here.

If 32-bit is enabled for your application pool, make sure to edit the following key instead:

HKLMSOFTWAREWow6432NodeMicrosoftInetStpConfigurationMaxWebConfigFileSizeInKB

Is there a better way to manage big web.config file?

Yes. Instead of growing the file size, it’s better to separate the configuration into multiple files. Let’s look at two scenarios.

Extensive amount of URL Rewrite rules

If you have hundreds of URL Rewrite rules, you can create rewrite maps and store them in a separate file.

Let’s say you have a rewrite map like the one below. Save it in a file called rewritemaps.config.

<rewriteMaps>
  <rewriteMap name="Redirects">
    <add key="/fromthisURL" value="/tothisURL" />
    <add key="/fromthisURL2" value="/tothisURL2" />
  </rewriteMap>
</rewriteMaps>

Then refer it from your web.config file:

<configuration>
<system.webServer>
  <rewrite>
    <rewriteMaps configSource="rewritemaps.config"><rewriteMaps>
      <rule name="Redirect rule">
         ...
      </rule>
  </rewrite>
</system.webServer>
</configuration>

You can store rewrite rules themselves in a separate file as well:

<rules configSource="rewriteRules.config" />

Just like web.config file, rewritemaps.config and rewriteRules.config files have 250 KB size limit as well.

Is it a good idea to have hundreds of URL rewrite rules or maps in config files? For performance, redirection by using URL Rewrite rules is better as the requests will be redirected before they are handled by ASP.NET handler. For maintenance, it’s better to do redirection and manage URLs in database so config files won’t need to be edited often.

Extensive amount of application settings

If you need to add enormous amount of settings into your config file, you can use multiple web.config files.

In the example below, application settings and connecting strings are stored in separate config files. Here is how they are referenced from the main web.config:

<appSettings configSource="appSpecific.config">
</appSettings>
<connectionStrings configSource="databaseSpecific.config">
</connectionStrings>

Maximum count for web.config files

Based on my research, there is no theoretical limit. However, CPU and memory usage can play a factor when there are too many config files mapped.

Gaining trust in your SCCM Console Monitoring

by Scott Muniz | Aug 24, 2020 | Uncategorized

This article is contributed. See the original author and article here.

Hi Everyone!

My Name is Fabian Scherer, Customer Engineer (CE – formally PFE) at Microsoft Germany for Microsoft Endpoint Manager related topics.

Challenge

During the daily challenges at Customer Environments one thing was coming to my mind on every Engagement. No one trusts the monitoring status of their Console.

This is a familiar look in the morning at every Infrastructure I have seen during the past years. During the day, the counts are shifting a little bit but at midnight during the Status Summarizer Reset everything will go back to green and on the next day everything repeats. The most Customers are monitoring the Systems and will be notified if there is a bigger Issue with one of the Servers. But that’s an reactive Solution.

If you ask anyone about the status, the answers are always the same:

• We can’t trust this status
• If there is a big issue, we will get a Notification
• Our Infrastructure is too big

But if you want to get from the reactive to the proactive side it’s necessary to edit the Thresholds of the Stats in your Environment and to change the handling of the Supporters to a new level.

In this Blog I want to show you the journey we have taken to get to this point.

Preparation

After the decision to change the whole process the biggest and most annoying part of the project starts, the Preparation Phase. During this phase you must start to collect all the relevant data for your own infrastructure. This includes:

• Technical Understanding
• Listing Classification of your Components
• Thresholds during the past two weeks
• Status Messages which can be ignored

Technical Understanding

First, it is important to understand how the Threshold Topic works. You got all the Components at your Infrastructure and defined Thresholds like this:

(located at Administration > Site Configuration > Status Summarizers à Component Status Summarizer)

This means that the Component SMS_AD_SECURITY_GROUP_DISCOVERY needs 2,000 Messages of the Type Information to get to the Status Warning and 5,000 to get at the Critical state.

It also needs 10 Warning Messages to change to Warning and 50 Warnings to change to Critical state.

In Addition, it needs 1 Error Message to Change at the Warning State and 5 Error Messages to change to the Critical state.

This Defaults will make sense for some Components, but every Environment is different and needs separate Thresholds. Even at a Hierarchy you can’t compare Site A to Site B if there is a different count on Clients and Distribution Points.

One thing should also be clear – there is an separate Component named SMS_COMPONENT_STATUS_SUMMARIZER which detects if the Threshold of one Component is reached and switch it to the defined Status.

Listing Classification of your Components

So, let’s start on the top and list all Components in an Excel List.

After that you should also add the Systems where every of these Components is installed. When finally all Components are listed and linked to the Site Systems, you should start to tag the components with different Categories like this:

• Not installed
  • Components which are not installed and shouldn’t be watched

• Not Relevant
  • Components which are installed but currently not in Use

• Basic
  • Components which are used by the Departments but just must be watched during Error and Warnings

• Important
  • Components which are important for the Departments and there should be an investigation if something isn’t working in regular ways

• Critical
  • Components which shows Critical Workflows and should be investigated as soon as something is strange

Thresholds during the past two weeks

As mentioned before the Count of Messages is relevant. So, you should start studying the Counts of Information, Warning and Error Messages for each Component during at least the past two weeks and wrote them down.

Some other Environment Issues like ‘Managements Points with a lower workload’ or ‘Distribution Points where the Site Server was unable to read the Registry’ got lighted out. This could be addressed during the Preparation Phase and were shown as good Quick Wins.

After you listed all the Message Counts you will be able to get an view all over the Weeks and to define how much Errors on some Components are ‘Normal’ and where too many Information Messages may can be Critical for the Environment.

Status Messages which can be ignored

On my Investigation, I found some Messages without any Sense for this Environment and Excluded them to minimize the Messages. For Example:

Message ID 9520 on SMS_DISTRIBUTION_MANAGER informs you that a Distribution will not take place because the Distribution Point is set on Maintenance Mode.

There are more Messages that could be not relevant for your own Environment, but you must detect and decide it by yourself.

Definition

After collecting all this Data it’s time to define new Thresholds for each Component on each Site. As first Key Factor you should choose the defined Category:

(Note: The Information that the Component has been switched will also add one Message to your count.)

Examples:

• SMS_SITE_BACKUP | CAS | Critical | IW 12, IC 25, WW 1, WC 2, CW 1 CC 2

This Component on the CAS is writing 11 Information Messages per Day the whole Time I was spectating. If it’s writing more than 11 Messages, it’s important for me to see what’s different and if there is something we need to Investigate.

• SMS_SITE_SQL_BACKUP_% | SQL CAS | Critical | IW 5, IC 11, WW 1, WC 2, CW 2 CC 3

This Component on the SQL System related to the CAS is writing 4 Messages per Day the whole Time I was spectating. It also wrote 1 Error Message every Night. This was during the SMS_SITE_BACKUP and after one hour everything was fine. So, I accept the 1 Error Message per Night and let this Component switch after the Second Error Message.

Recommendation:

Discuss this step with all Units which are involved at your daily Business. They can show you some aspects you may not notice.

Implementation

After the Definition, the technically Part comes up. As mentioned before the Thresholds are defined at the GUI:

Administration > Site Configuration > Status Summarizers > Component Status Summarizer

But you can also list it using WMI:

WQL: 

rootSMSSite_Sitecode
Select * from SMS_SCI_Component where ItemName like '%sms_component_Status_summarizer%'

Powershell: 

$SiteCode = "<SiteCode>"

$ComputerName = "<FQDN>"

$QueryString =  "Select * from SMS_SCI_Component where ItemName like '%sms_component_status_summarizer%' and SiteCode='$SiteCode'"

$WMIObjects = Get-WmiObject -Namespace "rootsmssite_$SiteCode" -Query $QueryString -Impersonation 3 -ComputerName $Computername

$PropList = $WMIObjects.PropLists

$Property = $PropList | where {$_.PropertyListName -eq "Component Thresholds"}

$Values = $Property.Values

And also by using SQL: 

select * from SC_Component_PropertyList where Name = 'Component Thresholds' and SiteNumber = '<SiteNumber>'

The SiteNumber can be detected by watching the SiteControlFile:

select * from vSMS_SC_SiteControlXML

The most uncomplicated (but also the longest way) to update the Thresholds is using the Console but it’s a pity to update all Files using the GUI:

4 Site Systems * 6 Entries * 70 Components would be 1.680 entries that must be manually edited.

The smartest way is using SQL. But be careful – The command must be exactly been executed. If you forget to define the Name your Environment will be crashed. So please perform a Backup before you try to edit the Thresholds and use the whole Command. I copied the Values of the .xml File at the SQL query and edited the defined thresholds.

Index:
IW = Information Messages to get The Warning State
IE = Information Messages to get the Critical State
WW = Warning Messages to get the Warning State
WE = Warning Messages to get the Critical State
EW = Error Messages to get the Warning State
EE = Error Message to get the Critical State

!YOU WILL HAVE TO UPDATE THE WHOLE XML FILE, NOT JUST THE ENTRIES YOU WANT TO EDIT!

If you choose this way you can use the following Query:

update SC_Component_PropertyList SET Value = '<The whole XML File>' where Name = 'Component Thresholds' AND SiteNumber = '<SiteNumber>'

It is possible that the defined Thresholds will be overwritten with the Default during an SCCM CB Update. So please check the Settings after every Update. You should also be aware of new Components releases with any Version.

Additional Words

This Adjustment is not the End of the Process – it’s the Start. After you have done the first part you can choose the possibilities and develop it to a new level. Some Thresholds will have to be edited later. You should implement a Documentation to get rid of recurrently appearing Issues and you can define Rules, E-Mail Messages or Actions that should be performed after special Events appear. It’s just the first step out of the reactive Support moving to a Proactive Service and an Improvement of your Service Quality.

Fabian Scherer

CE

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.