As of today, Tsunami follows a hardcoded 2-step process when scanning a publicly exposed network endpoint (see Future Works on the potential improvement on the workflow):
- Reconnaissance: In the first step, Tsunami identifies open ports and subsequently fingerprints protocols, services and other software running on the target host via a set of fingerprinting plugins. To not reinvent the wheel, Tsunami leverages existing tools such as nmap for some of these tasks.
- Vulnerability verification: Based on the information gathered in step 1, Tsunami selects all vulnerability verification plugins matching the identified services and executes them in order to verify vulnerabilities without false positives.
Following diagram shows the overall workflow for a Tsunami scan.
In the reconnaissance step, Tsunami probes the scan target and gathers as much information about the scan target as possible, including:
- open ports,
- protocols,
- network services & their banners,
- potential software & corresponding version.
Tsunami performs the Reconnaissance step in 2 separate phases.
In the port scanning phase, Tsunami performs port sweeping in order to identify
open ports, protocols and network services on the scan target. The output of
Port Scanning is a PortScanReport protobuf that contains all the identified
NetworkServices from the port scanner.
PortScanner is a special type of Tsunami plugins design for Port Scanning
purpose. This allows users to swap the port scanning implementations. To not
reinvent the wheel, users could choose a Tsunami plugin wrapper around existing
tools like nmap or
masscan. You may find useful
PortScanner implementations can be found in
tsunami-security-scanner-plugins
repo.
Usually port scanners only provide very basic service detection capability. When the scan target hosts complicated network services, like web servers, the scanner needs to perform further fingerprinting work to learn more about the exposed network services.
For example, the scan target might choose to serve multiple web applications on
the same TCP port 443 using nginx for reverse proxy, /blog for WordPress, and
/forum for phpBB, etc. Port scanner will only be able to tell port 443 is
running nginx. A Web Application Fingerprinter with a comprehensive crawler is
required to identify these applications.
ServiceFingerprinter is a special type of Tsunami plugin that allows users to
define fingerprinters for a specific network service. By using filtering
annotations (see
how to apply my plugins to certain types of services / software?),
Tsunami will be able to automatically invoke appropriate ServiceFingerprinters
when it identifies matching network services.
At the end of the reconnaissance step, Tsunami compiles both the port scanner
outputs and service fingerprinter outputs into a single ReconnaissanceReport
protobuf for Vulnerability Verification.
In the Vulnerability Verification step, Tsunami executes the VulnDetector
plugins in parallel to verify certain vulnerabilities on the scan target based
on the information gathered in the Reconnaissance step. VulnDetector's
detection logic could either be implemented as plain Java code, or as a separate
binary / script using a different language like python or go. External binaries
and scripts have to be executed as separate processes outside of Tsunami using
Tsunami's command execution util. See
Future Works for our design ideas of
making Tsunami plugins language agnostic.
Usually one VulnDetector only verifies one vulnerability and the vulnerability
often only affects one type of network service or software. In order to avoid
doing wasteful work, Tsunami allows plugins to be annotated by some filtering
annotations (see how-to guide for details) to limit
the scope of the plugin.
Then before the Vulnerability Verification step starts, Tsunami will select
matching VulnDetectors to run based on the exposed network services and
running software on the scan target. Non-matching VulnDetectors will stay
inactive throughout the entire scan.