内网渗透攻防技术-课件【ch03】Windows认证协议

第3章Windows认证协议内网渗透攻防技术01NTLM认证PARTONE协商就是客户端向服务器端发送TYPE1（协商）消息，主要包含客户端支持和服务器端请求的功能列表。图3-2展示了协商阶段发送消息的格式。1格式一：协商质询是NTLM认证流程中Challenge/Response机制的核心阶段。在这一阶段中，服务器向客户端发送一个随机生成的Challenge。客户端随后将使用Challenge和其掌握的密码生成一个加密的随机值，并将其发送回服务器。图3-3展示了质询阶段发送消息的格式。2格式二：质询身份验证主要是在质询完成后验证结果，是认证的最后一步。消息中的Response最为关键，用于向服务器端证明客户端已经掌握了正确的密码。图3-4展示了身份验证阶段发送消息的格式。3格式三：身份验证在NTLMv1中使用LMHash和NTLM-hash来进行验证，而后续推出的v2版本成为WindowsVista及后续版本操作系统中的默认认证协议。两者加密的原料都是NTLM-hash，不同之处在于，NTLMv1中的Challenge有8字节数值，主要加密算法为DES；而NTLMv2中的Challenge有16字节数值，主要加密算法为HMAC-MD5。图3-5展示了NTLMv2认证流程。3格式三：身份验证LMHash（1）（2）（3）（4）将密码转换为大写格式。如果密码长度不足14字节，则将会用\0在后面补全，最终得到长度为14字节的密码字符串。将填充后的密码字符串分成两个7字节的块，并分别对每个密码块使用DES加密算法进行加密。两个7字节的密码块被分别用作DES密钥，对固定的字符串“KGS!@#$%”进行DES加密。每个密码块进行DES加密后的输出结果都是8字节数值，将两个DES加密结果拼接在一起，得到最终的LMHash。计算方式LMHashLMHash算法有以下缺陷。（1）密码不区分大小写。LMHash将密码强制转换为大写格式，降低了密码的复杂度。（2）LMHash最多支持14个字符的密码，超过部分会被忽略。（3）如果密码长度小于7字节，那么第二个分组加密后的结果肯定是aad3b435b51404ee。（4）14个字符的密码被分成两个7字节的部分，并分别加密，这使得每部分可以被单独暴力破解，极大地降低了破解难度。（5）DES密码强度较低。DES是一种较早的加密算法，密钥长度较短（56位），很容易被暴力破解。NTLM-hash基于LMHash存在的问题，微软于1993年引入了NTLM-hash。个人版从WindowsVista开始，服务器版从WindowsServer2003开始，Windows操作系统的认证方式均变更为NTLM-hash。NTLM-hash的计算方式如下。（1）将密码转换为十六进制格式。（2）对十六进制格式的密码进行Unicode编码。（3）使用MD4摘要算法对Unicode编码数据进行哈希计算。02Kerberos认证PARTTWOKerberos认证介绍Kerberos是一种网络认证协议，它的名字来源于希腊神话中一只守护着冥界、长着3只头颅的神犬。在Kerberos认证中，Kerberos的3只头颅代表认证过程中涉及的三方：Client（客户端）、Server（服务器）和KDC（KeyDistributionCenter，密钥分发中心）。Kerberos从提出到今天，共经历了5个版本的发展。其中，第一版到第三版主要在麻省理工学院（MIT）内部使用。当发展到第四版的时候，Kerberos已经获得了MIT校外的广泛认同和应用。随着第四版的传播，人们逐渐发现了Kerberos的一些局限性和安全困境，如适用网络环境有限、加密过程存在冗余等。MIT充分吸取了各方意见，对第四版进行了修改和扩充，形成了今天较为完善的第五版。第五版由JohnKohl和CliffordNeuman设计，1993年作为RFC1510颁布，2005年由RFC4120取代，目的在于克服第四版的局限性和安全困境，用更细化和明确的解释说明了Kerberos协议的一些细节和使用方法。Kerberos协议的基本应用是在一个分布式的Client/Server体系结构中，采用一台或多台Kerberos服务器提供鉴别服务。当客户端想要请求服务器上的资源时，首先由客户端向密钥分发中心请求一张身份证明，然后将身份证明交给服务器进行验证，在通过服务器的验证后，服务器就会为客户端分配其请求的资源。Kerberos认证流程Kerberos认证流程1第一阶段：ASExchange某个客户端用户Client试图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的Kerberos服务会向KDC的AS发送一个AS_REQ认证请求。请求的凭据是Client的哈希值NTLM-hash、加密的时间戳及Client-info、Server-info等数据，以及一些其他信息。当Client发送身份信息给AS后，AS会先向AD发送请求，询问是否有此用户。如果有，就会取出它的NTLM-hash来对AS_REQ进行解密。如果解密成功，则证明客户端提供的密码正确。如果解密后得到的时间戳与当前时间差在5分钟之内，则认证成功。然后AS会生成一个AS_REP。AS_REP中包含两部分内容。一部分是AS生成的临时密钥Session-keyAS，使用Client的NTLM-hash加密，用于确保Client和KDC之间的通信安全。另一部分是TGT，内容包括使用特定账户krbtgt（创建域控时自动生成的账户）的NTLM-hash加密的Session-keyAS、时间戳及一些用户信息，这个用户信息就是PAC（PrivilegeAttributeCertificate，特权属性证书），PAC中包含用户的SID（SecurityIdentifier，安全标识符）和用户所在的组等信息。Kerberos认证流程1第一阶段：ASExchangeKerberos认证流程2第二阶段：TGSExchangeClient接收到AS的回复AS_REP后，分别获得了TGT和加密的Session-keyAS。它会先用自己的ClientNTLM-hash解密得到原始的Session-keyAS，然后在本地缓存此TGT和原始的Session-keyAS，当需要访问某个服务时，就可以构成TGS_REQ提交给TGS，以此来得到对应的ST。在这个过程中发送的TGS_REQ中包含使用Session-keyAS加密的时间戳及Client-info、Server-info等数据，以及使用krbtgt账户的NTLM-hash加密的TGT。TGS接收到TGS_REQ后，先用krbtgt账户的NTLM-hash解密TGT得到Session-keyAS、时间戳、Client-info及Server-info，再用Session-keyAS解密第一部分内容得到Client-info、时间戳，接着将两次获取的时间戳进行比较，如果时间戳跟当前时间相差太久，就需要重新认证。TGS还会将这个Client的信息与TGT中Client的信息进行比较，如果两者相同，则会继续判断Client有没有权限访问Server。如果都没有问题，则表示认证成功。认证成功后，TGS会生成一个Session-keyTGS，并用Session-keyAS加密Session-keyTGS作为响应的一部分。此Session-keyTGS用于确保客户端和服务器之间的通信安全。Kerberos认证流程2第二阶段：TGSExchange响应的另一部分是使用Server的NTLM-hash加密Session-keyTGS、时间戳、Client-info等数据生成的ST。最后TGS将这两部分信息返回给Client，即TGS_REP。至此，Client和KDC之间的通信就结束了，之后是和Server之间的通信。Kerberos认证流程3第三阶段：C/S（Client/Server）Exchange该阶段是Client和TGS的认证，通过认证的客户端将与服务器建立连接。Client接收到TGS_REP后，分别获得了ST和加密的Session-keyTGS。它会先使用本地缓存的Session-keyAS解密出原始的Session-keyTGS，然后在本地缓存此ST和原始的Session-keyTGS。当Client需要访问某台服务器上的服务时，会向Server发送请求。它会使用Session-keyTGS加密Client-info、时间戳等数据作为请求的一部分。因为ST是使用ServerNTLM-hash进行加密的，Client无法解密，所以Client会将ST作为请求的另一部分继续发送给Server。这两部分构成的请求被称为AP_REQ。Kerberos认证流程3第三阶段：C/S（Client/Server）ExchangeServer接收到AP_REQ后，先用自身的ServerNTLM-hash解密ST得到Session-keyTGS，再解密出Client-info、时间戳等数据，接着与ST的Client-info、时间戳等数据一一进行对比。时间戳的有效时间一般为8小时。通过Client身份验证后，Server会拿着PAC去询问DC（DomainController，域控制器）该用户是否有访问权限。DC拿到PAC后，先进行解密，再通过PAC中的SID判断用户所在的组、用户权限等信息，并将结果返回给Server，Server将此信息域用户请求的服务资源的ACL（AccessControlList，访问控制列表）进行对比，最终决定是否给用户提供相关的服务。通过认证后，Server将返回最终的AP-REP，并与Client成功通信。03PACPARTTHREE在Kerberos最初的设计中，其主要目标是解决如何证明Client是Client的问题，即确保通信的一方并非被其他人冒充。然而，在早期的设计中，Kerberos并未涉及对Client是否具备访问特定Server服务权限的验证。在这种情况下，即便Client成功完成了身份验证，依旧无法有效区分其访问服务的权限。为了在域内实现更加精细的权限控制，确保不同权限的用户只能访问符合其身份的资源，微软在其Kerberos协议的实现中引入了PAC的概念。PAC的引入使得Kerberos协议不仅能验证身份，还能验证权限。PAC的核心功能是提供一段描述用户权限、身份属性和组信息的校验数据。可以将PAC理解为一串加密的结构化数据，其中包含了用户的SID、组成员信息及其他权限属性。PAC的存在使得认证过程不再单单是对身份的验证，而是同时完成对权限的确认，这在域环境中显得尤为重要。为了防止PAC数据被伪造或篡改，PAC通常被存储在Kerberos票据中，并由KDC通过其主密钥进行加密和签名保护，从而确保数据的完整性与可信性。PAC的生成和验证过程贯穿于Kerberos认证流程中。在客户端通过AS请求获取TGT时，KDC会在生成的TGT中嵌入PAC。这个PAC中包含两部分重要的数字签名：PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM。前者由Server的NTLM-hash加密，用于校验Server的合法性；而后者则由krbtgt账户的NTLM-hash加密，用于确保PAC的完整性。PAC数据和TGT一起被AS_REP消息传递到客户端，客户端在后续的认证请求中将携带这些数据。PAC的具体作用在TGS和Server处理阶段得以体现。当客户端向TGS请求特定服务的访问票据时，KDC会首先验证PAC的完整性和真实性。只有在PAC验证通过后，KDC才会在生成的ST中嵌入一个新的PAC，并将其返回给客户端。客户端随后将ST发送给目标Server。Server接收到票据后，通过验证ST中的PAC来确认客户端的权限信息，并将其与目标资源的ACL进行匹配，最终决定是否授予客户端访问权限。PAC的存在简化了Server对权限的处理逻辑。在没有PAC的情况下，Server需要单独向DC查询客户端的权限信息，而PAC的引入使得权限数