Harbor 未授权漏洞的背后是魔幻的荒诞主义
前言
怎么说呢，心里五味杂陈，面对在大年前横空而来的 CVE-2022-46463，以及一通测试复现后，面对着电脑屏幕久久说不出话来，于是便有了这篇文章。突然感觉安全已经进入到了一个魔幻的荒诞主义：我们还有什么可信的东西？
大家可以当作一篇小说看看吧。
事情经过
事情要从我的一个安全朋友说起。
起因
1.16日，天高气爽，想着还有两天就要放假回家过年的心，根本无法集中在工作中，于是在摸鱼冲浪的时候，突然发现了一篇紧急通告，
CVE-2022-46463 漏洞预警
很快啊，赶紧点进去一看，发现是一个名为harbor的未授权漏洞，私有 和 公开 仓库镜像可以被未授权获取，可能导致敏感信息泄漏。
一打眼看到的漏洞评级 严重 吓了一激灵，并且显示POC已经在野利用了？还两天过年了，要是这么严重的问题，还怎么安心回家过这个团圆？
由此，开启了一段魔幻的 "漏洞" 修复过程。
追踪
根据互联网的信息，发现各平台预警，除CVE外，所有链接均指向了一个 github 仓库，
在这个github仓库里，标记的很清楚的复现步骤啊：通过登录页面的搜索接口，可以搜索到显示为 私有 项目的仓库。
这还是挺吓人的，利用方式简单、影响严重，可能会导致公司几千个私有镜像被他人获取，后果不堪设想。
按照cve给出的影响范围：
1.x <= Harbor <= 2.5.3
很不幸，自家的harbor正好在范围内，看来年前又要找运维大哥去帮忙修复了。
坎坷的复现
去找运维大哥帮忙，作为安全人员，肯定先要自己搞明白了再去摇人，于是就拿着公司的harbor尝试了一下，发现好像有点不对劲： 不论我怎么搜索，从 a-z都只能显示公开仓库的数据，并无漏洞所描述的 私有仓库数据。
会不会是复现的步骤有问题？又重新读了一遍整体的逻辑，会不会是我们公司的仓库就没有 私有 属性的呢？
赶紧去和运维大哥确认了一下，发现的确存在 私有 镜像，可为什么这个漏洞却搜不到呢？
怀着窘迫的心在harbor 官方仓库不断寻找，发现，好像官方也没对这个漏洞进行相关 fix的提交记录哎，那预警里面的 请升级到最新版本 是如何得出的呢？
一定是自己功夫还不够深，一定是自己的姿势还不太对，此时的菜鸡的安全人员还没有意识到问题的严重性和魔幻性，依旧还在自身寻找问题。
反转
1.17日，复现一天无果的安全人员，气急败坏只能继续摸鱼，然后发现了另一篇通告：
关于Habor CVE-2022-46463的说明
文章大概就是经过测试，所有版本都没有搜索到私有仓库；同时还分析了search api 的认证逻辑。官方手册指出 公开仓库 能够被搜索到，属于产品特性。这个CVE甚至称不上是漏洞。
事情开始变得魔幻起来了。
未完待续
从事情开始出现反转后，便开始出现了各路声音：有人为这个漏洞就不该出现CVE的；有认为Harbor设计不合理的，就因该算Harbor的漏洞；有认为Harbor应该修改默认选项来避免出现滥用的不安全配置的，等等等等。
截止至发文今日，搜索该CVE编号，依旧能够发现大量的"安全公告",无一例外都是相同的漏洞描述，相同的影响范围，相同的修复建议。
我们仍未知道那天所看见的cve的名字。
来关注漏洞
故事讲完了，我们来实际关注下漏洞。
根据 https://github.com/lanqingaa/123 所描述的poc, harbor v1 v2版本均存在该问题，但是自己观察会发现，该作者在v1的截图中的确搜到了显示为 private 的仓库：
但是在 v2 的版本中，他给出的结果却是 public 仓库。
再回看漏洞描述：
Harbor 中存在访问控制错误问题，允许攻击者无需身份验证即可访问公共和私有镜像存储库的所有信息，并拉取镜像。
理清逻辑
首先要明确一下几个点：
- 第一，私有化仓库到底能不能像漏洞所描述的那样，被搜索发现？
- 第二，仅能访问到公开仓库，是否还能被称之为漏洞？
如果第一点成立，那么 CVE-2022-46463 无疑是一个高危漏洞，未认证户通过该漏洞可以获取到了认证用户的权限，明显的越权问题。
如果第一点不成立，也就是该接口只能获取到公开仓库的情景下，问题自然而然的来到了第二点：如果仅能够访问到公开仓库的信息，是否还存在风险呢？
在讨论第二点的同时，我们还需要预先讨论一个问题：
- 公开仓库的概念到底是面向所有认证用户还是所有用户？
带着这几个问题，我们亲自去复现一波这个魔幻的 CVE-2022-46463
复现
v2
因为目前harbor的release多数为v2, 就先使用v2的版本进行了复现：
首先我们用权限账户登陆，可以看到仓库存在 private/public两种项目。
其中，私有的library内存在如下镜像。
我们退出账户，尝试去搜索：
毫无结果，再尝试搜索一下公开镜像：
确实获取到了列表信息。
总结: v2仅能够搜索到公开镜像。
v1
在测试无果的情况下，想到：会不会是v1和v2的版本存在差异呢？
于是我们来尝试，使用和https://github.com/lanqingaa/123 作者完全一致版本的v1进行尝试：
与v2相同，我们先创建私有的仓库，然后上传测试镜像：
然后退出登录，尝试搜索私有仓库：
无果，再尝试搜索下公开的 library 仓库
？？？ 的确出现了私有仓库，但是仔细看？是在管理面板内为public权限的library
为了更有效的说明这个事情，我们再创建个公开仓库：
然后退出登录，再次搜索：
结果两个公开仓库都被搜索出来了，而且还标注着private
.......看到这里的各位，应该能猜测这是一个什么问题了。
个人观点
经过复现，我想大家也知道这个 CVE-2022-46463 到底是个如何的漏洞了：通过该接口，能够搜索到所有的公开仓库。
对于第一点，已经没有讨论的必要了，问题来到第二点：仅能搜索到公开仓库，到底还是不是一个漏洞。
在判断是否是个漏洞之前，需要先达成两点共识：
- public 镜像，到底是面对所有用户，还是所有的认证用户。
- 到底什么才叫做漏洞
个人认为，harbor很明显的认为 public 镜像是针对所有用户。可以从官方的手册上搜索到public 的概念，也可以类比 dockerhub 私有镜像和公开镜像的概念。因此我个人认为，public 的定义并无任何问题。
而至于：什么是漏洞，我想引介《我的安全世界观》中的观点：
程序的目的是为了实现业务功能
程序的实现可能额外实现了些其他的功能
这些其他的功能影响到安全，就可以被称漏洞。
其中，影响安全才是定义的关键。
来看这个api的设计，harbor的定位就是想要搜索到所有的 public 镜像，程序完美的实现了目的，且没有搜索到额外的private镜像。 程序没有做超出业务功能的事情；同时在官方的手册里，清晰明了的定义着什么是public权限。
除此外，我们再来看影响：搜索到公开仓库，会对企业带来什么样的影响，有怎样的安全隐患。
在该漏洞所描述中，公开仓库可能会“导致信息泄露”，获取到镜像信息。
我们知道，镜像其实就是一个打包好的分层的文件系统。那么对于获取到这个文件系统的人来说，他可以获取到这个镜像内部的任何信息。
如果说是由于harbor 的原因导致的这部分信息泄漏，那么即使是公开的镜像，harbor 也应该为这个事情负责。而事实是，任何获取到这个文件系统的人，都能够获取到harbor 所展示出的这部分信息。 这样来讲，harbor只是个搬运工而已，仅仅展示了一些任何人都能够读到的数据而已。导致信息泄露的，应该是归属于 “镜像安全” 的范畴。
因此，我们应该把漏洞中所描述的“敏感信息泄漏”，视作是镜像安全问题，而并非harbor 应用本身。漏洞的原因是在于镜像夹杂了不应该被打包进去的数据。该问题并不关心你是用的是harbor 仓库还是portus 仓库，还是dockerhub 仓库，他就是这个镜像本身携带的问题。
唯一能被视为漏洞影响点的，就是在于，用户如果想获取有哪些镜像的这个信息，原本只能够通过猜测或已知的镜像名称，通过pull 的方式获取到镜像本身。在未知镜像名的条件下是比较困难批量获取到更多信息的，只能尝试暴力猜解。而公开仓库搜索提供了这样一个便利的入口来展示当前能获取的镜像列表，对攻击者提供了帮助。
这样，问题又回到了第二个点。public 仓库面向所有用户而非认证用户，是否存在问题。
当业务功能存在部分风险时，那么应该告知并警惕用户使用的方式，正确使用该功能。我们来看下harbor是如何做的：
在项目创建页面，harbor清楚的描述着 什么叫做public仓库，告知了： "无需login即可docker pull"。同时，公开仓库还是一个非默认选项，默认创建的仓库都是私有的。我实在想不出还有什么别的方式能够来"帮助" 用户 建设意识上的安全问题。
就好比 php exec函数，你不能说exec可能会执行恶意命令，就直接说php存在漏洞，而直接不允许了业务使用该函数。exec本身并不是漏洞，但当你使用的方式不正确时，的确会造成一定的安全风险。这个比喻模型同样可以适用于 CVE-2022-46463。
综合评估
最终，我们为这个"漏洞"（如果非要说是的话，毕竟有了CVE编号）做一个客观的评估。
漏洞描述
Harbor api search 允许未认证的用户搜索仓库内存在的 公开仓库，若将私有业务镜像放置于公开仓库，可能存在信息泄漏风险。
漏洞级别
中危偏低，无需紧急修复，但仍需引起注意，排查仓库权限设置是否正确。
漏洞修复建议
官方最新版本仍存在上述特性，升级修复属于无稽之谈。
对于无public需求的用户
直接全部设置为私有项目即可。
对于仍需public功能但又担心风险的用户
可以手动创建一个全局用户，然后将这个用户添加到所有项目中，最后将所有项目设置为私有。
这么做可能会导致，原本可以直接获取到的镜像信息，现在都需要使用该账户进行认证后获取，可能会对您的自动化业务(如 CI/CD) 产生影响。
除此之外，您也可以考虑从根源解决问题。该漏洞最大的安全隐患在于 敏感信息的泄漏。而这些风险来自于没有进行过安全检查的公开镜像。因此，可以使用云安全工具进行检测，如：使用 Veinmind-SaaS 版本对harbor仓库进行扫描，支持云探针扫描方式，无需部署探针，实现快速一键式解决公开镜像的安全问题：
也可以选择轻量级的 Veinmind-Tools 对您重点关注的镜像，一一进行人工排查，保证您的镜像安全。
除此以外，对于仍认为 public 仓库应该在登陆后才能够被访问的用户，可以选择非harbor的同级别产品如portus，所有的仓库必须在登陆后才有权限访问，即使是public仓库。
最后
整个CVE 从最初的大家都无法复现却存在编号的漏洞，到有人站出来说根本不应该称之为漏洞，再到认为Harbor的设计不合理，没有做到所谓的“尽可能的安全设置作为默认设置”，到最后的呼吁不要仅关注漏洞本身，而是要更关注客户的安全，为客户负责的角度。 这个"漏洞"属实在2022年的年终 荒诞而又魔幻的 结束了这荒诞而又魔幻一年。
从安全的角度来想，我不理解为什么这样的一个"漏洞"，如此简单粗暴的过程，无官方的fix记录，仅有一堆雷同式的公告，却鲜有不同的声音。
从产品的角度上来想，我觉得这类的安全问题，并不是一个产品上能够 cover 的事情，而是用户意识上的安全。类比弱口令，如果我们真的认为，默认复杂的密码就可以解决弱口令的问题，而没有关注用户自身意识的安全建设，那么对于安全意识较差的用户来讲，他甚至可能会觉得默认密码过于复杂而吐槽产品，然后自行将密码修改为了弱口令。为什么一个开源的产品，明确写的特性，明确写的功能提示，还需要为用户的安全意识建设买单？
手机很好用，但你总担心手机屏幕的屏保图片会被别人偷窥到你的隐私，你很担心，因为你把有银行卡密码的图片作为了屏保，说这个手机要是屏幕保护不会被偷窥就好了，手机做的还是不够好啊。
有没有一种可能，当大家都意识到屏幕保护就是要给别人看的时候，就不会把隐私的图片，设置为屏幕保护了？我们作为专业人员要做的，是告诉用户，用密码做屏幕保护，这么做不安全，提高用户的意识，而不是和用户一起诟病手机这产品为什么不去做一个只有我自己能看到屏幕保护的功能，去对线开源社区去争执一个特性到底是否是漏洞。
见贤思齐焉，见不贤而内自省也。不论这个CVE最终会如何收尾，不论这个事情会走向何种结局，对于使用了harbor的用户，看到了这个CVE, 都应该思考一下，对于public的理解是否正确，自家使用的harbor会不会同样存在安全隐患；是否需要考虑镜像安全的检测来加强防护。
最后也希望，大家能对开源社区多一些包容，多站在互相的角度进行思考，多把精力集中到一些有价值的事情上去。安全和产品，从来不应是对立面，也永远不会是对立面。
参考链接
17.Veinmind-SaaS : https://rivers.chaitin.cn/app/veinmind
19.Veinmind-Tools : https://github.com/chaitin/veinmind-tools
21.portus : http://port.us.org/documentation.html