Archive

Archive for the ‘VPN’ Category

Microsoft works with healthcare organizations to protect from popular ransomware during COVID-19 crisis: Here’s what to do

April 1st, 2020 No comments

True to form, human-operated ransomware campaigns are always on prowl for any path of least resistance to gain initial access to target organizations. During this time of crisis, as organizations have moved to a remote workforce, ransomware operators have found a practical target: network devices like gateway and virtual private network (VPN) appliances. Unfortunately, one sector that’s particularly exposed to these attacks is healthcare.

As part of intensified monitoring and takedown of threats that exploit the COVID-19 crisis, Microsoft has been putting an emphasis on protecting critical services, especially hospitals. Now more than ever, hospitals need protecting from attacks that can prevent access to critical systems, cause downtime, or steal sensitive information.

Why attackers are using human-operated ransomware

While a wide range of adversaries have been known to exploit vulnerabilities in network devices, more and more human-operated ransomware campaigns are seeing the opportunity and are jumping on the bandwagon. REvil (also known as Sodinokibi) is one of the ransomware campaigns that actively exploit gateway and VPN vulnerabilities to gain a foothold in target organizations. After successful exploitation, attackers steal credentials, elevate their privileges, and move laterally across compromised networks to ensure persistence before installing ransomware or other malware payloads.

Microsoft has been tracking REvil as part of a broader monitoring of human-operated ransomware attacks. Our intel on ransomware campaigns shows an overlap between the malware infrastructure that REvil was observed using last year and the infrastructure used on more recent VPN attacks. This indicates an ongoing trend among attackers to repurpose old tactics, techniques, and procedures (TTPs) for new attacks that take advantage of the current crisis. We haven’t seen technical innovations in these new attacks, only social engineering tactics tailored to prey on people’s fears and urgent need for information. They employ human-operated attack methods to target organizations that are most vulnerable to disruption—orgs that haven’t had time or resources to double-check their security hygiene like installing the latest patches, updating firewalls, and checking the health and privilege levels of users and endpoints—therefore increasing probability of payoff.

Human-operated ransomware attacks are a cut above run-of-the-mill commodity ransomware campaigns. Adversaries behind these attacks exhibit extensive knowledge of systems administration and common network security misconfigurations, which are often lower on the list of “fix now” priorities. Once attackers have infiltrated a network, they perform thorough reconnaissance and adapt privilege escalation and lateral movement activities based on security weaknesses and vulnerable services they discover in the network.

In these attacks, adversaries typically persist on networks undetected, sometimes for months on end, and deploy the ransomware payload at a later time. This type of ransomware is more difficult to remediate because it can be challenging for defenders to go and extensively hunt to find where attackers have established persistence and identify email inboxes, credentials, endpoints, or applications that have been compromised.

We saw something. We said something.

The global crisis requires everyone to step up, especially since attackers seem to be stepping up in exploiting the crisis, too, even as some ransomware groups purportedly committed to spare the healthcare industry. Through Microsoft’s vast network of threat intelligence sources, we identified several dozens of hospitals with vulnerable gateway and VPN appliances in their infrastructure. To help these hospitals, many already inundated with patients, we sent out a first-of-its-kind targeted notification with important information about the vulnerabilities, how attackers can take advantage of them, and a strong recommendation to apply security updates that will protect them from exploits of these particular vulnerabilities and others.

When managing VPN or virtual private server (VPS) infrastructure, it’s critical for organizations to know the current status of related security patches. Microsoft threat intelligence teams have observed multiple nation-state and cybercrime actors targeting unpatched VPN systems for many months. In October 2019, both the National Security Agency (NSA) and National Cyber Security Centre (NCSC) put out alerts on these attacks and encouraged enterprises to patch.

As organizations have shifted to remote work in light of the pandemic, we’re seeing from signals in Microsoft Threat Protection services (Microsoft Defender ATP, Office 365 ATP, and Azure ATP) that the attackers behind the REvil ransomware are actively scanning the internet for vulnerable systems. Attackers have also been observed using the updater features of VPN clients to deploy malware payloads.

Microsoft strongly recommends that all enterprises review VPN infrastructure for updates, as attackers are actively tailoring exploits to take advantage of remote workers.

How to detect, protect, and prevent this type of ransomware

The Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and Department of Commerce National Institute of Standards and Technology (NIST) have published useful guidance on securing VPN/VPS infrastructure.

We understand how stressful and challenging this time is for all of us, defenders included, so here’s what we recommend focusing on immediately to reduce risk from threats that exploit gateways and VPN vulnerabilities:

  • Apply all available security updates for VPN and firewall configurations.
  • Monitor and pay special attention to your remote access infrastructure. Any detections from security products or anomalies found in event logs should be investigated immediately.  In the event of a compromise, ensure that any account used on these devices has a password reset, as the credentials could have been exfiltrated.
  • Turn on attack surface reduction rules, including rules that block credential theft and ransomware activity. To address malicious activity initiated through weaponized Office documents, use rules that block advanced macro activity, executable content, process creation, and process injection initiated by Office applications. To assess the impact of these rules, deploy them in audit mode.
  • Turn on AMSI for Office VBA if you have Office 365.

To help organizations build a stronger security posture against human-operated ransomware, we published a comprehensive report and provided mitigation steps for making networks resistant against these threats and cyberattacks in general. These mitigations include:

  • Harden internet-facing assets and ensure they have the latest security updates. Use threat and vulnerability management to audit these assets regularly for vulnerabilities, misconfigurations, and suspicious activity.
  • Secure Remote Desktop Gateway using solutions like Azure Multi-Factor Authentication (MFA). If you don’t have an MFA gateway, enable network-level authentication (NLA).
  • Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords. Use tools like LAPS.
  • Monitor for brute-force attempts. Check excessive failed authentication attempts (Windows security event ID 4625).
  • Monitor for clearing of Event Logs, especially the Security Event log and PowerShell Operational logs. Microsoft Defender ATP raises the alert “Event log was cleared” and Windows generates an Event ID 1102 when this occurs.
  • Determine where highly privileged accounts are logging on and exposing credentials. Monitor and investigate logon events (event ID 4624) for logon type attributes. Domain admin accounts and other accounts with high privilege should not be present on workstations.
  • Utilize the Windows Defender Firewall and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.

We continue to work with our customers, partners, and the research community to track human-operated ransomware and other trends attackers are using to take advantage of this global crisis.

For more guidance on how to stay protected during this crisis, we will continue to share updates on our blog channels.

 

Microsoft Threat Protection Intelligence Team

Microsoft Threat Intelligence Center (MSTIC)

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection tech community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

 

The post Microsoft works with healthcare organizations to protect from popular ransomware during COVID-19 crisis: Here’s what to do appeared first on Microsoft Security.

A brief discourse on ‘Changing browsing experience’

In response to questions we’ve received from the software distribution and monetization industry, and following our blog announcing our browser modifier policy update, we’d like to provide some details on what we refer to in our policy as “changing browsing experience”.

For us, “changing browsing experience” means behaviors that modify the content of webpages.

We consider programs installed and running on a PC that make webpages look differently than they would on the same browser had those programs not been installed, to be programs that change browsing experience.  These programs are required to use the browsers’ extensibility models.

Browsers’ extensibility models ensure user choice and control.  Extensible browsers present consent prompts that ensure users are asked to grant permission for an extension to be enabled.  It is done using a consistent language and placement that is straightforward and clear.

By requiring programs that change browsing experience to use the extensibility models, we ensure that users are kept at the helm of their choice and control.  Programs can only make such alterations to webpages when users grant them the permission to do so, using the browsers’ consistent and reliable consent prompting.

Some programs modify browsing access in ways that don’t insert or change web content.  We don’t consider these as changing the browsing experience.

Examples of programs that modify browsing access include:

  • VPNs – software type that provides access
  • Parental control programs – software type that restricts access

If these programs don’t insert or change web content, then they are not changing browsing experiences. Therefore, they are not required to use the browsers’ extensibility models.

Our intent with this policy is clear: we are determined to protect our customers’ choice and browsing experience control.  The requirement to use the browsers’ supported extensibility models is an important pillar in achieving this goal.

 

Barak Shein and Michael Johnson

MMPC

A brief discourse on ‘Changing browsing experience’

In response to questions we’ve received from the software distribution and monetization industry, and following our blog announcing our browser modifier policy update, we’d like to provide some details on what we refer to in our policy as “changing browsing experience”.

For us, “changing browsing experience” means behaviors that modify the content of webpages.

We consider programs installed and running on a PC that make webpages look differently than they would on the same browser had those programs not been installed, to be programs that change browsing experience.  These programs are required to use the browsers’ extensibility models.

Browsers’ extensibility models ensure user choice and control.  Extensible browsers present consent prompts that ensure users are asked to grant permission for an extension to be enabled.  It is done using a consistent language and placement that is straightforward and clear.

By requiring programs that change browsing experience to use the extensibility models, we ensure that users are kept at the helm of their choice and control.  Programs can only make such alterations to webpages when users grant them the permission to do so, using the browsers’ consistent and reliable consent prompting.

Some programs modify browsing access in ways that don’t insert or change web content.  We don’t consider these as changing the browsing experience.

Examples of programs that modify browsing access include:

  • VPNs – software type that provides access
  • Parental control programs – software type that restricts access

If these programs don’t insert or change web content, then they are not changing browsing experiences. Therefore, they are not required to use the browsers’ extensibility models.

Our intent with this policy is clear: we are determined to protect our customers’ choice and browsing experience control.  The requirement to use the browsers’ supported extensibility models is an important pillar in achieving this goal.

 

Barak Shein and Michael Johnson

MMPC

How to implement PEAP-MSCHAPv2 as authentication method for VPN connections in TMG 2010

December 11th, 2012 No comments

As you may know, there is a known security vulnerability for the authentication method MS-CHAPv2.

The following TechNet article provides some detailed information about it:
Microsoft Security Advisory (2743314)

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

http://technet.microsoft.com/en-us/security/advisory/2743314

You may consider moving away from PPTP VPN connections which are configured to use this authentication method therefore.

But, what are the alternatives and how can you integrate these in TMG 2010 which is configured as a VPN Server?

As you can see, only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole
authentication method are vulnerable to this issue. If you need to rely on PPTP connections due to down level clients’ requirements, you may consider changing the authentication method for such PPTP connection to PEAP-MSCHAPv2. I will illustrate later how this can be achieved with TMG 2010.

First of all I would like to mention that you should consider using SSTP or L2TP/IPSec connections instead of PPTP.

Both types are also supported and integrated in TMG 2010.

image

Why you should deprecate PPTP?

PPTP uses Microsoft Point to Point encryption (MPPE). MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the cipher text stream and therefore the cipher text is vulnerable to a bit-flipping attack.

You could use an authentication method like EAP-TLS, PEAP-TLS or PEAP-MSCHAPv2 for a PPTP connection to address the mentioned vulnerability in MS-CHAPv2. But the encryption method does not change by doing that.

So let’s take a look at L2TP/IPsec and SSTP.
The main advantage of Secure Socket Tunneling Protocol (SSTP) is that it is uses TCP port 443 as its server destination port since it relies on SSL which provides transport layer security. Therefore the SSTP packets can pass firewalls and proxies. Unfortunately there is no built-in SSTP support in down level or several 3rd party operating systems. That’s why the affected administrators need to decide between PPTP and L2TP/IPsec for compatibility reasons.

L2TP/IPsec is well-known and has been widely used for many years. If you need some in-depth information, please refer to the following article:

http://technet.microsoft.com/de-de/library/cc771298(v=ws.10).aspx

Because of that fact that there is no need to reinvent the wheel, I would like to point to Deb Shinder who did a pretty good job writing a step-by-step guide on how to implement L2TP/IPsec in TMG 2010.

http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part3.html

Though its quality, Microsoft does not adhere for third party information.

Before we look at the configuration of PEAP-MSCHAPv2, let me clarify that PEAP-MSCHAPv2 is NOT affected by the mentioned vulnerability, because the MSCHAPv2 information is only transmitted within a secure channel in PEAP phase 2.
The following article provides further information about the authentication method PEAP-MSCHAPv2 in general:

http://technet.microsoft.com/en-us/library/cc779326(v=WS.10).aspx
One more word before you read ahead. PPTP PEAP-MSCHAPv2 requires a certificate with Server Authentication EKU on a NPS Server from either your organizations PKI or a public CA.

Now let’s focus on how to implement PEAP-MSCHAPv2 in TMG. You may expect that TMG supports PEAP-MSCHAPv2 as valid authentication method, since it is some sort of EAP variant with improved security and because EAP can be enabled in TMG as authentication method. Unfortunately this is not 100% correct. If you choose EAP it in the Remote Access Policy it will cause the VPN connection to fail.

image

A Windows 7 client will report the following error:

image

Why does this happen?
The reason is that TMG configures the Routing and Remote Access Service (RRAS) and the Network Policy Service (NPS) which are included in the Windows Server operating system.

Doing this, TMG adds the following authentication method as a valid type to its local NPS configuration:
“Microsoft: Smart Card or other certificate” which is EAP-TLS, but neither PEAP-MSCHAPv2 or PEAP-TLS.

image

If you change the NPS configuration on the TMG Server, it will only provide a temporary workaround. The reason is that TMG will overwrite the NPS configuration once its service is restarted.

How you can solve that:

You will need to configure TMG to use Radius Authentication. This will result in outgoing Radius packets to a remote Radius/NPS Server. This additional NPS Server can be configured to enable PEAP support.

image

As next step you will need to define the remote RADIUS Server(s)

image

This is it from TMG perspective. After you have applied the configuration, you will need to configure the remote NPS Server.

After you have added the required NPS role on your remote server, open the NPS MMC.

First of all you will need to define and enable a RADIUS client there. This will ensure that incoming RADIUS packets from this source will not be dropped.

clip_image001

Next you will need to create a ‘Connection Request Policy’ and a ‘Network Policy’ in the remote NPS Server.

The following article explains the differences between ‘Connection Request Policies’ and ‘Network Policies’.

http://technet.microsoft.com/en-us/library/cc772279(v=WS.10).aspx

When installing NPS, you will have some policies already. Either you can edit them or create some new ones. We will create new ones for this example. Let’s start with a new ‘Connection Request Policy’ by using the wizard.

clip_image002

Then you will have to define conditions when this policy applies. You have lots of possibilities to define granular rules which match your needs. These possibilities are illustrated in the linked article above. To make things as easy as possible for this guide, we only use a Day-and-Time condition. Basically the condition always applies.

clip_image002[6]

Leave the default settings on the next screen. You could forward the requests once more (Radius Proxy feature), but that does not make sense for this example.

clip_image004

If you are using Network Access Protection (NAP) for your VPN clients, you will need to use the setting “Override network policy authentication settings”. If you don’t use NAP, leave the default settings which I do for this straight-forward example.

clip_image002[8]

Leave the settings on the next page to its defaults and click ‘Next’. After you have checked the summary, click on ‘Finish’. That’s it for the ‘Connection request policy’.

Let’s move on to the network policy.

Right click on ‘Network Policies’ and choose ‘New’.

clip_image002[10]

In the next screen define a suitable policy condition which defines, when the network policies is about to be applied for a connection request. Again, you have plenty of options to use granular conditions. This does not only make sense, but may also be required due to your infrastructure needs. For example you may want to use different authentication methods, you may need to create different policies for VPN, 802.1x, etc.

To keep things simple, we use the Day and Time restriction once more. Again, using it in this way, it will always apply this rule.

clip_image004[7]

Skip the next screen by clicking on ‘Next’. This will bring you to the configuration of the valid EAP types.

You will need PEAP-MSCHAPv2 for this scenario. Uncheck the ones which are not required and add PEAP-MSCHAPv2 by clicking on ‘Add’.

clip_image005

Click on ‘Ok’.

You screen should look like this:

clip_image007

Highlight the PEAP entry in the list and click ‘Edit’:

Make sure that you have chosen a valid and trusted certificate. Besides add EAP-MSCHAP v2 as inner method.

clip_image008

Click ‘Ok’, click ‘Next’ three times and then ‘Finish’ completing the configuration.

That’s it. I hope this guide helps you to understand if you need to change your VPN type and if needed, how to do it.

I am happy to answer related questions and read your feedback in the comments below.

 

Author:

Frank Hennemann

Microsoft CSS Forefront Security Edge Team

Technical Review:

Markus Sarcletti

Microsoft CSS Windows Networking

Categories: RRAS, secure, TMG, VPN Tags:

How to implement PEAP-MSCHAPv2 as authentication method for VPN connections in TMG 2010

December 11th, 2012 No comments

As you may know, there is a known security vulnerability for the authentication method MS-CHAPv2.

The following TechNet article provides some detailed information about it:
Microsoft Security Advisory (2743314)

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

http://technet.microsoft.com/en-us/security/advisory/2743314

You may consider moving away from PPTP VPN connections which are configured to use this authentication method therefore.

But, what are the alternatives and how can you integrate these in TMG 2010 which is configured as a VPN Server?

As you can see, only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole
authentication method are vulnerable to this issue. If you need to rely on PPTP connections due to down level clients’ requirements, you may consider changing the authentication method for such PPTP connection to PEAP-MSCHAPv2. I will illustrate later how this can be achieved with TMG 2010.

First of all I would like to mention that you should consider using SSTP or L2TP/IPSec connections instead of PPTP.

Both types are also supported and integrated in TMG 2010.

image

Why you should deprecate PPTP?

PPTP uses Microsoft Point to Point encryption (MPPE). MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the cipher text stream and therefore the cipher text is vulnerable to a bit-flipping attack.

You could use an authentication method like EAP-TLS, PEAP-TLS or PEAP-MSCHAPv2 for a PPTP connection to address the mentioned vulnerability in MS-CHAPv2. But the encryption method does not change by doing that.

So let’s take a look at L2TP/IPsec and SSTP.
The main advantage of Secure Socket Tunneling Protocol (SSTP) is that it is uses TCP port 443 as its server destination port since it relies on SSL which provides transport layer security. Therefore the SSTP packets can pass firewalls and proxies. Unfortunately there is no built-in SSTP support in down level or several 3rd party operating systems. That’s why the affected administrators need to decide between PPTP and L2TP/IPsec for compatibility reasons.

L2TP/IPsec is well-known and has been widely used for many years. If you need some in-depth information, please refer to the following article:

http://technet.microsoft.com/de-de/library/cc771298(v=ws.10).aspx

Because of that fact that there is no need to reinvent the wheel, I would like to point to Deb Shinder who did a pretty good job writing a step-by-step guide on how to implement L2TP/IPsec in TMG 2010.

http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part3.html

Though its quality, Microsoft does not adhere for third party information.

Before we look at the configuration of PEAP-MSCHAPv2, let me clarify that PEAP-MSCHAPv2 is NOT affected by the mentioned vulnerability, because the MSCHAPv2 information is only transmitted within a secure channel in PEAP phase 2.
The following article provides further information about the authentication method PEAP-MSCHAPv2 in general:

http://technet.microsoft.com/en-us/library/cc779326(v=WS.10).aspx
One more word before you read ahead. PPTP PEAP-MSCHAPv2 requires a certificate with Server Authentication EKU on a NPS Server from either your organizations PKI or a public CA.

Now let’s focus on how to implement PEAP-MSCHAPv2 in TMG. You may expect that TMG supports PEAP-MSCHAPv2 as valid authentication method, since it is some sort of EAP variant with improved security and because EAP can be enabled in TMG as authentication method. Unfortunately this is not 100% correct. If you choose EAP it in the Remote Access Policy it will cause the VPN connection to fail.

image

A Windows 7 client will report the following error:

image

Why does this happen?
The reason is that TMG configures the Routing and Remote Access Service (RRAS) and the Network Policy Service (NPS) which are included in the Windows Server operating system.

Doing this, TMG adds the following authentication method as a valid type to its local NPS configuration:
“Microsoft: Smart Card or other certificate” which is EAP-TLS, but neither PEAP-MSCHAPv2 or PEAP-TLS.

image

If you change the NPS configuration on the TMG Server, it will only provide a temporary workaround. The reason is that TMG will overwrite the NPS configuration once its service is restarted.

How you can solve that:

You will need to configure TMG to use Radius Authentication. This will result in outgoing Radius packets to a remote Radius/NPS Server. This additional NPS Server can be configured to enable PEAP support.

image

As next step you will need to define the remote RADIUS Server(s)

image

This is it from TMG perspective. After you have applied the configuration, you will need to configure the remote NPS Server.

After you have added the required NPS role on your remote server, open the NPS MMC.

First of all you will need to define and enable a RADIUS client there. This will ensure that incoming RADIUS packets from this source will not be dropped.

clip_image001

Next you will need to create a ‘Connection Request Policy’ and a ‘Network Policy’ in the remote NPS Server.

The following article explains the differences between ‘Connection Request Policies’ and ‘Network Policies’.

http://technet.microsoft.com/en-us/library/cc772279(v=WS.10).aspx

When installing NPS, you will have some policies already. Either you can edit them or create some new ones. We will create new ones for this example. Let’s start with a new ‘Connection Request Policy’ by using the wizard.

clip_image002

Then you will have to define conditions when this policy applies. You have lots of possibilities to define granular rules which match your needs. These possibilities are illustrated in the linked article above. To make things as easy as possible for this guide, we only use a Day-and-Time condition. Basically the condition always applies.

clip_image002[6]

Leave the default settings on the next screen. You could forward the requests once more (Radius Proxy feature), but that does not make sense for this example.

clip_image004

If you are using Network Access Protection (NAP) for your VPN clients, you will need to use the setting “Override network policy authentication settings”. If you don’t use NAP, leave the default settings which I do for this straight-forward example.

clip_image002[8]

Leave the settings on the next page to its defaults and click ‘Next’. After you have checked the summary, click on ‘Finish’. That’s it for the ‘Connection request policy’.

Let’s move on to the network policy.

Right click on ‘Network Policies’ and choose ‘New’.

clip_image002[10]

In the next screen define a suitable policy condition which defines, when the network policies is about to be applied for a connection request. Again, you have plenty of options to use granular conditions. This does not only make sense, but may also be required due to your infrastructure needs. For example you may want to use different authentication methods, you may need to create different policies for VPN, 802.1x, etc.

To keep things simple, we use the Day and Time restriction once more. Again, using it in this way, it will always apply this rule.

clip_image004[7]

Skip the next screen by clicking on ‘Next’. This will bring you to the configuration of the valid EAP types.

You will need PEAP-MSCHAPv2 for this scenario. Uncheck the ones which are not required and add PEAP-MSCHAPv2 by clicking on ‘Add’.

clip_image005

Click on ‘Ok’.

You screen should look like this:

clip_image007

Highlight the PEAP entry in the list and click ‘Edit’:

Make sure that you have chosen a valid and trusted certificate. Besides add EAP-MSCHAP v2 as inner method.

clip_image008

Click ‘Ok’, click ‘Next’ three times and then ‘Finish’ completing the configuration.

That’s it. I hope this guide helps you to understand if you need to change your VPN type and if needed, how to do it.

I am happy to answer related questions and read your feedback in the comments below.

 

Author:

Frank Hennemann

Microsoft CSS Forefront Security Edge Team

Technical Review:

Markus Sarcletti

Microsoft CSS Windows Networking

Categories: RRAS, secure, TMG, VPN Tags:

How to implement PEAP-MSCHAPv2 as authentication method for VPN connections in TMG 2010

December 11th, 2012 No comments

As you may know, there is a known security vulnerability for the authentication method MS-CHAPv2.

The following TechNet article provides some detailed information about it:
Microsoft Security Advisory (2743314)

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

http://technet.microsoft.com/en-us/security/advisory/2743314

You may consider moving away from PPTP VPN connections which are configured to use this authentication method therefore.

But, what are the alternatives and how can you integrate these in TMG 2010 which is configured as a VPN Server?

As you can see, only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole
authentication method are vulnerable to this issue. If you need to rely on PPTP connections due to down level clients’ requirements, you may consider changing the authentication method for such PPTP connection to PEAP-MSCHAPv2. I will illustrate later how this can be achieved with TMG 2010.

First of all I would like to mention that you should consider using SSTP or L2TP/IPSec connections instead of PPTP.

Both types are also supported and integrated in TMG 2010.

image

Why you should deprecate PPTP?

PPTP uses Microsoft Point to Point encryption (MPPE). MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the cipher text stream and therefore the cipher text is vulnerable to a bit-flipping attack.

You could use an authentication method like EAP-TLS, PEAP-TLS or PEAP-MSCHAPv2 for a PPTP connection to address the mentioned vulnerability in MS-CHAPv2. But the encryption method does not change by doing that.

So let’s take a look at L2TP/IPsec and SSTP.
The main advantage of Secure Socket Tunneling Protocol (SSTP) is that it is uses TCP port 443 as its server destination port since it relies on SSL which provides transport layer security. Therefore the SSTP packets can pass firewalls and proxies. Unfortunately there is no built-in SSTP support in down level or several 3rd party operating systems. That’s why the affected administrators need to decide between PPTP and L2TP/IPsec for compatibility reasons.

L2TP/IPsec is well-known and has been widely used for many years. If you need some in-depth information, please refer to the following article:

http://technet.microsoft.com/de-de/library/cc771298(v=ws.10).aspx

Because of that fact that there is no need to reinvent the wheel, I would like to point to Deb Shinder who did a pretty good job writing a step-by-step guide on how to implement L2TP/IPsec in TMG 2010.

http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part3.html

Though its quality, Microsoft does not adhere for third party information.

Before we look at the configuration of PEAP-MSCHAPv2, let me clarify that PEAP-MSCHAPv2 is NOT affected by the mentioned vulnerability, because the MSCHAPv2 information is only transmitted within a secure channel in PEAP phase 2.
The following article provides further information about the authentication method PEAP-MSCHAPv2 in general:

http://technet.microsoft.com/en-us/library/cc779326(v=WS.10).aspx
One more word before you read ahead. PPTP PEAP-MSCHAPv2 requires a certificate with Server Authentication EKU on a NPS Server from either your organizations PKI or a public CA.

Now let’s focus on how to implement PEAP-MSCHAPv2 in TMG. You may expect that TMG supports PEAP-MSCHAPv2 as valid authentication method, since it is some sort of EAP variant with improved security and because EAP can be enabled in TMG as authentication method. Unfortunately this is not 100% correct. If you choose EAP it in the Remote Access Policy it will cause the VPN connection to fail.

image

A Windows 7 client will report the following error:

image

Why does this happen?
The reason is that TMG configures the Routing and Remote Access Service (RRAS) and the Network Policy Service (NPS) which are included in the Windows Server operating system.

Doing this, TMG adds the following authentication method as a valid type to its local NPS configuration:
“Microsoft: Smart Card or other certificate” which is EAP-TLS, but neither PEAP-MSCHAPv2 or PEAP-TLS.

image

If you change the NPS configuration on the TMG Server, it will only provide a temporary workaround. The reason is that TMG will overwrite the NPS configuration once its service is restarted.

How you can solve that:

You will need to configure TMG to use Radius Authentication. This will result in outgoing Radius packets to a remote Radius/NPS Server. This additional NPS Server can be configured to enable PEAP support.

image

As next step you will need to define the remote RADIUS Server(s)

image

This is it from TMG perspective. After you have applied the configuration, you will need to configure the remote NPS Server.

After you have added the required NPS role on your remote server, open the NPS MMC.

First of all you will need to define and enable a RADIUS client there. This will ensure that incoming RADIUS packets from this source will not be dropped.

clip_image001

Next you will need to create a ‘Connection Request Policy’ and a ‘Network Policy’ in the remote NPS Server.

The following article explains the differences between ‘Connection Request Policies’ and ‘Network Policies’.

http://technet.microsoft.com/en-us/library/cc772279(v=WS.10).aspx

When installing NPS, you will have some policies already. Either you can edit them or create some new ones. We will create new ones for this example. Let’s start with a new ‘Connection Request Policy’ by using the wizard.

clip_image002

Then you will have to define conditions when this policy applies. You have lots of possibilities to define granular rules which match your needs. These possibilities are illustrated in the linked article above. To make things as easy as possible for this guide, we only use a Day-and-Time condition. Basically the condition always applies.

clip_image002[6]

Leave the default settings on the next screen. You could forward the requests once more (Radius Proxy feature), but that does not make sense for this example.

clip_image004

If you are using Network Access Protection (NAP) for your VPN clients, you will need to use the setting “Override network policy authentication settings”. If you don’t use NAP, leave the default settings which I do for this straight-forward example.

clip_image002[8]

Leave the settings on the next page to its defaults and click ‘Next’. After you have checked the summary, click on ‘Finish’. That’s it for the ‘Connection request policy’.

Let’s move on to the network policy.

Right click on ‘Network Policies’ and choose ‘New’.

clip_image002[10]

In the next screen define a suitable policy condition which defines, when the network policies is about to be applied for a connection request. Again, you have plenty of options to use granular conditions. This does not only make sense, but may also be required due to your infrastructure needs. For example you may want to use different authentication methods, you may need to create different policies for VPN, 802.1x, etc.

To keep things simple, we use the Day and Time restriction once more. Again, using it in this way, it will always apply this rule.

clip_image004[7]

Skip the next screen by clicking on ‘Next’. This will bring you to the configuration of the valid EAP types.

You will need PEAP-MSCHAPv2 for this scenario. Uncheck the ones which are not required and add PEAP-MSCHAPv2 by clicking on ‘Add’.

clip_image005

Click on ‘Ok’.

You screen should look like this:

clip_image007

Highlight the PEAP entry in the list and click ‘Edit’:

Make sure that you have chosen a valid and trusted certificate. Besides add EAP-MSCHAP v2 as inner method.

clip_image008

Click ‘Ok’, click ‘Next’ three times and then ‘Finish’ completing the configuration.

That’s it. I hope this guide helps you to understand if you need to change your VPN type and if needed, how to do it.

I am happy to answer related questions and read your feedback in the comments below.

 

Author:

Frank Hennemann

Microsoft CSS Forefront Security Edge Team

Technical Review:

Markus Sarcletti

Microsoft CSS Windows Networking

Categories: RRAS, secure, TMG, VPN Tags:

How to implement PEAP-MSCHAPv2 as authentication method for VPN connections in TMG 2010

December 11th, 2012 No comments

As you may know, there is a known security vulnerability for the authentication method MS-CHAPv2.

The following TechNet article provides some detailed information about it:
Microsoft Security Advisory (2743314)

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

http://technet.microsoft.com/en-us/security/advisory/2743314

You may consider moving away from PPTP VPN connections which are configured to use this authentication method therefore.

But, what are the alternatives and how can you integrate these in TMG 2010 which is configured as a VPN Server?

As you can see, only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole
authentication method are vulnerable to this issue. If you need to rely on PPTP connections due to down level clients’ requirements, you may consider changing the authentication method for such PPTP connection to PEAP-MSCHAPv2. I will illustrate later how this can be achieved with TMG 2010.

First of all I would like to mention that you should consider using SSTP or L2TP/IPSec connections instead of PPTP.

Both types are also supported and integrated in TMG 2010.

image

Why you should deprecate PPTP?

PPTP uses Microsoft Point to Point encryption (MPPE). MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the cipher text stream and therefore the cipher text is vulnerable to a bit-flipping attack.

You could use an authentication method like EAP-TLS, PEAP-TLS or PEAP-MSCHAPv2 for a PPTP connection to address the mentioned vulnerability in MS-CHAPv2. But the encryption method does not change by doing that.

So let’s take a look at L2TP/IPsec and SSTP.
The main advantage of Secure Socket Tunneling Protocol (SSTP) is that it is uses TCP port 443 as its server destination port since it relies on SSL which provides transport layer security. Therefore the SSTP packets can pass firewalls and proxies. Unfortunately there is no built-in SSTP support in down level or several 3rd party operating systems. That’s why the affected administrators need to decide between PPTP and L2TP/IPsec for compatibility reasons.

L2TP/IPsec is well-known and has been widely used for many years. If you need some in-depth information, please refer to the following article:

http://technet.microsoft.com/de-de/library/cc771298(v=ws.10).aspx

Because of that fact that there is no need to reinvent the wheel, I would like to point to Deb Shinder who did a pretty good job writing a step-by-step guide on how to implement L2TP/IPsec in TMG 2010.

http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part3.html

Though its quality, Microsoft does not adhere for third party information.

Before we look at the configuration of PEAP-MSCHAPv2, let me clarify that PEAP-MSCHAPv2 is NOT affected by the mentioned vulnerability, because the MSCHAPv2 information is only transmitted within a secure channel in PEAP phase 2.
The following article provides further information about the authentication method PEAP-MSCHAPv2 in general:

http://technet.microsoft.com/en-us/library/cc779326(v=WS.10).aspx
One more word before you read ahead. PPTP PEAP-MSCHAPv2 requires a certificate with Server Authentication EKU on a NPS Server from either your organizations PKI or a public CA.

Now let’s focus on how to implement PEAP-MSCHAPv2 in TMG. You may expect that TMG supports PEAP-MSCHAPv2 as valid authentication method, since it is some sort of EAP variant with improved security and because EAP can be enabled in TMG as authentication method. Unfortunately this is not 100% correct. If you choose EAP it in the Remote Access Policy it will cause the VPN connection to fail.

image

A Windows 7 client will report the following error:

image

Why does this happen?
The reason is that TMG configures the Routing and Remote Access Service (RRAS) and the Network Policy Service (NPS) which are included in the Windows Server operating system.

Doing this, TMG adds the following authentication method as a valid type to its local NPS configuration:
“Microsoft: Smart Card or other certificate” which is EAP-TLS, but neither PEAP-MSCHAPv2 or PEAP-TLS.

image

If you change the NPS configuration on the TMG Server, it will only provide a temporary workaround. The reason is that TMG will overwrite the NPS configuration once its service is restarted.

How you can solve that:

You will need to configure TMG to use Radius Authentication. This will result in outgoing Radius packets to a remote Radius/NPS Server. This additional NPS Server can be configured to enable PEAP support.

image

As next step you will need to define the remote RADIUS Server(s)

image

This is it from TMG perspective. After you have applied the configuration, you will need to configure the remote NPS Server.

After you have added the required NPS role on your remote server, open the NPS MMC.

First of all you will need to define and enable a RADIUS client there. This will ensure that incoming RADIUS packets from this source will not be dropped.

clip_image001

Next you will need to create a ‘Connection Request Policy’ and a ‘Network Policy’ in the remote NPS Server.

The following article explains the differences between ‘Connection Request Policies’ and ‘Network Policies’.

http://technet.microsoft.com/en-us/library/cc772279(v=WS.10).aspx

When installing NPS, you will have some policies already. Either you can edit them or create some new ones. We will create new ones for this example. Let’s start with a new ‘Connection Request Policy’ by using the wizard.

clip_image002

Then you will have to define conditions when this policy applies. You have lots of possibilities to define granular rules which match your needs. These possibilities are illustrated in the linked article above. To make things as easy as possible for this guide, we only use a Day-and-Time condition. Basically the condition always applies.

clip_image002[6]

Leave the default settings on the next screen. You could forward the requests once more (Radius Proxy feature), but that does not make sense for this example.

clip_image004

If you are using Network Access Protection (NAP) for your VPN clients, you will need to use the setting “Override network policy authentication settings”. If you don’t use NAP, leave the default settings which I do for this straight-forward example.

clip_image002[8]

Leave the settings on the next page to its defaults and click ‘Next’. After you have checked the summary, click on ‘Finish’. That’s it for the ‘Connection request policy’.

Let’s move on to the network policy.

Right click on ‘Network Policies’ and choose ‘New’.

clip_image002[10]

In the next screen define a suitable policy condition which defines, when the network policies is about to be applied for a connection request. Again, you have plenty of options to use granular conditions. This does not only make sense, but may also be required due to your infrastructure needs. For example you may want to use different authentication methods, you may need to create different policies for VPN, 802.1x, etc.

To keep things simple, we use the Day and Time restriction once more. Again, using it in this way, it will always apply this rule.

clip_image004[7]

Skip the next screen by clicking on ‘Next’. This will bring you to the configuration of the valid EAP types.

You will need PEAP-MSCHAPv2 for this scenario. Uncheck the ones which are not required and add PEAP-MSCHAPv2 by clicking on ‘Add’.

clip_image005

Click on ‘Ok’.

You screen should look like this:

clip_image007

Highlight the PEAP entry in the list and click ‘Edit’:

Make sure that you have chosen a valid and trusted certificate. Besides add EAP-MSCHAP v2 as inner method.

clip_image008

Click ‘Ok’, click ‘Next’ three times and then ‘Finish’ completing the configuration.

That’s it. I hope this guide helps you to understand if you need to change your VPN type and if needed, how to do it.

I am happy to answer related questions and read your feedback in the comments below.

 

Author:

Frank Hennemann

Microsoft CSS Forefront Security Edge Team

Technical Review:

Markus Sarcletti

Microsoft CSS Windows Networking

Categories: RRAS, secure, TMG, VPN Tags: