minio未授权信息泄露漏洞：一个被低估的授权存储层风险

一次渗透测试中，我随手输入了一个MinIO控制台的信息泄露默认端口9000，没带任何凭证，漏洞页面竟然弹出了存储桶列表。授权里面躺着几十个数据库备份文件，信息泄露时间戳显示最近一次备份就在两小时前。漏洞这不是授权什么高深攻击，只是信息泄露目标把MinIO部署在了公网，且没改任何访问策略。漏洞

MinIO作为开源对象存储，授权常被当作S3的信息泄露本地替代品。很多团队图省事，漏洞直接跑默认配置，授权以为内网就安全。信息泄露但现实是漏洞，MinIO的默认配置里，匿名用户能调用ListBuckets接口。攻击者只需发一个空的GET请求到/，就能拿到所有桶名。再遍历桶内对象，连下载权限都未必被拦截。整个过程不需要密码，不需要token，curl一条命令搞定。

问题根源不在MinIO本身，而在部署者的“想当然”。我见过不少案例，运维把MinIO当普通文件服务器，忽略了它本质上是一个HTTP服务。它跟Apache、Nginx一样，暴露在公网就必须面对扫描器。Shodan上搜“MinIO”，全球暴露实例成千上万，其中相当一部分响应了匿名的桶列举请求。

更隐蔽的泄露路径是Presigned URL。就算管理员设置了桶的私有读写，如果应用代码里生成了预签名URL用于分享文件，而URL有效期设得过长——比如一天甚至一周——那这个URL本身就成了泄密通道。攻击者拿到一个有效签名，就能在有效期内反复下载对象，直到过期。这个细节常被开发忽略，他们只检查了桶的ACL，却忘了签名URL是独立的授权凭证。

还有一类特殊场景：MinIO与K8s集成。很多集群用MinIO做PV后端，或存日志、监控数据。如果MinIO的Service类型是NodePort或LoadBalancer，且没加网络策略限制来源IP，那任何能触达该节点端口的人都能尝试匿名访问。2023年某云厂商的故障复盘里，就有攻击者通过MinIO漏洞读取了集群内的etcd备份，导致管理员凭证泄露。

修复方案并不复杂。第一，确保所有桶显式设置访问策略，默认拒绝匿名读写。第二，关掉控制台的匿名登录，强制使用IAM用户。第三，给MinIO套一层反向代理，加Basic Auth或IP白名单。第四，定期审计审计日志里的Anonymous请求。这些动作十分钟能做完，但很多人就是不做。

最后说点个人的刺耳判断：MinIO的文档把“简单”当卖点，但简单不等于安全。默认配置下，它就是一个带Web界面的文件服务器，而文件服务器一旦暴露在公网，未授权访问只是时间问题。别把希望寄托在“没人知道这个端口”上——扫描器比你想象的更有耐心。