新版向日葵本地凭据存储分析与密码提取安全审计

1. 项目概述向日葵新版密码抓取的真正含义远程控制软件在运维和日常支持里几乎是刚需向日葵则是国内被聊得最多的一款。我这次盯上它不是想搞什么黑产操作而是因为在一次合规授权的外围安全审计中客户点名要求验证“如果攻击者拿到一台安装了向日葵新版的机器能否把本地保存的远程控制密码提取出来”。这个需求听起来很直接但深入做下去发现里面的水比较深。新版向日葵在凭据存储上做了不少调整和网上那些旧文章描述的“明文config日志”完全不同原有的思路基本失效必须重新梳理本地的数据架构和加密逻辑。很多安全圈的老手都知道早期不少远程控制软件会把账号、临时密码甚至明文配置放在安装目录或注册表里拿到文件就等于拿到钥匙。但新版向日葵明显提升了本地防护临时访问密码、验证码、设备识别码等关键信息的保存方式变得更加隐蔽并且部分数据会和系统账户体系绑定。如果你只是照搬两三年前的抓取脚本大概率会扑空。这篇内容就是把我这次对新版向日葵的分析过程、数据路径判断、抓取实验的完整逻辑以及最后落地的防护建议整理出来供同样在做安全研究或软件审计的同学参考。先说边界这篇文章只讨论两个场景一是你在自己机器或自己管理的设备上做测试二是你拿到了对方明确的书面授权属于合规的渗透测试或安全评估。任何未经授权尝试获取他人远程控制凭据的行为都是违法的写这篇文章的目的也是帮助大家理解攻击者的思路以便更好地防御而不是提供“一键破解工具”。技术本身没有颜色但使用技术的立场必须拎清。2. 新版向日葵的本地数据架构拆解2.1 安装目录与数据存储位置向日葵在Windows系统上安装后核心程序一般会落在C:\Program Files\Oray\SunLogin这种标准路径下具体版本和位数会有差异但大方向不变。然而真正存放用户配置和运行状态的位置并不全在安装目录新版更倾向于把动态数据放到用户数据目录。这里要留意一个细节向日葵服务是以系统服务方式运行的但它的很多配置实际上分别存在Program Files、ProgramData以及当前登录用户的AppData下所以审计时不能只搜一个位置。我习惯先用Process Monitor对程序启动过程做一次文件访问记录这样可以快速画出它的数据读写地图。简单说你在装有向日葵的机器上启动一次主程序然后在Procmon里按进程名过滤就能看到它从头到尾碰了哪些文件、改了哪些注册表键值。这个方法对任何软件都通用特别是新版向日葵这种可能把文件拆到多处的情况比盲猜目录高效很多。观察下来新版最主要的数据目录集中在安装目录可执行文件、驱动组件、部分默认配置ProgramData下的Oray目录服务状态、策略文件、运行日志用户AppData目录当前登录用户的界面配置、临时缓存、最近连接记录。这三块不是割裂的它们之间有联动。主程序在启动时会读取服务端下发的策略再结合本机用户设置生成最终生效的配置。审计的时候只看某一个目录很容易丢信息必须完整覆盖。2.2 配置文件与凭据存储形态新版向日葵的配置不再像老版本那样直接放一个明文的config.ini把所有参数摊开而是出现了更结构化的存储方式。部分版本引入了SQLite数据库来管理运行数据数据库文件里通常会有多张表分别存放设备信息、网络参数、账号绑定关系、历史连接记录等。这时就要区分“设备识别码”和“远程访问密码”两个概念。设备识别码相当于这台设备的唯一ID是公开的别人知道识别码才能发起连接请求。远程访问密码则分两种一种是用户自己设置的独立访问密码另一种是客户端自动生成的临时访问密码。新版向日葵的临时验证码通常会周期刷新并且不会直接以明文躺在文件里。我在审计中把目标锁定在几个数据库文件上有些表名看起来很直接比如client_config、account_info、security之类。但要注意新版对敏感字段做了加密存储字段值是一长串不可读的密文并且加密过程不是简单Base64或者XOR而是接入了系统级加密接口。这意味着如果你单独拷走数据库文件放到另一台机器去读即使拿到密文也没有办法解密因为解密需要的密钥绑定在原始系统的用户态环境中。2.3 加密算法的选择与演化为什么新版要改加密方式因为老一代的静态密钥方案太容易被破解了。以前很多软件在代码里写死一个密钥然后拿这个密钥去加密所有配置只要有人逆向出这个密钥全版本通用所有机器都能解。新版明显转向了与Windows系统账户体系绑定的DPAPIData Protection API方案。DPAPI本身是一个操作系统级别的数据保护接口它利用当前Windows用户账户的凭据派生加密密钥用这个密钥对指定数据进行加解密。好处有两个一是密钥不出现在软件代码里攻击者单纯逆向程序很难提取出全局密钥二是数据与特定用户、特定机器绑定把数据库复制到另一台机器上无法直接解密。还有部分字段采用了标准加密算法加随机密钥组合的方式加密后的密钥再通过DPAPI保护。这种“两层封装”设计审计时比较棘手但也不是没有弱点。攻击者如果已经拿到了目标机器的最高权限并且当前用户处于已登录状态就可以直接调用相同的API来解密。换句话说新版防的是“离线拖库”式攻击而不是“已经拿到本机管理员权限”的终极攻击。这也解释了为什么后续我们验证时必须在目标机器的真实用户环境下执行操作而不能简单地静态分析文件。3. 本地凭据存储机制的审计思路与实操要点3.1 授权前提与审计准备开始任何凭证提取实验前先确认授权范围。我的做法是让客户在测试委托书上写明“允许在指定IP/主机上执行本地安全审计包括尝试读取软件本地存储的敏感数据”然后限定时间窗口和操作方式。这在企业安全测试里是标准动作没有这一步后面所有动作都有法律风险。准备工具上没有太多花哨的东西几样就够了Process Monitor用于观察文件与注册表访问Sysinternals套件里的一些小工具用于查看进程加载的模块和句柄一个支持SQLite的数据库浏览器以及一个简单的文本编辑器和PowerShell环境。我不建议一上来就上重型逆向工具先用行为分析把逻辑摸清楚比静态啃汇编快得多。还有一个容易被忽略的准备工作在干净的虚拟机里安装同版本向日葵先主动设置一个已知的独立访问密码同时记下当前自动生成的临时访问密码再用这个已知样本去反推存储位置和加密逻辑。审计的本质是掌握规律如果你连自己的明文密码都定位不到就不要去尝试读别人的数据了。3.2 定位关键数据的常规方法定位数据的常规方法分三步走。第一步在虚拟机里启动向日葵主程序打开Process Monitor添加过滤器只保留进程名包含SunloginClient的活动再设置一个路径过滤指向C:\Program Files\Oray和C:\ProgramData\Oray。这时候程序运行期间所有读写的文件都会暴露在眼前。第二步正常使用软件比如刷新临时密码、修改独立访问密码、发起一次测试连接。目的就是触发数据写入操作让Procmon抓取到密码变更那一刻对应的文件路径和注册表操作。我实验中发现修改独立访问密码后不久数据库文件的时间戳会发生变化说明敏感信息写入该文件。第三步用SQLite工具打开那个变动的数据库逐个表浏览字段。正常情况下大部分表的结构很清晰但敏感字段是密文。你可以把已知明文密码和数据库里的密文做比对确认哪个字段负责存储密码。在测试中我们看到名为security_config的表里有一个local_password字段值类似一串经过编码的密文确认就是独立访问密码的落点。3.3 凭据解密路线分析找到密文不等于抓到密码关键在解密。新版向日葵走的是DPAPI路线那么解密就必须在原始用户环境里调用CryptUnprotectData。这个API可以看成一把由当前Windows账户自动管理的钥匙程序在加密时用CryptProtectData解密时对称调用即可。实操中我写了一个简单的PowerShell控制台程序调用系统API对指定密文执行解密。但需要注意的是不能直接在密文字符串上解密因为向日葵可能对密文做过额外的编码封装比如先Base64解码再送入DPAPI接口。遇到这种情况就需要分析密文的前缀格式看它是不是标准DPAPI Blob样式。我在测试中卡过一阵最后发现新版在DPAPI之外还加了一层针对临时访问密码的时效性处理。具体表现是临时验证码不仅加密还存了一个生成时间戳程序在读取时会校验收码时间如果超过有效期即使解密成功也会被判定为过期。所以在“抓取”临时密码时尽量在密码刷新后立刻读取并解密时间窗口很短。独立访问密码则没有这个限制只要没被用户重新修改就能稳定解密出来。3.4 实操中需要注意的细节进程权限必须足够。一定要以目标用户身份运行解密工具最好是管理员权限。如果使用SYSTEM账户或者其他用户上下文执行DPAPI解出的结果可能不对因为密钥和用户SID、主凭据绑定。关闭杀毒软件干扰。测试机上某些安全软件会对API调用行为产生拦截最好在排除规则里放行否则解密过程会莫名失败。密文可能封装多层。不要以为拿到数据库字段就是最终密文多看几眼数据格式有些值是Base64后又有自定义标记需要逐层拆。记录版本号。向日葵的小版本更新非常频繁不同小版本的数据库表结构可能不同方案不能完全照搬。读者在实操时应以自己环境中的实际现象为准。4. 常见问题与排查技巧实录4.1 为什么新版改了加密方式很多人习惯用旧思路在新版下找不到明文就开始怀疑是不是自己姿势不对。其实原因很简单厂商也在进行安全对抗升级。老版本把密码直接写在配置文件里或被简单编码后存放这种设计在局域网安全测试里基本等于裸奔。新版改用DPAPI后离线攻击门槛一下提高了不少。要说服客户不要迷信网上流传的旧方法我得给他们演示完整流程先证明旧思路失效再证明新思路在获得本机权限的前提下仍然可解但需要额外步骤。这本身就是一种安全意识教育。4.2 找不到对应数据目录怎么办如果你装了新版但按上面路径没有找到数据库文件有几个排查方向。第一个是版本差异商业版和个人版、绿色版和安装版的数据布局不一定一致。第二个是多用户环境不同的Windows账户登录后会生成不同的用户配置目录你必须在目标账户下运行程序并保存一次设置数据才会完整落盘。第三个是程序可能尚未真正初始化启动后很快退出没有写入配置这时需要手动触发一次登录或连接操作。另外部分版本会把数据库文件放在安装目录下的config子目录文件名也不是常见的.db或.sqlite而是一个无后缀文件或者.dat格式需要通过文件头判断。SQLite文件的头一般是SQLite format 3用十六进制编辑器看一眼就能确认。如果文件头对不上那就是厂商做了自定义封装或者干脆换成了其他的存储引擎不能硬套SQLite工具。4.3 抓取结果乱码或不全的可能原因解密后得到乱码最常见的原因就是解密上下文不对。前面说了DPAPI绑定用户你如果是在另一个用户下解或者用远程工具以服务方式调用即便返回数据也不是原来的明文。还有可能是字符编码问题向日葵在Windows上可能使用UTF-8或Unicode保存数据解密后字节流没有正确转换看起来就是乱码。解决方法是先转成十六进制字节对比已知明文密码的ASCII码或Unicode码点确定编码方式后再显示。抓取不全则可能是因为同时存在多个密码字段你只抓到了其中一个。比如设备识别码、临时密码、独立访问密码、解锁屏幕密码它们往往分开存储。评估时不要只盯着一个字段要多看几个表。另外有些密码拆成了前后两部分分别存储在两个字段程序在运行时拼接后使用这种情况也可以通过对比总长度来发现。5. 从攻防视角看防护策略5.1 用户侧防护清单理解了攻击者提取本地凭据的思路后防御就变得清晰了。最基础的一条是不要在不信任的电脑上保存远程控制的独立访问密码。如果你经常在公用电脑或客户现场使用向日葵尽量使用临时验证码而非永久密码这样就算本地数据被提取泄漏窗口也有限。另一个容易被忽视的点是定期清理本机存储的账号缓存。向日葵客户端会保存历史连接记录和账号信息方便下次快速登录。但便利和安全往往对立。对个人用户来说离开公共设备前最好退出软件并选择“清除本机记录”。企业用户则应通过组策略或终端管理工具限制本地数据导出避免员工随意拷贝配置目录。操作系统账户本身的强度也很关键。因为DPAPI的安全性依赖于Windows用户密码如果你的系统登录密码太简单攻击者拿到数据库后可以尝试在另一台机器上模拟该用户凭据进行离线解密。设置复杂的本地登录密码并开启BitLocker加密磁盘这些基础操作能极大提高攻击门槛。5.2 企业侧部署建议企业在内部大规模部署远程控制工具时需要从管理端入手。首先启用服务端的密码策略要求强制使用强密码并定期轮换。第二关闭不必要的自动登录功能要求每次远程会话都通过动态验证码或二次认证完成。第三通过企业版管理后台下发配置禁止终端本地保存敏感字段。有条件的话建议使用EDR系统持续监控SunloginClient进程对本地敏感文件的异常读取一旦发现短时间内频繁读取数据库文件就要立刻告警。还有一个常被忽略的方面企业镜像里的内置密码。有些IT部门在制作办公镜像时为了方便测试在向日葵里保存了一个通用访问密码。这个密码随镜像扩散到成百上千台电脑一旦其中一个拿到管理员权限就能提取出这个共用的凭据从而横向控制所有同镜像终端。这种问题比个人密码泄漏影响大得多规划镜像时一定要清理干净。5.3 安全研究者可以延伸的方向新版向日葵的凭据存储机制值得作为研究样本因为它代表了一类国内Windows桌面软件的普遍安全水平已经意识到安全开始使用系统级加密但在最终用户便利性和安全性之间做了妥协。后续可以从这几个方向继续深入一是分析新版更新中加密方案的迭代过程对比旧版漏洞如何被修补二是研究临时验证码的随机数生成机制看是否存在弱随机导致可预测的问题三是在获得本机权限前提下尝试绕过DPAPI保护提取密钥的技术路线。这类研究对提高软件整体安全性有实际价值也能沉淀成可复用的审计方法论。我个人的经验是做这类研究一定要养成记录和复现的习惯。每打一个补丁、每换一个版本马上把已有的提取方案重新跑一遍看看哪些环节失效了哪些环节还能走通。时间长了你会形成一套自己的“版本演进对照表”比临时翻文档高效得多。这次向日葵新版密码抓取的项目做完让我最大的感触是本地数据和系统账户绑定加密正在成为主流以后做安全审计不能把眼光只放在应用层必须对操作系统加密接口有足够理解。不夸张地说这个方向值得每一个做终端安全的人花时间琢磨。