这是[信安成长计划]的第 20 篇文章
0x00 目录
0x01 安全描述符的结构
0x02 两个结构的不同点
0x03 真正的查询方案
0x04 参考文章
0x01 安全描述符的结构
在上一篇文章中,我们在取 DACL 的时候,对安全描述符的结构产生了疑问,在查到的资料中都在说使用 _SECURITY_DESCRIPTOR 结构,但是因为符号不是最新的等等原因,造成了错位,最后发现应该 +0x30
而在我们去分析内核实际操作的时候发现,应该使用的是 _SECURITY_DESCRIPTOR_RELATIVE 结构,采用相对偏移的方法来进行
事实证明这是正确的,也能够更加合理的解释为什么 +0x30 的位置才是真正 DACL 的位置
0x02 两个结构的不同点
通过对比可以很明显的发现,两个结构的差异主要出现在后面的四个成员中,前三个成员的偏移和大小都是一致的,只有在取后面内容的时候所需要的方式是不同的。
在 _SECURITY_DESCRIPTOR 中,取 DACL,可以直接使用 +0x20 偏移的方式来进行
在 _SECURITY_DESCRIPTOR_RELATIVE 中,取 DACL,需要先 +0x10 偏移,从中取出一个相对的偏移,在我们的测试环境中,这个值是 0x30,然后在将这个偏移值加过去,也就是 +0x30 的偏移得到 DACL
0x03 真正的查询方案
本来以为这样就结束了,但是在最后整理的时候,发现了一个我们一开始就漏掉的信息
我们选取的方案是使用 _SECURITY_DESCRIPTOR_RELATIVE 结构,从中取出偏移值以后,再将其加上
而在最后面,有一个漏掉的信息,一个非常眼熟的 +0x20 的操作
所以,我重新看了一下整个的逻辑,发现了获取 DACL 时真正的逻辑
注意下面的这个跳转,这个跳转指令的上面是对 Control 等的操作,这些值的偏移和大小在两个结构中都是一样的,所以不存在任何的冲突
而这个判断条件用来判断了 Control 中所存储的值,如果是正数就跳转,跳转以后就会直接取 +0x20 的位置,然后将其返回给 DACL
接着,我去查找了相关的资料,得到了下面这样的信息,如果未设置的话,就说明是存储的是绝对的偏移
而这个值正好是 0x8000,在判断 cx 的时候,最高位为 1,代表是一个负数,所以,如果判断 Control 为正数的话,就直接拿偏移进行了获取
所以最终的逻辑应该是这样的,根据 Control 的情况来判断使用什么样的方式
一定一定一定要把逻辑看清楚