This is not something new, however I personally only discovered this recently whilst looking at the product and thought that others may benefit from the information.

At this point I would also like to state that Sophos have informed Portcullis that they are aware of this issue and will be addressing it in a future version.

What is “Web Protection”?

“Web Protection” is described as follows within Sophos Anti-Virus Help:

“Sophos Web Protection provides enhanced protection against web threats by preventing access to locations that are known to host malware. It blocks endpoints access to such sites by performing a real-time lookup against Sophos’s online database of malicious web sites.” (Sophos Endpoint Security and Control Help / About Sophos Endpoint Security and Control).

Why can enabling “Web Protection” cause a potential privacy concern?

When it is enabled and a user visits a web site, the URL is sent to Sophos’ online database where a check is performed to determine if the site is known to be malicious. If the web site is not deemed to be a known malicious web site then the user will not be prevented from accessing it, however if the web site is found to be malicious Sophos will block access and provide the user with a page similar to that shown below:

Sophos Anti-Virus detects malicious web site

As a result of this, if your organization is more concerned about privacy than a check being performed to determine if a web site being visiting is known to be malicious or not, then `Web Protection’ should be disabled. This is due to the fact that whilst “Web Protection” is enabled, Sophos will have knowledge of the web sites that you are visiting.

How is this information sent to Sophos?

When a user visits a web site a subsequent GET request is automatically sent to Sophos’ online database containing the URL that the user is attempting to visit. However, the URL is encoded using ROT13, a simple letter substitution that replaces letters with those that are 13 positions ahead in the alphabet.

Lets take a look at an example.

When a user browses to https://labs.portcullis.co.uk, the following request is then automatically sent to Sophos’ online database to confirm that the web site is safe to access:

• http://http.00.s.sophosxl.net/V3/01/ynof.cbegphyyvf.pb.hx.w/

The initial part of the above URL “http://http.00.s.sophosxl.net/V3/01/” and the end of the URL “.w” remain static when these requests are submitted to Sophos. It is only the part of the URL between these static points which contains the ROT13 encoded version of the URL that the user is attempting to access. Let’s decode the ROT13 encoded part of this URL, using the following command:

$ echo ynof.cbegphyyvf.pb.hx | gcipher -C Rot -k 13
labs.portcullis.co.uk

The response from Sophos, as shown below, indicates that the site is not malicious and therefore allows the user to continue to the web site:

HTTP/1.1 200 OK
Content-Length: 20

w l h 06 109100713

If however the user browses to a malicious web site, for example the Sophos test web site located at http://sophostest.com/malware/index.html, the response will look similar to the following and will result in the user being blocked from accessing the web site (and will be shown a page similar to that depicted in the screenshot shown earlier within this post):

HTTP/1.1 200 OK
Content-Length: 28

w h p 13 101 Mal/HTMLGen-A

It is noted that all requests submitted automatically to Sophos when “Web Protection” is enabled are sent over the plain text protocol HTTP. This includes SSL links that the user is attempting to visit. For example a user visiting https://www.hotmail.com would result in the following request being submitted to Sophos http://http.00.s.sophosxl.net/V3/01/jjj.ubgznvy.pbz.w/. If you wish you can decode this URL yourself using the method described earlier in this post!

Finally, it is noted that requests submitted to Sophos do not appear to include query parameters, however I have observed directory names included within requests.

How to disable “Web Protection”

Before detailing the steps that can be taken to disable “Web Protection” it is worth pointing out that Sophos do not advise disabling this feature, as they believe this will reduce the level of protection provided by their product. It is therefore advised that a risk assessment be conducted to ensure that the benefits of disabling this feature outweigh the risk of keeping it enabled for your particular environment.

The following steps can be taken to disable “Web Protection”:

1. Open Sophos Endpoint Security And Control
2. Click “Configure” in the menu bar and select “Anti-Virus > Web Protection”
3. A new window will appear, as pictured below
4. Ensure “Block access to malicious web sites” is set to Off
5. Click “OK”
6. 

   

   “Web Protection” is now disabled

The post Could Sophos Anti-Virus Web Protection cause a privacy concern for your organisation? appeared first on Portcullis Labs.

I would like to point out that I did not discover this vulnerability and it is not something new, in fact it has been well documented on the Internet for over a year. It is however clear that not all systems administrators are aware of the associated risks when using Group Policy Preferences, as I continue to see their use.

What are Group Policy Preferences?

Group Policy Preferences were introduced in Windows Server 2008 and provide additional functionality over Group Policy Objects (GPOs). Group Policy Preferences allow administrators to deploy specific configurations that can be configured to affect all computers/users within a domain, or target specific users/groups of users only.

Configured within the Group Policy Management Console, Group Policy Preferences allow administrators to push out a ultitude of policies, such as automatically Mapping a Network Drive when a user logs into their computer, updating the username of the Built-in Administrator account, or making changes to the Registry.

Group Policy Preferences can also be used with earlier versions of Windows, however additional client-side extensions are required to be installed. Further details can be obtained via the Microsoft Group Policy Preferences Getting Started Guide.

Group Policy Preference Example XML Configuration File

In this post I am not going to detail the steps taken to create and deploy a new policy through Group Policy Preferences, however the following provides an example of a Group Policy Preference XML configuration file that I have created to update the name and password of the Built-in Administrator account across all systems on which it is deployed:

You should be able to see that this policy will rename the Built-in Administrator account to “locadm”. The password that we have set on this account is however encrypted within the “cpassword” attribute.

Why using Group Policy Preferences is a bad idea

So far there does not seem to be too much wrong with the use of Group Policy Preferences. They are easy to configure/deploy and any password contained within a policy is encrypted within the Group Policy Preference XML configuration file, so what is the problem?

When a Group Policy Preference is deployed on a Domain Member, in this example on a Windows 7 client, a sub-directory is automatically added within “C:\Users\All Users\Microsoft\Group Policy\History”, which contains the Group Policy Preference XML configuration file. The full path to the history configuration file that I detailed earlier, the one that will rename the Built-in Administrator account and change its password, is shown below as an example:

• C:\Users\All Users\Microsoft\Group Policy\History\{A1C0C41B-D2F8-401B-A5D1-437DA197A809}\Machine\Preferences\Groups\Groups.xml

The history file is readable by any authenticated user, as shown below:

The same Group Policy Preference XML configuration file is also accessible via the following UNC path on the Domain Controller, again by any authenticated user:

• \\Domain_Controller\sysvol\Domain_Name\Policies\{A1C0C41B-D2F8-401B-A5D1-437DA197A809}\Machine\Preferences\Groups\Groups.xml

The problem is that although the password is encrypted within the Group Policy Preference XML configuration file, using 256-bit AES encryption, the 32-byte AES key is openly document by Microsoft. As a result, any authenticated user with access to the Group Policy Preference XML configuration file can easily decrypt the password stored within the “cpassword” attribute, using tools that are freely available on the Internet.

A user that decrypts the password stored within the “cpassword” attribute of my example Group Policy Preference XML configuration, would then have the username and password of the renamed Built-in Administrator account “locadm”, enabling then to log into their computer as this user. They would also be able to connect to other systems within the network where the credentials have been reused.

In the event of a domain administrator account being used within a Group Policy Preference policy, the user would be able to compromise the security of the entire domain.

Can unauthenticated users obtain access to this information?

Yes. Any user on the network that is able to monitor the network traffic between a Domain Controller and a system on which a Group Policy Preference is being deployed would be able to view the XML configuration file as plain text, as it is traverses the network unencrypted via the Server Message Block (SMB) protocol. The following screenshot shows an example of a captured SMB2 packet using wireshark, which contains the Group Policy Preference XML configuration file:

Proof of concept: Decrypting the password

To decrypt the password stored within the ‘cpassword’ attribute of a Group Policy Preference XML configuration file, I make use of the Ruby script published on the carnal0wnage web site.

The following screenshot shows the Ruby script that I have updated to include the encrypted password from the “cpassword” attribute of my example Group Policy Preference XML configuration file (line 5 contains the encrypted password I want to decrypt):

Now lets decrypt the password…

Can the History files be easily removed from Domain Members?

Yes. History files for individual Group Policy Preferences are automatically removed from Domain Members once they perform a Group Policy update (i.e. “gpupdate”), but only after “link enabled” is unchecked against the specific policy within Group Policy Management on the Domain Controller. It is imperative to unlink the policy and not simply delete it, as deleting the policy will not result in the corresponding History files being deleted on Domain Members. Instead, they will remain present until manually deleted.

However, it should not be considered sufficient to only delete the History files from Domain Members and then disable the policies on the Domain Controller and think all is well. Instead it should be assumed that any credentials used within deployed Group Policy Preferences have been compromised and therefore the password to each account should be updated.

The screenshot below shows the ‘link enabled’ option being unchecked:

To Summarise

Lets quickly recap why Group Policy Preferences should not be used when there is a requirement for the policy to contain a user credentials:

• Any authenticated user within the domain can trivially obtain access to the Group Policy Preference XML configuration files either locally on their computer, or via the sysvol folder on the Domain Controller. They can then decrypt any password contained within the “cpassword” attribute of a Group Policy Preference XML configuration file and escalate their level of privilege and obtain an unauthorised level of access to any resource within the network on which the credentials are accepted
• Any unauthenticated user on the network (e.g. an unauthorised user who connects a laptop to the network) that is able to sniff network traffic would be able to capture Server Message Block packets that contain the Group Policy Preference XML configuration file. They could then decrypt the password contained within the “cpassword” attribute, enabling them to obtain unauthorised access to any resource on which the credentials are accepted

So, do you still want to utilise Group Policy Preferences to deploy configurations within your domain?….

The post Are you considering using Microsoft Group Policy Preferences?… Think again! appeared first on Portcullis Labs.