Several vulnerabilities were found when scanning Docker containers

docker-hacked

Recently became known through a blog post, the results of testing tools to identify vulnerabilities no patch and identify security issues in isolated Docker container images.

The test showed that 4 of the 6 scanners known Docker images had critical vulnerabilities that allowed to attack the scanner itself and run its code on the system, in some cases (using Snyk for example) with root privileges.

For an attack, an attacker only needs to start checking his Dockerfile or manifest.json, which includes specially formatted metadata, or put the podfile and gradlew files inside the image.

We manage to prepare exploit prototypes for WhiteSource, Snyk, Fossa and anchore systems.

The package Clair, originally written with safety in mind, showed the best security.

No problems identified in the Trivy package and as a result, it was concluded that Docker container scanners should be run in isolated environments or used only to verify their own images, and also be careful when connecting such tools to automated continuous integration systems.

These scanners do complicated and error-prone things. They are dealing with the docker, extracting layers / files, interacting with package managers, or analyzing different formats. Defending them, while trying to accommodate all use cases for developers, is very difficult. Let's see how the different tools try and manage to do it:

The responsible disclosure score reflects my personal opinion: I think it is important for software vendors to be receptive to security issues reported to them, to be honest and transparent about vulnerabilities, to ensure that the people who use their products are properly informed to make decisions about the update. This includes the most important information that an update has security-relevant changes, opening a CVE to track and communicate about the problem, and potentially notify your customers. I think this is especially reasonable to assume if the product is about CVE, providing information about vulnerabilities in software. Also, I am reassured by the quick response, reasonable correction times, and open communication with the person reporting the attack.

At FOSSA, Snyk and WhiteSource, the vulnerability was related with calling to an external package manager to determine the dependencies and allow you to organize the execution of your code by specifying the touch and system commands in the gradlew and Podfile files.

En Snyk and WhiteSource also found a vulnerability, associated with the launch system commands organization that parsed Dockerfile (for example, in Snyk via Dockefile you could replace the utility ls (/ bin / ls), caused by the scanner and in WhiteSurce you could replace the code through the arguments in the form of "echo" ; tap /tmp/hacked_whitesource_pip;=1.0 '«).

In Anchore, the vulnerability was caused by the use of the skopeo utility to work with docker images. The operation was reduced to adding parameters of the form '»os»: «$ (touch hacked_anchore)»' to the manifest.json file, which are replaced by calling skopeo without a proper escape (only the characters «; & <were removed > ", But the construct" $ () ").

The same author conducted a study on the effectiveness of vulnerability detection not patched via security scanners of docker containers and the level of false positives.

Besides the author argues that several of these tools directly use package managers to resolve dependencies. This makes them particularly difficult to defend. Some dependency managers have configuration files that allow the inclusion of shell code. 

Even if these simple ways are somehow handled, calling these package managers will inevitably mean shelling out money. This, to put it mildly, does not facilitate the defense of the application.

Test Results for 73 Images Containing Vulnerabilities known, as well as an evaluation of the effectiveness to determine the presence of typical applications in images (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), can be consulted within the publication made In the following link.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.