Should You Send Your Pen Test Report to the MSRC?

Should You Send Your Pen Test Report to the MSRC?

Every day, the Microsoft Security Response Center (MSRC) receives vulnerability reports from security researchers, technology/industry partners, and customers. We want those reports, because they help us make our products and services more secure. High-quality reports that include proof of concept, details of an attack or demonstration of a vulnerability, and a detailed writeup of the issue are extremely helpful and actionable. If you send these reports to us, thank you!

Customers seeking to evaluate and harden their environments may ask penetration testers to probe their deployment and report on the findings. These reports can help that customer find and correct security risk(s) in their deployment.

The catch is that the pen test report findings need to be evaluated in the context of that customer’s group policy objects, mitigations, tools, and detections implemented. Pen test reports sent to us commonly contain a statement that a product is vulnerable to an attack, but do not contain specific details about the attack vector or demonstration of how this vulnerability could be exploited. Often, mitigations are available to customers that do not require a change in the product code to remediate the identified security risk.

Let’s look at the results of an example penetration test report for a deployment of Lync Server 2013. This commonly reported finding doesn’t mention the mitigations that already exist.

 

Whoa—my deployment is vulnerable to a brute-force attack?

In this scenario, a customer deployed Lync Server 2013 with dial-in functionality. The deployment includes multiple web endpoints, allowing users to join or schedule meetings. The customer requests a penetration test and receives the report with a finding that states “Password brute-forcing possible through Lync instance.”

Let’s look at this in more detail.

Lync Server 2013 utilizes certain web endpoints for web form authentication. If these endpoints are not implemented securely, they can open the door for attackers to interact with Active Directory. Penetration testers that analyze customer deployments often identify this issue, as it represents risk to the customer environment.

The endpoint forwards authentication requests to the following SOAP service /WebTicket/WebTicketService.svc/Auth. This service makes use of LogonUserW API to authenticate the requested credentials to the AD.

In this scenario, there is a brute-force attack risk to customers when exposing authentication endpoints.   

This is not an unsolvable problem. In environments with mitigations on user accounts (such as a password lockout policy), this would cause a temporary Denial of Service (DoS) for the targeted user, rather than letting their account be compromised. Annoying to the user (and a potential red flag of an active attack if this keeps happening) but not as serious as a compromised account.

Mitigating brute-force AD attacks via publicly exposed endpoints

We advocate for defense in depth security practices, and with that in mind, here are several mitigations to shore up defenses when an endpoint like this is publicly exposed.

1. Have a strong password policy.

Having a strong password policy in place helps prevent attacks using easily guessed and frequently used passwords. With dictionaries of millions of passwords available online, a strong password can go a long way in preventing brute-forcing. Microsoft guidance on password policies (and personal computer security) is published here – https://www.microsoft.com/en-us/research/publication/password-guidance/ – and provides some great tips based on research and knowledge gained while protecting the Azure cloud.

2. Have an account lockout policy.

The second step to protecting the environment and taking advantage of a strong password policy is having an account lockout policy. If an attacker knows a username, they have a foothold to perform brute-force attacks. Locking accounts adds a time-based level of complexity to the attack and adds a level of visibility to the target. Imagine attempting to log into your own account, and you’re notified that it’s been locked. Your first step is to contact your IT/support group or use a self-service solution to unlock your account. If this continues to happen, it raises red flags. Guidance and information regarding account lockout policies may be found on our blog here – https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/.

3. Log (and audit) access attempts.

Another step to detect and prevent this behavior is related to event logging and auditing, which can be done in multiple locations. Depending on the edge or perimeter protections, web application filtering or rate limiting at the firewall level can reduce the chances of a brute-force attack succeeding. Dropped login attempts or packets mitigate an attack from a single IP or range of IPs.

4. Audit account logon attempts.

On any servers used for authentication, a Group Policy auditing account logon events could give visibility into any attempts at password guessing. This is a best practice in any network environment, not only those with web-based endpoints that require authentication. Guidance on securing an Active Directory environment through Group Policy auditing can be found in our guide here – https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/monitoring-active-directory-for-signs-of-compromise.

5. Use Web application filtering rules.

When one of the above recommendations is not a viable option, alternate mitigations may be needed to reduce risk in the environment. To verify the viability of a potential mitigation, we have setup a test environment for Lync Server 2013 with IIS ARR (application request routing) reverse proxy to test the requirements:

1. Disable windows auth externally
2. Allow anonymous user sign externally.

In this environment, the following Web Apps under “Skype for Business Server External Web Site” were blocked by using IIS rewrite rules returning error code 403 on the reverse proxy:

1. Abs
2. Autodiscover
3. Certprov
4. Dialin
5. Groupexpansion
6. HybridConfig
7. Mcx
8. PassiveAuth
9. PersistentChat
10. RgsCients
11. Scheduler
12. WebTicket/WebTicketService.svc/Auth

The following web apps were not blocked in reverse proxy:

1. Collabcontent
2. Datacollabweb
3. Fonts
4. Lwa
5. Meet
6. Ucwa

Under this environment – Windows Authentication is blocked on the meeting web app and sign-in fails. Anonymous users could join a conference and still work with the following modalities:

1. Chat message in meeting
2. Whiteboard
3. PPT share
4. Poll
5. Q n A
6. File transfer
7. Desktop share

Each customer needs to consider the functionality needed for external users. In the example provided, this assumes that you would not need the following functionality externally:

1. Dial-in page (shares number to dial-in etc.)
2. Web Scheduler
3. PersistentChat
4. Rgsclients
5. Hybrid PSTN (Skype for Business using on-prem PSTN infra)
6. No mobility client users

For reference, we’ve included a sample rule that blocks external access requests to the Dialin folder. Rules are stored in the ApplicationHost.config file, and the rule is added under the configuration/system.webserver/rewrite/globalrules/ section.

 

<rule name=”BlockDialin” patternSyntax=”Wildcard” stopProcessing=”true”>

<match url=”*” />

<conditions logicalGrouping=”MatchAny” trackAllCaptures=”false”>

<add input=”{HTTP_HOST}” pattern=”dialin.foo.bar.com” />

<add input=”{REQUEST_URI}” pattern=”/dialin/*” />

</conditions>

<action type=”CustomResponse” statusCode=”403″ statusReason=”Access denied.” statusDescription=”Access denied.” />

</rule>

 

Additional guidance on Application Request Routing (ARR) in IIS for Lync servers can be found on our blog – https://blogs.technet.microsoft.com/nexthop/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013/

The best use for pen test reports

Recommendations will depend on how an environment is configured, it’s best to dig into the report for available mitigations before sharing the results outside your organization. If the report comes up with an unpatched vulnerability that has no mitigations, please send us the report and POC.

For more information, please visit our website at www.microsoft.com/msrc

 

This article was written with contributions from Microsoft Security Center team members–Christa Anderson, Saif ElSherei, and Daniel Sommerfeld; as well as Pardeep Karara from IDC Skype Exchange R&D, and Caleb McGary from OS, Devices, and Gaming Security.

Source: Should You Send Your Pen Test Report to the MSRC?