How network segmentation mitigates unauthorized access risk

Especially with the pandemic, organizations want their technology accessible from any location. Security vulnerabilities, however, dictate that it may not be wise to expose everything to the internet.

I have seen businesses or educational institutions set up all their computers and devices with public IP addresses. It’s common to accidentally leave networks open to attackers. Network segmentation is one way to mitigate risk from these open doors. Before I discuss that, let’s look at some recent examples that allow attackers to go after an entire network.

Bad Neighbor exploits Windows handling of router advertisement packets

A Microsoft security patch released in October fixed an issue that exposed a vulnerability in how the Windows TCP/IP stack improperly handles ICMPv6 router advertisement packets. Called Bad Neighbor, CVE-2020-16898 impacts all versions of Windows 10 and Server 2016 and Server 2019. The risk of this attack is not necessarily a direct remote attack, but a blended attack starting with a phishing lure that then injects itself into workstation to gain network access. The proofs of concept trigger blue screens of death and not full remote control.

The underlying issue is caused by the improper handling of router advertisement messages, which are part of the neighbor discovery protocol. A remote hacker can execute the attack without authentication, but not easily. As noted in a proof of concept, “To achieve remote code execution, the attacker would need to bypass the stack cookie protection, and would also need to have knowledge of the memory layout of the kernel of the target machine, so this bug probably needs to be chained with an additional memory disclosure vulnerability.”

Some have recommended disabling IPv6 to mitigate this attack, but as SANS ISC notes, don’t disable IPv6 unless you know for certain the impact. If you can’t patch, it’s better to disable the specific feature. You can do this with the command:

 netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable.

To determine the interface number, enter route print at an elevated command line. This will list the interfaces on your IP addresses as shown below.

Susan Bradley

Next, enter the command:

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

Insert the interface number from above (in this case 7) in the command as shown below.

Susan Bradley

Once you are ready to deploy the patch, undo the workaround by undoing the command:

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=enable

SharePoint vulnerability allows remote code execution

A second security patch is just as serious to an enterprise if not more so. Impacting SharePoint 2013, 2016 and 2019, CVE-2020-16952 occurs when an attacker/user uploads a specially crafted SharePoint application package to an affected version of SharePoint. The software fails to check the source markup of an application package and remote code execution (RCE) can occur. As noted in the proof of concept, “An authenticated attacker can craft pages to trigger a server-side include that can be leveraged to leak the web.config file. The attacker can leverage this to achieve remote code execution.”

If SharePoint is configured for an unprivileged SharePoint user to upload files — for example if they have AddAndCustomizePages permission — unauthenticated users might be able to trigger this RCE if your SharePoint deployments have looser permissions than is recommended. The normal permissions for authenticated users allow page creation privileges and allows the leaking of an arbitrary file, notably the application’s web.config file. Attackers can use that file to trigger RCE via .NET deserialization as noted by AttackerKB. Many servers are exposed to the internet and could be at risk for attack.

The case for network segmentation

Both vulnerabilities point out risks of exposure based on how your network is set up and configured. While the immediate remedy in these two examples is apply the appropriate patches, you should also review access and configuration in your network. When you set up a computer, a server, a cloud service or any resource with the ability to access from the internet, evaluate the extra precautions and resources you might need to protect the access. Too often we set up Group Policy firewall rules to allow access and do not make them specific to a network or grouping.

Network segmentation has been a foundational best practice for many years. The concept behind network segmentation is to ensure that you have separated the network based on the type of information and the sensitivity of the information processes and stored. Whether you are protecting physical or virtual machines or servers, or even cloud resources, review how you have set up your resources and who and what has access to them.

Follow these best practices to ensure protection of internal resources.

• Regularly scan the network to ensure that only authorized devices are connected.
• Limit devices that are on the same subnet to only those devices required or authorized to do so.
• When you set up DMZs, configure logging and monitoring to record header and payload information going through the network border and send the information to a logging system.
• Use virtual LANs (VLANs) to isolate types of information and processing with different protection requirements with firewall filtering to ensure that only authorized individuals can communicate with systems necessary to fulfill their specific responsibilities.
• Establish an inventory of technology assets that connect to the network including a list of devices and IP addresses. It should include all systems in the network. Devices that have IP addresses connecting to your network can include internet-of-things devices, printers, telephones, and with working from home being the new norm, home devices that have been inadvertently connected.

Look at the impact of the October updates on your network. If you determined that you need to patch immediately, evaluate if you can segment your network so that you can buy yourself some time. Always ensure workstations and servers are not directly on the web without some protection. Review how your SharePoint servers are set up and deployed. This will not be the last time that an RCE vulnerability will be found on SharePoint servers. Review how you have deployed your servers and if you can better protect them with SSL VPN or other options. You may find that there are much better ways to deploy resources and keep them better protected.