乐趣区

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

在写《一个通过 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 曾经反对这类蜜罐辨认并打标!

退出移动版