Before the Wave

Container Tsunami

The alternative route with Docker containers offers both advantages and disadvantages. On the one hand, you do not need to have a system with a Java environment, and you do not need to install Nmap and Ncrack or manipulate files in the filesystem afterward. In this way, the local system remains clear. On the other hand, this approach requires maintaining separate Dockerfiles for each target host, depending on the host to be checked, because Tsunami currently only supports calls with a single host as the target. Scanning entire networks is explicitly not on the list of supported functions.

Although this restriction sounds annoying, it can turn out to be a practical work approach. For example, if you generate your Docker images for Tsunami directly from a continuous integration and continuous delivery (CI/CD) pipeline, you can automatically create corresponding images for all required target systems and make them available in a local registry. The task of operating the scanners can then be automated easily on the system side with Ansible or systemd, for example, by having one of the services automatically start the containers every six hours and mail the output to a specified address. The containers with Tsunami also are conveniently designed by default to execute only the tsunami command itself and to terminate afterward.

You need at least git on a system to check out the Docker sources from the source code. Once you do, type

git checkout https://github.com/google/tsunami-security-scanner
ce tsunami-security-scanner
docker build -t tsunami

to check out and build the image on the basis of the Dockerfile data. In the Dockerfile, you need to edit the IP address of the target system in the last line, which is set to 127.0.0.1 by default. Afterward, you can launch the container with Tsunami:

docker run --network="host" -v "$(pwd)/logs":/usr/tsunami/logs tsunami

To do this, the current folder must have a logs subfolder to store the container's logfiles after it completes its run.

At this point, you should note that the example does not go into the complexity of a setup with automatically generated images. If you want to run Tsunami automatically in the form of Docker containers, you first need to select a host that has network access to all the instances you want to check. It might be advisable to create your own Docker host whose only task is to run Tsunami containers. On top of this, a Dockerfile as described should ideally be designed dynamically as part of a CI/CD environment so that a local Git directory can automatically create Docker containers for all of your target systems.

Testing

To say that Tsunami is written exclusively in Java is not entirely true, because some parts of the software are in Go. The tests, though, are written entirely in Java. Once familiar with the tool and its use, ideally the first step is to take stock of the existing tests. Currently, Tsunami scans are available from four different sources: Google, the community, Facebook, and a company called GovTech that targets a vulnerability in Cisco network devices. Mind you, all these checks are performed automatically by the software when you run it with the default options. You do not need to enable or disable individual tests because, if Tsunami determines that a test is not applicable on a particular system (e.g., because no services are running), the software declares the system to be "not vulnerable" instead of quitting and outputting an error message.

The community directory with the tests contains several checks for bugs in well-known web applications and web frameworks. For example, Tsunami automatically detects whether an older Apache version is installed, specifically, the one with the bug in the rewrite engine that allows unauthorized access to arbitrary paths on the filesystem (CVE-2021-41773). Similarly, Tsunami detects a bug in Apache Solr that lets an attacker read arbitrary files. The Grafana data visualizer had an unpleasant bug described in CVE-2021-43798 that let attackers fool its user management system.

That said, problems that allow the execution of arbitrary code are definitely more critical than problems of the "file traversal" type. Again, the community has some goodies: Tsunami detects a bug of this type in Apache (CVE-2021-25646), GitLab (CVE-2021-29441), and Confluence (CVE-2021-26084).

When you look at the years of the CVE entries, you might think that Tsunami is only all about old vulnerabilities, but that is not the case. Tsunami also comes with a number of checks for more recent problems. In many places the daily administrative routine allows admins virtually no time to patch problems in central software. Not everyone is aware that a patch was released for Confluence over a year ago to plug a critical security hole. That's where software such as Tsunami comes in handy.

Versatile Checks

The checks contributed by Google make up the bulk of the Tsunami scans, and you'll find something here for every purpose. For example, with Google plugins loaded, Tsunami checks a system's ports for unnecessary permissiveness and various passwords with Ncrack for their security, which prevents dictionary attacks. On top of this, Google provides many plugins that detect whether specific services are exposed, even though they shouldn't be.

One problem that might be familiar to you from your own experience is that many programs come with components that only need to be accessible internally but are accidentally exposed to the network. The crux of the matter is that the developers of the respective software do not even have this problem on their radar and therefore do not actively check this type of use for security problems. Administrators are then often blindsided when they realize that an intrusion has occurred through a service that should not have been exposed to the Internet at all.

Examples include the ElasticSearch API or the Kubernetes API. Jenkins and Jupyter are also regularly configured such that their administrative interfaces are accessible from the network, even though it should not happen. Thanks to Google plugins, Tsunami intercepts open WordPress setups where the initial configuration page is still accessible and is therefore easy to hijack on the web and misappropriate because a password is missing (Figure 1).

Figure 1: Tsunami finds unconfigured WordPress instances that open the door to attacks.

Google also provides quite a few plugins that allow Tsunami to detect typical vulnerabilities in web software like Joomla (Figure 2), for which something I mentioned at the beginning of this article comes into play: A platform provider will not typically be aware of all the services running in its environment. However, Tsunami finds installations of Joomla with unpatched vulnerabilities.

Figure 2: Problems with Joomla, like the code injection vulnerability in LDAP in this example, can be proactively avoided with Tsunami.

Usually, the idea behind exploiting these loopholes is not to hijack the Joomla instance. It's much more about using basic services like the email configuration of a Jira instance to spread spam on an email server that has a good reputation. However, this vulnerability falls directly at the provider's feet, and you end up both with masses of data traffic and with your entire IPv4 network ending up on various blacklists. It's a good idea for the platform operator to intervene promptly or – even better – take appropriate precautions.