从“假漏洞”到“不忘初心”

资讯 1年前 (2023) admin

619 0 0

从“假漏洞”到“不忘初心”

Harbor是什么

Harbor是一个开源的用于存储和分发Docker镜像的平台，开源地址：

https://github.com/goharbor/harbor

随着Docker的普及及大量应用，Harbor也有非常大的使用量，这点可以从ZoomEye的数据可以看出来：

从“假漏洞”到“不忘初心”

CVE-2022-46463

因为这个是在github上开源项目，所以这个CVE很可能就是github签发的：

https://github.com/advisories/GHSA-5c53-mg2q-8qhc

在References里原始提交者

https://github.com/lanqingaa/123/blob/main/README.md

[目前已经被删除] 做了一个演示，大体流程就是通过界面里的搜索不需要任何认证就能搜索到一个project，并进行对应的操作。

随后国内多个安全公司进行应急并对外发布公告，当然我们404团队也发布了对应的应急报告：

从“假漏洞”到“不忘初心”

到了今天发生反转，说这个是一个“假漏洞”，可能是社区有人找到官方，官方看到后认为这不是一个 Vulnerability 而是一个正常的 feature，因为在官方设计及文档里

https://goharbor.io/docs/2.7.0/working-with-projects/project-configuration/?continueFlag=b003751b15414cec9164c23cc703c702

明确说明了这个项目有权限区分 public 和 private，对于public权限的项目本身就是可以直接开放搜索的，所以官方的回复直接说这个是一个 feature 而不是一个 Vulnerability。

从“假漏洞”到“不忘初心”

当然很多安全研究人员很可能包括漏洞提交者本人也认同，所以就默默删除了那个漏洞报告的README.md。

争论的关键

这个算是比较典型的 Vulnerability vs feature 一类问题，这也算是网络安全漏洞研究领域几大经典问题之一，在10余年前我在baidu空间上多次说到这个话题，比如：

从“假漏洞”到“不忘初心”

以至于在后面我写《我的安全世界观》

https://dokumen.tips/documents/superhei-.html?page=8

里有专门在功能角度去评估的视角观点：

从“假漏洞”到“不忘初心”

再比如我多次讲到的一个问题：“上传txt算不算漏洞？”，很多时候漏洞与功能或特性确实是存在各种争论，实际上在《我的安全世界观》里早就提了：

“当这些功能（预期和非预期）影响到安全时候，那就是漏洞”

“漏洞”实际上是要看“场景”的！

我们回归到Harbor这个问题上，那么这个能不能导致安全问题呢？从我们看到的一些数据来看我觉得很多用户可能根本就不清楚项目的 public 和 private的问题（当然在我这个CSO的角度来看企业的Harbor开放到互联网本身就是一个问题），很显然带来很多安全风险，而且从ZoomEye测绘的数据发布量非常大。

继续顺着这个逻辑走下去，按我的理论，这个功能很大程度上存在“滥用”场景，给用户带来了安全风险，是个“漏洞”。

那么接下来的问题是：这个是谁的漏洞？

从“假漏洞”到“不忘初心”

官方当然会甩锅给用户，这个是正常的功能就是这样设计的，是用户非要把私有项目放到公开项目组里，我能有啥办法？当然其实这个也算比较普遍，就好像现在很多的厂商都不把默认口令当从是产品“漏洞”一样，在我的角度这个可以用比较时髦的词语“懒政”来描叙，我们回到Harbor这个问题上，实际上我们在产品角度上还是有很大的安全优化空间的，比如默认把私有的project设置为private，当用户真正有public需求时，手动更改设置。如果我们产品方能充分做到以“尽可能的安全设置作为默认设置”这个原则来实施的话，那会减少很多的安全事件风险！

还有一个点我觉得Harbor设计还是有非常大的问题的：在Harbor默认首页其实就是一个登陆页面，所以很多用户很可能形成错误的认知，我们的所有project都需要登陆，所以就非常放心放到互联网上，即使把本该private的项目，设置为public也不打紧。

漏洞根源

我看到包括一些友商的研究者甚至是漏洞发现者，视角都是放在操作界面“搜索”这个功能上，实际上这是又是一个“时髦”的API鉴权或者说滥用的问题。

搜索功能实际调用的是这个API：

/api/v2.0/search?q=a

那么既然是API的问题，那么其他的API接口情况是怎么样的呢？所以我们404小伙伴在应急的时候，按官方的一些手册作了进一步的测试，实际上也如同官方所说，大部分的涉及敏感信息接口是作了鉴权的，比如

ubuntu@primary:~$ curl -i -k "http://x.x.x.x/api/v2.0/users"HTTP/1.1 401 UnauthorizedServer: nginxDate: Tue, 17 Jan 2023 12:50:29 GMTContent-Type: application/json; charset=utf-8Content-Length: 62Connection: keep-aliveSet-Cookie: sid=00157bbd594e8b461512e988327e12c5; Path=/; HttpOnlyX-Request-Id: f2bae0e6-1ca7-4d4e-92e5-bb9fb6bb79d7
{"errors":[{"code":"UNAUTHORIZED","message":"unauthorized"}]}

除了上面提到的search接口，当然也还有一些不需要鉴权的：

ubuntu@primary:~$ curl -i -k "http://x.x.x.x/api/v2.0/systeminfo"HTTP/1.1 200 OKServer: nginxDate: Tue, 17 Jan 2023 12:51:57 GMTContent-Type: application/jsonContent-Length: 85Connection: keep-aliveSet-Cookie: sid=680ed830b0fe8efd90039d2421460cbf; Path=/; HttpOnlyX-Request-Id: 0f905796-e5a1-43ae-86d9-f2e0bf13a650X-Frame-Options: DENYContent-Security-Policy: frame-ancestors 'none'
{"auth_mode":"db_auth","harbor_version":"v2.5.0-98e1b82f","self_registration":false}

可以得到版本信息等

ubuntu@primary:~$ curl -i -k "http://x.x.x.x/api/v2.0/projects"HTTP/1.1 200 OKServer: nginxDate: Tue, 17 Jan 2023 12:56:04 GMTContent-Type: application/jsonContent-Length: 378Connection: keep-aliveSet-Cookie: sid=22646ce047d268433b33be9e998156db; Path=/; HttpOnlyX-Request-Id: 5d82950b-a83a-40c9-a6d5-2088ee1304c6X-Total-Count: 1X-Frame-Options: DENYContent-Security-Policy: frame-ancestors 'none'
[{"chart_count":0,"creation_time":"2023-01-03T02:55:37.858Z","current_user_role_ids":null,"cve_allowlist":{"creation_time":"0001-01-01T00:00:00.000Z","id":1,"items":[],"project_id":1,"update_time":"0001-01-01T00:00:00.000Z"},"metadata":{"public":"true"},"name":"x","owner_id":1,"owner_name":"admin","project_id":1,"repo_count":0,"update_time":"2023-01-03T02:55:37.858Z"}]

这个projects接口才是这个问题的关键，这个可以不用search就可以直接列举所有的public的项目，并结合下一级的API调用参数对项目进行对应的操作。

所以这个根源就是API接口对于public的project的是不是就不需要任何鉴权问题，因为我注意到Harbor本身是区分usergroups的，结合上面我提到Harbor设计问题，public的理解产生了分歧，或者产品方的设计本身出现混乱：原本public的设计是对Harbor所有用户开放，而不是对所有互联网访问者开放，实际上这个理解区别是非常之大的！当然我需要说明的这些都是我的推测，没有去实际求证。

不忘初心

这种问题存在甲方与安全研究者之间争论是非常正常，也普遍存在的。只是看到一些“友商”还专门写文章“说明”并且不忘diss下另外一些发过漏洞应急公告的厂商，而这个发起diss的厂商比较认同官方的“不是漏洞”的说法，当然我无意于“吃瓜”，只是觉得我们作为安全从业者及组织应该“不忘初心”，而不是为了diss而diss（当然我也diss过很多，你看这篇文章本身就是在diss），在我看来Harbor拥有那么庞大的用户群，很可能出现大量的不安全“滥用”情况，所以我们上面的这些争论并不重要，重要的是作为一个专业的安全公司，应该认真提醒客户注意排查自己有没有用到Harbor，有没有因为不理解publice的范围而带来的安全风险！

实际上这种踢皮球，谁也不愿意出手修复，的“特性”才是“渗透手”们真正喜欢的！所以客户的安全才是真正需要去关心关注的！安全是一个相对概念，我们都需要加尽可能为自己的客户安全负责：我们的产品方以自己产品的用户的安全负责、我们的安全能力输出的乙方为甲方安全负责 … 我们的互联网才会更好更安全！

知道创宇一直坚持“为了更好的更安全的互联网”、“侠之大者，为国为民”的理念输出专业的安全能力。就在前不久2022年12月，以“AI+安全大数据”赋能安全托管实战化能力，发布了“创宇铁卫”网络安全一体化安全托管服务（Managed Security Service，MSS），并“为安全结果负责”强调实战化的“真安全”。

简单一句话就是说：“创宇铁卫”就是创宇的安全专家带着创宇的专业设备贴身为维护您的网络安全！有兴趣的可以先免费挂个号：

从“假漏洞”到“不忘初心”