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.

This blog post relates to an advisory. See CVE-2014-1213: Denial of Service in Sophos Anti-Virus for the release.

One of the major differences of the system object namespace, versus filesystem and registry namespaces, is the concept of a default Discretionary Access Control List (DACL). These DACLs are the cornerstone of the Windows security model, and are used to describe which entities (users, groups, etc.) have specific types of access to an object. When you view the permissions on a file or directory, you’re looking at a direct representation of the DACL for that object. Each rule within a DACL is called an Access Control Entry (ACE). When an object in any namespace is created and the application does not explicitly provide a DACL, the system looks at the parent container to see if it has any ACEs within its DACL that are marked as inheritable. If it finds some, it applies them across into a new DACL for the newly created object. There are special rules around inheritance for containers, but we won’t get into that here. If there are no inheritable ACEs, it resorts to applying the default DACL for the namespace. This is where things get interesting from a security perspective; the system object namespace, in contrast with registry and filesystem namespaces, has no default DACL. In this situation, the system applies an empty DACL, which allows everyone full access to the object.

This is a corner-case that many developers fall foul of. Objects created in the local container (i.e. the system object container for the current session) inherit some ACEs from the session container, but the global container has no inheritable ACEs, and therefore objects within it that are created without an explicit DACL will end up with an empty DACL. We can see this in action by viewing the DACLs applied to the global and session containers, using a tool such as WinObj:

DACL applied to session container in the Windows system object namespace.

DACL applied to global container in the Windows system object namespace.

Notice that all the ACEs in the global container are marked as “Inherit None”, meaning that child objects will not inherit them as part of their DACL. As such, if you create a system object such as a mutex or an event through the usual CreateMutex or CreateEvent API calls, and fail to explicitly provide a DACL, all users on the system will have unrestricted access to that object.

Whilst digging into security issues around this common mistake, I found a number of vulnerabilities in a range of products. In general the impacts of being able to mess with these were low, usually causing the affected application to lock up or stop working in some way. In Sophos Endpoint Security, however, the impact was more interesting. Most anti-malware software consists of three major sections: a user-facing GUI for controlling and monitoring the product, a high privilege user-mode service for performing various scanning features, and one or more kernel-mode modules (commonly referred to as drivers) that provide filesystem filters, notification of new threads and processes, low-level memory access, hook detection, and other kernel-level functionality. Communicating quickly and reliably between these components is a daunting task, especially when your messages have to traverse across the user-mode / kernel-mode barrier. Enter global system objects. Mutexes, events, semaphores, and shared memory sections in the global container of the system object namespace are all directly accessible from both user-mode and kernel-mode. When combined properly, these object types allow a developer to create an inter-process communications framework that is fast, reliable, and thread-safe.

One example of this might be a feature where a filesystem filter driver needs to notify the user-mode service that new data has been written to disk, so that it can scan it. Three named objects – an event, a mutex, and a shared memory section – are created within the global namespace, so that both components can access them. The event is used to signal that a write operation is pending, the mutex is used to ensure that the shared memory section is accessed by only one thread at a time, and the shared memory section is used to hold information about the event. The whole process is rather complex, and is best described in a diagram:

Diagram of an example IPC mechanism between a user-mode AV service and a kernel-mode file system driver.

As you can see, the user-mode service is responsible for checking the write operations before they are allowed. The decision is passed back to the driver, which either completes the write or rejects it, issuing an appropriate error code.

Now, imagine you let a low-privilege user interact with these objects. For one, they may be able to wait on the event object themselves and modify the shared memory section via a race condition. This can be somewhat mitigated by various integrity checks, but isn’t outside the realms of possibility. Another issue is that all of these components modify their state, and in some cases block execution, when the event and mutex objects are waited upon or signalled. Imagine that a malicious local user acquires the mutex, then signals the event. The user-mode service continues execution (step 7) and attempts to acquire the mutex (step 8), but since the malicious user has already acquired it, the service thread is now blocked. From this point on, the driver’s calls to have write operations checked go unheeded. Although the architecture is not identical, this is precisely the mechanism in which Sophos Endpoint Security failed.

As the advisory describes, CVE-2014-1213 relates to a lack of DACLs applied to system objects. As we discussed above, failure to explicitly supply a DACL when creating system objects results in the object being created with the default DACL for the namespace, which is null (i.e. empty). The impact is that a local low-privilege user can manipulate these objects as they wish. Since this can lead to disk IO requests being ignored, or at least heavily delayed, the system eventually cannot continue. In many cases it simply locks up and becomes unresponsive, as user-mode programs and subsystems (e.g. SMSS / CSRSS) cannot complete blocking disk operations. In some cases, the system will recognise the pattern of failures and forcefully terminate the system with a bugcheck (BSoD) in order to reduce the potential for permanent damage to the system state. Of course, this isn’t particularly interesting from a security perspective if you only consider a desktop environment, but imagine the impact on a terminal services system with hundreds or thousands of users.

Sophos have now patched this issue in engine 3.50, which went live on the 21st of January. Portcullis have independently verified this fix as being effective after the update is applied and the system is rebooted.

The post Windows System Objects and Sophos Endpoint Security appeared first on Portcullis Labs.