*本文作家：littlepotato安卓手机成人游戏安卓手机成人游戏，本文属FreeBuf原创奖励筹备，未经许可谢却转载。

研究认证经营的安全问题也有一段实施了，今天就对认证经营的安全问题作念个回归。其中波及到一些前置办法这里无法一一扶植，可以在经营RFC文档或者陆续中深入阅读，笔者照旧把经营尊府整理收录在参考陆续。本文更多的是对认证经营的安全问题作念个回归。另外文中援用了一些汇聚积的图片，由于来源不一，是以就不一一表明，在此一并感谢。

序

先对这些认证经营的东东作念个毛糙的归类：

PKI，X509是公钥密码规模用来进行公钥认证，惩处，分发的机构以及范例；

cookie，session，JWT是web规模保握会话情状的；

ADS是行动目次处事器系统，与LM，NTLM，kerberos通盘与windows认证或windows域认证密不可分；

Oauth和OpenID皆可以行为认证需求，只不外前者多了授权的办法；

SSO是单点登陆，是企业里面使用比拟多的办法，终显着SSO的契约有许多，包括kerberos，CAS等，而SAML就行为单点认证过程中的xml数据载体，也可以说是一种契约，提供了契约约定字段范例。咋一看会以为SSO和Oauth，OpenID有点访佛，其实他们很不一样。SSO但愿达到的遵守是登陆一次在expire期限内访谒悉数处事，即使是跨域情状，然则Oauth或者OpenID终了的是使用归并平台账号登陆不同处事。

这里会有疑问，这么看来不是和SSO一样了吗？其实否则，咱们顾惜到Oauth或者OpenID登陆不同的处事是需要一直授权的，举个例子，咱们登陆淘宝和微博是需要授权两次，然则在SSO中就不一样了。举个例子，在公司中我只须认证一次，就可以访谒坐褥网上的悉数处事，也可以访谒办公网上的一些资源，咱们只需要一次认证，这么来看就可以意会二者的不同了。

0x01 cookie，session，JWT

cookie，session， JWT皆可以用来纪录会话情状，JWT是一种相对前两者比拟新的办法，和cookie一样需要保存在客户端，session保存在处事端。这里先主要聊聊cookie和session。

径直看几张图咱们就可以对cookie，session的道理有所了解。

以php为例，处事端session生成以及cookie生成的过程：

客户端cookie和session的体现，session字段在cookie里面

浏览器对cookie和session的缓存

处事端对session的保存样子

字据使用风尚有以下几点特点：

1. cookie数据存放在客户的浏览器上，session数据放在处事器上；

2. cookie不是很安全，别东说念主可以分析存放在腹地的COOKIE并进行COOKIE糊弄计划到安全应当使；

3. 用session。将登陆信息等遑急信息存放为SESSION，其他信息若是需要保留，可以放在COOKIE中，缩小处事端压力。

4. 单个cookie保存的数据弗成卓绝4K，许多浏览器皆截至一个站点最多保存20个cookie。

cookie的六元组的意会

setcookie(name，value，expire，path，domain，secure，httponly)

1\. name和value字段自是不消多说，key-value键值对

2\. expire礼貌了cookie的逾期时刻

3\. path从旅途上指定了在请求某个特定的url目次的时候需要发送cookie值到处事端

4\. domain则从域名上指定了在访谒某个域的时候需要发送cookie值到处事端，默许便是产生cookie时候的域名，在大型的多子域名下的网站可以使用这个字段将domain缔造成根域终了cookie分享。

5\. secure属性则表明唯独当一个请求通过 SSL 或 HTTPS 创建时，包含 secure 选项的 cookie 才能被发送至处事器。这种 cookie 的内容具有很高的价值，若是以纯文本样子传递很有可能被点窜。

6\. httponly缔造成 TRUE，Cookie 仅可通过 HTTP 契约访谒。 这兴趣便是 Cookie 无法通过访佛 JavaScript 这么的剧本言语访谒。 要有用减少 XSS报复时的身份窃取行径，可淡薄用此缔造（天然不是悉数浏览器皆接济），不外这个说法频频有争议。 PHP 5.2.0 中添加。 TRUE 或 FALSE

会话限定要害成就php.ini

https://www.php.net/manual/en/session.security.ini.php

顾惜到会话中有一些成就和之前提到的cookie六元组有相似的地点，然则缔造的地点不一样，session是通过php成就项径直惩处，而cookie在运行时设定，通过set-cookie相应头反映给客户端。

# 有用期

session.cookie_lifetime = 0

# 有用旅途

session.cookie_path = /

# 有用域

session.cookie_domail=...

# httponly属性

session.cookie_httponly = 1

# 留意会话固定，防护session未运转换，默许是0不开启，[https://wiki.php.net/rfc/strict_sessions](https://wiki.php.net/rfc/strict_sessions)

session.use_strict_mode=0

# 是否安全传输，仅当使用https传输时才可访谒会话

session.cookie_secure = on

# 暗示SESSION时期的终了是否需要依赖COOKIE 1暗示是 0暗示否。若是开启会话id将只在cookie中存储，幸免了url传递会话的报复。

session.use_only_cookies = 0

# 暗示是否允许使用表单传值的形貌传递PHPSESSID 0暗示否 1暗示是

session.use_trans_sid = 1

# session的散列函数

session.hash_function="sha256"

底下主要聊聊cookie和session常见的安全问题：

1. cookie字段未缔造HttpOnly容易被DOM访谒，纠合xss剧本劫握报复，诈欺如下：

<img src=# onerror= "?data=" + document.cookie>

2. 会话固定（session fixation），用户未认证前和认证后的sessionID莫得刷新，导致可以诈欺社工或者XSS等技巧达到让其他东说念主用我方已知的sessionID登陆，从何获取受害者会话。

https://www.owasp.org/index.php/Session_fixation

笔者一发轫以为会话固定是个比拟容易被忽视的破绽点，是以尝试搭建环境复现了解下细节，也尝试了上述陆续提到的常见的几种诈欺技巧。然则发现一个问题，要想诈欺会话固定破绽，怎样把固定的sessionID注入victim的浏览器中，而况是和所要访谒站点是同源态。基于这两个截至，诈欺的条款变得特殊的尖酸。经过一番实施简陋可以得到四种想路：

1. 中间东说念主劫握，径直注入sessionID

2. 诈欺同源站点的XSS，在莫得缔造和httponly条款下，document.cookie径直修改

3. 诈欺站点CLRF破绽，注入sessionID

4. use_only_cookies字段关闭下，URL传递sessionID，php默许开启。

当看到php默许开启use_only_cookie，心里拔凉，毕竟前三种诈欺的前提多些许少有些尖酸，以至让东说念主灰心。自后经过一番搜索了解到，javaEE默许是接济jsessionid，主张便是幸免有些浏览器不接济cookie，这么是为了兼容，如斯一来，会话固定就又有了许多的诈欺价值。这里有一个老哥和我的疑问访佛

https://julienprog.wordpress.com/2017/08/17/session-id-in-the-url-is-it-a-vulnerability/。

总的来说，尽管sessionID深刻在url存在一定安全隐患，然则为了兼容，也还有不少网站使用这个作念法，让会话固定诈欺有了更低的门槛。同样的，进一步的了解发现，php 子系统session会话固定有一个CVE编号：CVE-2011-4718)。自后多的蜕变门径是更新重写了一些函数，并出现了session.use_strict_mode模式。在翻开这个模式而况按照官方的实例代码，可以很好的幸免会话固定破绽。

登陆时代后端session生成

session_destory();

session_regenerate_id();

$_SESSION['valid_id'] = session_id();

认证会话校验

if ($_SESSION['valid_id'] !== session_id()) {

  die('Invalid use of session ID');

}

JWT全名是json web token，和cookie，session一样亦然用来会话保握的。与cookie和session机制不同的是，它不需要再处事端保握会话情状，每个JWT完全标记了一个用户的登陆态，而况token完全保存在客户端，在需要访谒受访谒限定的页面的时候就需要使用token，token可以存储在localstorage或者cookie字段。Token 由头部 (header)、负载 (payload)、签名 (signature) 构成。在许多找回密码或者考据邮箱的功能中，会使用到JWT这一时期，将情状完全保存在客户端，可以很大的开释处事端的资源压力，也使得逻辑线没那么冗长。

有小伙伴可能会对完全保存存在客户端的jwt的安全性存在费神，jwt的筹划之初的契约是语义安全的。因为处事端有签名的私钥，唯独处事端可以签名和考据签名。在使用安全的签名算法的条款下可以保证不可点窜。然则这一费神却是很应该的。契约筹划没问题，不代表终了没问题（这是一条很实用的定律）。现回归一下常见的jwt认证安全问题。

需要顾惜的是jwt中对应的base64并不是一个严格道理上的base64，由于token有可能被作念为url，而base64中的+/=三个字符会被转义，导致url变得更长，是以token的base64会将+转换为-、/转换为_、删除=。

1.修改认证形貌（空认证和HS256认证的残障）

若是后端的空认证检测作念得不够好，就会形成客户端修改签名形貌为none，然后绕过在处事端的签名认证，从未可以终了修改token的主张

若是后台使用RSA私钥进行认证，咱们可以把签名换成HS256，然后通过HMAC-SHA256签名算法，使用RSA公钥来进行客户端认证点窜，然后终了自便payload点窜的主张。

2.弱认证形貌的暴力破解

当今GitHub上有一些相对比拟训练的用具，暴力破解HS256签名的JWT，若是签名的key是脆弱的，那么可以径直暴力解出key，然后就可以为所欲为。

3.使用refresh token和access token 的非关联性脆弱

授权处事器莫得查验refresh令牌<->访谒令牌关联。这意味着我可以用attack的refresh令牌刷新victim的访谒令牌。

4.JWT中字段涉数据库查询的注入诈欺

这一要害是指在后台对JWT的payload数据进行了相应的数据库操作，如插入，查询等等，然则却过滤不严谨，在诈欺JWT的脆弱性后就可以进行自便的sql注入，许多时候为了便捷，可以使用sqlmap，我方编写经营temple剧本达到自动化注入。

上头提到的报复形貌照旧集成到了webgoat靶场中，而况网上也有了不少教程这里就不再啰嗦。

0x02 SSO单点认证

SSO认证最常见的场景是在公司里面终了ACL限定的搭伙化，一来是增多企业安全性，防护口令泛滥，而来给职工惩处或者资源访谒带来便捷。那么什么是SSO呢？先看下下图：

以下内容节选自参考陆续[3]

1. 用户访谒app系统，app系统是需要登录的，但用户当今莫得登录。

2. 跳转到CAS server，即SSO登录系统，以后图中的CAS Server咱们搭伙叫作念SSO系统。 SSO系统也莫得登录，弹出用户登录页。

3. 用户填写用户名、密码，SSO系统进行认证后，将登录情状写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。

4. SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同期将ST行为参数传递给app系统。

5. app系统拿到ST后，从后台向SSO发送请求，考据ST是否有用。

6. 考据通事后，app系统将登录情状写入session并缔造app域下的Cookie。

至此，跨域单点登录就完成了。以后咱们再访谒app系统时，app便是登录的。接下来，咱们再望望访谒app2系统时的经过。

1. 用户访谒app2系统，app2系统莫得登录，跳转到SSO。

2. 由于SSO照旧登录了，不需要重新登录认证。

3. SSO生成ST，浏览器跳转到app2系统，并将ST行为参数传递给app2。

4. app2拿到ST，后台访谒SSO，考据ST是否有用。

5. 考据见效后，app2将登录情状写入session，并在app2域下写入Cookie

SSO单点认证的终了形貌有许多，包括主机认证层面和web处事用户认证层面。上头的交互过程是web用户认证层面的交互细节。后头聊到的Window域认证kerberos契约便是主机认证域处事授权的终了形貌。

SAML

有兴味可以参考SAML的RFC文档

往毛糙了说SAML便是一种XML数据样子，界说了范例字段用于单点认证，本人也可以意会为一种契约范例，认证绪论或者数据载体。它行为SSO一种常用的终了形貌。咱们望望SAML存在的安全隐患。

分析测试用具

SAML Raider bp(https://github.com/SAMLRaider/SAMLRaider)

安全性问题

1. 删除签名形貌标签，可以绕过认证，源于ssl模式下的认证可选性

例子： https://hackerone.com/reports/136169

2. python-saml组件对于字段的索要忽略标签属性后的值，导致截断，然则在作念举座hash校验的时候会先进行范例化忽略凝视，导致修改固定字段但saml文献仍旧校验通过。

例子：https://duo.com/labs/psa/duo-psa-2017-003

3. SAML音信逾期机制和重放，若是SAML中坚苦了音信expiration界说，而况断言ID不是惟一的，那么就容易受到常见的重放报复。

0x03 Oauth与OpenID

其实实质上来看，openID和Oauth皆是SSO的一种变形，或者说是一种拓展终了，其达到的遵守在客户端看来皆是使用一个账号登陆了许多种处事。然则在处事端这几种形貌切入点有不同。SSO的初志是为了终了ACL按捺到一个进口，便捷作念权限惩处，幸免密钥泛滥形成的安全隐患。而OpenID是一种将认证承包给第三方处事的作念法，使得处事商可以幸免复杂的ID惩处，而专注于业务。Oauth其实一发轫不是用来作念认证的，而是一种授权，举个例子，处事商A和处事商B从属不同公司，然则A的处事需要用到B处事中的一些资源，这个时候就需要client将A处事的账号和B处事的账号关联，走Oauth的契约终了这一资源请求的授权，只不外到了Oauth 2.0以后，东说念主们发现授权的过程包含了认证的过程，是以干脆就径直可以使用Oauth来进行认证。

OpenID

国内一般皆用Oauth2契约作念认证和授权，是以这里只先容一下OpenID的经营办法。

最初先容办法：

- End User：终局用户，使用OP与RP的处事

- Relying Party依赖方：简称RP，处事提供者，需要OP鉴权终局用户的身份

- OpenID Provider：OpenID提供者，简称OP，对用户身份鉴权

- Identifier标记符：标记符可以是一个HTTP、HTTPS或者XRI(可延迟的资源标记)

- User-Agent：终显着HTTP1.1契约的用户浏览器

- OP Endpoint URL：OP鉴权的URL，提供给RP使用

- OP Identifier：OP提供给终局用户的一个URI或者XRI，RP字据OP Identifier来领悟出OP Endpoint URL与OP Version

- User-Supplied Identifier：终局用户使用的ID，可能是OP提供的OpenID，也可以是在RP注册的ID。RP可以字据User-Supplied  

- Identifier来领悟出OP Endpoint URL、OP Version与OP_Local Identifer

- Claimed Identifier：终局用户声明我方身份的一个标志，可以是一个URI或者XRI

- OP-Local Identifier：OP提供的局部ID

终局用户请求登录RP网站，用户选拔了以OpenID形貌来登录

RP将OpenId的登录界面复返给终局用户

终局用户以OpenID登陆RP网站

RP网站对用户的OpenID进行圭臬化，此过程至极复杂。由于OpenID可能是URI，也可能是XRI，是以圭臬化形貌各不一样。具体圭臬化过程是：若是OpenID以xri://、xri://$ip或者xri://$dns起原，先去掉这些标记；然后对如下的字符串进行判断，若是第一个字符是=、@、+、$、!，则视为圭臬的XRI，否则视为HTTP URL（若莫得http，为其增多http://）。

RP发现OP，若是OpenId是XRI，就采纳XRI领悟，若是是URL，则用Yadis契约领悟，若Yadis领悟失败，则用Http发现。

RP跟OP建立一个关联。两者之间可以建立一个安全通说念，用于传输信息并裁汰交互次数。

OP处理RP的关联请求

RP请求OP对用户身份进行鉴权

OP对用户鉴权，请求用户进行登录认证

用户登录OP

OP将鉴权结尾复返给RP

RP对OP的结尾进行分析

Oauth

Oauth在国内用得比拟多，这里就要点聊聊Oauth。

OpenID是用来认证契约，OAuth是授权契约，二者是互补的。但在国内的使用情况中，Oauth被行为认证进行“挥霍”，是以在国内基本皆是采纳Oauth这种形貌进行第三方账号登陆。在学习Oauth之前，需要先了解以下Oauth的发展史。2007年12月4日发布了OAuth Core 1.0， 此版块的契约存在严重的安全破绽：OAuth Security Advisory: 2009.1。2009年6月24日发布了OAuth Core 1.0 Revision A：此版块的契约确立了前一版块的安全破绽，并成为RFC5849，咱们当今使用的OAuth版块无数皆是以此版块为基础。OAuth 2.0是OAuth契约的下一版块，但不向后兼容OAuth 1.0。 OAuth 2.0关心客户端开发者的肤浅性，同期为Web应用，桌面应用和手机，和起居室斥地提供挑升的认证经过。

国内常用的第三方平绽放台

微博绽放平台

[]()

微信绽放平台

[https://open.weixin.qq.com](https://open.weixin.qq.com)

QQ互联平台

[https://connect.qq.com](https://connect.qq.com)

Oauth2几个办法：

resource owner，资源悉数者，莽撞允许访谒受保护资源的实体。若是是个东说念主，被称为 end-user。

resource server，资源处事器，托管受保护资源的处事器。

client，客户端，使用资源悉数者的授权代表资源悉数者发起对受保护资源的请求的应用法式。如：web网站，迁徙应用等。

authorization server，授权处事器，莽撞向客户端颁发令牌。

user-agent，用户代理，匡助资源悉数者与客户端视通的用具，一般为 web 浏览器，迁徙 APP 等。

一个客户端想要获取授权，就需要先到处事商那注册你的应用。一般需要你提供底下这些信息：

应用称呼

应用网站

重定向 URI 或回调 URL（redirect_uri）

在发送Oauth请求的时候，咱们经称容易在请求头部看到如下几个参数：

client_id客户端标记，这个参数是和客户端一一双应的，这么处事端才知说念认证请求来自哪个客户端.举例”101019034”代表的便是新浪微博这个客户端

response_type授权类型，上文照旧说了OAuth有多种授权类型.此处”code”代表使用的是Authorization Code(授权码模式)

scope央求的权限范畴

redirect_uri重定向URI，用户赐与授权后，将会佩带授权码跳转到此地址

state这个参数是用来留意CSRF的，你可以将其意会为咱们常用的”token”.这里它的使用和”token”亦然一样的.

每次授权请求，客户端皆会生成一个state，并将其保存到cookie或session中.授权见效后，处事端原样复返state，客户端将其与cookie或session中的值进行比对.

重定向 URI 是处事商在用户授权（或隔断）应用法式之后重定向用户的地址，因此亦然用于处理授权代码或访谒令牌的应用法式的一部分。在你注册见效之后，你会从处事商那获取到你的应用经营的信息：

客户端标记 client_id

客户端密钥 client_secret

client_id 用来表识客户端（公开），client_secret 用来考据客户端身份（守密）。

Oauth2 常见的四种模式

具体的终了过程可以参看rfc文档

授权码模式

隐式模式（简化授权码模式）

登陆模式

客户端模式

Oauth安全问题

谈及Oauth的安全问题，在了解Oauth的认证机制后，可以发现其中access_token，code这两个值是特殊要害的，只须咱们有办法获取这些值，或者径直劫握用户可以达到报复遵守。底下是当前比拟常见的安全问题。

1.绽放的重定向陆续模式匹配

咱们试想客户端在授权绽放平台注册的重定向URI不是完全详情的，如"https://*.somesite.example/*"，[https://client.somesite.example/param?](https://client.somesite.example/param?)*。针对这两种注册形貌，是完全有可能绕过的底下给出绕过的poc（假定client_id = 123456）

针对第一种注册重定向陆续的模式：摄取了其子域名的情况下，咱们可以构造如下url诱使客户端访谒。然则一般情况下，还需要client_secret，隐式模式下完全信任客户端就不再需要client_secret获取code，而是径直获取access token。

[?response_type=code&client_id=123456&state=xyz&redirect_uri=https://evil.somesite.example/cb

针对第二种注册重定向陆续的模式，在客户端存在可控的重定向参数(这里是redirect_to)的情况下，若是Oauth采纳隐式模式，咱们可以径直将access_token引流至咱们处事器

[?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https://client.somesite.example/cb&redirect_to%3Dhttps%3A%2F%2Fclient.evil.example/c

2.认证流沾污

这其实有点访佛于中间东说念主劫握，而况要求的条款比拟尖酸，要想终了这种报复需要自在三个条款：

（1）隐式或授权代码授权被用于多个AS（这里先假定两个），其中一个被认为是“真实的”(H-AS)，另一个由报复者操作(A-AS)，

（2）客户端将用户选拔的AS存储在绑定到用户浏览器的会话中，并对这两个AS和使用一样的重定向URI，

（3）报复者可以操作从用户浏览器到客户端的第一个请求/响草率(其顶用户选拔某个AS，然后由客户端重定向到该AS)。

3.认证信息泄露（access token，state，code......）

其实这种报复和粗鄙的xss访佛，只不外将document.cookie向量换成window.location.href，或者通过镶嵌iframe的形貌，让认证信息外泄。或者径直在处事端泄露access_token等。

4.浏览器访谒历史纪录

一般的Oauth终了中，由于波及浏览器的重定向，参数一般皆是径直放在url上，基于这一特点，若是有办法径直构兵浏览器的历史纪录，亦然一个可以的方法。不外这种技巧有一个局限性，那就Oauth一般有expire或者放重放机制，若是时效性或者防重放作念得不好，或者使用了隐式模式也会带来危害。

5.redirect_url 重定向破绽

若是处事器在用户输入的redirect_url参数上莫得作念过滤，就会存在重定向破绽，纠合csrf，可以让重定向破绽为csrf或者xss提供跳板。或者径直输入attack限定的域名，在refer头部获取token。顾惜到在授权码模式下，redirect_url的处理出当今AS和client端，是以这两个地点皆需要对redirect_url进行校验过滤，第一处报复可以获取token，诈欺获取的token，第二次就可以获取access_token。

6.不安全的Oauth认证会话

用户在授权的时候需要先认证，若是AS在授权收场后不主动刊出登陆会话，就会产生会话溢出。在用户登出请求授权的client后，AS处用户的登陆态仍旧保握，那么若是浏览器被东说念主限定的话，可以径直获取这一开启的会话。

7.账号关联功能CSRF

试想一种报复场景，比如报复者在一个网站关联QQ号，那么它截获临了复返access_token时候的数据包，把这个请求行为payload诱使victim访谒，在victim登陆了网站的前提下，会自动将账号和报复者的qq账号关联。

0x04 windows 认证

windows上的认证简陋可以分为两种，一是莫得加入kerberos的使命组办法的基于NTLM契约的认证，二是windows域环境的下的认证。

NTLM认证

第一步，最初在client输入username，password和domain，然后client会把password hash后的值先缓存到腹地

第二步，之后，client把username的明文发送给server(DC)

第三步，DC会生成一个16字节的当场数，即challenge(挑战码)，再传回给client

第四步，当client收到challenge以后，会先复制一份出来，然后平和存中的密码hash再一同搀杂hash一次，搀杂后的值称为response，之后client再将challenge，response及username一并皆传给server

第五步，server端在收到client传过来的这三个值以后会把它们皆转发给DC

第六步，当DC接到过来的这三个值的以后，会字据username到域控的账号数据库(ntds.dit)里面找到该username对应的hash，然后把这个hash拿出来和传过来的challenge值再搀杂hash

第七步，将(6)中搀杂后的hash值跟传来的response进行比拟，一样则认证见效，反之，则失败，天然，若是是腹地登录，悉数考据坚信也全部皆径直在腹地进行了

咱们可以看到，在这个认证中，使用到明文密码的地点唯独用户登陆的时候，后头使用到的全是密码hash，这么一来就产生了一个安全问题，PTH（Pass The Hash），只须咱们拿到了密码hash值就可以径直模拟用户登陆。

顾惜到NTLM时基于挑战的认证契约，在认证前，DC必须有用户密码hash的存储，否则时不可能在第七部解密见效。天然，上头的场景是比拟逼近域的办法，使用了中心DC来存储用户的密码hash而况作念挑战校验，有少许SSO单点的登陆的兴趣，然则仔细看会发现少了ticket的办法，后头会发现域认证是SSO单点登陆的一种具体终了。不外其实许多时候，DC和Server是归并台机器，契约经过和上头一致。

kerberos认证

意会kerberos认证之前照旧先来了解一下经营办法：

KDC: Key Distribution Center，包括三大块（KAS，TGS，密码hash数据）

KAS：Kerberos Authentication Service，庄重用户认证并签发TGT

TGS: Ticket Granting Service，庄重认证TGT并签发处事单据ST

TGT: Ticket Granting Ticket，包括用户经营信息和Logon Session Key(确保该用户和KDC之间通讯安全的会话秘钥)，标记认证已完成

ST: Service Ticket，处事单据，用来访谒经营处事，标记处事已授权。ST主要包含两方面的内容：客户端用户信息和Service Session Key(保客户端-处事器之间通讯安全的会话秘钥)，并通过被请求处事的处事器密钥加密。

1)最初，客户端(client)将域用户的密码hash一次并保存，然后，以此hash来行为客户端和KDC之间的恒久分享密钥[kc](天然，在DC上也保存着同样的一条hash)

2)KRB_AS_REQ：客户端(client)发轫诈欺(1)中的域用户密码hash再把时刻戳，clientid，TGS id等信息搀杂hash一次，然后向as(认证处事器 [Authentication Server])处事器进行请求

3)KRB_AS_REP：AS接到该请求后，诈欺恒久分享密钥(kc)进行解密，解密见效后，会复返给客户端两个单据

  (1)加密的K(c，tgs)(用于客户端后续向KDC发起请求)，其中c=(TGS Name/ID，时刻戳等)，该单据由Kc加密

  (2)单据授予单据(Ticket Granting Ticket，简称TGT)，该单据是给TGS的，单据的内容包括K(c，tgs)，其中c=(Client身份信息，域名，时刻戳等)，该单据由TGS的秘钥加密，唯独TGS莽撞解密

4)KRB_TGS_REQ：客户端会诈欺恒久分享密钥解密k(c，tgs)，并诈欺该秘钥加密生成一个Authenticator，其中c=(lifetime，时刻戳，Client身份信息等)，连同从AS获取的TGT一并发送给TGS

5)KRB_TGS_REPTGS：TGS诈欺自身的秘钥解密TGT，获取K(c，tgs)，并用K(c，tgs)解密客户端发送的Authenticator，对Client进行认证，若是Client通过了认证，TGS当场生成一个Session Key K(c，s)，并产生两个单据

  (1)处事单据(Ts):这是给处事器的处事单据，由Server秘钥Ks加密，内容包括：K(c，tags)，其中c=(Client身份信息，Service ID，时刻戳，lifetime等)

  (2)客户端单据(Tc)：该单据由K(c，tgs)加密，其中c=(K(c，s)，Server身份信息等)

6)KRB_AP_REQ：客户端收到tgs的复兴后，诈欺K(c，tgs)解密Tc，获取K(c，s)，Server身份信息等，并诈欺K(c，s)加密生成一个Authenticator发送给Server，内容包括:时刻戳，Client ID等信息，连同Ts一并发送给Server

7)KRB_AP_REP：Server端在收到Client的请求后，诈欺自身秘钥Ks解密Ts，得到K(c，s)，再诈欺K(c，s)解密Authenticator，对Client进行认证，若是认证通过，则暗示KDC照旧允许了这次通讯，此时Sever无需与KDC通讯，因为Ks为KDC和Sever之间的恒久分享秘钥，若是在有用时刻内，则这次请求有用。

对于windows认证存在的报复形貌

通过对上述认证经过的意会，咱们可以归纳出windows的域认证有以下几个明锐的特点：

国产色情

- NTLM认证中只用到用户密码hash

- kerberos用户的密码一般很少改革

- 只须知说念kerberos 用户hash就可以签发TGT

- 只须知说念提供处事的主巧妙码hash，就可以签发ST

- 客户端可以松驰计划特定处事的TGT

- 域内的主机皆能查询SPN（处事标记符）

基于上头说到几个明锐特点，催生了一些域渗入报复技巧。

PTH（Pass The Hash）

通过上濒临windows认证经营的了解，咱们可以知说念在默许的使命组环境中，以密码hash行为玄妙，通过challenge机制行为校验通过的依据，是以认证的整个过程，咱们只需要知说念用户hash，就可以字据契约经过终了特定用户的登陆。

https://github.com/gentilkiwi/mimikatz/wiki/module-~-sekurlsa

privilege::debug

sekurlsa::pth /user:xxx /ntlm:xxx's ntlm hash /domain:xxx /run:cmd.exe

PTT（Pass The Ticket）

PTT报复是基于上述kerberos认证契约，简陋分为白银单据和黄金单据两种单据伪造报复样子。

白银单据：知说念了办当事者机的ntlm hash咱们可以伪造ST，构造KRB_AP_REQ请求过程，让处事端信托咱们的ST是从KDC获取的，其实咱们是通过其NTLM hash我方生成的，也即我给我我方颁发了一个正当的ST。

黄金单据：同样的，若是咱们有才智获取到kerberos用户的密码hash，那么咱们就可以领有KDC统统的权益，比如咱们可以给我方签发高权限的TGT，然后诈欺构造KRB_TGS_REQ请求包获取自便处事的ST。

https://github.com/gentilkiwi/mimikatz/wiki/module-~-kerberos

# 白银单据

mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<主张处事器主机名> /service:<处事类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exit

# 黄金单据

mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<自便用户名> /ptt" exit

MS14-068

微软在Windows平台上的Kerberos并莫得采纳MIT的终了，而是对Kerberos契约进行了一些推论，其中最遑急的推论便是增多了认证过程中的权限认证，也便是在契约中增多了PAC（Privilege Attribute Certificate），特权属性文凭，主要主张便是用来终了权限的ACL。恰是PAC这的加入，开发对kerberos的终了就出了岔子。可以形成在客户端KRB_AS_REP要害中，修改PAC从而获取域控权限的TGT。

具体道理淡薄移步这篇著作： https://www.freebuf.com/vuls/56081.html

微软破绽声名：https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-068

# 域控上获取补丁确立信息

systeminfo | findstr /i kb3011780

通过上述的技巧若是发现域控莫得装配这一补丁，内网渗入的门路就会开朗开来，当今照旧有不少exe，或者剧本，以至在msf里面也有了诈欺集成。

Python Script)Msf Payload)

Kerberoasting

三勤学生前辈的著作，写得照旧十分翔实。

https://3gstudent.github.io/3gstudent.github.io/域渗透-Kerberoasting/

参考

[1] https://tools.ietf.org/html/rfc7522

[2] https://tools.ietf.org/html/rfc6749

[3] https://tools.ietf.org/id/draft-ietf-oauth-security-topics-06.html

[4] https://duo.com/blog/the-beer-drinkers-guide-to-saml

[5]

[6] -10-oauth-2-implementation.html

[7] https://ldapwiki.com/wiki/OAuth 2.0 Vulnerabilities

[8] https://www.sans.org/reading-room/whitepapers/application/attacks-oauth-secure-oauth-implementation-33644

[9] https://xz.aliyun.com/t/2445

*本文作家：littlepotato，本文属FreeBuf原创奖励筹备，未经许可谢却转载。

• 安全
• 认证
• 安卓手机成人游戏
• 看懂
• 疑问