前言
本文阅读需要10min，介绍了从SSO到MFA发展的身份认证安全体系的缺陷，再到FIDO对IAM的补充。最终介绍了ITDR（身份威胁检测和响应）等新理念以攻击者视角对零信任方案的补充。
从SSO说起
传统框架的缺陷
“都什么年代了，还在用传统认证方式？”
在技术不断迭代的当下，还有不少企业在使用传统认证方式。使用者通过B/S或者C/S的框架向后端服务器认证身份，服务器通过一系列流程，验证成功后通过例如JWT/Cookie的机制，在客户端保存用户的登录凭证。
除了本身机制带来的传统安全问题（比如URL中带密码、撞库、弱口令），传统认证方式还会增加较大的运维成本。假设企业内部有多套业务系统，其使用人员包括但不限于公司员工，外包人员，供应商，监管机构等。使用的人数与类型越多，其存在的风险点也会与日俱增。而且员工被迫要为多套系统记录多个账号密码，尽管参加了许多安全意识培训，但惰怠和健忘是难免的，就算是专业的安全从业者也不一定能完全做到完全符合安全规范。
此外，使用密码管理器也有风险，今年九月份，某知名密码管理器公司承认其被黑客攻击。尽管公司在发现攻击行为后已经拼命进行阻止，但是结果令人感到惋惜，黑客依旧突破了封锁，该公司的部分源代码和专有技术信息被窃取。该公司随后发布了一份安全公告，确认黑客是通过访问公司开发人员的账户进行入侵。
OAuth认证流程
单点登录（Single Sign On）技术的出现在一定程度减少了上述风险，并提供了更好的可用性与用户体验。SSO的实现方式也分多种，有基于Cookie的单点登录，登录子应用时，会带上父应用的Cookie，解密之后校验用户的身份，基于JWT的SSO也不失为一种优秀的解决方案，不过得到广泛应用的认证标准还得是OAuth2。
我们在登录很多站点，比如语雀的时候，经常能看到如图所示的登录框，提供了多种登录方式。这就是OAuth的一个经典场景，当用户点击任何一个平台作为登入方式后，便进入了OAuth的认证流程。
RFC6749中描述了OAuth的授权模型，首先介绍两个比较容易混淆的概念。认证与授权是安全人员用于保护系统的两个重要安全过程，认证负责验证用户或服务的身份，授权决定了他们的访问权限。
Authenticate(v)：认证。其重点倾向于“证明”用户具有对应的权限，其行动主体是服务器，验证主体为用户方。
Authorize(v)：授权。其重点倾向于“赋予”，用于授予用户或者服务具体的访问级别。
简而言之，一个在授予用户访问权限之前验证用户或者服务的身份，而另一个确认他们在获得访问权限后可以做什么。以语雀使用支付宝为例，当用户点击使用支付宝登录之后，进入以下流程。
这种是最为常见的授权码认证方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
由于前端直接管理与获取Access Token，并携带Access Token发出请求获得对应资源，因此隐藏式授权码在安全性上会相对薄弱一点。
如果用户高度信任某个应用，比如内部的堡垒机系统，也可以直接将账号密码信息告知应用，由该应用直接向Authorization Server获取Access Token，整体使用方式与传统方式相同。
如果连前端都没有，直接由应用程序发送请求，一般常见于Machine to Machine的认证过程，则会用到凭证式认证方法，以比较常见的Windows Kerberos/NTLM为例，大致流程如下图。
SSO面临的安全挑战
诚然，SSO能一定程度缓解企业所面临的安全挑战，但它作为一种工具，也存在着一些天然缺陷，接下来主要从漏洞和风控两个层面来分析。
首先是老生常谈的Xss，如果SSO没有对参数做对应的过滤，就会出现跨站脚本的问题。
同理，也会出现SQL注入。
而OAuth的认证过程中会带入Redirection URL，如果没有对Redirection URL做有效校验，SSO的重定向页面便可用于钓鱼。此类漏洞归结于业务中如何处理返回的Redirect URL 参数。
Paypal之前就爆出过一个SSO重定向漏洞，开发人员可通过开发者账号开发PayPal支付服务组件，之后应用可生成令牌请求并发送到授权服务器，服务器会制定返回参数Redirect URL并作了相关过滤。但是可能出于方便开发者调试的考虑，PayPal允许localhost 作为 Redirect URL参数，经过测试发现可以利用类似localhost.mydomain.com的域名来接受返回的Access Token。
Facebook开发平台在运行之初也爆出过越权问题，在开发平台体系中，各个App的App Id实际上是非常好获取的，攻击者如果构造一个恶意App，然后假冒合法高权限App的App Id引导用户进行Scope授权 此时用户一般不太会关注其授权的应用名字，而完成授权后，即可拿到该用户的Access Token。之后Facebook要求开发者导出签名并配置到开放平台，也成为了通用的解决方案。
除此之外，SSO还会引入风控问题。国家网信办发布的《移动互联网应用程序信息服务管理规定》今年8月起施行，要求移动互联网应用程序（APP）按照“后台实名、前台自愿”的原则，对注册用户进行基于移动电话号码等真实身份信息认证。比如说国内很多应用都支持微信作为SSO的登录源，而微信是支持VoIP号码作为绑定号码的，这个地方就会产生一个风控问题，微信采用了其他实名认证机制比如人脸识别，绑定银行卡等所以不依赖绑定号码作为唯一实名制凭证。下面举一个例子：
如图所示，测试微信号绑定了基于Know Roaming的VoIP国外号码。
国内某社交网站，由于风控机制，如果注册号是+86开头，则不允许换绑其他区号的号码。
而此时，在App的登录界面，选择使用微信作为SSO登录方式，登录成功后，在账号管理界面即可看到，绕过了平台的风控机制，此时解绑微信账号，仍可保留VoIP的号码，并可以正常接收登录验证码，并在平台发布内容。
笔者测试了不少国内大型网站，存在类似问题的不在少数。从风控的角度看这个问题，攻击者可以在敏感时间段利用类似风控隐患得以较低成本地在社交媒体发布不当内容，造成舆情影响。随着个人信息保护法和等保的深入推进，类似的风控问题可能将成为热点问题。
MFA 闪亮登场
喜闻乐见的验证码
为了应对SSO所面临的安全挑战，使MFA（多因子认证）作为第二道防线，它要求用户提供两个或以上验证因子才能访问对应资源，MFA是IAM（身份识别与访问管理）的核心组件，有效降低网络攻击成功的可能性。而随着等保2.0的普及，MFA也成为了很多企业业务的标配。
参考最近的一起安全事件，某企业疑似泄露4000W短信数据，该公司拥有银行、电子商务、移动互联网、快速消费品等不同类别的客户。是众多知名企业的短信平台服务商。就是短信中有染色数据可以事后追溯，但依然难以遏制即时的短信验证码泄露问题。不光如此，之前还报道过短信降维打击的攻击手法。攻击者使用“GSM劫持+短信嗅探技术”的手法，便可以嗅探到短信明文，虽然随着技术的进步，比如使用了CMPP协议加上TLS传输，这些隐患的发生概率都在降低，但使用短信作为OTP的终端还是存在风险。
兼容性与安全性
一些规模体量比较大的企业，为了向下兼容，往往会提供全终端支持，其中包括了一些比较冷门的平台，比如S40，BlackBerry，Palm，WAP端等，一些制造业企业甚至会提供PAD端。向后兼容和前向安全有的时候就在此处爆发矛盾了。
在实际的渗透测试过程中，我们可能会拿到客户一些登录凭证，而使用陌生设备加上陌生IP登录一般会触发SSO平台的风控，而此时这些平时容易忽略的冷门平台就派上用场了。
某次渗透测试过程中，使用获取到的邮箱密码登录客户邮箱系统，显示非常用IP端，禁止登录，使用了伪造XFF头，X-Remote-IP等方式均无果。而后来下载客户专用Windows Phone端邮件客户端，成功登录客户邮箱系统，抓取请求包后使用Burp在浏览器重放，可登录Web端邮箱，绕过MFA机制。
上述案例肯定不是孤例，之前苹果的2FA也爆出过严重漏洞。一位Laxman Muthiyah的安全研究人员证明了，只要你拥有28000个IP的IP池，便可以力破巧，绕过Apple ID的2FA，只需要知道受害者的手机号码，即可接管其Apple ID。漏洞的原理是竞争条件，攻击者利用服务器的竞争条件漏洞并发送多个并发请求来重置密码。苹果为了避免这种竞争条件利用，对可以发送的重置密码的请求数量进行限制。在有限的时间段内，每个号码最多有5次尝试的限制，之后它会阻止该帐户几个小时。然而，攻击者发现从不同的 IP 发送了多个请求以欺骗系统便可绕过机制。
iforgot.apple.com 在全球有6个负载均衡节点——（17.141.5.112、17.32.194.36、17.151.240.33、17.151.240.1、17.32.194.5、17.111.105.243）。
其中有两个限制，单个号码发送超过五次请求与同时发送超过六个并发Post请求。
这两个速率限制都特定于苹果服务器 IP，这意味着可以向另一个负载均衡发送请求。
根据限制，我们可以从单个 IP 地址向 6 个负载均衡地址（6 x 6 = 36）发送多达 36 个请求。
攻击者构造了一个包含28000IP的IP代理池，演示爆破了特定Apple ID账户。
虽然不是每个人都能构造一个巨大的IP池，不能否认MFA机制中存在的隐患。还有一些更为显而易见的漏洞，比如MFA的响应可预测。举个例子，某应用使用了OTP作为MFA的验证方式，在抓包后发现其验证失败的响应为error，而其认证成果的响应为success。
简单的修改响应，便绕过了形同虚设的MFA。
沙场秋点兵
由以上的案例可以得出一个明显的结论，不安全的MFA机制比没有MFA更加危险。在部署MFA之前，用户/员工可能会比较谨慎地选择强密码，而在MFA落地后，反而更容易选用弱口令。因此有必要评估一下MFA的各个选项，按照上面的思路，同时评估其安全性与实用性。
OTP：One-Time Pass,一次动态口令验证，是指计算器系统或其他数字设备上只能使用一次的密码，有效期为只有一次登录会话或交易。一般的静态密码在安全性上容易因为木马与键盘侧录程序等而被窃取，而只要花上相当程度的时间，也有可能被暴力破解。为了解决一般密码容易遭到破解情况，因此开发出一次性密码的解决方案。其载体也比较多样，邮件，短信，纸本文件，App，硬件载具等，其安全性根据载体的不同而变。重点说一下硬件载具，将产生动态密码所需的密钥存放于载具内，避免被中间人攻击或因为行动载具的系统漏洞而被获取密钥。此外，独立载具内置电池模块，因此会有寿命和回收的问题；或是使用由外部供电的载具，经由模拟键盘输入的方式访问密钥，但是此种载具和电脑有实体接触，因此没有与独立载具相同的安全性。
优势：
解决用户在记忆与保存密码上的困难；
由于密码只能使用一次，且是动态产生，难以预测，可以大为提升使用的安全程度。
劣势：
一次性密码多数需要手机号码收取短信；
收取方可能会有延迟或无法收取的问题。
由于设计问题，有可能被完全绕过。
CBA：Certificate Based Authenticators,即基于证书的认证。基于非对称加密，安全性较高，可以采用双向认证方式支持。服务器证书可以自己签发也可以由 第三方签发，银行颁发的U-key就属于这种MFA类型。不过弊端是开发成本高，对服务器资源的占用也较大，而且需要安装浏览器插件，有可能出现兼容性问题（仅支持IE浏览器）。
优势
非对称密钥加密，安全性能高。
劣势
开发维护成本高，服务器资源消耗较大。
兼容性堪忧，不能做到全平台使用。
FIDO：Fast IDentity Online.
FIDO 明日之星
less之风兴起
2019 年，Serverless 就曾被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路。
根据 2022 年 Verizon 数据泄露调查报告，65% 的数据泄露是由凭据滥用引起的,而只有4%是由系统漏洞引起的。82%的内部违规行为都涉及人为因素，包括社会工程攻击、用户错误和数据滥用。而纵向观察近几年的OWASP Top10，可以明显地看到失效的访问控制已经成为最大的一项。为了应对这种情况，企业内部的安全部门或者SOC需要新的工具。在Serverless大规模落地后，以Microsoft，Google等厂商牵头，开始提出Passwordless的概念，今年五月，Apple、Google与Microsoft等众多企业纷纷表示支持FIDO联盟与W3C理事会提出的通用无密码登入标准（common passwordless sign-in standard），希望向消费者提供一致、安全、简单易操作，无须输入密码的系统。
Google指出，比起输入密码与MFA，Passwordless更加安全，为了解决这个痛点，FIDO标准就此诞生，旨在将用户的生物特征（人脸、指纹等）注册成一串钥匙，而每个人只要握有自己的钥匙，就能在各大网站与应用程式中畅通无阻。最初的FIDO 1.0注重硬件载体、无密码认证、本机认证机制，后来升级为FIDO 2.0后，允许浏览器进行密钥注册与验证，使用重硬件载体与MFA App实现多重验证标准。
同时，微软也在测试无密码验证机制，Windows Hello企业版不仅提供生物辨识与PIN码验证，也结合企业身份辨识服务Azure Active Directory（Azure AD），设计出一套利用数位签证与加密技术进行验证的机制。而Microsoft Authenticator（微软身份验证器）也有提供生物辨识、加入Azure AD，不过它还允许使用者选择手机号码或身份验证App方式进行认证。
密钥载体
理想很美满，但是仍然需要一个物理载体。目前FIDO2的物理硬件一般是指Yubikey，Google在其高级保护计划中便推荐了Yubikey作为实体密钥。那么它能做到哪些功能呢？
Legacy Keyboard：Yubikey支持长按与短按两个Slot，用于存储用户两个预设好的密码。虽然看起来非常不安全，不过要求接触到物理密钥。反倒是有人在输入密码的时候看着输更令人担忧。静态密码不安全无非在于，Yubikey 离身后直接被熟人套取密码，但是有两个静态密码，就可以有很多种组合，例如A、B、AB、BA，以及在此基础上添加字符、删减字符，这样可以使得你的主密码更加安全。当然，做了这么多工作，最重要的还是 Yubikey 尽可能的不要离身，这样静态密码才能安全。
OTP：Yubikey一共支持三种OTP协议，分别是 OTP一次性密码，Challenge-Response 挑战-响应认证，OATH+HOTP 基于 HMAC/时间的两种一次性密码算法。重点讲一下Challenge-Response和TOTP。在支持的网站添加Yubikey作为认证方式后，每次登录后都会要求提供Response作为MFA的凭证，实际使用中只要触摸一下金属片即可，非常方便。其用两种工作方式：
Yubico OTP 模式
在这个模式下，客户端会发送一个 6 字节的挑战码，然后 Yubikey 使用 Yubico OTP 算法来创建一个反馈码，创建过程会用到一些变量字段，所以就算是同一个挑战码，每次创建的也是不同的。
HMAC-SHA1 模式
在这个模式下，客户端会发送一个 0 - 64 字节的挑战码，然后 Yubikey 使用 HMAC-SHA1 算法结合一个 20 字节的密钥来创建一个反馈码，创建过程不会用到其它变量字段，所以针对同一个挑战码，每次创建的都是相同的。
TOTP比较好理解，和网易将军令类似，是通过 HMAC生成的，其中 timestamp 每 30 秒变化一次，而 sharedSecret 通常通过二维码提供或者已经预编写在了硬件令牌里。
OpenGPG：OpenPGP 是一个用于签名和加密的开放标准。它通过像 PKCS#11 这样的接口，使用存储在智能卡上的私钥来启用 RSA 或 ECC 签名/加密操作。这个应用可以为验证、签名和加密各存一个 PGP 密钥。和 Challenge-Response 触摸策略类似，OpenPGP 应用也可以设置需要接触金属触点来允许一个操作。实际用处也比较客观，我们日常使用可以将SSH私钥存在Yubikey中，并只允许它作为认证方式。
FIDO2：在支持FIDO2登录的网站中设置后，便可体验，支持NFC和USB Type C/A两种方式。其优点在于全平台兼容，目前测试兼容平台有Windows11、MacOS、Linux（Debian&CentOS）、Android、鸿蒙，以及 Google Chrome、Mozilla Firefox、Microsoft Edge和 Apple Safari网络浏览器；也避免了MiMT与钓鱼，比较要接触到硬件密钥并能提供正确的Pin码不是一件容易事。通过Passwordless，减少了记忆成本与运维成本，也无需额外部署例如插件和Agent之类的客户端，单个设备可绑定多个设备，多个账户。网站的唯一密钥，服务提供商之间不共享密钥，每个网站或应用的密钥都是单独的；由于FIDO2标准由W3C联盟牵头，开发者在适配方面也轻松了许多，网站可以通过简单的 JavaScript API 调用启用 FIDO2。
云时代的新挑战
传统的 IAM
传统的IAM只是一种安全规程，它使正确的个人能够在正确的时间出于正确的原因访问正确的资源。” 换句话说，它是一类 IT 解决方案，可以使用称为身份的唯一用户配置文件安全地管理用户并将其连接到设备、应用程序、文件、网络等 IT 资源。
可以为每个唯一用户配置身份，让他们可以控制访问 WiFi 和公司服务器等内容，同时限制访问他们不需要完成工作的数字资产。在安全方面的定位也只是分为了建立信任和执行策略两方面。
建立信任——使用身份验证和其他验证方法，可以确认最终用户的身份，以确保交易和数据的安全。
执行策略——已经开发了管理时间和运行时访问控制，以执行管理适当分配和使用访问的公司策略。
零信任与IAM
随着技术的进步，必须实施安全的 IAM 解决方案以在 API 级别保护身份和敏感数据。企业必须利用由动态授权（谁、什么、哪里、何时、为什么）和零信任方法组成的工具，在用户访问多个重要应用时为他们提供持续的、上下文身份验证——传统无法无缝执行的关键功能，于是当零信任遇到IAM,就像最后一块拼图被拼全，瞬间被孕育而出。
零信任中新的焦点：
零信任中IAM 的核心主要几个方向：
为什么要把IAM拉出来讲，主要从IAM的几个理念和一名攻防人员在实战中碰到的场景高度一致，但是仍然有局限性。例如，SolarWinds漏洞始于攻击者获得公司全局管理员帐户的管理权限。然后，攻击者使用受信任的安全断言标记语言(SAML)令牌签名证书随时伪造SAML令牌，从而能够随意在SolarWinds的基础设施中移动。
Gartner预测，2022年75%的安全事故将归因于未能有效管理身份、访问和特权，高于2020年的50%——考虑到2022年发生了大量基于IAM的攻击，实际比例可能更高。即便在多云环境中，IAM和特权访问管理(PAM)的局限性依然很明显。
每个公共云提供商都依赖各自特定版本的IAM、PAM、策略管理、配置以及管理员和用户访问控制，导致云平台之间的安全差距，从而给网络攻击者留下机会。弥合多云安全漏洞和多云身份管理是多数把业务云化的企业急需解决的两个领域。即使企业已经定义并开始部署其零信任框架，基础设施中以及IAM平台内部和之间仍然存在信任差距。零信任“永不信任”的不仅仅是用户（信任），还应将身份视为威胁。
应用程序、数据、设备、传输/会话和用户信任必须在所有强化IAM基础设施的零信任框架中得到解决。
ITDR在多云环境
在向混合工作方式转变和云采用率的增加已经确立了身份作为新的边界，突出了用户活动可见性的重要性，在零信任以及XDR中恰好缺少了对于身份威胁检测和响应的一部分策略，于是就有人提出了ITDR(身份威胁检测和响应)的新技术。 ![]()
疫情的变化影响着人们的生活方式和办公方式。随着远程办公、物联网的快速普及，企业纷纷创建了大量数字身份，使得攻击面继续扩大，企业容易受到基于身份的威胁攻击。身份威胁检测和响应（ITDR）保护您的身份基础设施免受恶意攻击。
身份威胁检测和响应（ITDR）弥补了不同IAM、PAM和身份治理和管理（IGA）系统之间的身份保护“空挡”。
ITDR产品的设计思路是通过识别权限暴露、攻击者的特权提升来加强最低特权访问，在入侵发生之前识别凭证滥用。 ITDR被列为高优先级，因为多云和容器密集型基础设施是现阶段流行的攻击对象，网络攻击者利用IAM、PAM和IGA系统相互独立的弱点进一步攻击。 通过入侵IAM，网络攻击者能够获取进入企业网络的钥匙，拥有接管企业网络所需的所有凭据。此外，企业还面临跨多云平台进行身份编排的问题，这个领域的解决方案也是高能力威胁对抗关注的热点。
参考资料
https://www.onelogin.com/learn/authentication-vs-authorization
https://www.microsoft.com/en-us/security/blog/2022/08/18/connect-with-microsoft-security-experts-at-the-2022-gartner-identity-access-management-summit/
wooyun-2013-020790
https://mp.weixin.qq.com/s/N9O2rmt8PwKEupNBK--UDw
https://thezerohack.com/apple-vulnerability-bug-bounty
https://thehackernews.com/2020/05/sign-in-with-apple-hacking.html
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods
https://www.dataversity.net/the-pitfalls-of-traditional-identity-and-access-management-solutions/
https://www.accenture.com/us-en/blogs/security/identity-projects-zero-trust-roadmap
如有侵权请联系:admin#unsafe.sh