Laravel调试模式未关闭导致管理员凭证泄露及敏感报告暴露
背景
11年前,Benjamin与我在BMJ Careers发表了《There’s a medical app for that》一文。当时我们关注的是患者安全,而今天我们将重点关注医疗工作者自身的安全。
让我们仔细研究这款允许报告工作场所不当行为的应用——#zouikwatzeggen-app(直译:#我会说些什么应用)。这款应用使用起来安全吗?
该应用提高了对不当行为的认识,并展示了如何将其变为可讨论的话题。还有一个报告按钮,可以直接(匿名)向合适的人报告不良行为。该应用是关于预防不良行为的电子学习包和该主题研讨会的一部分。
工作场所的不良行为以多种方式出现:流言蜚语、欺凌、排斥、恐吓、言语和身体攻击、歧视、冲突以及性言论或行为。
归根结底,我认为每个人都同意减少不良行为是件好事。应用程序可能会有帮助,但我们需要确保应用程序本身在处理高度敏感数据时尽可能安全。
侦查:应用程序具体如何工作?
作为安全研究人员,我们对"使用应用程序发送报告"的功能很感兴趣。这是如何工作的?某种将数据中继到电子邮件的表单?哪些参数?支持此功能的代码托管在哪里?这台服务器是否得到适当保护?
让我们从Android应用程序开始,因为我们可以轻松下载该应用程序并修补代码,以便能够拦截应用程序发出的流量。
如今所有应用程序都使用HTTPS进行通信,通过修补我们禁用了这些安全检查。修补后,我们可以通过Burp Suite路由应用程序的流量并检查/操纵它。
有多种方法可以获取应用程序的APK安装文件。
方法1 — 从Google Play商店在安卓手机上安装该应用程序,并使用此处描述的方法。
方法2 — 信任第三方下载网站并下载APK;参见https://apkpure.com/上的深层链接。
拦截应用程序流量
获得APK后,我们使用APK-MITM修补APK,使其不再检查HTTPS证书;它需要接受我们Burp强制实施的HTTPS证书。
安装apk-mitm后,我们可以运行:
|
|
来修补它。
之后,我们可以使用ADB将应用程序安装到手机上(有关说明,请参见此页面)。专业提示:使用scrcpy在桌面上捕获手机屏幕,如果您想同时捕获两个屏幕,如下面的视频所示,这非常方便。
准备您的手机,使其可以与Burp Suite协同工作。例如,参见本教程。使用Burp拦截流量仍然有问题?您可以使用以下命令将Burp Suite证书直接注入到修补后的APK中:
|
|
cacert.pem
文件是通过运行以下命令创建的:
|
|
我们现在能够拦截应用程序与其后端系统之间的流量。例如,当我们提交新报告时,我们能够拦截发出的请求:
堆栈跟踪错误消息?
这很奇怪。提交报告的功能被破坏,应用程序返回错误。快速查看请求,我们看到:"recipient": "null"
。开发人员在发送表单时忘记了设置电子邮件…
此外,我们返回的错误非常详细。它反映了触发错误的确源代码文件和代码行。这闻起来像是有人在应用程序发布前忘记了正确测试所有功能,并且忘记了关闭调试消息。
然而,首先让我们更深入地挖掘,尝试通过注入我们自己的电子邮件地址作为收件人来修复请求。
|
|
几秒钟后,我们收到了这封电子邮件:
漏洞1:能够从#zouikwatzeggen应用程序向任何人发送电子邮件
我们发现了第一个漏洞:电子邮件欺骗。
尽管影响有限;但有人可以使用该应用程序向任何人发送带有自定义文本的电子邮件。这对于网络钓鱼活动很方便,或者只是为了在互联网上向用户发送垃圾邮件。
现在让我们仔细查看提交电子邮件表单时返回的标头:
|
|
PHP调试栏
如果您仔细观察,会注意到phpdebugbar-id
;这是PHP开发人员使用的一种工具,用于轻松调试已部署应用程序上的问题。这可能解释了为什么我们得到那些详细的错误消息。应用程序的调试模式未关闭,并且它包括一个php调试栏。
让我们看看是否能在桌面上触发调试栏的用户界面。一个简单的方法是访问应用程序使用的其中一个端点来触发错误。
我们从Burp历史记录中随机选择一个URL并在浏览器中打开它。
https://api.zouikwatzeggen.nl/getToKnowYou?domain=1&model=App%5CCms%5CModels%5CAfterIntroBeforeQuestionsHolxder
(注意Holxder部分是一个触发错误的拼写错误)。
漏洞2:php调试栏暴露
请参阅https://github.com/barryvdh/laravel-debugbar以了解其所有功能。
此漏洞使我们能够洞察应用程序背后的代码、其设置和活动用户会话及其数据。正如我们所理解的那样,这是一个问题。但我们需要一个概念证明,让组织中的每个人都能理解,这对阿姆斯特丹UMC的15,000名员工有什么影响?他们是如何受到影响的?如果我告诉董事会"PHP调试栏未关闭!",他们会耸耸肩。
只要可能,我们应该提供一个每个人都能理解的概念证明,同时限制这样做所造成的损害。例如:我们现在能否使用此调试栏泄露我们自己提交的关于不当行为的报告之一?
好的。这很严重;我们可以泄露提交的报告。
调试栏允许列出服务器所有访问者的最新请求。这包括不当行为报告的提交。在调试栏用户界面中,它并不反映这些报告的确切细节。但是,当有人拦截调试栏流量(使用Burp浏览器)时,它将反映所有报告的详细信息。
上面的概念证明视频可能有点快,所以让我们仔细看看。
步骤1:打开请求模态框。
步骤2:打开来自应用程序的传入POST请求。
步骤3:拦截PHP调试栏关于此请求发出的请求,在Burp中检查响应,并搜索字符串Serieuze
以查看是否能找到我们报告的一部分(并确认泄漏)。
漏洞2:响应包含不当行为报告消息
换句话说,人们可以监视此端点https://api.zouikwatzeggen.nl/_debugbar/open?op=get
,无需身份验证,每隔几秒存储一次输出。这允许人们近乎实时地捕获员工发送的所有报告。
我们现在已经证明了该漏洞会泄露报告详细信息,但是否还有更多?
我们还能做些什么来利用这个调试栏实现RCE?
泄露管理员密码
如果系统管理员使用相同的Web应用程序访问管理面板怎么办?我们能够泄露密码吗?
让我们监视此服务器上的传入请求几个小时,看看我们是否幸运地监视到管理员登录:
太好了!正如我们所见,路径/cm/login
被另一个用户请求。让我们看看用于此登录的凭据。
漏洞3:管理员用户名和密码被泄露
我们现在证明了这个漏洞给了我们访问管理员仪表板所需的凭据。
是时候停止我们的研究并与CERT分享我们所有的见解了。
讨论,不伤害原则——Primum non nocere
现代(和古老)医学的基本原则之一是,我们需要确保我们的干预确实有助于解决问题,而不是实际上使其变得更糟。
如果提交者的高度敏感数据被泄露,或者关于不知情的不当行为潜在对象的报告细节被泄露,会怎样?这会对我们对系统的整体信任产生什么影响?
一个有趣的观点是,尤其是这条"不伤害"规则使我们在医学上建立了适当的(透明的)程序,然后我们才能甚至在人类身上研究医学干预。当您想研究一种新的干预措施时,您需要获得研究伦理委员会的批准。出错的风险是什么?如果出错,影响是什么?它可能造成伤害吗?此外,您被强制报告不良事件,因此研究可以关闭,或者可以提前告知新参与者。
一如既往,我尝试分享当我们试图让数字世界更安全时,我们可以从医学中学到什么,反之亦然。
实施威胁建模
在发布这样的应用程序之前需要做什么?这是一个难题,让我分享我的想法。然而,我很高兴向您学习,所以请改变我的想法并在下方留下您的评论!
我的建议是事先进行适当的渗透测试,修复发现的错误,然后执行系统化的威胁建模,如includesnodirt.com(邀请黑客、开发人员、隐私官、最终用户和CERT成员)。
完成此操作后,将结果提交给一个小型委员会,就像我们在医学上称为研究伦理委员会的委员会一样(如果可能,包括伦理学家),并决定风险是否值得潜在收益。对于一个"简单的应用程序"来说,这听起来很麻烦。然而,员工/客户的信任受到威胁,一个错误可能会严重影响其他(正常工作的)应用程序的信任。所以"不伤害"并尝试证明您的应用程序是否真的解决了问题,如果没有,请关闭它(我喜欢在医疗保健中看到更多基于证据的政策)。
可能的改进
如果认为有必要发布这样的应用程序,我建议做一些事情来限制如果出现问题时的爆炸半径。一个良好的开端是对最敏感的数据实施客户端加密。
我们可以使用OpenPGP,这是一种开源的、经过实战检验的加密协议,允许在消息离开设备之前对其进行加密。有关在客户端工作的示例,请参阅OpenPGP文档。
此时,应用程序中的消息被发送到外部供应商的Web服务器,从Web服务器到外部供应商的内部邮件服务器,并中继到AmsterdamUMC(或使用该应用程序的其他医院之一)的电子邮件服务器。由于电子邮件默认不加密,如果任何涉及的服务器遭到入侵,可能会产生风险。
每当有人实施OpenPGP加密时,影响将是"泄露的加密电子邮件",与当前情况相比,影响较小。电子邮件的接收者需要实施OpenPGP,以便使用秘密私钥解密内容(只有那些应该能够查看报告的人知道)。
剩下的风险是供应链攻击(有人替换应用程序的代码并嗅探报告)、网络钓鱼(有人发布模仿原始应用程序的恶意应用程序并嗅探报告)或者当接收者的电子邮件箱遭到入侵时。最后但并非最不重要的是,当接收者的电子邮件箱因任何原因失败并且电子邮件被发送回实际发件人,即webmaster@<app-developer-name>.nl
(参见漏洞1的屏幕截图)时,内容将泄露给有权访问webmaster@<app-developer-name>.nl
帐户的人(不太可能发生,但需要考虑)。
透明就是信任
我能够毫无问题地发布这篇博客的事实非常重要。感谢协调漏洞披露政策。
对这样的漏洞保持沉默不是前进的方向。就像在医学中一样,我们都从别人犯的错误中学习。这不是为了羞辱犯这个错误的人,而是为了从中学习并为每个人创造一个更安全的环境。
一个良好运作的CVD的绝佳例子
在我按下错误报告的发送按钮后,只用了10分钟就收到了相关CERT的回复。当时是当地时间20:30,但他们确认了错误并采取行动通知供应商。
在提供了关于额外影响(泄露的管理员凭据)的更多信息后,我也有同样的体验;快速回复并采取了适当的行动。
该应用程序由外部供应商托管,此报告展示了当并非所有基础设施都在您控制之下时所面临的挑战。供应商是否与您自己托管的应用程序具有相同级别的安全性?更重要的是,他们也支持CVD吗?
然而,这份报告是一个绝佳的例子,说明了CVD如何帮助您的组织提高一切安全性。快速行动并消灭错误!
免责声明
正如你们中的一些人所知,我本人就在受影响的医院工作,但这项研究是在我的业余时间完成的。作为SCIRT(SURF社区事件响应团队)的一员,我很高兴在需要时分享我的见解并提高认识。
时间线
- 2021年6月17日 — 首次宣布应用程序可用性;仅限学生
- 2022年9月7日 — 宣布应用程序可用性;所有15,000名员工
- 2022年9月12日 — 发现电子邮件欺骗漏洞,报告给CERT
- 2022年9月12日 — 发现PHP调试栏漏洞,报告给CERT
- 2022年9月12日 — CERT在10分钟内回复确认漏洞
- 2022年9月13日 — 发现管理员凭据,报告给CERT
- 2022年9月13日 — CERT确认入侵并命令供应商关闭服务器。CERT报告了数据泄露。
- 2023年3月23日 — 受邀在SURF安全与隐私会议上分享漏洞详情
- 2023年5月29日 — 撰写了此博客的第一稿,并与AmsterdamUMC CISO共享以协调披露。
- 2023年6月20日 — AmsterdamUMC允许披露该漏洞
- 2023年6月29日 — 展示上述研究,发布博客
- 2023年6月29日 — 从AmsterdamUMC获得"谢谢!“钥匙扣奖