ITDR 未来可期的安全趋势

2023/05/17

从SSO说起

SSO在很多企业中落地已经不久了，很多SSO登录方案使用了OAuth作为认证标准，在此之上，为了减少弱口令与内部泄密造成的影响，还会加入MFA作为增强安全措施。这样就能够保证万无一失了吗？

传统框架的缺陷

“都什么年代了还在用传统认证方式“

在技术不断迭代的当下，还有不少企业选择了传统认证方式。使用者通过B/S或者C/S的框架向后端服务器认证身份，服务器通过一系列流程，验证成功后通过例如JWT/Cookie的机制，在客户端保存用户的登陆凭证。

除了本身机制带来的传统安全问题，比如URL中带密码、撞库、弱口令，还会增加比较大的运维成本。假设企业内部有多套业务系统，其使用人员包括但不限于公司员工，外包人员，供应商，监管机构等。使用的人数与类型越多，其存在的风险点也会与日俱增。而且员工被迫要为多套系统记录多个账号密码，尽管安全意识培训不断，但惰怠和健忘的难免的，就算是专业的安全从业者也不一定能完全做到。使用密码管理器也有风险，今年九月份，知名密码管理器LastPass承认其被黑客攻击。尽管公司在发现攻击行为后已经拼命进行阻止，但是结果令人感到惋惜，黑客依旧突破了封锁，可窃取该公司的源代码和专有技术信息。LastPass随后发布了一份安全公告，确认黑客是通过访问公司开发人员的账户进行入侵，并取得了可观的信息。

OAuth认证流程

单点登录（Single Sign On）技术的出现在一定程度遏抑了上叙风险，并提供了更好的可用性与用户体验。SSO的实现方式也分多种，有基于Cookie的单点登录，登录子应用时，会带上父应用的Cookie，解密之后校验用户的身份，基于JWT的SSO也不失为一种优秀的解决方案，不过得到广泛应用的认证标准还得是OAuth2。

我们在登录很多站点，比如语雀的时候，经常能看到如图所示的登录框，提供了多种登录方式。这就是OAuth的一个经典场景，当用户点击任何一个平台作为登入方式后，便进入了OAuth的认证流程。

RFC6749中描述了OAuth的授权模型，首先介绍两个比较容易混淆的概念。认证与授权是安全人员用于保护系统的两个重要安全过程，认证负责验证用户或服务的身份，授权决定了他们的访问权限。

Authenticate(v):认证。其重点倾向于“证明”用户具有对应的权限，其行动主体是服务器，验证主体为用户方。

Authorize(v):授权。其重点倾向于”赋予“，用于授予用户或者服务具体的访问级别。

简而言之，一个在授予用户访问权限之前验证用户或者服务的身份，而另一个确认他们在获得访问权限后可以做什么。以语雀使用支付宝为例，当用户点击使用支付宝登录之后，进入以下流程。

这种是最为常见的授权码认证方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

如果用户的应用是纯前端类型，如手机/桌面客户端程序、浏览器插件等，缺少了后端服务器通过授权码来获取Access Token这一步，便称为（授权码）”隐藏式”（Implicit）。

由于是前端直接管理与获取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。

攻击者便可从自己的页面中提取 PayPal 返回的支付请求中的认证令牌信息。

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也成为了很多企业业务的标配。目前主流的解决方案有USBKey、FIDO、OTP、指纹、声纹等等，这些MFA要素都可以抽象成三种属性，你所知道的，你拥有的和你是什么。随着机器学习和AI的普及，MFA也变得更加贴心和智能，比如如果你在非常用地点登录某业务，便会触发MFA，而平时只要输入账号密码即可。

提一下日常生活中使用的最多的MFA，短信验证码。不知道各位有没有发现，短信验证码的有效时间一直在缩短，而且越敏感的业务，短信验证码的有效时间越短。参考最近的一起安全事件，某企业疑似泄露4000W短信数据，该公司拥有银行、政府机关、App、第三方支付、电子商务、移动互联网、快速消费品、物流快递等不同类别的客户。是阿里巴巴、支付宝、京东、腾讯、汽车之家、拼多多、百度、中国工商银行、广发银行、小米、华为、广汽集团、沃尔玛、歌华有线、盛大游戏、安心保险等众多知名企业的短信平台服务商。就是短信中有染色数据可以事后追溯，但依然难以遏抑即时的短信验证码泄露问题。不光如此，之前还报道过短信降维打击的攻击手法。攻击者使用“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。

Reference

Timedout

Gravity is our eternity.

共有 0 条评论

發佈留言取消回覆

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料。