Windows Agent Priv Esc to nt authority\system

[nealdj]

There's a directory traversal issue on the local windows OSSEC agent that allows a low privilege user to become nt authority\system if they have access to the OSSEC server.

Requirements to exploit:

1. Full access to the OSSEC server.
2. Low privileged access to a windows system that has the ossec hids agent installed.

[nbuuck]

Someone requested CVE-2018-19666 for this. That may have been premature as this issue is predicated on having full control the OSSEC server which is already understood to be a privileged system relative to the agents that retrieve rules, active response commands, and even arbitrary script files from the server.

While I'm no longer an active ~maintainer~ contributor, I fully expect this to be disputed by the project team both because this is inherent to the architecture and the details thus far are sparse. I recommend you develop and provide something closer to a full proof-of-concept if you wish this issue to be evaluated.

[nealdj]

Here's the POC, a snippet from ossec.conf:

<command>
    <name>win_nullroute</name>
    <executable>..\..\..\..\Users\Public\malware.exe</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
    <command>win_nullroute</command>
    <location>local</location>
    <level>6</level>
    <timeout>600</timeout>
</active-response>

The issue here that that an attacker with access to the OSSEC server and limited access to the windows system would be able to become nt authority\system by executing malware outside of the pre-configured active-response\bin directory via directory transversal. If we assume that this level of access is given to the OSSEC admin, then this is a not an issue.

Let me know if you have any additional thoughts on this, thanks!

[atomicturtle]

This is more or less by design. In addition to the active response system being able to execute commands, there is a log type called full_command where the server can configure the agent to run a command on a loop (examples: df for disk monitoring, nmap for discovery, etc).

Like this:

  <localfile>
    <log_format>full_command</log_format>
    <command>/bin/df -h</command>
    <frequency>60</frequency>
  </localfile>

I'm closing this out, but I do want to thank you, and all the security researchers out there auditing our code base. Its important work, and we very very much appreciate it

[pillarsdotnet]

@atomicturtle -- Would you please re-open this issue? CVE-2018-19666 has received a "High" rating:

• CVSS v3.0=7.8
• CVSS v2.0=7.2

For many organizations, this rating means that we cannot ignore this report with impunity, no matter how misguided we feel it may be.

[atomicturtle]

@davidj8080 would you be so kind as to update that for us in the MITRE database? This is absolutely by design, we do not agree with this assessment at all. It would break a core capability.

[pillarsdotnet]

Maybe you could backport the patch from Wazuh: https://github.com/wazuh/wazuh/commit/a4a2d607a85f2efcac3f71e876e2c5574348ae82

@davidj8080 @ddpbsd @atomicturtle

[nealdj]

@atomicturtle Requested it be removed on Dec 1st based on your response, no update from MITRE yet. Re-requested it be removed today.

@pillarsdotnet Thanks for pointing that out, I think that would resolve the issue.

[pillarsdotnet]

Made a patch; needs testing: #1630

[nbuuck]

I suspect there are few - if any - users that rely on upward traversal, but it probably needs to be emphasized in the release notes that include this PR that support for such traversal in active response commands has been removed.

This is a partial mitigation. Other mechanisms exist to achieve unfettered file system access via an active response command that a privileged user on the OSSEC server can modify arbitrarily:

• Full path name (I can just reference a sensitive file directly without upward relative traversal). There's no check in execd that I could identify that ensures the command path is within the agent install directory.
• Create or follow an existing symlink that targets a path outside of the agent installation directory.

While this fix might not be harmful, respectfully, the threat model doesn't make sense to me.