前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Windows原理深入学习系列-访问控制列表-关于安全描述符的补充

Windows原理深入学习系列-访问控制列表-关于安全描述符的补充

作者头像
信安成长计划_Stars
发布2022-03-10 10:59:25
3250
发布2022-03-10 10:59:25
举报
文章被收录于专栏:信安成长计划

这是[信安成长计划]的第 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 的情况来判断使用什么样的方式

一定一定一定要把逻辑看清楚

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-03-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 信安成长计划 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档