【翻译】Hunting Common Misconfigurations in Electron Apps - Part 1
Electron 应用程序通过将 Node.js 和 Chromium 技术相结合,彻底改变了桌面开发。然而,这种便利性如果配置不当也会带来安全风险。在本博客中,我们将检查 Electron 应用程序中最常见的错误配置,攻击者可能利用这些配置来获取代码执行权限或敏感信息泄露。
Electron 是由 OpenJS 基金会开发和维护的一个免费开源软件 (跨平台) 框架。该框架的设计方式是使用 Web 技术创建桌面应用程序,使用 Chromium 浏览器引擎的版本进行渲染,并使用 Node.js 运行时环境作为后端。
你可能知道"Chromium"和"Node.js"这两个组件被广泛使用,这使得此类技术栈的攻击面增加,我们看到多个 CVE 影响这些产品。这是制作 Electron 应用程序的两个主要技术栈;如果配置/加固不当,它们就会存在漏洞。
为什么选择 Electron 但是...?
这是由于以下原因:
-
性能 -
跨平台兼容性 -
简单的开发体验 -
友好的社区和生态系统
例如,开始使用 Electron 最简单的方法是"Fiddle",它带有自定义直接 API 调用,因此你可以看到"BrowserView"或"desktopCapturer"如何工作。简单来说,使用 Fiddle 创建 Electron 应用程序就像使用 WordPress 创建网站一样 - 只需拖放,无需安装依赖项。
当 Web 遇到 Node
Web 浏览器可以访问/控制本机操作系统 API,这会导致客户端漏洞,当你在这类应用程序中发现 JavaScript 执行,即 XSS 可能会导致 RCE(远程代码执行),这是因为 node 运行时环境 (在 EA(Electron App) 中默认启用)。
所以问题是:当 electron 应用程序就像 web 应用程序一样,不需要任何基于操作系统的 API 时,启用 Node 是没有意义的。
很好!到目前为止,我们知道什么是 electron 应用程序以及它们的后端技术栈 (chromium 和 node) 是什么,以及如果配置不当会导致 electron 容易受到多种攻击的主要问题。
糟糕!Electron
现代桌面应用程序需要现代攻击!在下图中,基于关键词搜索"electron",由于配置错误导致信息泄露或代码执行,有超过 55+ 条记录 (CVE) 针对各种 electron 应用程序。
工具,真的吗?
那么,对 electron 应用程序进行审查/评估需要什么工具呢?对于静态分析,electron 有自己的归档机制"Asar"。
@electron/asar - Electron 归档。Asar 是一个简单的可扩展归档格式,可以通过 7-zip/keka 轻松提取。只需喝杯咖啡,审查代码即可。 对于动态分析,理想情况下检查`main.js`并添加"devTools:true",然后使用 DevTools + Burpsuite 代理 接下来,我将讨论在对 electron 应用程序进行审查时,我的检查清单中的五个最常见的错误配置。
#1 调试模式已启用
Electron 应用程序基于 Chrome,因此,如果应用程序没有很好地加固,我们可以在 electron 应用程序中调试渲染器进程。一个典型的例子是"CVE-2024-36287"。在最终用户使用的 electron 应用程序中启用调试模式不是一个好主意。
理想情况下,发布二进制文件时这些调试标志应设置为"false"。然而,这里没有直接的重大影响,但它可能允许攻击者将其与其他可能产生潜在影响的漏洞链接起来。
要识别应用程序是否启用了调试模式,你只需开始浏览应用程序的功能,直到看到一个写着打开"Dev Tools"的栏。
#2 通过 CLI 读取运行时日志
我看到一个非常黑客的方法来做这个。这更像是在做移动应用程序渗透测试时的"logcat",但不完全像"logcat",而是类似的方式。
只需通过命令行提供绝对路径直接运行二进制文件,即"/Applications/Discord.app/Contents/MacOS/Discord",如下面的概念验证所示。
这些信息可用于查看正在使用的模块的详细信息、详细消息,以及应用程序是否正在更新。包的绝对临时路径是什么?在这种情况下,绝对路径将是"/Users/zero/Library/Caches/com.hnc.Discord.ShipIt/update.xxxxx/Discord.zip"
在这种情况下,我们可以检查这些路径是否是全局可写的,允许任何低权限用户修改或添加任何包。一些旧版应用程序通常在应用程序更新时使用"/tmp/xxxx.zip",低权限用户可以制作恶意包来实现代码执行。
#3 基于注入的攻击
如前所述,electron 应用程序下的客户端攻击被认为是高严重性的。这是因为 electron 应用程序具有对操作系统的本机 API 调用,如果应用程序容易受到基于注入的攻击 (即跨站脚本),可能允许攻击者控制和调用操作系统命令。
在这个例子中,我们使用 macOS 版本 1.8.4 的"Notable",由于这个项目没有得到很好的维护,我们可以用它作为例子。Notable 是一个基于 markdown 的笔记应用程序,所以我们知道 mark-down 命令会在应用程序的上下文中呈现。如果应用程序没有正确地净化从用户接收的输入,它可能会导致呈现恶意 JavaScript。在下面的例子中,我们将尝试呈现基本的跨站脚本攻击负载,看看 Notable 应用程序是否呈现它。
在上面的概念验证中,我们试图看看基本负载是否可以被呈现。当我们如下所示保存上述 MD 文件时,注入的 JS 负载没有被呈现,这意味着应用程序实施了一些基本检查来防止此类攻击。
在这种情况下,我检查我们是否可以通过标签/注释来转义它,如下面的概念验证所示。
然而,我们的基本转义没有起作用,没有执行 JS。让我们通过将负载模式从"<script>"标签更改为其他内容来进一步尝试。
很好,至少我们现在知道应用程序容易受到基于注入的攻击。让我们尝试看看是否可以通过 electron API 制作负载来执行命令注入。在这种情况下,我制作了以下负载:
<aonmouseover="try{ const {shell} = require('electron'); shell.openExternal('file:/System/Applications/Calculator.app/') }catch(e){alert(e)}">Calling native APIs to pop calc</a>
让我们分析一下这段代码。
-
a标签:这是一个锚标签,通常用于创建超链接。onmouseover事件:当用户将鼠标悬停在锚点上时会触发 JS 函数。在"onmouseover"事件中将执行以下 JS 代码。 -
try { ... } catch(e) { ... }:一个基本的 try catch 语句。const { shell } = require('electron'):这部分假设应用程序在 electron 环境下运行。 -
{ shell }:Electron 有一个"shell"模块,允许打开外部应用程序或 URL。 -
shell.openExternal('file:/System/Applications/Calculator.app/'):"openExternal"是 electron "shell"模块中的一个方法,用于打开外部应用程序或 URL。
#4 DYLIB 劫持
你可能熟悉,DYLIB(动态库)是一种主要用于 macOS 的共享库。简单来说,它类似于其他操作系统中的共享库(如 Windows 的.dll 文件和 Linux 的.so 文件)。
通常,软件只是一组指令,而这些动态库就是用来实现这些指令的。DYLIB 劫持是一种通过劫持执行流程,在当前运行程序的上下文中加载未签名动态库的方法。就像 DLL 劫持一样,DYLIB 劫持也有多种类型。
当构建 electron 应用程序时,应该使用名为hardedRuntime
的安全机制,它限制某些行为并确保对应用程序可以做什么/运行什么有精细的控制。如果没有使用这些控制,攻击者可以使用"DYLD_INSERT_LIBRARIES"环境变量在运行进程中注入恶意 DYLIB,这将劫持应用程序的当前运行流程并执行恶意 DYLIB。
让我们准备一个示例 DYLIB 文件来演示这一点。
$ cat poc.c
#include <syslog.h>
#include <stdio.h>
__attribute__((constructor))
staticvoidpoc(void)
{
printf("Malicious DYLIB Inserted, Cobalt");
}
$ gcc -dynamiclib -arch x86_64 -o poc.dylib poc.c
bash-3.2$ DYLD_INSERT_LIBRARIES=poc.dylib /Applications/Sample.app/Contents/MacOS/Sample
MaliciousDYLIBInserted, Cobalt
[INF] 18:53:31: (front-end) InitialisingSample core
[INF] 18:53:31: (front-end) Startingwithlanguage: en-US
[INF] 18:53:31: (front-end) Window opened and initialised
[INF] 18:53:31: (front-end) Setting body theme: dark
[INF] 18:53:31: (front-end) Updated1 vaults from back-end
[INF] 18:53:31: (front-end) Rendering application
[INF] 18:53:31: (front-end) Auto-nav: First vault inorder: 85732f9b-c426-49a1-9c8a-a0d1ee444046
[INF] 18:53:31: (front-end) Toggling auto-update for vault editing (editing=false, auto-update=true)
[INF] 18:53:31: Enabled vault auto-update
bash-3.2$
在上述 macOS 应用程序示例中,一旦我们通过"DYLD_INSERT_LIBRARIES"注入我们的 DYLIB,应用程序就会接受它并将其放入程序堆栈中,随后恶意 DYLIB 被执行。这是一个典型的缺少基本加固检查(如"hardedRuntime")的程序示例。 要了解更多关于 macOS 上 DLL 劫持的信息,Patrick Wardle 在DEFCON上发布了一个很棒的视频。
这些是我在对 electron 应用程序进行研究/渗透测试时寻找的一些常见错误配置。我将在"Hacking Electron Apps"的第二部分中继续探讨针对 electron 应用程序的本地权限提升(LPE)漏洞。
总结
虽然 Electron 简化了跨平台开发,但其错误配置可能会使应用程序面临各种攻击。开发人员可以通过解决常见的错误配置和安全漏洞来显著降低这些风险。请继续关注第二部分,我们将探讨更高级的漏洞,如权限提升。
原文始发于微信公众号(securitainment):寻找 Electron 应用程序中的常见错误配置 - 第 1 部分
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论