Photo by Silas Baisch on Unsplash

Photo by Silas Baisch on Unsplash

Discover vulnerabilities with Google Tsunami

Before the Wave

Article from ADMIN 74/2023
Google Tsunami security scanner detects errors that typically signal danger and outputs alerts. We look into how you can get the tool up and running and even write the required plugins yourself.

Identifying and fixing security vulnerabilities before an attacker exploits them is one of the most difficult tasks an administrator faces. Virtually any infrastructure component can become a target for crooks. Web applications, with their cornucopia of cross-site scripting (XSS) and other injection attacks, are a problem, as are systems with unpatched software, insecure user accounts, misconfigured firewalls, poorly protected network devices, and so on. At the same time, IT setups are becoming increasingly complex, comprising increasing numbers of components. What's more, sometimes you do not know exactly what components you are dealing with locally.

The best way to prevent attacks is to identify and eliminate security risks before an attack happens. Of course, you cannot hope to do this manually if you have thousands or more virtual instances running the most diverse software zoo imaginable in your company data center. The only tools that can help you there are those that automatically query entire networks or hosts and search for specific vulnerabilities.

Google comes to the aid with its Tsunami [1] offering. Because it is not an official project, Google does not provide any support. That said, Tsunami is now available under the Apache license on GitHub, and the tool can be used without any further Google involvement.


Google has taken a smart approach and designed the program as a framework to which you can add arbitrary functions as plugins. Tsunami, written in Java and therefore platform independent, implements basic functions (e.g., opening connections). Therefore, the plugins "only" contain the specific commands and calls needed to check remote services for specific vulnerabilities.

Accordingly, the Tsunami source code is broken down into several sections that comprise the main program on the one hand (i.e., the Tsunami engine and its interface for loading plugins) and its collection of plugins on the other. There are already quite a few detectors to use for common attack scenarios, contributed in part by Google and in part from the community. On the downside, however, getting started with Tsunami is not as trivial as you might expect.

Docker or Shell

Google basically envisages two approaches to getting started with Tsunami. The first of these involves a shell script provided by Google that builds Tsunami locally. The second option wraps Tsunami in a Docker container, which can then be rolled out as desired. The crux of the matter is that Tsunami either expects the configuration at startup in the form of a file named tsunami.yml (although this is only an empty placeholder in the GitHub directory of the tool without any documentation) or is controlled with command-line parameters when invoked, although this parameter is part of the Dockerfile when used with Docker. In this scenario, you would be need to build a separate Docker container for each host to be tested, which is hardly efficient or useful. I present both approaches because, in practice, both have their place.

The Shell Approach

The following example assumes you have a host machine running Ubuntu Linux 22.04 with Java installed. Besides Java, you need Nmap network scanner version 7.80 or newer and the Ncrack password cracker version 0.7 or newer. Tsunami calls these components in several of its own actions; without the appropriate programs, those calls would go nowhere. Moreover, simulating a misconfigured service requires a runtime environment for Docker containers, either the Docker community edition or a current Podman.

As usual, Google offers its users a kind of all-around package in the example and immediately shows in the documentation how to start an incorrectly configured service, which Tsunami subsequently detects. The command

docker run --name unauthenticatedjupyter-notebook -p 8888:8888 -d jupyter/base-notebook --NotebookApp.token=''

launches an instance of Jupyter Notebook, a kind of online computing platform for various programming languages. A Jupyter instance should always be password protected; otherwise, it allows any visitor to execute arbitrary code. A setup with precisely this issue is simulated by the example used by Google to introduce Tsunami and its features.

The next (less intuitive) command

bash -c "$(curl -sfL"

downloads a script from the Tsunami source code. The script, in turn, fetches the complete Tsunami source code along with the code for the available plugins, builds the Tsunami binary, and finally executes it on IP address After the call, you will find the tsunami binary in the executing user's $HOME/tsunami folder, where it can be used for further calls and, more specifically, for calls that do more than just detect the vulnerable container example on the local host.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=