网络安全【免费下载链接】sliverAdversary Emulation Framework项目地址https://gitcode.com/gh_mirrors/sl/sliver点击查看免费下载导读本文以 SliverAdversary Emulation Framework仓库内 vendored 的gopkg.in/jcmturner/gokrb5.v7的 gssapi/README.md 为核心系统讲解 GSS-APIGeneric Security Services Application Program Interface协商机制在 Kerberos 认证中的完整流程客户端如何通过NewNegTokenInitKrb5构造首条协商消息、服务端四种NegTokenResp状态accept-completed / accept-incomplete / reject / request-mic分别表示什么以及对应的 ASN.1 结构、OID、状态码与 MIC/Wrap 令牌在 gokrb5.v7 源码中的实现。读完本文你将能读懂 SPNEGO 协商报文的字节结构、定位 gokrb5.v7 中对应的实现文件并理解 Sliver 依赖树中这段 Kerberos 代码的用途边界。背景为什么 Sliver 的依赖里会有 GSS-API 协商机制Sliver 作为跨平台 C2 框架其 implant 端需要与目标 Windows/Linux 主机上的各类服务交互其中就包括使用 Kerberos 身份认证的 HTTP 服务。gopkg.in/jcmturner/gokrb5.v7是一个纯 Go 实现的 Kerberos 5 客户端/服务端库其gssapi子包为 SPNEGOSimple and Protected GSS-API Negotiation MechanismRFC 4178认证提供了 GSS-API 抽象层。需要说明的是gssapi包在本仓库中以两份几乎相同的 vendored 副本存在——implant/vendor/gopkg.in/jcmturner/gokrb5.v7/gssapi 与 vendor/gopkg.in/jcmturner/gokrb5.v7/gssapi分别服务于 implant 与服务器端的构建。两者内容一致下文引用统一以 implant 侧路径为准。gssapi/README.md 全文以 RFC 4178 为主线回答了三个问题协商消息由谁生成、包含什么、服务端如何应答。下面逐层展开。协商机制总体流程RFC 4178 核心脉络按 gssapi/README.md 的描述SPNEGO 协商流程如下客户端发起客户端向服务端发送一条初始协商消息NegTokenInit在其中列出自己支持的所有机制Mechanism按偏好降序排列。机制列表该消息由NewNegTokenInitKrb5方法生成且只声明支持 Kerberos v5 一种机制。可选内嵌令牌RFC 4178 规定该消息可以可选地包含客户端首选机制此处即 KRB5的初始机制令牌initial mechanism token。NewNegTokenInitKrb5会将该令牌一并嵌入协商消息从而在单条消息内完成机制协商与首轮安全上下文交换。服务端应答服务端针对该消息返回四类应答之一详见下一节分别表示协商完成、仍需继续、拒绝或要求 MIC 交换。这一“机制列表 内嵌首轮令牌”的设计使得最常见的 Kerberos 场景下客户端与服务端只需一次往返即可建立安全上下文——这也是 SPNEGO 在浏览器/HTTPAuthorization: Negotiate场景中被广泛使用的原因。服务端的四种应答状态README 用一张表概括了服务端对初始协商消息的四种应答对应 SPNEGONegotiationToken中的NegTokenResp结构消息类型/状态描述accept-completed表示目标接受发起方选择的机制且第一条协商消息中内嵌的安全机制令牌足以完成认证accept-incomplete客户端至少还需要再发送一条消息才能建立安全上下文reject协商被终止request-mic仅可能出现在目标的第一条应答消息中表示若提供逐消息per-message完整性服务则必须进行 MIC 令牌交换在 gokrb5.v7 中这四种状态被编码为NegState枚举常量见 negotiationToken.goconst ( NegStateAcceptCompleted NegState 0 NegStateAcceptIncomplete NegState 1 NegStateReject NegState 2 NegStateRequestMIC NegState 3 )其中request-mic的语义值得展开它只能出现在服务端的第一条应答里用于告知客户端“若后续要使用逐消息完整性保护GSS_GetMIC / GSS_VerifyMIC则必须额外进行一次 MIC 令牌交换”。也就是说它强制客户端回传一条携带 MIC 的应答服务端据此验证消息完整性能力。这与下文要讲的MICTokenRFC 41210x0404令牌直接相关。协商消息的 ASN.1 结构与生成NegTokenInit / NegTokenResp 结构SPNEGO 的协商令牌基于 ASN.1 编码negotiationToken.go 顶部完整保留了 RFC 4178注释中引用 MSDN 版本的结构定义NegotiationToken :: CHOICE { negTokenInit [0] NegTokenInit, -- 客户端发送给服务端的协商令牌 negTokenResp [1] NegTokenResp } NegTokenInit :: SEQUENCE { mechTypes [0] MechTypeList, reqFlags [1] ContextFlags OPTIONAL, -- 继承自 RFC 2478推荐留空 mechToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... } NegTokenResp :: SEQUENCE { negState [0] ENUMERATED { accept-completed(0), accept-incomplete(1), reject(2), request-mic(3) } OPTIONAL, supportedMech [1] MechType OPTIONAL, -- 仅出现在目标的第一条应答 responseToken [2] OCTET STRING OPTIONAL, mechListMIC [3] OCTET STRING OPTIONAL, ... }对应的 Go 实现为NegTokenInit与NegTokenResp两个结构体并通过marshalNegTokenInit/marshalNegTokenResp携带显式 ASN.1 标签asn1:explicit,tag:N完成编解码。注意NegTokenResp.negState在第一个应答中为必填supportedMech也只在第一个应答中出现与 README 中“request-mic 只可能出现在第一条应答”的约束相互印证。NewNegTokenInitKRB5客户端协商消息的生成入口README 提到的NewNegTokenInitKrb5在 gokrb5.v7 中的实际签名位于 negotiationToken.gofunc NewNegTokenInitKRB5(cl *client.Client, tkt messages.Ticket, sessionKey types.EncryptionKey) (NegTokenInit, error)它接收已通过 AS 交换/TGS 交换获得的客户端会话凭证内部完成两件事将 KRB5 AP-REQ 封装为KRB5Token机制令牌构造NegTokenInit把 KRB5 机制 OID 写入MechTypes、把 KRB5 令牌字节写入MechTokenBytes随后由NegTokenInit.Marshal()输出为 ASN.1 字节流。从 spnego.go 可见其调用链negTokenInit, err : NewNegTokenInitKRB5(s.client, tkt, key) ... return SPNEGOToken{}, fmt.Errorf(could not create NegTokenInit: %v, err)服务端收到后调用NegTokenInit.Verify()做校验Verify 的实现逻辑为遍历MechTypes查找 KRB5OIDKRB5或 MS 遗留 KRB5OIDMSLegacyKRB5OID若找到但mechToken/MechTokenBytes为空则返回StatusContinueNeeded对应 accept-incomplete 语义若一个支持的机制都没有则返回StatusBadMech随后解包并验证内嵌的 KRB5 令牌。这套校验与 README 表格中 accept-completed / accept-incomplete 的描述一一对应。机制 OID 与 GSS-API 抽象层NegTokenInit.MechTypes中的机制用 OID 标识。gssapi 包在 gssapi.go 中定义了三个 OID 名称并在OID()函数中映射为 ASN.1 ObjectIdentifierOID 名称OID 值含义OIDSPNEGO1.3.6.1.5.5.2SPNEGO 机制本身OIDKRB51.2.840.113554.1.2.2Kerberos 5 机制OIDMSLegacyKRB51.2.840.48018.1.2.2MS 遗留的 Kerberos 5 机制变体gssapi 包的核心抽象是Mechanism接口gssapi.go它把 GSS-API 的操作映射为 Go 方法AcquireCred()获取凭据对 KRB5 而言即 AS 交换InitSecContext()发起出站安全上下文TGS 交换构造 AP_REQ 放入 ContextTokenAcceptSecContext(ct)服务端验证令牌、建立上下文MIC()/VerifyMIC()逐消息完整性GSS_GetMIC / GSS_VerifyMICWrap()/Unwrap()签名、可选加密并封装 / 解封装GSS_Wrap / GSS_Unwrap。ContextToken接口gssapi.go则规定了Marshal/Unmarshal/Verify/Context四个方法是机制令牌的通用抽象。同文件还列出了标准 GSS-API 的凭据管理、上下文级、逐消息级、支持级调用清单可作为理解接口设计背景的参考。状态码StatusGSS-API 调用失败通过Status结构CodeMessage返回gssapi.go 定义了 24 个状态常量其中与本主题直接相关的包括StatusBadMech请求了不支持的机制NegTokenInit.Verify 无支持机制时返回StatusContinueNeeded需要继续调用例程对应 accept-incomplete 流程StatusDefectiveToken令牌损坏机制令牌解包失败时返回StatusBadSig/StatusBadMIC令牌完整性校验失败。Status实现了error接口Error()方法把 Code 翻译为可读描述如StatusBadMech→ unsupported mechanism requested便于排障。内嵌令牌的底层MIC 与 Wrap 令牌RFC 4121README 提到内嵌的“初始机制令牌”与 request-mic 状态其落地形式正是 gssapi 包实现的两种逐消息令牌——它们按 RFC 4121 的二进制格式非 ASN.1编码MICToken0x0404MICToken.go 顶部保留了 RFC 4121 §4.2.6.1 的字节布局字节字段说明0..1TOK_ID固定04 04大端2Flags属性位acceptor / sealed / acceptor subkey3..7Filler五个0xFF字节8..15SND_SEQ明文发送序号大端16..SGN_CKSUM对“待签名数据 0..15 字节”的校验和MICToken结构体持有Flags、SndSeqNum、Payload与Checksum并提供Marshal()将头 校验和拼成字节流校验和未计算时报错SetChecksum(key, keyUsage)用指定加密密钥与 key usage 计算{ payload | header }的校验和Verify(key, keyUsage)重算校验和并用hmac.Equal与令牌内校验和比对防时序侧信道Unmarshal(b, expectFromAcceptor)校验 TOK_ID、acceptor 标志方向、Filler 字节再解析字段NewInitiatorMICToken(payload, key)构造发起方令牌使用keyusage.GSSAPI_INITIATOR_SIGN25计算校验和。其中Filler字段也参与校验和计算RFC 4121 注释说明“for simplicity”。WrapToken0x0504wrapToken.go 对应 RFC 4121 §4.2.6.2 的布局字节字段说明0..1TOK_ID固定05 04大端2Flags属性位3Filler固定0xFF4..5ECextra count即校验和长度大端6..7RRCright rotation count大端8..15SndSeqNum明文发送序号大端16..Data加密数据保密模式或明文校验和非保密模式实现要点计算校验和时EC 与 RRC 必须清零computeCheckSum中的getChecksumHeader将 4..8 字节置 0NewInitiatorWrapToken根据加密类型的 HMAC 位长计算ECencType.GetHMACBitLength()/8并使用keyusage.GSSAPI_INITIATOR_SEAL24Unmarshal会做长度健全性检查校验和长度不得超出剩余字节并对 token ID、acceptor 标志、Filler 逐一校验。四个 GSS-API key usageMIC/Wrap 的校验和计算依赖 key usage 区分调用方向定义于 iana/keyusage/constants.go常量值用途GSSAPI_ACCEPTOR_SEAL22接收方 WrapGSSAPI_ACCEPTOR_SIGN23接收方 MICGSSAPI_INITIATOR_SEAL24发起方 WrapGSSAPI_INITIATOR_SIGN25发起方 MIC这与 SPNEGO 协商完成后双方使用同一会话密钥对业务消息做逐消息保护request-mic 所要求的能力直接衔接。上下文标志ContextFlagsNegTokenInit 中的可选reqFlags字段由 contextFlags.go 定义RFC 2478/4178 位标志常量值含义ContextFlagDeleg1委托delegationContextFlagMutual2双向认证ContextFlagReplay4防重放ContextFlagSequence8消息序号ContextFlagConf16机密性ContextFlagInteg32完整性ContextFlagAnon64匿名ContextFlags以asn1.BitString为载体NewContextFlags()初始化 32 位全零标志位。gokrb5 在 HTTP SPNEGO 服务端会引用NegTokenInit.ReqFlags见 spnego.go表明这些标志会被用于协商后的上下文属性判定。HTTP 场景下的完整闭环Authorization: Negotiategssapi 包本身不依赖传输层但 gokrb5.v7 的spnego子包在 http.go 中提供了 HTTP 集成README 中四种应答状态在这里以WWW-Authenticate响应头的形式落地// 认证成功时的响应头预编码常量避免重复编解码开销 spnegoNegTokenRespKRBAcceptCompleted Negotiate oRQwEqADCgEAoQsGCSqGSIb3EgECAg // 认证失败时的响应头 spnegoNegTokenRespReject Negotiate oQcwBaADCgEC服务端逻辑http.go在 SPNEGO 校验失败时回spnegoNegTokenRespReject对应reject状态成功时回spnegoNegTokenRespKRBAcceptCompleted对应accept-completed状态并记录userDOMAIN身份信息。由此可以看到README 描述的四种状态并不是抽象概念而是会在真实 HTTP 协商头中出现的具体字节。与 RFC 标准的对应关系小结README 主题RFC 依据gokrb5.v7 实现位置初始协商消息RFC 4178 NegTokenInitspnego/negotiationToken.goNewNegTokenInitKrb5RFC 4178 §3.1同上NewNegTokenInitKRB5L320四种应答状态RFC 4178 NegTokenResp同上NegState常量L50-L56KRB5 机制 OIDRFC 4120 / MS 扩展gssapi/gssapi.gorequest-mic 所需的逐消息保护RFC 4121 MIC/Wrap 令牌gssapi/MICToken.go、gssapi/wrapToken.goGSS-API 抽象层与状态码RFC 2743/2744gssapi/gssapi.go排障要点与注意事项确认机制列表顺序SPNEGO 要求MechTypes按偏好降序排列。gokrb5.v7 的NewNegTokenInitKRB5只写入 KRB5 机制因此不存在排序问题若自行扩展多机制列表必须保持偏好顺序。accept-incomplete 不等于失败它表示仍需一次客户端往返。NegTokenInit.Verify()在机制令牌缺失时返回StatusContinueNeeded服务端应以 accept-incomplete 应答并等待下一轮令牌。request-mic 仅限首个应答若服务端首个应答之外再出现该状态属于协议违规应对报文做防御性拒绝。MIC 令牌的方向校验MICToken.Unmarshal/WrapToken.Unmarshal的expectFromAcceptor参数用于校验令牌发送方向跨方向使用会在校验和匹配前就被拒绝。vendored 副本一致性本仓库同时存在 implant/vendor/.../gssapi 与 vendor/.../gssapi 两份副本排查或修改行为时需留意当前编译目标引用的是哪一份implant 与服务器端分别使用。结语gssapi/README.md 虽然篇幅简短但精确概括了 RFC 4178 SPNEGO 协商的核心骨架客户端以NegTokenInit声明机制偏好并内嵌 KRB5 首轮令牌服务端以NegTokenResp的四种状态驱动协商走向。在 gokrb5.v7 中这一骨架由 spnego/negotiationToken.go 的 ASN.1 结构、gssapi/gssapi.go 的 OID/状态码/Mechanism 抽象以及 MICToken.go 与 wrapToken.go 的 RFC 4121 逐消息令牌共同落地。理解这条链路是进一步阅读 gokrb5.v7 的 Kerberos 交换AS/TGS、AP-REQ 构造以及 HTTPNegotiate认证集成代码的起点。赞分享网络安全【免费下载链接】sliverAdversary Emulation Framework项目地址https://gitcode.com/gh_mirrors/sl/sliver点击查看免费下载相关推荐Tempo 依赖中的 GSS-API/SPNEGO 协商机制解读从 NegTokenInit 到 Kerberos MIC 与 Wrap 令牌Tempo 依赖中的 GSS API/SPNEGO 协商机制解读从 NegTokenInit 到 Kerberos MIC 与 Wrap 令牌 导读 Graf后端可观测性链路追踪curl --negotiate 选项详解使用 SPNEGO/GSS-API 实现 HTTP Negotiate 认证curl negotiate 选项详解使用 SPNEGO/GSS API 实现 HTTP Negotiate 认证 导读 negotiate 是 curl 命CLI网络通信scan4all 依赖解析xdg-go/stringprep——RFC-3454 stringprep 与 RFC-4013 SASLprep 的 Go 实现深度剖析scan4all 依赖解析xdg go/stringprep——RFC 3454 stringprep 与 RFC 4013 SASLprep 的 Go 实现网络安全漏洞扫描渗透测试应用安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考