本人从事网路安全工作12年,曾在2个大厂工作过,安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过,对这个行业了解比较全面。
最近遍览了各种网络安全类的文章,内容参差不齐,其中不伐有大佬倾力教学,也有各种不良机构浑水摸鱼,在收到几条私信,发现大家对一套完整的系统的网络安全从学习路线到学习资料,甚至是工具有着不小的需求。
最后,我将这部分内容融会贯通成了一套282G的网络安全资料包,所有类目条理清晰,知识点层层递进,需要的小伙伴可以点击下方小卡片领取哦!下面就开始进入正题,如何从一个萌新一步一步进入网络安全行业。
学习路线图
其中最为瞩目也是最为基础的就是网络安全学习路线图,这里我给大家分享一份打磨了3个月,已经更新到4.0版本的网络安全学习路线图。
相比起繁琐的文字,还是生动的视频教程更加适合零基础的同学们学习,这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。
网络安全工具箱
当然,当你入门之后,仅仅是视频教程已经不能满足你的需求了,你肯定需要学习各种工具的使用以及大量的实战项目,这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。
项目实战
最后就是项目实战,这里带来的是SRC资料&HW资料,毕竟实战是检验真理的唯一标准嘛~
面试题
归根结底,我们的最终目的都是为了就业,所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
漏洞简介
2022年5月10日,微软发布补丁修复了一个AD域权限提升漏洞(CVE-2022–26923)。该漏洞是由于在申请证书时对AD域中的计算机账户身份审核不够严格,经过身份验证的攻击者可以操纵他们拥有或管理的计算机帐户的属性,假冒DC从ADCS 服务器获取DC证书,最终导致普通权限用户提升至域管理员权限。这一漏洞最早由安全研究员Oliver
Lyak在2021年12月14日报告给微软,微软在2022年5月的安全更新中对其进行了修补。
01 AD CS身份识别
默认情况下,CA允许域用户注册User模板证书,允许域计算机注册Machine模板证书。两个证书模板都允许客户端身份验证。这意味着颁发的证书可用于通过PKINIT
Kerberos 扩展对KDC进行身份验证。
通过对比User和DomainController两个模板的msPKI-Certificate-Name-
Flag属性可以看到User模版包含SUBJECT_ALT_REQUIRE_UPN,DomainController包含
SUBJECT_ALT_REQUIRE_DNS。这两个字段分别标识证书中的用户和计算机的身份,用于CA识别证书的所有者。
如当我们使用User模板请求证书时,用户帐户的UPN将嵌入到证书中。在进行进行身份验证时,KDC会尝试将 UPN 从证书映射到用户。
尝试修改用户的UPN属性,如果能够将该属性修改为AD管理员账号的UPN,则可以实现欺骗AD
CS获取AD管理员权限证书,但是实际上DC会对UPN检查保持全林唯一。
虽然UPN无法假冒,但是不代表dnsHostName不可以假冒。在MS-ADTS(3.1.1.5.1.3
唯一性约束)文档中并没有标识dnsHostName属性具有唯一性。实际上,通过下面的漏洞分析也可以发现实际这个属性可以重复,这也是这个漏洞产生的主要原因。
02漏洞分析复现
成功利用该漏洞需要满足以下几个必要条件:
1、攻击者获取到一个通过认证的普通域用户凭据或计算机账户凭据
2、AD 域内已配置了 AD CS 服务
3、Machine模板证书可以自动申请
首先第一步需要获得一个已知凭据的计算机账户,如果没有可以使用普通账户通过Impacket创建一个新的计算机账户。
默认情况下每个普通用户都拥有添加10个机器账户的权限,添加机器权限可以通过编辑组策略控制,在Windows Server
2012以下版本的DC可以通过用户的属性 MS-DS-Machine-Account-Quota设置可添加计算机账户的数量。
尝试直接修改机器的dnsHostName,提示出现操作错误(无法更新属性值),但是没有提示唯一性错误,因此可以猜测该值可以修改为DC的dnsHostName,但是出于某种限制,如值的类型不对或者是有某种对象的值依赖于该值导致无法成功更新修改到AD。
观察使用账户test3创建的主机,发现其ACL信息非常有意思。虽然是test3创建的计算机账户,但是机器账户的所有者却是Domain
Admins账户。机器账户的中几条ACL信息非常有价值,分别是:
1.已验证的到DNS主机名的写入
2.已验证的到服务主体名的写入
3.已验证的到计算机属性的写入
这证明创建计算机账户的用户账户是有计算机账户的dnsHostName、servicePrincipalName和其他属性的写权限,因此修改dnsHostName属性值在ACL权限上是可行的。
通过普通域用户对其创建主机的dnsHostName进行修改,将值修改为一个不存在的主机名发现成功,因此实现本漏洞的关键是如何绕过限制进行修改。
在将dnsHostName从mc7.moin.com修改为xxx.moin.com时,发现该计算机账户的servicePricipalName属性也发生了变化,其中的两个字段包含了新的dnsHostName。可以推测这个属性对dnsHost
Name有依赖。
查看微软的官方文档https://docs.microsoft.com/en-us/windows/win32/adschema/r-validated-
spn,发现官方对servicePrincipalName属性的描述为“验证写入权限以启用符合计算机 DNS 主机名的 SPN
属性设置”,因此猜测是该属性中对应的值中包含现有的dnsHostName,尝试删除servicePrincipalName中包含hostHostName的值,也可直接删除servicePrincipalName属性。
在删除后,通过修改dnsHostName属性值为DC的dnHostName,发现修改成功。
现在成功获得一个dnsHostName与域控相同的机器账户,由于创建账户时指定了账户密码,因此可以利用该账户欺骗AD CS获取域控权限证书。
该漏洞的主要实现过程可以总结为以下几步:
1.获取一个已知密码的计算机账户
2.删除计算机账户的servicePrincipalName属性或删除其中与dnsHostName有关的值
3.修改dnsHostName为DC的dnsHostName
最后使用该机器账户向AD CS服务器申请模版为“Machine”的证书并保存的本地,此时获取的实际是DC权限的证书。
使用该证书申请TGT,能够成功获取域控账户的NT Hash,说明证书有效。这说明成功的从普通域用户权限提升到了域控权限。
查看AD CS服务器中的证书申请记录,也可以看出AD CS认为认为颁发的证书为DC。
03痕迹信息
在进行修改dnsHostName值时,会在域控产生事件ID为5136的目录服务更改日志。其中的特征为将计算机对象的dNSHostName值修改为DC的名称。
同时会产生事件ID为4742的计算机管理审核成功日志,日志信息中包含了被修改的计算机账户信息和修改后的dnsHostName信息。如若使用此漏洞后需要进行痕迹清理,这两条日志最为关键。
04 总结
本次漏洞产生的主要原因是计算机账户关键属性的ACL设置问题和AD
CS检查客户端身份不严格导致,结合之前的samAccountName欺骗漏洞,AD域中涉及身份认证标识的问题不止一次,微软在AD域中不用具有唯一性的自动编号字段SID而是其他字段作为身份认证标识在安全方面着实欠妥。
本次漏洞利用简单,流量特征不明显难以检测,同时获取的AD域证书有效时间长,因此对于AD域的提权和权限维持都有很高的利用价值。
网络安全学习路线&资源分享
【----帮助网安学习,以下所有学习资料免费领!】
① 网安学习成长路径思维导图
② 60+网安经典常用工具包
③ 100+SRC漏洞分析报告
④ 150+网安攻防实战技术电子书
⑤ 最权威CISSP 认证考试指南+题库
⑥ 超1800页CTF实战技巧手册
⑦ 最新网安大厂面试题合集(含答案)
学习路线:
这个方向初期比较容易入门一些,掌握一些基本技术,拿起各种现成的工具就可以开黑了。不过,要想从脚本小子变成黑客大神,这个方向越往后,需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!