Today we release the details of CVE-2014-3440, a remote code execution vulnerability in Symantec Critical System Protection. You can get the detailed advisory on the following link:

CVE-2014-3440 – Symantec Critical System Protection Remote Code Execution

We reported the vulnerability with the help of Beyond Security, Symantec fixed the vulnerability on 19.01.2015. Although we didn’t manage to get a nice logo :) in this blog post we give some additional information regarding the issue. This is another example that just like any other software, security products can introduce new security risks to their environment too.

First of all, here’s a short video demonstrating our exploit in action:

The exploit consists of two parts: First we need to register ourselves as an Agent to the SCSP Server. In default installations Agents can be registered without any authentication or prior knowledge. Before the official Symantec advisory was available I asked some of my peers there if this step can be hardened/mitigated somehow, but they couldn’t present any method to do this. Even in case that Agent registration would be somehow restricted, the attack could be executed from a compromised host with an Agent installed.

During the registration we obtain a GUID that allows us to make use of the bulk log upload feature. This feature is affected by a path traversal issue that allows arbitrary file writes leading to RCE. The exploitation method is detailed in our advisory.

Regarding the official workarounds: I actually jiggled when read about placing the log directory to different physical drive, but quickly realized that this is not the first case that software exploitation is mitigated by hardware :) The workaround definitely would work and you only need a different logical partition (not a full physical drive) so the drive letters will be different.

Considering the Prevention policies let’s just say that I studied SCSP to measure the behavioral detection capabilities of different endpoint products, and wasn’t really impressed (by any of the tested products)…

Bonus

While studying SCSP I stumbled upon another interesting thing, that I wouldn’t consider a vulnerability, more like a really strange design decision. In a nutshell, the SCSP management interface allows connecting to different servers and the server list can be edited without authentication. This way an attacker can replace the address of a legitimate server with her own and wait for administrators to log in:

And if you are wondering what that binary thing at the end is, here are some clues:

public byte[] encipherPassword(byte pwd[])
{
    XOREncoding.encode(pwd);
    return pwd;
}
public static void encode(byte data[])
{
    for(int i = 0; i < data.length; i++) data[i] ^= 0x5a;
}