Laravel调试模式开启导致管理员凭证泄露及敏感报告泄漏风险

背景

11年前，Benjamin与我曾在BMJ Careers发表文章《There’s a medical app for that》，帮助读者评估医疗应用的安全性。当时我们关注的是患者安全，而如今焦点转向了医疗工作者自身的安全。

让我们深入分析一款用于报告工作场所不当行为的应用——#zouikwatzeggen-app（意为“#我会说些什么”应用）。这款应用真的安全吗？

该应用旨在提高对不当行为的认识，并展示如何讨论这些问题。它还提供一个报告按钮，允许用户（匿名）直接向相关负责人报告不当行为。该应用是一个更大的电子学习包的一部分，内容包括预防不当行为和相关研讨会。

工作场所的不当行为形式多样：流言蜚语、欺凌、排斥、恐吓、言语和身体攻击、歧视、冲突以及性言论或行为。

归根结底，减少不当行为是大家的共识。应用或许能有所帮助，但我们必须确保应用本身在处理高度敏感数据时尽可能安全。

侦察：应用如何工作？

作为安全研究人员，我们对“通过应用发送报告”的功能产生了兴趣。这是如何实现的？是某种将数据转发到电子邮件的表单吗？涉及哪些参数？支持此功能的代码托管在哪里？服务器是否安全？

我们从Android应用开始，因为可以轻松下载应用并修改代码以拦截应用产生的流量。

如今所有应用都使用HTTPS进行通信，通过修改代码，我们禁用了这些安全检查。修改后，我们可以通过Burp Suite路由应用流量并检查/操纵它。

有多种方法获取应用的APK安装文件。方法一：从Google Play商店在Android手机上安装应用，并使用此处描述的方法提取APK。方法二：信任第三方下载网站并下载APK；参见https://apkpure.com/上的深层链接。

拦截应用流量

获取APK后，我们使用APK-MITM修改APK，使其不再检查HTTPS证书；它需要接受我们通过Burp强制使用的HTTPS证书。

安装apk-mitm后，我们可以运行：

1

apk-mitm \#Zouikwatzeggen_2.2.2_Apkpure.apk

来修改它。

修改APK文件后，我们可以使用ADB将应用安装到手机上（参见此页面获取说明）。专业提示：使用scrcpy在桌面上捕获手机屏幕，如果您想同时捕获两个屏幕，如下面的视频所示，这将非常方便。

准备手机以便与Burp Suite配合工作。参见此教程为例。如果仍然无法用Burp拦截流量？您可以使用以下命令将Burp Suite证书直接注入修改后的APK：

1

apk-mitm \#Zouikwatzeggen_2.2.2_Apkpure.apk --certificate cacert.pem

cacert.pem文件通过运行以下命令创建：

1

curl --proxy http://127.0.0.1:8080 -o cacert.der http://burp/cert && openssl x509 -inform DER -in cacert.der -out cacert.pem

在APK中注入Burp证书后，应用流量拦截成功。左侧显示应用发出的请求。

我们现在能够拦截应用与其后端系统之间的流量。例如，当我们提交新报告时，能够拦截发出的请求：

提交新报告时发送到服务器的请求。它返回一个错误消息，包括堆栈跟踪。

堆栈跟踪错误消息？

这很奇怪。提交报告的功能已损坏，应用返回错误。快速查看请求，我们看到：“recipient”: “null”。开发者在发送表单时忘记了设置电子邮件地址……

此外，返回的错误非常详细。它反映了触发错误的确源代码文件和代码行。这闻起来像是有人在应用发布前没有正确测试所有功能，并且忘记了关闭调试消息。

然而，首先让我们深入挖掘，尝试通过注入我们自己的电子邮件地址作为收件人来修复请求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

POST /formData HTTP/1.1
Host: api.zouikwatzeggen.nl
Cookie: XSRF-TOKEN=eyJpdiI6Ijh6ODVJYTZrQ1lsOHlpbXVCWm51dkE9PSIsInZhbHVlIjoiRnBabGd6U0pCSGw0Y0hyYXlPa1IzcGVoS1BLZkYyeVR6WEtoZlV5N2xUVERpbnd2eGdVSVdPUzQxdjJtTFlLcm9ZNy9pVWR0Rk1CWFlwSlAvQjNmcVdNKzc4czBwZXJSa016YnpJdlVnMjhkTEtSS0c5M1hjOGxYSzdSQ3YvMUUiLCJtYWMiOiI4MzVjZmU1MDVmOTQ1MTliNmY5YTMyOGI4NzliYjM4NWQwMmJkOTFjNGVlN2JlODViY2MzOTQ1NWFkNWI3ZGQ2In0%3D; zouikwatzeggen_fritz_api_v2_session=eyJpdiI6IkMya3ZIcEozV2RpdUg0NkRqUU14V2c9PSIsInZhbHVlIjoiVGo2eGJFaElHek5jREhXL3RGM093R0xZRXlZbm41UldvT3hsMXRRRWV3VktIMVZBL215NTV2TExUQmlGT3Irc1dkT0lEYmFJNWYrQU1KaU9aUmJ6TGt5cVhnSFFPUDhRVkFER1oyTzRnaC83a2x3WUNsbVhKV2s4MmJkTkJRcFIiLCJtYWMiOiI0YWUyZmVlZjk1ZTA1NmVkMjU1MTljMDE0MWYxMDM5Njk0M2I2YjljOWU1ODUzMTRlNmIyNDQ0ODUzOTM0OWVlIn0%3D
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=utf-8
Content-Length: 112
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.14.9
Connection: close
{"message":"https://test.nl <h1>test</h1>","type":"ContactViaAnonymousEmail","recipient":"pentest@protozoan.nl"}

注入我们自己的电子邮件作为收件人。

几秒钟后，我们收到了这封邮件：

漏洞1：能够从#zouikwatzeggen-app向任何人发送电子邮件

我们发现了第一个漏洞：电子邮件欺骗。

尽管影响有限；但有人可以使用应用向任何人发送自定义文本的电子邮件。这对于网络钓鱼活动或仅仅垃圾邮件用户都很方便。

现在让我们仔细查看提交电子邮件表单时返回的头部：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HTTP/1.1 200 OK
Date: Mon, 12 Sep 2022 17:50:06 GMT
Server: Apache/2.4.41 (Ubuntu)
Cache-Control: no-cache, private
phpdebugbar-id: X87122f399eb1db5364428a9111273a8b
Set-Cookie: XSRF-TOKEN=eyJpdiI6Ik9ROW14ckUrbU0xVjdXQzZWMko0R2c9PSIsInZhbHVlIjoiUnFIQW1YZlBSbXVmaEhkREpjeHUyYTRXbUZhY3pyK1JLbmhKaFU0QXQvOUR4YXF1MUJMallOUUZyR05NOVV4S2wyYTZDc2lERTJZU0IxL2RyTzcrZVFhd25ndFpRWXd4WVJtNHFLUVVWdEZ2OTd2MWJBTURGd1Z2VjJIUStHZmIiLCJtYWMiOiI1ZDE3Y2IxZDEyODFkZGRlNWEwMjBkODJjZWUyN2M1ODkxZThjM2Q5OTQ1YTcyNzk2MWEwZmVmNGZmOWYwMmE1In0%3D; expires=Mon, 12-Sep-2022 19:50:06 GMT; Max-Age=7200; path=/; samesite=lax
Set-Cookie: zouikwatzeggen_fritz_api_v2_session=eyJpdiI6Im1hMWpreFZ6VjIwRSsySmtjcjBCbUE9PSIsInZhbHVlIjoiVzRiSy9nZ1F6c0pTZDNLUjE1bUNqR0FTSUM4UDFweG4rVjNsRUVzTGtSdFpSeXFrUnZSOHJUZnhzQU0yalZWMzJKQmhkK2ZSRHVaVjBmNGFzemVXSWNYak9FdHRYa0tmYnlpdnpxTlhOZlZsaVpSd0hwNDVJWVVSRzBBeXpkalkiLCJtYWMiOiI3OGU0Yzk1NTQ1NTRkZDNiYjJlMzQ4ZjkyYWMwNTI3OGVhZTQwNTFlMmJlMDZkMGIyOTY3ODZhOGI5NjI2NDVkIn0%3D; expires=Mon, 12-Sep-2022 19:50:06 GMT; Max-Age=7200; path=/; httponly; samesite=lax
Content-Length: 17
Connection: close
Content-Type: application/json
{"status":"sent"}

PHP调试栏

如果您仔细观察，会注意到phpdebugbar-id；这是PHP开发者使用的一种工具，用于轻松调试已部署应用中的问题。这可能解释了为什么我们收到那些详细的错误消息。应用的调试模式未关闭，并且包含一个PHP调试栏。

让我们看看是否能在桌面上触发调试栏的用户界面。一个简单的方法是访问应用使用的其中一个端点来触发错误。

我们从Burp历史记录中随机选择一个URL，并在浏览器中打开它。 https://api.zouikwatzeggen.nl/getToKnowYou?domain=1&model=App%5CCms%5CModels%5CAfterIntroBeforeQuestionsHolxder（注意Holxder部分是一个触发错误的拼写错误）。

我们获得了调试栏的访问权限！

这里我们发现了第二个漏洞：PHP调试栏暴露。请参见https://github.com/barryvdh/laravel-debugbar以了解更多关于其所有功能。

这个漏洞让我们洞察应用背后的代码、其设置和活跃用户会话及其数据。正如我们所理解的，这是一个问题。但我们需要一个概念证明，让组织中的每个人都能理解，这对阿姆斯特丹UMC的15,000名员工有什么影响？他们如何受到影响？如果我告诉董事会“PHP调试栏未关闭！”，他们可能会耸耸肩。

尽可能提供一个人人都能理解的概念证明，同时限制由此造成的损害。例如：我们现在能否使用这个调试栏泄漏我们自己提交的一份关于不当行为的报告？

左侧是我们的手机刚刚发送的报告，右侧是暴露的调试栏。灰色部分是用于搜索我们刚发送报告泄漏的Burp Suite。蓝色标记了实际的泄漏。

好的。这很严重；我们可以泄漏提交的报告。

调试栏允许列出服务器所有访问者的最新请求。这包括不当行为报告的提交。在调试栏用户界面中，它不反映这些报告的确切细节。然而，当有人拦截调试栏流量（使用Burp Browser）时，它将反映所有报告的细节。

上面的概念证明视频可能有点快，所以让我们仔细看看。

步骤1：打开请求模态框。 按下文件夹图标打开活跃会话的模态框。

步骤2：打开来自应用的传入POST请求。 打开请求/formData。

步骤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服务器到外部供应商的内部邮件服务器，并中继到阿姆斯特丹UMC（或使用该应用的其他医院之一）的电子邮件服务器。由于电子邮件默认不加密，如果任何涉及的服务器被入侵，可能会产生风险。

每当实施OpenPGP加密时，影响将是“泄漏的加密电子邮件”，与当前情况相比，影响较小。电子邮件的接收者需要实施OpenPGP才能使用秘密私钥解密内容（只有应该能够查看报告的人知道）。

剩下的风险是供应链攻击（有人替换应用代码并嗅探报告）、网络钓鱼（有人发布模仿原始应用的恶意应用并嗅探报告）或接收者的邮箱被入侵。最后但并非最不重要的是，当接收者的邮箱因任何原因失败，电子邮件被发送回实际发件人，即webmaster@.nl（参见漏洞1的截图），内容将泄漏给有权访问webmaster@.nl帐户的人（不太可能发生，但需要考虑）。

透明就是信任

我能够毫无问题地发布这篇博客的事实非常重要。感谢协调漏洞披露（CVD）政策。

对这样的漏洞保持沉默不是前进的方向。正如在医学中，我们都从他人犯的错误中学习。这不是关于羞辱犯这个错误的人，而是从中学习并为每个人创造更安全的环境。

正常工作的CVD的一个很好的例子

在我按下错误报告的发送按钮后，只用了10分钟就收到了相关CERT的回复。当时是当地时间20:30，但他们确认了漏洞并采取行动通知供应商。

在提供关于额外影响（泄漏的管理员凭据）的更多信息后，我有同样的体验；快速回复并采取适当行动。

该应用由外部供应商托管，这份报告展示了当并非所有基础设施都在您控制之下时所面临的挑战。供应商的安全水平与您自己托管的应用程序相同吗？更重要的是，他们也支持CVD吗？

然而，这份报告是CVD如何帮助您的组织使一切更安全的一个很好的例子。快速行动并消灭漏洞！

免责声明

正如你们中的一些人所知，我自己在受影响的医院工作，然而这项研究是在我的业余时间完成的。作为SCIRT（SURF事件响应团队社区）的一部分，我很高兴分享我的见解并在需要时提高意识。

时间线

• 2021年6月17日：首次宣布应用可用；仅限学生
• 2022年9月7日：宣布应用