-
为什么更新本篇？
-
客户端风险和解决什么问题
-
资产不全风险
-
被攻击风险
SmartSoft这么复杂、这么多系统也经历了例如SolarWinds的这种供应链的攻击，造成了相应的内部部分核心代码遭到泄露，所以终端的攻击检测非常重要。包括操作系统漏洞、配置风险、提权、操作系统漏洞利用、被横向移动作为跳板、访问Chrome(Windows、MacOS)、Safari（MacOS）等0day和xday的利用、被钓鱼攻击利用Payload加载C&C木马。最核心的还是被利用了相关漏洞撕破边界而导致的被攻击风险。这里面的风险包括例如Microsoft Defender在Mac、Linux和Windows上做了相应的保护。第五个部分来详细展开。
-
数据资产不清风险
在SmartSoft历史的攻击来看，大部分是想窃取云和操作系统的代码，便于国家级威胁体的后续动作。但是对于被攻击的终端来看有两个盲区，第一个就是在终端上到底包含了哪些数据（代码、凭证、账号、密码、架构图、企业内部组织架构）等确实不清晰。第二个盲区就是针对接入SmartSoft Corp网络的IOS和安卓等手机操作系统并无特别的防护手段，导致后续的数据泄露和被作为跳板机作为进入网络的核心边界突破口。
-
数据安全问题频发
数据安全问题其实是分成两个部分第一个部分是Insider Threat内部威胁导致的数据泄露，例如恶意和别有用心的员工去窃取相应的数据达到自己的目的（变现、跳槽、自己创业等）。第二个部分是就是因为黑客攻击导致的个人范围内的数据泄露和作为跳板窃取企业的数据数据。目前有一个很明显的趋势，由于全球疫情的原因，很多员工都开始了居家办公模式，很多人的笔记本就会长时间连接到公司网络通过VPN，或者通过账号登录了企业相关的应用系统，就会造成相应的攻击面。
-
网络风险
-
应用安全风险
-
身份风险
其实大家对于传统的攻防风险和数据泄露风险都有很多了解，其实相信身份攻击的风险会更加有趣一些。这块也重点提一下，针对身份的攻击，笔者在之前的文章中也总结过一些。以身份构建的核心基础设施安全提升水位，已经明显在美国拜登的总统令中开始推进，而且速度非常迅速，要在3-4年完成安全水位的提升，留给我们的时间不多了。
身份的风险在于获取到一个合法的身份之后可以利用这个身份做太多的事情，身份攻击依然成为了一个新的撕开企业边界的新攻击面。身份的攻击包括Password Sparying攻击、Account Takeover攻击、钓鱼攻击。其实这些还是传统的攻击手法，由于SmartSoft的核心地位，针对它的身份攻击已经提升到了绕过MFA（软硬令牌、SMS认证、YubiKey等FIDO2认证、WebAuthn）、绕过设备认证、绕过TPM等现实中出现的攻击手法了（后面会介绍1-2个绕过的漏洞），虽然通过TPM、设备认证、MFA通过身份衍生和覆盖到终端上这一点来看，保护云平台的安全的核心点，已经逼到了终端安全上，通过终端安全->网络->云端->应用->数据的真正端到端的攻防体系。
-
云端安全风险
-
云端云化办公风险（RBI、VDI）
通过统一身份认证以及鉴权之后，其实还有另外一个云端的真正的“数据不落盘”解决方案。就是通过RBI和VDI的方式来在远端访问数据，这样可以让数据保存在RBI和VDI上。从这半年的针对RBI和VDI的攻击分析来看，有几个重要的攻击面，先简单写一下。
RBI攻击面，先从RBI的架构来看首先是使用统一身份认证SSO系统进行身份认证，认证过后使用Chrome浏览器工具进行执行，执行载体在Docker容器上，容器在弹性ECS上，弹性ECS在物理机只上，其实核心的架构就是这样的。只不过在实现上有很多人做的很到位而已。例如AWS可能采用Firecracker多租户模式来做、Azure可能会Hypervisor容器来做、Google可能选择gVisor来做、也许还会有其他厂商选择Kata Container来做。技术选型很多，RBI的核心是安全容器的隔离。这个里面RBI有几个重要的攻击面，身份的攻击前面已经讲到了，第二个攻击面就是浏览器本身存在相关的漏洞，包括Chrome的文件逃逸、Chrome漏洞、执行相关的命令、SSRF Meta（Docker特性漏洞，AWS、Azure、自建容器在AWS、Azure、Google等云上无一幸免）到STS Token等漏洞就会控制相应的容器，如果容器隔离没有做好，就会导致直接进行网络渗透、Docker逃逸、Docker利用ECS提权等漏洞进而控制整个RBI系统。
针对VDI的攻击其实早在好几年前就开始研究了，那个系统就叫Citrix，Citrix是最早一批做VDI的厂商。笔者针对VDI的攻击简单总结几句，之前Citrix VDI系统大部分是没有MFA的（不像今天MFA大范围支持DUO等MFA），也就是说可以通过账号登录Citrix，而Citrix VDI本身有太多的设计缺陷了，包括AD域控的渗透、内网的横向移动（网络隔离太不到位）、Citrix VDI自身也出现了非常多的漏洞（比较著名的就是CVE-2019-19781通杀漏洞，影响面巨大）。核心逻辑还是通过VDI这个边界口子进行横向的渗透，获取到最核心的域控权限，然后再往云上进行横向移动，最终进而控制整个混合云。
-
云端数据泄露风险
-
客户端安全设计和实现
-
资产管理：应对资产不全风险，通过设备管理MDM、设备注册等方式来解决数据资产不全的风险问题；
-
Defender防御：通过Defender的漏洞管理模块（评估安全状态分、缓解零日漏洞、漏洞补丁）、网络安全防御（Windows防火墙联动、防火墙日志查看）、攻击面削减（下载的可执行程序、运行混淆的脚本、）、Hunting能力（通过上传日志到服务端进行Hunting和Investigation）、受控文件夹保护（预防勒索和其他手法窃取有价值的数据）、AV防病毒、行为阻止（白名单体系）、终端安全基线等水位；
-
EDR检测：信息采集做检测覆盖ATT&CK、告警运营、事件Hunting、应急响应、海量分析师分析事件产出报告另外还可以使用SmartSoft的专家模式来做更深入的服务；
-
MDM设备管理：可信设备注册（Unmanaged和Managed）、远程设备管理（包含删除丢失设备）、合规性检测（满足端的零信任）、VPN管理、终端保护、条件访问、管理应用和应用保护。
-
通过EDR、Defender、MDM来解决攻防风险；
-
数据安全对抗体系：解决数据资产不可知和数据外泄安全风险（1月1日的文章再次粘贴到这里一方面是数据全链路跟踪和管控，一个是终端的外发渠道管理）：
-
数据全链路跟踪和管控：
SmartSoft企业面临的数据流转的问题，数据是没有边界的，数据会在任何地方进行流传，这些流转包括终端（BYOD设备、托管设备、手持设备、笔记本、PAD等）、云端（微软自身的产品Office365）、SaaS产品（SalesForces、Box）、混合云（Google、AWS、Azure）、On-Permise（线下Office）等，在这么复杂的链路上如何做好数据安全保护是一个非常难得问题，微软由于其自身的Office优势、云的优势、Office 365、SharePoint、OneNotes、Teams等的全套链路，导致它提出了一套创新的解决方案。
笔者经过大量的文档阅读，总结和抽象了对应的观点（Label And Classification Policy Built In The Files And Protection、Monitoring、Tracing By Everywhere）：
微软信息保护的目标就是所有的微软数据都会被分类、分级并且被保护的。在这个目标下微软是如何实现的。首先架构大图有了之后，肯定有一张产品大图来贯穿这个目标的，下面这个图就是贯穿目标的大图：第一步是知道数据在哪里，理解数据的态势；第二步就是保护数据应用加密、访问限制来进行控制；第三步就是保护数据防止丢失，检测数据行为和保护敏感数据；第四步就是进行数据的治理。
在这个顶层治理框架下它是如何实现目标的：Azure针对上面的目标拆成了三个部分，包括Office 365 IP保护、Windows IP保护、Azure IP保护三个部分，分别对应Office 365应用、Windows设备、第三方设备和On-Permises部分。
然后是具体的产品实现落地方式：首先微软每月有1500万的文件/邮件保护的数量，通过上面不同的IP保护产品来做。首先通过分类分级客户端打标，策略下发和自动化的分类分级策略来定义文件的策略，文件流传到云端、Office 365、SharePoint线下和SharePoint Online、Teams等的时候都可以针对这个文件的标记进行处理，而且也可以针对文件的内容进行特定的加密策略。另外笔者认为一点还不错的就是跟RMS（Rights Managements）权限管理系统和Azure AD零信任身份体系进行打通，通过文件分享到其他云的时候，可以通过本地终端等设备打开的时候进行身份认证、身份认证完之后进行权限认证、权限认证之后进行文件解密操作，最终被有权限的经过身份认证的人打开，而且文件还受到屏幕水印、打印控制等的限制，最终完成基于文件标签的信息保护体系，最终实现SmartSoft的数据安全目标。
有了大图就看一下产品落地细节：
定位：DLP 可以监视和保护处于非活动状态的文件、使用的文件以及跨 Microsoft 365 服务、Windows 10、Windows 11 和 macOS (Catalina 10.15 及更高版本的) 设备、本地文件共享和本地 SharePoint 的文件；
范围：Exchange Online电子邮件、SharePoint Online 站点、OneDrive帐户、Teams 聊天和通道消息、Microsoft Cloud App Security、Windows 10、Windows 11 和 macOS 设备、本地存储库、元数据；
渠道：检测渠道、上传到云端服务，或通过不允许的浏览器访问、复制至其他应用、复制到 USB 可移动媒体、拷贝到网络共享、复制到远程会话；
覆盖文件类型：PowerPoint 文件、Excel 文件、PDF 文件等
操作行为动作：视觉标记：页眉、页脚和水印、元数据：以纯文本添加到文件和电子邮件头。为电子邮件添加了敏感度的页脚，用于所有收件人，用来指示它适用于不应在组织外部发送的常规业务数据。电子邮件头中的嵌入元数据，邮件头数据使电子邮件服务可以检查标签，或防止在组织外部发送。
部署方式Agent：经典客户端、统一标签客户端、Office内置标签
功能：手动标记、默认标签、推荐或自动标记、强制标记、用户为标签定义的权限、对标签的多语言支持、应用信息、保护Office栏、视觉标记作为标签操作（页眉、页脚、水印）、Powershell标记、跟踪受保护的文档、吊销受保护的文档；
零信任+RMS：Login.Microsoftonline.com认证登录获取身份，通过RMS来进行授权；云端（SaaS+Cloud App Security: Microsoft Defender for Cloud Apps ）：集成SaaS API（Box、Salesforce等）进行DLP策略的延展；同时集成Defender For Endpoint做联动；
SDK：MIP SDK、RMS Client等提供给生态集成；Azure Information Protection unified labeling scanner扫描微软内部文件；
扫描方法：Microsoft 365深入内容分析（而不只是简单的文本扫描）检测敏感项目。内容按以下方法进行分析：关键字的主数据匹配、正则表达式评估、内部函数验证和与主要数据匹配接近的辅助数据匹配。此外，DLP 还使用机器学习算法和其他方法来检测与 DLP 策略匹配的内容。
最终再看一下MIP的SDK实现如何分配给生态合作伙伴的，微软MIP提供了对应的SDK，通过SDK可以让生态厂商例如Veritas、Digital Guardian、ForcePoint、Varonis等来利用MIP SDK来对文件API：文件打Label、更新Label等级、MSG标记；保护API：加密文档、解密文档；策略API：读取、写入和删除标签和保护信息的一些安全策略；
微软最终的安全体系是实现Gartner所定义的Cybersecurity Mesh产品联动。微软自己定义为Localized Intelligence。这个可以看到微软做产品的一个愿景和最终的大图，用来联动On Permises、Cloud、Mobile、DLP、分类分级、AD、UEBA、威胁情报、Malware保护和对应的DLP分类分级等。
-
数据终端外发：
核心的数据流转还是在企业内部、云端、SaaS进行的管控和流转，另外还是需要更多的渠道管控能力的。例如SmartSoft采取的六类渠道：邮件管控、WEB HTTP/HTTPS、打印、云端软件、可删除设备以及局域网LAN的覆盖。当然这里面覆盖的点可能达到几百个，后续有机会再深入这个链路。
-
网络安全设计和实现
-
应用安全设计和实现
-
统一开发框架、统一身份登录、提升漏洞治理安全水位
-
前后端分离架构增强API安全
-
前端框架：前端采用JS框架Angular、Vue.js、Ember.js、Durandal.jsReact框架以及Next.js、Gatsby.js框架来布局页面和对应的后台请求； -
手机框架：IOS、安卓前台； -
操作系统：应用程序Windows、Linux、Mac等； -
Node框架：Electron、Express Node应用 后端：JAVA、Python、.NET C#等基本上全部采用的是API架构，API架构采用上面说的应用身份和用户身份来构建两层的访问逻辑。核心其实就是通过受限用户以受限的应用身份获取对应的数据，详细细节参考下文。
-
身份安全治理
通过接入的SSO使用身份来做统一的接入，使用RBAC来做权限的限制，具体的实现在身份安全方案中赘述。
-
API安全治理
SmartSoft针对所有的API进行了身份限制、鉴权和IDOR的漏洞治理，同时还通过iFX注入框架，注入后端API中采集对应的调用信息，最终把这些调用链路信息透传到Cloud SIEM Kusto中，进行分析，发现API相关的异常、信息泄露等问题。
-
数据安全治理
SmartSoft创新性的提出了Data Security Runtime Protection（DSRP）的框架，通过.NET C#注入技术，注入到了前端、中间件、应用程序中，核心目标有两个一个是做到数据链路追踪，一个是为了做GDPR、PCI-DSS、HIPAA等隐私和合规的要求，做到通过DSRP框架解决方案来落地数据不可见的目标。并且通过SDLC安全开发生命周期推进DSRP的推进和落地，并且在过程中沉淀了对应的解决数据安全问题的方案和能力，最终落地框架来解决更多的GDPR、PCI-DSS、HIPAA关注的隐私控制落地的能力。
-
身份安全设计和实现
-
云端安全设计和实现
-
云端数据泄露风险
-
身份安全设计和实现和攻防对抗（本文重点和核心关键内容）
身份是新边界，身份驱动业务变革，身份也是业务构成的关键（本文的点睛之笔来源Nuke金将军），因为身份而导致的业务变革数不胜数。后续会讲1个SmartSoft遭遇的国家级威胁体黑客攻击的窃取代码的例子，贯穿透彻全文，其实思来想去这个例子只是解决了数据安全的问题，并没有很好的体现业务，在文章最后简单一笔带过一个生态交付的CASE，来呼应这句话点睛之笔。
首先前面分崩离析的讲解了网络安全、云端安全、终端安全、RBI&VDI等内容，但是还是分散的，本小节重点讲解一下如何通过身份和一个最近SmartSoft遭遇国家级威胁体攻击来窃取代码案例来进行整体的打穿链路。
1、在正式讲解CASE之前，还是简单同步一下身份的认证逻辑：
-
OAuth2隐式授权
A、通过浏览器访问https://login.smartsoftxxxx.com/common/oauth2/v2.0/authorize终结点；
B、浏览器的用户输入账号密码进行登录，并且授予对应的访问权限发送到认证终结点；
C、认证终结点通过之后返回对应的Token；
D、浏览器使用在HTTP Header中的Authorization头调用Web API；
E、WEB API确认Token的有效性、失效时间、权限等，确认通过之后返回数据；
F、通过短的失效时间之后Token过期；
G、浏览器重新发起登录请求，在用户浏览器的Session有效期内刷新另外，这个时候攻击就出现了，也就是说在终端上是可以拥有这个浏览器的Session的，也就是Cookie重放攻击^_^；
H、认证终结点返回新令牌给到浏览器；
I、浏览器再通过新的令牌访问后台Web API；
-
OAuth2应用授权
OAuth2应用授权这里目前还是SmartSoft最大的攻击利用点，通过Client ID和Client Secret可以用来以应用身份获取令牌，通常这个令牌的权限较大，对SmartSoft来说存在巨大的攻击面风险。
-
OAuth2 SAML2认证
SAML2其实是被国家级威胁体用来攻击的非常爽的工具手法，完美绕过MFA。当然SmartSoft也知道和发现这种攻击手法，针对ADFS的Golden SAML2攻击手法也增加了对抗。但是目前还是存在一个较大的攻击面，就是SmartSoft SSO单点登录支持除了ADFS SAML2认证之外，还包括Github、Salesforce等SaaS的认证方式，如果能够拿到对应的SAML2认证私钥进行SAML2 Response的推送认证攻击，就会导致可以登录SmartSoft任意的Github、SalesForce、Dropbox等应用。这个风险SmartSoft后续也需要进行持续的增强和提升。
-
MFA认证
目前SmartSoft支持包括SMS短信认证、Device设备认证、SmartCard硬件USB认证、Software Token软令牌认证、Windows Hello认证、跟操作系统绑定的TPM认证方式。下面简单说几句话说一下MFA的绕过手法。绕过SMS短信认证包括劫持短信网关、修改账号手机进行认证绕过；Device设备认证绕过通过认证协议缺陷来注册和骗过设备认证进而发放PRT主令牌；SmartCard目前没找到很好的绕过手段、Software Token软令牌攻击方式还是主要是通过推送消息让用户进行授予登录权限的暴力手段；通过TPM来进行保护零信任身份，最终历史上也存在终端被突破进而被绕过的漏洞。
-
中高级难度的PRT+TPM认证流程解析和已知漏洞分析
PRT+TPM认证关键点：
PRT是操作系统Windows 10或更高版本、Windows Server 2016 及更高版本、iOS 和 Android 设备上 Azure AD 身份验证的认证凭证。通过PRT可以认证响应操作系统的身份，签发JWT Token进而登录SmartSoft SSO单点登录平台；
A、发送挑战请求，通过Post 终结点发送grant_type=srv_challenge请求：
B、返回Nonce响应；
C、发送对应的登录请求来获取JWT Token
D、输入账号密码；
E、最终反馈PRT主令牌：
F、TPM跟存储两个核心变量用来生成PRT：
G、通过Mimikatz获取到了Context和Derived Key
H、最终利用Context和Derived Key签出PRT主令牌：
核心签出的核心代码如下：通过derived_key、context、nonce来签出JWT PRT Token，进而用于后面的认证逻辑；
def authenticate_with_prt(self, prt, context, derived_key=None, sessionkey=None):"""Authenticate with a PRT and given context/derived key"""# If raw key specified, use thatif not derived_key and sessionkey:context, derived_key = self.calculate_derived_key(sessionkey, context)secret = derived_key.replace(' ','')sdata = binascii.unhexlify(secret)headers = {'ctx': base64.b64encode(binascii.unhexlify(context)).decode('utf-8') #.rstrip('=')}if not '_' in prt:prt = base64.b64decode(prt+('='*(len(prt)%4))).decode('utf-8')nonce = self.get_prt_cookie_nonce()if not nonce:return Falsepayload = {"refresh_token": prt,"is_primary": "true","request_nonce": nonce}cookie = jwt.encode(payload, sdata, algorithm='HS256', headers=headers).decode('utf-8')return self.authenticate_with_prt_cookie(cookie)def calculate_derived_key(self, sessionkey, context=None):"""Calculate the derived key given a session key and optional context using KBKDFHMAC"""label = b"AzureAD-SecureConversation"if not context:context = os.urandom(24)else:context = binascii.unhexlify(context)backend = default_backend()kdf = KBKDFHMAC(algorithm=hashes.SHA256(),mode=Mode.CounterMode,length=32,rlen=4,llen=4,location=CounterLocation.BeforeFixed,label=label,context=context,fixed=None,backend=backend)if len(sessionkey) == 44:keybytes = base64.b64decode(sessionkey)else:keybytes = binascii.unhexlify(sessionkey)derived_key = kdf.derive(keybytes)# This is not ideal but further code expects it as hex stringreturn binascii.hexlify(context).decode('utf-8'), binascii.hexlify(derived_key).decode('utf-8')
-
条件访问
条件访问核心是通过设备安全、实时风险、应用程序状态，来决策能否访问后端应用和数据、是否需要开启MFA和禁止访问后端应用和数据。
SmartSoft通过设备安全状态包括漏洞、托管状态、基线水位、安装风险软件、告警是否处理完成等200+条件来进行判断；
-
权限控制
A、通过Azure RBAC来控制对云的细粒度访问，包括条件、访问行为和规则；
例如：
((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}))OR([Microsoft.Storage/storageAccounts/blobServices/containers:name]StringEquals 'blobs-example-container'))
最终的结果就是：以下条件包含“读取 Blob”操作。 该表达式检查容器名称是否为 blobs-example-container。
B、通过Azure AD RBAC来控制对SmartSoft服务的访问：
例如SharePoint Online相关的读取和写入权限、Exchange Online的读取邮件的权限、Azure AD的用户读取和写入、目录读取和写入等200+个细颗粒度的权限控制。
2、国家级威胁体代码窃取模拟案例
首先国家级威胁体进行目标推演：核心是拿到SmartSoft的云（包括SSO登录代码、Intune终端管理代码、SmartSoft安全代码）和操作系统的代码。
-
踩点：
利用自研的ASM（攻击面管理）工具进行边界探测，发现重要的核心云业务的托管SaaS AD存在用户猜测漏洞，通过踩点发现了大量SmartSoft的用户；
-
获取账号凭证
通过网络流量大数据、NSA类似量子注入技术等手段获取到了账号密码，在登录过程中遇到了MFA的强力阻断，因为单点技术的对抗而提升水位的案例极其稀少，国家级威胁体进行了MFA的强力研究，目前假设是国家级威胁体利用NSA类似的量子注入技术获取到了SmartSoft的一个账号权限比较高的办公PC。因为账号权限相对比较高，这个中等管理员的PC（WIN11）上通过TPM来进行保护账号，国家级威胁体通过CloudAP+Roadrecon最终在本地PC上获取到了PRT主令牌，最终绕过MFA进行了登录；
-
权限控制
通过PRT主令牌登录之后，访问了Azure DevOps SaaS服务VisualStudio服务，访问了其中SmartSoft的相关代码，但是由于代码权限的设计，国家级威胁体只拿到了少量的部分代码，任务以失败而告终。但从泄露的少量代码中，能否发现新的攻击面我们拭目以待。
3、“端到端零信任”驱动业务变革
既然提到了”零信任“是会导致业务变革的核心点，那就简单描述一下其中的一个业务是如何通过身份来管理的：
A、SmartSoft为了给客户提供操作系统安装、软件安装、云产品售卖服务，为渠道商、三方合作伙伴、云生态公司搭建了统一身份认证平台，所有的人都通过统一的认证之后访问不同的业务系统，完成SmartSoft收入的90%都是这些人贡献的目标；
B、渠道商、三方合作伙伴、云生态公司利用已有的权限来访问SmartSoft的客户列表，通过受限制权限的有限访问，来挖掘更多的潜在客户和本土客户；
C、挖掘到客户之后，这些人通过SmartSoft在统一身份的应用中学习Workshop、交付文档、SOP指南等，让这些人可以利用自己的渠道去让客户成单；
D、客户下单之后，通过财务系统上报SmartSoft，SmartSoft通过这个平台来让售后工程师在所在的城市中进行上门安装、调试、售后服务等；
E、客户安装完成之后也可以通过反馈到这个系统中，其实就是通过统一身份认证的多个系统中完成业务交付和流转动作，保持业务的持续、高效、快速的数字化运营方式产生商业价值。安全是最核心的底座，这也是SmartSoft CEO的一致对外理念灌输。
本文完！！！
原文始发于微信公众号（鸟哥谈云安全）：混合办公（Hybrid Work）安全的“三年”技术落地趋势推演
