记一次渗透实战中对 .NET 伪加密存储的审计

在.NET程序开发中，开发者出于安全性考虑，通常会尝试对敏感数据如密码、Token等进行加密存储。然而，在实际的安全评估中，我们经常会发现开发者使用了自定义加密或混淆手段，看似防护严密，实则形同虚设。

本文将以一个真实的.NET程序为例，演示如何识别并还原这类伪加密存储机制，帮助红队与安全研究人员识破表象，洞察本质。

01. 漏洞场景介绍

该.NET应用具有本地记住用户登录信息的功能。用户登录成功后，程序会将当前用户名与密码保存至本地路径下的 user.xml 文件中，内容格式如下：

<user><username>admin</username><password>RkFHUEFTU1dPUkQxMjM=</password></user>

其中用户名以明文形式保存，而密码看似经过加密，表现为Base64字符串，给人一种已加密存储的错觉。然而，在没有算法信息的前提下，直接将该字段进行Base64解码后得到的是乱码，说明其加密方式并非标准。

02. 漏洞审计入手

通过对源代码或反编译结果分析，发现数据写入逻辑集中在一个名为 SaveUserInfo() 的方法中。进一步追踪，可以还原出完整的密码处理流程，大致程序会调用 GetUpperCase() 方法生成三个随机的大写字符，作为加密结果的前缀。例如：

string prefix =GetUpperCase();// 例如 "Z6Q"

用户的明文密码会被Base64编码，具体代码如下所示。

string encodedPassword = Convert.ToBase64String(Encoding.UTF8.GetBytes(password));

最终将前缀与Base64密文拼接，形成最终保存值，这意味着真实密码只是被Base64编码 + 加3位随机前缀，没有使用任何加密算法，也没有秘钥机制。攻击者只需忽略前三个字符，即可还原密码。

string finalPassword = prefix + encodedPassword;

换句话说，该“加密”逻辑本质上只是将明文密码进行Base64编码（不是加密算法），并在前面添加3位随机前缀。例如，明文密码为 P@ssw0rd123，则：

Base64编码后 → UEAzc3cwcmQxMjM=添加前缀如 "Q9Z" → 最终保存为 Q9ZUEAzc3cwcmQxMjM=

略作分析，便可跳过前三位字符，提取出真正的Base64密文，并还原出明文密码。跟踪登录运行的步骤，并且在密码base64编码后添加到起始位置，最后在SaveUserInfo方法内将账密等信息保存到xml文件内，如下图所示。

综上，在本次.NET代码审计中，我们通过动态分析与静态追踪相结合的方式，成功识别了一处敏感信息伪加密漏洞。这种漏洞看似安全，但实质极其脆弱，对安全评估和渗透测试人员来说是一个重要的攻击面。

作为红队或安全从业者，应时刻关注程序中隐藏在自定义加密下的安全隐患，深入理解加解密流程背后的本质逻辑，才能在实战中获得真正有价值的突破口。

03.NET安全扩展学习

以上相关的知识点已收录于新书《.NET安全攻防指南》，全书共计25章，总计1010页，分为上下册，横跨.NET Web代码审计与红队渗透两大领域。

上册深入剖析.NET Web安全审计的核心技术，帮助读者掌握漏洞发现与修复的精髓；下册则聚焦于.NET逆向工程与攻防对抗的实战技巧，揭秘最新的对抗策略与技术方法。

04. NET代码审计学习

微软的.NET技术广泛应用于全球企业级产品，包括其知名的Exchange、SharePoint等，国内如 某友的Cloud、某通的T系列、某蝶的云产品 等也广泛采用。各行业核心业务均依赖于此技术。这些基于.NET的系统频繁遭攻击，问题涵盖任意文件上传、反序列化漏洞、SQL注入、文件下载漏洞、命令执行漏洞等。