Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Agent Priv Esc to nt authority\system #1585

Closed
nealdj opened this issue Nov 28, 2018 · 9 comments
Closed

Windows Agent Priv Esc to nt authority\system #1585

nealdj opened this issue Nov 28, 2018 · 9 comments
Assignees

Comments

@nealdj
Copy link

nealdj commented Nov 28, 2018

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
Copy link
Contributor

nbuuck commented Nov 29, 2018

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
Copy link
Author

nealdj commented Nov 29, 2018

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
Copy link
Member

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
Copy link
Contributor

pillarsdotnet commented Jan 2, 2019

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

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

@atomicturtle
Copy link
Member

@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
Copy link
Contributor

pillarsdotnet commented Jan 2, 2019

Maybe you could backport the patch from Wazuh: wazuh/wazuh@a4a2d60

@davidj8080
@ddpbsd
@atomicturtle

@nealdj
Copy link
Author

nealdj commented Jan 4, 2019

@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
Copy link
Contributor

Made a patch; needs testing: #1630

@nbuuck
Copy link
Contributor

nbuuck commented Jan 5, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants