docker 测试_测试docker cve扫描程序的第3部分，自己进行测试结论

docker 测试

In Part 1 and Part 2 I looked at the false negatives and detection rates of Docker image CVE scanners. This time I’m sharing the information about the vulnerable test images and detailed results from Part 1 so you can do the tests and analysis yourself. I’m also giving you my conclusion on the place for Docker image CVE scanners in the security tooling.

在第1部分和第2部分中，我研究了Docker映像CVE扫描仪的误报率和检测率。 这次，我将分享有关易受攻击的测试图像和第1部分中详细结果的信息，以便您可以自己进行测试和分析。 我还将就安全工具中Docker映像CVE扫描仪的位置给您我的结论。

When I’m working in security automation I always try to avoid asking “What is this tool good for?”. I believe this approach results in inefficiency because of the false positives and false negatives brought in by the tools in areas where they are not particularly effective. More than that, it often sidesteps the question: Is this even a problem for us?

在从事安全自动化工作时，我总是尽量避免询问“此工具有什么用处？”。 我相信这种方法会导致效率低下，因为这些工具在效果不佳的地方会带来误报和误报。 不仅如此，它还常常回避这个问题：这对我们来说是否甚至是一个问题？

A better question i think is “What is the issue specifically and what is the best way of addressing that and — only that?”

我认为，一个更好的问题是“具体是什么问题，解决这个问题的最佳方法是什么，而且-只有那样？”

With this in mind, in my conclusion, I will break down the different use-cases of docker image CVE scanners, to show which exact ones they add value currently.

考虑到这一点，在我的结论中，我将分解docker image CVE扫描器的不同用例，以显示它们当前能增加价值的确切的用例。

具有可利用CVE的Docker映像 (Docker images with exploitable CVEs)

As mentioned in Part 1 to evade the “is that CVE really exploitable?” question I decided to do my initial research on docker images that have proven, important, exploitable CVEs.

正如在第1部分中提到的那样，逃避“ CVE是否真的可以被利用吗？” 问题我决定对已被证明是重要的，可利用的CVE的Docker映像进行初步研究。

All the credit for these go to Vulhub, an open source collection of exploitable environments and walkthroughs. Please support them, they are doing awesome work.

所有这些功劳归功于Vulhub ，这是可利用环境和演练的开源集合。 请支持他们，他们正在做很棒的工作。

Vulhub has around 100 different docker based exploitable environments, with vulnerabilities that are mostly CVEs. Sometimes they even build complicated examples with docker-compose if the exploit requires multiple components.

Vulhub具有大约100个基于docker的不同可利用环境，这些漏洞主要是CVE。 有时，如果利用漏洞需要多个组件，他们甚至会使用docker-compose构建复杂的示例。

So all I had to do is filter their builds and adjust them a bit:

因此，我要做的就是过滤它们的构建并对其进行一些调整：

• I removed all where the issue is not a CVE
  我删除了所有不是CVE的问题
• Removed some where the component that has the CVE is added in some funky way (say in the entrypoint script). Not that people wouldn’t do things like this but it is natural to assume scanners will not pick these up.
  删除了一些以时髦的方式添加具有CVE的组件的地方(例如在入口点脚本中)。 并不是说人们不会做这样的事情，而是自然会假设扫描仪不会捡起这些东西。
• Wherever they used multiple images in a complex docker-compose environment I extracted the image that had the CVE
  无论他们在复杂的docker-compose环境中使用多张图片的任何地方，我都会提取具有CVE的图片
• For cases where they used volumes in docker-compose to add, for example a static web page, I adjusted the images to directly contain the files. I did this to avoid criticism that something might not be exploitable. I was so shocked by the bad results that I felt I had to make sure everything is fine. At the end it did not make any difference
  对于他们在docker-compose中使用卷添加例如静态网页的情况，我将图像调整为直接包含文件。 我这样做是为了避免批评某些东西可能无法利用。 我对糟糕的结果感到震惊，以至于我不得不确保一切都很好。 最后没有任何区别

• On top of that I have created a few scripts to exploit the vulnerabilities in the images, partly to make sure they are in fact exploitable. I have also done this to be able to show to the engineers working on the specific products that in fact the versions are right and the vulnerabilities are exploitable.

  最重要的是，我创建了一些脚本来利用图像中的漏洞 ，部分目的是确保它们实际上是可利用的。 我也这样做是为了向从事特定产品工作的工程师表明，实际上版本是正确的并且漏洞是可以利用的。

If you want to run your own scans you can find the images in this registry tagged by the CVE they contain. You can also build them with this script I added to the testing github repo. As we know you should be careful scanning random images!

如果要运行自己的扫描，则可以在此注册表中找到由包含的CVE标记的图像。 您也可以使用我添加到测试github repo的脚本来构建它们。 我们知道您应该小心扫描随机图像！

You can check out the list of images, with the corresponding CVEs, Dockerfiles and the results from each scanner among the results in the repo.

您可以在repo中的结果中检出图像列表，以及相应的CVE，Dockerfile和每个扫描程序的结果 。

I think I’m not the only one who was shocked by the results so I have gone quite some length to validate them and to try to find some reason how this happened. In Part 2 I have talked about some of the ways it is hard to find the components that have the vulnerabilities, now I’m going to try to be even more pessimistic.

我认为我不是唯一一个对结果感到震惊的人，因此我花了相当长的时间来验证结果并尝试找出发生这种情况的原因。 在第2部分中，我讨论了很难找到具有漏洞的组件的一些方法，现在我将变得更加悲观。

CVE的阴暗面 (Dark side of CVEs)

I’d assume one of the upsides people expect from CVE scanners is to be able to be more efficient and specific about picking which vulnerabilities to care for. In fact this is also the main marketing for some of the commercial tools. They spend the time doing the sorting for you. However, having reviewed some of these CVEs my opinion is that it is not possible to be selective about patching based on CVEs if you want to make sure you don’t miss anything.

我认为人们对CVE扫描仪的期望之一是能够更高效，更具体地选择要解决的漏洞。 实际上，这也是某些商业工具的主要营销方式。 他们花时间为您进行分类。 但是，回顾了其中的一些CVE之后，我的观点是，如果您想确保自己不会遗漏任何东西，就不可能选择性地基于CVE进行修补。

I already mentioned in Part 1 that RCE type vulnerabilities will at times be classified as not High risk, so if you only go for those you will definitely miss some. For example if you look at the results, Xray rates CVE-2016–4977 as a Medium, even though it is a remote code execution without much of a setup. It is hard to blame Xray for this though, since the other scanners didn’t even find it.

我已经在第1部分中提到过，RCE类型漏洞有时会被归类为“高风险”，因此，如果您只选择那些，则肯定会错过一些漏洞。 例如，如果您查看结果 ，则Xray将CVE-2016-4977评为“中等”，即使它是远程代码执行，也没有太多设置。 不过，这很难怪Xray，因为其他扫描仪甚至都找不到。

But what if you or, in case you get one of the intelligent/expensive products, the engineers at these providers read the CVE description of CVE-2017–12615?

但是，如果您，或者如果您获得一种智能/昂贵的产品，这些提供商的工程师会阅读CVE-2017–12615的CVE说明， 该怎么办 ？

When running Apache Tomcat 7.0.0 to 7.0.79 on Windows with..

在Windows上使用..运行Apache Tomcat 7.0.0至7.0.79时。

Aaand I stopped reading mine is running on Debian (and even possibly the version is say 8.5.19) so clearly I’m all good. Well not so much. You can say I’m unfair (especially if you read mandarin) because it is a bypass for the original patch. Maybe. But my point is still valid. There is no separate CVE for this one, so how were you supposed to know looking at CVEs that you need to upgrade your 8.5.19 to 8.5.20 to fix this?

Aaand我停止阅读我的软件正在Debian上运行(甚至可能是8.5.19版)，所以我显然很好。 没那么多。 您可以说我不公平(特别是如果您阅读普通话)，因为它绕过了原始补丁。 也许。 但是我的观点仍然有效。 这个没有单独的CVE，那么您应该如何看待需要将8.5.19升级到8.5.20才能解决此问题的CVE？

Ok then let’s take maybe CVE-2017–11610. Let’s say you dig deeper this time and take a look at the exploit: https://www.exploit-db.com/exploits/42779. Ohh it says “< 3.3.2” and I’m running 3.3.2, all good. Except it is a typo and in the code it says “=< 3.3.2”

好吧，让我们考虑一下CVE-2017–11610。 假设您这次更深入地研究漏洞利用： https ： //www.exploit-db.com/exploits/42779。 哦，它说“ <3.3.2”，我正在运行3.3.2，一切都很好。 除非是错字，并且在代码中说“ = <3.3.2”

Now I’m not saying this is how you do your job, but clearly ruling out patches efficiently based on information you dig up on CVEs is not straightforward. Especially if you expect to do it a lot which means you have less time for each.

现在，我并不是说这就是您的工作方式，但是根据您在CVE上获得的信息明确地有效排除补丁并不是一件容易的事。 特别是如果您希望做很多事情，这意味着您每次的时间都更少。

您是说CVE扫描仪没用吗？ (Are you saying CVE scanners are useless?)

Nope.

不。

I’m saying this:

我是这样说的：

The best is having good enough testing and rollback that you can confidently roll out patches in a way that you don’t have to triage a lot and you could rather automatically bump versions. Every time we succeeded with patching it has been done like this, be it Apple, WordPress etc…

最好的是具有足够好的测试和回滚，您可以放心地发布补丁程序，而不必进行大量分类，而可以自动修改版本。 每次我们成功进行修补时，都是这样的，例如Apple，WordPress等…

Eventually there won’t even be any other option other than being able to apply patches without triage. The window between patch and exploit is over time getting smaller. It is largely an illusion to think that one can patch much faster when it is necessary compared to when one should.

最终，除了能够不需分流地应用补丁之外，别无选择。 随着时间的推移，补丁和漏洞利用之间的窗口会越来越小。 认为在必要时可以比在应该时更快地修补补丁，这在很大程度上是一种幻想。

If you don’t want to do this for some reason, this is what you should do:

如果由于某种原因不想执行此操作，则应执行以下操作：

CVE scanners definitely work and are useful for software dependencies. Due to the dynamism of the ecosystem software dependencies will likely have more breaking changes. You will have more of them and it is hard to keep up to date. Add to that they are described in a way that is easy to detect and resolve. You should absolutely do it.

CVE扫描仪肯定可以工作，并且对于软件依赖性很有用。 由于生态系统的动态性，软件依赖项可能会有更多重大变化。 您将拥有更多的这些，并且很难保持最新状态。 此外，它们以易于检测和解决的方式进行描述。 您绝对应该这样做。

Regarding operating system related dependencies you could use a CVE scanner. Practically any because they all do a good job looking at packages added by the OS package manager. But to be frank I think most sysadmins have gotten used to updating without a CVE scanner as well. There are fewer instances when you might break something so maybe this is not the biggest value added if you could simply keep updating things. Given that we are talking about docker images it is even easier. You can harden the images or even better use something that doesn’t come with much baggage like distroless or alpine. Finally, not to say that privilege escalation is good, but most of the vulnerabilities that can be exploited through the internet are not going to be in these packages.

关于与操作系统相关的依赖性，您可以使用CVE扫描程序。 几乎任何原因都是因为它们都能很好地查看OS软件包管理器添加的软件包。 但坦率地说，我认为大多数系统管理员也已经习惯于不使用CVE扫描程序进行更新。 可能会破坏某些事物的实例较少，因此，如果您可以继续更新事物，也许这并不是最大的附加值。 鉴于我们正在谈论docker映像，它甚至更容易。 您可以强化图像，甚至更好地使用不会带来麻烦的东西，例如坚硬的人或高山。 最后，并不是说特权升级是好的，但是可以通过互联网利用的大多数漏洞都不会包含在这些程序包中。

That leads us to what I perceive to be the main issue: what to do with nginx, apache, elastic search etc. These are clearly not picked up by the scanners, unless you find a way to install them with package managers. On the other hand, they seem to have the issues that are readily exploitable. I don’t see CVE scanners adding a lot of value here. I think you should take special care with these. For a smaller company this might be straightforward even without a sophisticated tool. I would argue it is better if you create a list of these tools that you manually maintain and simply keep track of releases. Oldschool. Aka security with RSS Feeds. Like an OG. If you want to do it based on CVEs subscribe to CVEs specifically to those components that you are interested in. This at least removes the issues with detection. It is not really fancy tooling to for example receive a mail or telegram notification from vulners on new CVEs for your list of products. But it works. It might even be a good idea to choose not to filter on specific versions to make sure there is no miscommunication of version numbers.

这使我们想到了我认为的主要问题：如何处理nginx，apache，弹性搜索等。这些扫描器显然不会被扫描程序接收，除非您找到一种使用软件包管理器进行安装的方法。 另一方面，它们似乎具有易于利用的问题。 我看不到CVE扫描仪会在这里增加很多价值。 我认为您应该特别注意这些。 对于较小的公司，即使没有完善的工具，也可能很简单。 我认为最好创建一个手动维护的工具列表并仅跟踪发布的工具。 老套。 RSS Feed的Aka安全性。 像OG。 如果要基于CVE执行此操作，请专门订阅您感兴趣的那些组件的CVE。这至少可以消除检测方面的问题。 例如，从新产品的CVE上的脆弱者那里收到有关产品列表的邮件通知或电报通知并不是真正有用的工具。 但这有效。 最好选择不对特定版本进行过滤，以确保没有错误传达版本号。

These proxies, web servers, database servers, etc are the 5–10 components that are the most important ones in your infrastructure in terms of realistically getting hacked. Maybe it is worth some of your time every day being proactive about them.

这些代理，Web服务器，数据库服务器等是5–10组件，就实际遭到黑客攻击而言，它们是基础结构中最重要的组件。 也许每天值得您花一些时间来积极主动地对待它们。

and… drum roll… to start catching up to Douglas Adams, later on I’ll add a 4th episode to my trilogy on CVE scanners: Exploiting CVE scanner, coming soon.

和……鼓声……开始追赶道格拉斯·亚当斯，稍后，我将在CVE扫描仪的三部曲中添加第4集：即将开发CVE扫描仪。

翻译自: https://medium.com/@matuzg/testing-docker-cve-scanners-part-3-test-it-yourself-conclusions-6de868124d3d

docker 测试