Apache Superset是一个开源数据可视化和探索工具。它在 GitHub 上有超过 50K 星，并且有超过 3000 个实例暴露在互联网上。在我们的研究中，我们发现这些服务器中的很大一部分——至少 2000 台（所有服务器的三分之二）——正在以危险的默认配置运行。因此，其中许多服务器有效地向公众开放。任何攻击者都可以使用管理权限“登录”到这些服务器，访问和修改连接到这些服务器的数据，获取凭据并执行远程代码。在这篇文章中，我们将深入研究错误配置，跟踪为CVE-2023-27524，并提供补救建议以及如果您是 Superset 用户需要寻找的妥协指标。
一个默认的 Flask 密钥
Superset 是用 Python 编写的，基于 Flask Web 框架。基于 Flask 的应用程序的常见做法是使用加密签名的会话 cookie 进行用户状态管理。当用户登录时，Web 应用程序将包含用户标识符的会话 cookie 发送回最终用户的浏览器。Web 应用程序使用SECRET_KEY对 cookie 进行签名，该值应该是随机生成的，通常存储在本地配置文件中。对于每个 Web 请求，浏览器都会将已签名的会话 cookie 发送回应用程序。然后应用程序验证 cookie 上的签名以在处理请求之前重新验证用户。
Web 应用程序的安全性关键取决于确保SECRET_KEY真正保密。如果SECRET_KEY暴露，没有事先特权的攻击者可以生成并签署他们自己的 cookie 并访问应用程序，伪装成合法用户。现成的flask-unsign工具可以自动完成这项工作：“破解”会话 cookie 以发现它是否由弱签名SECRET_KEY，然后使用已知的SECRET_KEY.
早在 2021 年 10 月，当我们第一次开始研究 Superset 时，我们注意到它默认为安装时的SECRET_KEY值。x02x01thisismyscretkeyx01x02\e\y\y\h最终用户有责任修改应用程序配置以将 设置SECRET_KEY为密码安全的随机字符串。这记录在Superset 配置指南中。但我们很好奇有多少用户实际阅读了文档。因此，我们使用 Shodan 在 Internet 上对 Superset 服务器进行了基本搜索。简单地请求 Superset 登录页面（不尝试登录）返回一个会话 cookie，然后我们通过它来flask-unsign确定它是否使用默认签名SECRET_KEY。令我们惊讶的是，我们发现所有服务器中有 918/1288（> 70%）使用默认值SECRET_KEY！
复现
那么攻击者知道SECRET_KEYSuperset 应用程序可以做什么呢？假设 Superset 服务器不支持单点登录 (SSO)，攻击者可以使用现成的工具包伪造一个user_idor值设置为 1 的会话 cookie，以管理员身份登录。“1”对应于第一个 Superset 用户，他几乎总是管理员。在浏览器的本地存储中设置伪造的会话 cookie 并刷新页面允许攻击者以管理员身份访问应用程序。对于 SSO 背后的 Superset 服务器，可能需要做更多工作才能发现有效值——我们尚未测试此攻击路径。_user_id“flask-unsign“user_id
Superset 旨在实现与各种数据库的集成，以探索数据和创建可视化效果。管理员访问权限使攻击者可以对这些数据库进行大量控制，并能够添加和删除数据库连接。默认情况下，数据库连接设置为只读权限，但具有管理员访问权限的攻击者可以启用写入和 DML（数据模型语言）语句。强大的 SQL Lab 接口允许攻击者对连接的数据库运行任意 SQL 语句。根据数据库用户权限，攻击者可以查询、修改和删除数据库中的任何数据，以及在数据库服务器上执行远程代码。
远程代码执行和凭证收集
Web 应用程序的管理界面通常功能丰富，并导致在应用程序服务器上执行远程代码。我们在各种配置中找到了跨不同 Superset 版本的远程代码执行的可靠路径。在连接到 Superset 的数据库和 Superset 服务器本身上都可以执行远程代码。我们还发现了许多获取凭据的方法。这些凭据包括 Superset 用户密码哈希和数据库凭据，均采用明文和可逆格式。我们目前没有透露任何利用方法，但我们认为感兴趣的攻击者可以很容易地找出它。
更多默认 Flask 密钥
在我们于 2021 年 10 月向 Superset 团队进行初步报告后，我们决定在 2023 年 2 月重新检查 Superset 的状态，看看默认 Flask 密钥的情况是否有所改善。
我们发现，在 2022 年 1 月，该SECRET_KEY值被轮换为新的默认值，并且在这次 Git提交的CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET日志中添加了一条警告。
我们很好奇这种变化是否转化为用户行为的变化。我们从 2021 年 10 月开始重复 Shodan 实验，同时使用原始默认设置SECRET_KEY和新默认设置。我们还包含了SECRET_KEY我们发现的另外两个，一个在部署模板中，thisISaSECRET_1234,另一个在文档 YOUR_OWN_RANDOM_GENERATED_SECRET_KEY中。
对 Superset 实例的基本搜索产生了 3390 个结果，其中 3176 个似乎是真正的 Superset 实例。在这 3176 个实例中，我们发现 2124 个（~67%）使用了四个默认密钥之一。
去年 Superset 的使用有所增加，但默认值的使用SECRET_KEY并没有下降太多。大量安装使用新的默认SECRET_KEY. 为了更加精确，我们扫描了 Superset 实例以获取它们的版本信息，这些信息通常在登录页面上可见。从这里我们得到了版本使用的默认密钥的细分：SECRET_KEY日志中警告的轮换和添加发生在版本 1.4.1 中。可以看出，从1.4.1版本开始，有相当一部分实例仍然以默认key运行。例如，71% 的 Superset 2.0.0 实例和 55% 的 Superset 2.0.1 实例以及 87% 的最新 Docker 版本 0.0.0-dev 实例正在使用默认密钥运行。
对这些数字感到震惊，我们重新确认了上述攻击路径，并再次向 Apache 安全团队提出了这个问题。
修补
Superset 团队对 2.1 版本进行了更新，如果服务器配置为默认SECRET_KEY. 通过此更新，Superset 的许多新用户将不再无意中搬起石头砸自己的脚。
SECRET_KEY这个修复不是万无一失的，因为如果它是通过docker-compose 文件或helm 模板安装的，它仍然可以默认运行 Superset 。docker-compose 文件包含一个新的默认值SECRET_KEY，TEST_NON_DEV_SECRET我们怀疑一些用户会无意中运行 Superset。某些配置还将 admin/admin 设置为 admin 用户的默认凭据。
整治
在 2000 多名受影响的用户中，我们发现了大公司、小公司、政府机构和大学的广泛组合。我们向许多组织发出善意通知，其中一些组织很快就进行了补救。
如果你是 Superset 的用户，你可以在 Github 上使用这个脚本检查你的服务器是否存在漏洞。该脚本使用该flask-unsign工具包来检查 Superset 会话 cookie 是否使用已知的默认值之一进行签名SECRET_KEY。
如果脚本显示您的 Superset 实例存在漏洞，并且您有一个 Superset 实例在 Internet 上运行，我们建议您立即修复或将其从 Internet 上删除。
解决这个问题需要按照此处的说明安全地生成SECRET_KEY并配置它。此外，由于数据库密码等敏感信息也使用 加密SECRET_KEY，因此需要使用新的SECRET_KEY. CLI工具superset自动执行轮换秘密的过程——请参阅此处。
我们尚未验证针对配置了单点登录 (SSO) 的 Superset 安装的利用。user_id如果s 是不可预测的 GUID 而不是自动递增的标识符，SSO 可能会使伪造会话 cookie 变得困难。同时，可能存在其他泄露用户 ID 的攻击路径，或者用户 ID 映射到易于发现的标识符，例如电子邮件地址。即使您的 Superset 安装落后于 SSO，我们也建议进行补救。
检测
判断您是否已经受到威胁并不容易，因为利用这种错误配置可以让任何人伪装成合法用户。Superset 在界面中提供了详细的操作日志，可用于检查用户活动。我们建议寻找不寻常的管理级操作，例如查看或修改数据库配置、添加新数据库、导出数据或 SQLLab 查询历史记录中的异常查询。我们还建议查看应用程序访问日志以检查异常 API 调用，例如对端点的调用/api/v1/database。当然，一旦攻击者完全破坏了服务器，他们就可以轻松地掩盖他们的踪迹。
启发
硬编码 Flask 密钥的问题并不新鲜。Superset 的姊妹项目 Apache Airflow 受到类似问题的影响，该问题被归档为CVE-2020-17526，由 Deliveryhero 的 Junghan Lee 发现。安全研究员@iangcarroll自动发现易受攻击的 Airflow 实例以获得漏洞赏金，并在此处撰写了一篇描述该过程的博文。他描述的身份验证绕过方法与上面描述的完全相同，因为 Airflow 和 Superset 都基于相同的通用框架Flask AppBuilder。
后来@iangcarroll在另一个基于 Flask 的开源数据可视化工具Redash中发现了类似的漏洞。这被归档为CVE-2021-41192。Superset 团队解决此漏洞的方法——如果服务器以默认方式运行则拒绝启动服务器SECRET_KEY——与 Redash 团队采用的方法相同。
很少有大量数据可用于了解安全设计选择如何影响用户行为。检查漏洞和错误配置通常需要跨越道德界限。在这种情况下，我们很幸运。判断 Superset 服务器是否配置错误只需要浏览到登录页面并破解返回的会话 cookie。
人们普遍认为，用户不阅读文档，应用程序的设计应该迫使用户走上一条他们别无选择，只能默认安全的道路。我们收集的数据支持这一常识。我们都知道默认凭据和默认密钥很糟糕，但它们到底有多糟糕？在 Superset 的情况下，不安全的默认 Flask 密钥的影响扩展到大约 2/3 的所有用户。同样，用户不阅读文档。并且用户不阅读日志。最好的方法是将选择权从用户手中夺走，并要求他们采取故意的行动来故意不安全。
参考
•Horizon3 漏洞检查/利用脚本
•配置超集
•GitHub 上的 Apache 超集
•Flask 取消签名工具包
•如果使用默认 SECRET_KEY 运行，则 Apache Superset 拉取请求不启动服务器
•Flask 配置处理：SECRET_KEY
•超集部署模板
•CVE-2023-27524：使用提供的 SECRET_KEY 时的超集会话验证漏洞
•CVE-2020-17526：Airflow 身份验证旁路错误配置
•CVE-2021-41192：Redash 身份验证绕过错误配置
翻译自网络
原文始发于微信公众号（闲聊知识铺）：CVE-2023-27524：Apache Superset远程代码执行
