Security

Docker Vulnerability Scanning 101 - A Self Hosting Guide

Ever wonder if those random Docker images you install are safe? I have terrible news for you, it's possible they aren't.

Phillip Tarrant

Phillip Tarrant

— 6 min read
Docker Vulnerability Scanning 101 - A Self Hosting Guide

Lots of software packages are vulnerable to several, maybe even hundreds of software vulnerabilities. What makes this worse is, very few image maintainers are scanning. This multi-part series will help you fix that, and arm you with the knowledge to scan and find vulnerabilities.

Before we jump into this topic, let's define some terms used in this series, and clear up some misunderstandings about this topic.

Common Terms

  • Vulnerability: A vulnerability is a weakness in an IT system that can be exploited by an attacker to deliver a successful attack. They can occur through flaws, features or user error, and attackers will look to exploit any of them, often combining one or more, to achieve their end goal.
  • Scanner: A vulnerability scanner is a computer program designed to assess computers, networks or applications for known weaknesses. These scanners are used to discover the weaknesses of a given system.
  • Vulnerability Scanning: A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. They normally don't attempt to exploit the vulnerability, just report on it.
  • Penetration Testing: A penetration test is a detailed hands-on examination by a real person that tries to detect and exploit weaknesses in your system. These are often long engagements that can take days or weeks at a time.
  • Patching: A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes or bug fixes
  • Remediating: Often used interchangeably with patching, remediation can also be configuration changes of software to prevent a vulnerability in software that wasn't caused by code, but a configuration setting. Example, a fully patched webserver might still allow SSL2. You can remediate without patching, or in some cases, patch without remediating.
  • CVE: CVE stands for Common Vulnerabilities and Exposures. CVE is a glossary that classifies vulnerabilities. The glossary analyzes vulnerabilities and then uses the Common Vulnerability Scoring System (CVSS) to evaluate the threat level of a vulnerability.
  • RCE : Remote Code Execution, or arbitrary code execution is an attacker's ability to run any commands or code of the attacker's choice on a target machine or in a target process.

Purpose and Intent

The purpose of this article is to allow people to scan their systems for vulnerabilities on their own computers or networks, or on someone else's as long as they have permission to do so. Knowledge is power, and with great power comes responsibility. Please take care to ensure you are within the guidelines of the law.

Details on Laws Regarding Unauthorized Access.

The Toolset

We will be using a variety of toolsets in this series, but all of these are 100% free and open source. There are also plenty of vulnerability scanners out there that are SaaS products, or commercial offerings. We will be sticking to a minimal set of tools with a low learning curve to keep things accessible. Note we will be focusing mainly on system vulnerabilities, not web application vulnerabilities as that is a much larger topic.

Commercial and Saas Vulnerability Scanners

https://hostedscan.com - Saas Offering with a free plan
https://www.zaproxy.org - An open source web application attack proxy
https://cirt.net/nikto2 - A web application scanner for various attacks
https://github.com/purpleteam-labs/purpleteam
https://securityforeveryone.com/tools/free-security-tools
https://github.com/greenbone/openvas-scanner - Open source self hosted scanner with a web interface.


Target

For the purposes of this article we will be using a very outdated version of Apache. We will be running this inside a docker container as well. Please ensure you take care not to expose this to the outside world as it could lead to bad things such as RCE and system compromise.

Let's startup a docker container for us to attack!

docker run --name bad_apache -p 8080:80 -d httpd:2.4.17

Let's run curl to ensure the server is up and working.

curl http://127.0.0.1:8080

You should see <html><body><h1>It works!</h1></body></html>

Great! Let's start scanning!

Nmap

No security article/series is complete without Nmap. The defacto security swiss army knife. Nmap comes with a wide variety of scripts that can be used to augment it's functionality. Let's go ahead and jump in with both feet and scan our horribly outdated docker container. For Debian based systems, you can install nmap by simply executing sudo apt install nmap -y

Let's first make sure we have the very latest scripts available by running an update script command. You will want to do this whenever you haven't ran a scan in a week or so.

cd /usr/share/nmap/scripts/
sudo nmap --script-updatedb

Now, let's scan our container with nmap! I'll explain the command flag we will be running first, so you understand:

  • -sV: Probe open ports to determine service/version info
  • -Pn: Treat all hosts as online -- skip host discovery
  • -p: : Only scan specified ports

Run our scan!
nmap --script vulners -sV -Pn -p 8080 127.0.0.1

So many vulnerabilities

Wow! That's a lot of vulnerabilities. Remember, this is a very very old version of apache, and as such, is very vulnerable. This shows us every vulnerability, but let's limit this output to something smaller, and only show us vulnerabilities with a CVE rating of 7 or higher.

nmap --script vulners --script-args mincvss=7.5 -sV -Pn -p 8080 127.0.0.1

Note that you can even see the vulnerabilities with EXPLOIT POC code available. You also get a nice link to learn more from this script.

You can filter the amount of data by looking at the min cvss score

Filtering the flood of data

If you want to be really clever, you can run this scan and then grep for only exploits, or pipe to count the lines for a total number of vulnerabilities.

nmap --script vulners -sV -Pn -p 8080 127.0.0.1 | grep '*EXPLOIT' | wc -l

To go even further, you can also grep and then count the lines for a total of exploitable vulnerabilities above 7.5 score.

nmap --script vulners --script-args mincvss=7.5 -sV -Pn -p 8080 127.0.0.1 | grep '*EXPLOIT' | wc -l

Doing the above command shows me we have about 18 exploits that are above 7.5

So What to do?

This is the first question I get when people see a vulnerability report, and it's a hard question to answer. There are many ways to weigh vulnerabilities and the current trend is what's called "Risk Based Vulnerability Score".

Here is a look at what some of the top people in this sector discuss:

I prefer to use a modified OWASP approach:

  Step 1: Identifying a Risk
  Step 2: Factors for Estimating Likelihood
  Step 3: Factors for Estimating Impact
  Step 4: Determining Severity of the Risk
  Step 5: Deciding What to Fix
  Step 6: Customizing Your Risk Rating Model

Wrapping up

This is a great time to pause before we dive deeper into this topic. Don't worry, another article will be coming soon with more tools, better data handling, Docker specifics, and Host vulnerability management as well. If you have any questions for me, feel free to hop in the Discord and ping me! Just look for ptarrant.

Read more