乐趣区

关于安全:一种通过-ZoomEye-捕获全新-Docker-蜜罐的案例

作者：

jiezi

在

在写《一个通过ZoomEye获取IOC的案例》我发现搜寻Docker的关键词：Server: Docker 会匹配到大量的蜜罐，而这些蜜罐合乎Anglerfish类蜜罐的特色，目前这里蜜罐十分常见部署也十分多，显然它并不是明天的配角，咱们先通过排除掉这些Anglerfish类的数据，搜寻语法：

"Server: Docker" -"<title>"

[解释下：因为咱们要搜寻的Docker是个API服务基本上是不可能呈现”<title>”这个词的，所以间接排除] 如下：

一共失去3.6w+的后果，随机做一些拜访确认发现一个比拟有意思浮现，Docker api默认端口为2375，然而在侧栏的端口散布栏来看能够看出很多其余端口，咱们应用排除语法搜寻：

"Server: Docker" -"<title>" -port:2375

尝试拜访根本都拜访不到，端口服务处于敞开状态，这是一个十分异样的状况。而后咱们看看banner信息，从ZoomEye里显示的banner信息很多申请应该是间接获取dorker版本信息的申请记录，留神察看你会发现这些申请都是版本信息Server: Docker/18.06.1-ce (linux)及Content-Length: 626都十分对立，持续搜寻：

"Server: Docker" +"Content-Length: 626"

能够失去1.2w+的后果，而且这些很多基本上拜访不到，或者开始能拜访，拜访几次后就没有响应了，十分奇怪景象。随即我选了几个IP查看IP档案页面看看其余端口状况：

从这个Server:头的很典型的“蜜罐”格调，初步揣测这些是设施为“蜜罐”并且带有IP阻断性能。当然可能有人会问你这个Content-Length: 626很可能默认的配置就是这个长度，那么咱们那在banner里选一个其余的关键词进行，残缺的banner如下：

HTTP/1.1 200 OK
Date: Thu, 11 Mar 2021 07:04:33 GMT
Server: Docker/18.06.1-ce (linux)
Api-Version: 1.38
Docker-Experimental: false
Ostype: linux
Content-Type: application/json
Content-Length: 626

{"Platform": {"Name": ""}, "Components": [{"Name": "Engine", "Version": "18.06.1-ce", "Details": {"ApiVersion": "1.38", "Arch": "amd64", "BuildTime": "2018-10-26T23:39:57.000000000+00:00", "Experimental": "false", "GitCommit": "e68fc7a/18.06.1-ce", "GoVersion": "go1.10.3", "KernelVersion": "4.14.47-64.38.amzn2.x86_64", "MinAPIVersion": "1.12", "Os": "linux"}}], "Version": "18.06.1-ce", "ApiVersion": "1.38", "MinAPIVersion": "1.12", "GitCommit": "e68fc7a/18.06.1-ce", "GoVersion": "go1.10.3", "Os": "linux", "Arch": "amd64", "KernelVersion": "4.14.47-64.38.amzn2.x86_64", "BuildTime": "2018-10-26T23:39:57.000000000+00:00"}

咱们选GitCommit这个值e68fc7a/18.06.1-ce 搜寻语法：Server: Docker +e68fc7a/18.06.1-ce失去1.4w+的后果，持续咱们看看还有没有其余Content-Length的指标 搜寻语法：Server: Docker +e68fc7a/18.06.1-ce-Content-Length: 626 找到2,465 条而且都是2019年的数据，具体banner如下：

HTTP/1.1 200 OK
Content-Length: 583
Server: Docker/18.06.1-ce (linux)
Ostype: linux
Api-Version: 1.38
Docker-Experimental: false
Date: Sat, 20 Apr 2019 23:57:57 GMT
Content-Type: application/json

{"Platform":{"Name":""},"Components":[{"Name":"Engine","Version":"18.06.1-ce","Details":{"ApiVersion":"1.38","Arch":"amd64","BuildTime":"2018-10-26T23:39:57.000000000+00:00","Experimental":"false","GitCommit":"e68fc7a/18.06.1-ce","GoVersion":"go1.10.3","KernelVersion":"4.14.47-64.38.amzn2.x86_64","MinAPIVersion":"1.12","Os":"linux"}}],"Version":"18.06.1-ce","ApiVersion":"1.38","MinAPIVersion":"1.12","GitCommit":"e68fc7a/18.06.1-ce","GoVersion":"go1.10.3","Os":"linux","Arch":"amd64","KernelVersion":"4.14.47-64.38.amzn2.x86_64","BuildTime":"2018-10-26T23:39:57.000000000+00:00"}

从http头及上面返回的内容参数除里http头里的Date内容如同没啥不一样，然而这个Content-Length是不一样的，一个是626 一个是583，而后认真核查你会发现，在http body里的json里626的是多了很多空格，如：
{“Platform”: {“Name”: “”}
{“Platform”:{“Name”:””}
这个空格的问题让我想起《利用 ZoomEye 追踪多种 Redteam C&C 后浸透攻打框架》 https://paper.seebug.org/1301/ 这篇文章里提到的，到这里基本上能够实锤，搜寻语法搜寻进去的Server: Docker+Content-Length: 626就是“蜜罐”，而且从选用的模版信息能够确定，这个蜜罐模版选用18.06.1-ce版本最为模版，而这个版本次要呈现在2019年！
最初一个问题始终困扰着我：既然是“蜜罐”不应该是吸引火力吗？为什么间接拦挡拜访IP呢？

编者注：ZoomEye始终提供蜜罐辨认业务，打标后果目前只对VIP用户凋谢。目前ZoomEye曾经反对这类蜜罐辨认并打标！

更多文章