红队专属技巧:记一次渗透实战中对 .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代码审计中,我们通过动态分析与静态追踪相结合的方式,成功识别了一处敏感信息伪加密漏洞。这种漏洞看似安全,但实质极其脆弱,对安全评估和渗透测试人员来说是一个重要的攻击面。

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

 文/章/涉/及/的/工/具/已/打/包,请//加//入//后/下//载:https://wx.zsxq.com/group/51121224455454 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dot.Net安全矩阵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值