勒索软件即服务Ransomware-as-a-Service  (RaaS)是当前全球勒索软件攻击势头急剧上升的背景下出现一种服务模式。同其他Saas解决方案类似,RaaS模式已经成为一种成熟软件商业模式。RaaS的出现大大降低了勒索攻击的技术门槛,勒索软件开发者可以按月或一次性收费提供给潜在用户(犯罪组织)。这些犯罪组织,只需要购买勒索软件来执行勒索攻击,获利后按比例支付赎金给勒索软件供应商。然而随着犯罪方式的演变,传统的勒索方式需要犯罪者“亲力亲为”,即勒索团伙需要自己发送钓鱼邮件或者自己寻找目标系统漏洞来植入勒索软件,这样大大消耗了时间和精力,RaaS组织需要更加直接的“大门”或者中间人去做入侵,于是 Initial Access Brokers(IAB)业务就变得活跃起来。

image001.png

图1- 勒索软件即服务(RssS)产业模式图

IAB产业现状

IAB(Initial Access Brokers-初始访问代理业务)是指攻击者通过多种方式获得的受害者网络资产初始化访问权限,而后将其出售给犯罪组织实施犯罪的中间人行为,犯罪组织通常为勒索软件团伙或其附属机构。“初始访问权限”不仅泛指RDP、VPN、Webshell、SSH权限这些可以直接进入目标网络的权限,还有一些未授权访问的资产、数据库资产、系统用户的账户权限等,也包括可利用的企业系统、网络设备,如Citrix、Fortinet、ESXI 和 Pulse Secure的历史漏洞和权限。攻击者可以将这些系统的权限放到黑客论坛售卖,有时候还可以多次售卖给不同勒索软件组织,这些攻击者可以和勒索软件供应商形成供需关系,两者通过匿名的IM通信,最后通过数字货币支付达成交易。通过黑客论坛,勒索软件运营商组织可购买IAB后直接植入勒索软件达成勒索目标,可以节省勒索组织在受害者网络环境中入侵的时间和精力以及各种成本,这样勒索软件攻击者可以将所有时间和精力集中在“改善”勒索软件有效载荷和与他们的附属机构协调操作上,同时可以在暗网论坛上指定需要的权限类型与目标行业,IAB的出现为RaaS提供了极大的便利。

image002.png

图2- RaidfForums上卖家出售数据库信息的帖子

image003.png

图3- RaidForums上买家购买手机数据库数据的帖子

在利益的驱动下,RaaS与IAB的交易越来越密切,值得关注的是:根据Digital Shadows统计,IAB交易的热点行业权限top5 为零售行业、金融行业、科技行业与工业制造业(如医药制造),科技行业的初始访问代理权限平均价格最高为13,607 美元。

image004.png

图4- DigitalsShadows统计2020年IAB的热点行业及价格

IAB初始访问权限获取方法

那么黑客通常是怎样获取有效的IAB的呢?我们结合威胁情报网站ke-la.com分析过IAB的几个趋势以及威胁情报网站curatedintel.org提供的资料,研究分析后归纳出如下图所示的IAB初始权限获取路径图。
image005.png

图5- IAB初始权限获取路径图

通过上图我们可以看到,IAB产业初始权限获取方法主要分为以下几个路径:

1.以目标漏洞为途径:攻击者通过黑客搜索引擎来获取受害者对外暴露的资产,之后进行ip探测,域名探测,端口开放探测(如RDP端口)以及漏洞扫描,类似于红蓝对抗中攻击队前期对目标的资产梳理和信息搜集,期间会用到各类黑客搜索引擎如Shodan、Censys,在确定目标资产后进行漏洞扫描,漏洞扫描过程主要探测是否存在一些知名软件的历史CVE漏洞,相关软件产品如VPN产品SecureVPN、云桌面常用的Citrix软件、虚拟化产品Vmware、微软系列的Exchange、负载均衡设备F5以及路由器设备Cisco等。黑客一旦探测到相应产品存在的漏洞,就发起攻击,攻击成功后可获取目标权限,之后可以进行内网横向,植入后门等操作,最终获取有效的初始访问权限。具体使用到的漏洞如下图所示。

image006.png

图6- IAB产业常用CVE漏洞

2.以社会工程学为途径:在信息窃取活动中主要以获得目标门户网站登录相关的MFA验证码(多因子校验的秘钥或验证码)为主,攻击方式不限于语音电话钓鱼、短信钓鱼、近源攻击、伪造商业合作钓鱼等一系列社会工程学攻击,这些攻击手段层出不穷,较为值得关注是电话钓鱼,国外专注于人员安全意识培训和钓鱼模拟攻击服务的公司Terranova有总结到相关社工策略:“第一种常见的策略是一些网络犯罪分子使用强硬的语言,表示他们正在帮助受害者避免刑事指控;第二种常见的策略是犯罪分子留下威胁性的语音邮件,告诉收件人立即回电,否则受害者可能会被逮捕,银行账户被关闭,或者会发生更糟糕的事情。在网络犯罪分子使用威胁和令人信服的语言下让受害者觉得别无选择,受害者只能提供犯罪分子想要的信息。”

image007.png

图7- Terranova对Vishing的解读

3.以售卖信息的地下市场为途径:使用在地下市场上出售的用户信息获得访问权限,黑客通过著名论坛OGuser购买到关于受害者目标用户身份的访问权限后尝试登录受害者的相关网站。

image008.png

图8- OGuser上的账户交易服务

4.以第三方数据泄露为途径:使用来自第三方数据泄露的凭证获取访问权限,拿到相关泄露数据后,与上述第三种方式不同,第三方泄露数据需要“二次加工”,可以通过密码喷洒,撞库攻击,暴力破解等方式尝试登录受害者系统来获取目标系统访问权限。

image009.png

图9- DeHashed论坛数据泄露交易

5.使用网络钓鱼活动获取访问权限:以邮件钓鱼为主,通过恶意邮件投递一些恶意软件,如RedLine Stealer (RedLine Stealer是一种恶意软件,该恶意软件从浏览器收集信息,例如保存的凭据:自动填充的数据和信用卡信息等),Vidar( Vidar是一种基于Arkei 的分叉恶意软件),Taurus(Taurus是一种基于C/C++实现的信息窃取恶意软件),LokiBot(也称为 Lokibot、Loki PWS和Loki-bot,使用特洛伊木马恶意软件来窃取敏感信息,例如用户名、密码、加密货币钱包和其他凭据)等,这些钓鱼方式大部分都是以恶意文档为载荷,当受害者打开文档后利用宏去执行或下载被加密后的Shellcode,之后建立C2信道进行长期控制窃取信息,相关细节如下图。Malpedia对这些软件都有解释和记录,有兴趣同学可在Malpedia上查询。黑客在受害者不小心中招了相关恶意软件后可直接获得目标的初始访问代理权限。

image010.png

图10- 国外对MaliciousSpam 钓鱼技术解读

image011.png

图11- Trickbot的邮件木马执行过程

(图片来源:Hornetsecurity)

6.以内部威胁为途径:内部员工直接就有内部IT系统访问权限,心怀不轨的员工可以拿公司的权限或数据到论坛进行贩卖或用于其他意图。

“IAB”下企业如何做好防范措施

1. 外部资产安全:攻击者先通过信息搜集,通过漏扫工具进行漏洞扫描或者通过第三方泄露数据进行撞库攻击,根据这些攻击方式,企业外部安全要做到:(1) 及时发现和修护系统漏洞,做好系统加固与升级,做好边缘资产的收束,非必要服务与端口不对外开放。通过“监控”第三方网站如Github,及时查看哪些员工数据遭到了泄露,避免有“强弱口令”和无风控机制下的系统出现问题;(2) 系统与设备上线前要做好安全审计与安全测试,规避带着“问题”上线而遭受黑客攻击。

2. 内部安全建设:从攻击者社工相关攻击路径来看,攻击者通过携带恶意后门,广撒网方式来进行邮件钓鱼,以及遭受“内鬼”的威胁,因此内部安全建设要做到:(1)离职人员的账户权限要及时清除,员工访问内网系统的权限要进行严格隔离,不同层级的网络也要做好隔离;(2)对员工做安全意识培训,防止员工中招邮件钓鱼以及其他社会工程学的攻击;(3)日志系统的建设与健全:入侵后可以通过日志及时查漏补缺;(4)安全设备的安装尽量覆盖所有终端,这样可以抵挡大部分病毒与木马的威胁,可以有效防止黑客横向移动与权限提升等后渗透行为,及时更新病毒库可以有效防止黑客利用NDay攻击。

3.威胁情报建设:攻击者通过在各大论坛出售与企业相关的数据与权限,因此企业需要做到:(1)及时从外部论坛,威胁情报网站等获取企业威胁信息,做好风险控制,及时关注最新安全态势;(2)密切关注IAB和三方数据泄露的动态,防止数据与权限被出售后对企业形成“二次”伤害。

4.数据备份与容灾:如果上述所有防线均被突破,那么平时做好数据备份与容灾工作,建立完善的灾备机制,拥有良好的数据权限隔离方案,可以有效防止业务系统数据被加密后无法解密的尴尬局面出现。

参考链接:

国外:

https://www.curatedintel.org/2021/10/initial-access-broker-landscape.html?m=1

https://ke-la.com/all-access-pass-five-trends-with-initial-access-brokers/

https://www.blueliv.com/cyber-security-and-cyber-threat-intelligence-blog-blueliv/research/use-of-initial-access-brokers-by-ransomware-groups/ 

https://github.com/curated-intel/Initial-Access-Broker-Landscapehttps://terranovasecurity.com/what-is-vishing/

恶意软件相关:

https://us-cert.cisa.gov/ncas/alerts/aa20-266a https://securityboulevard.com/2021/05/an-in-depth-analysis-of-the-new-taurus-stealer/

钓鱼邮件活动:

https://isc.sans.edu/forums/diary/Dridex+malspam+seen+on+Monday+20170410/22280/

https://www.hornetsecurity.com/en/security-information/trickbot-malspam-leveraging-black-lives-matter-as-lure/

https://securelist.com/malicious-spam-campaigns-delivering-banking-trojans/102917/

国内:

http://www.mchz.com.cn/cn/about-us/Industry-News/info_366_itemid_5065.html

https://new.qq.com/omn/20210901/20210901A0524K00.html

勒索软件即服务Ransomware-as-a-Service  (RaaS)是当前全球勒索软件攻击势头急剧上升的背景下出现一种服务模式。同其他Saas解决方案类似,RaaS模式已经成为一种成熟软件商业模式。RaaS的出现大大降低了勒索攻击的技术门槛,勒索软件开发者可以按月或一次性收费提供给潜在用户(犯罪组织)。这些犯罪组织,只需要购买勒索软件来执行勒索攻击,获利后按比例支付赎金给勒索软件供应商。然而随着犯罪方式的演变,传统的勒索方式需要犯罪者“亲力亲为”,即勒索团伙需要自己发送钓鱼邮件或者自己寻找目标系统漏洞来植入勒索软件,这样大大消耗了时间和精力,RaaS组织需要更加直接的“大门”或者中间人去做入侵,于是 Initial Access Brokers(IAB)业务就变得活跃起来。

image001.png

图1- 勒索软件即服务(RssS)产业模式图

IAB产业现状

IAB(Initial Access Brokers-初始访问代理业务)是指攻击者通过多种方式获得的受害者网络资产初始化访问权限,而后将其出售给犯罪组织实施犯罪的中间人行为,犯罪组织通常为勒索软件团伙或其附属机构。“初始访问权限”不仅泛指RDP、VPN、Webshell、SSH权限这些可以直接进入目标网络的权限,还有一些未授权访问的资产、数据库资产、系统用户的账户权限等,也包括可利用的企业系统、网络设备,如Citrix、Fortinet、ESXI 和 Pulse Secure的历史漏洞和权限。攻击者可以将这些系统的权限放到黑客论坛售卖,有时候还可以多次售卖给不同勒索软件组织,这些攻击者可以和勒索软件供应商形成供需关系,两者通过匿名的IM通信,最后通过数字货币支付达成交易。通过黑客论坛,勒索软件运营商组织可购买IAB后直接植入勒索软件达成勒索目标,可以节省勒索组织在受害者网络环境中入侵的时间和精力以及各种成本,这样勒索软件攻击者可以将所有时间和精力集中在“改善”勒索软件有效载荷和与他们的附属机构协调操作上,同时可以在暗网论坛上指定需要的权限类型与目标行业,IAB的出现为RaaS提供了极大的便利。

image002.png

图2- RaidfForums上卖家出售数据库信息的帖子

image003.png

图3- RaidForums上买家购买手机数据库数据的帖子

在利益的驱动下,RaaS与IAB的交易越来越密切,值得关注的是:根据Digital Shadows统计,IAB交易的热点行业权限top5 为零售行业、金融行业、科技行业与工业制造业(如医药制造),科技行业的初始访问代理权限平均价格最高为13,607 美元。

image004.png

图4- DigitalsShadows统计2020年IAB的热点行业及价格

IAB初始访问权限获取方法

那么黑客通常是怎样获取有效的IAB的呢?我们结合威胁情报网站ke-la.com分析过IAB的几个趋势以及威胁情报网站curatedintel.org提供的资料,研究分析后归纳出如下图所示的IAB初始权限获取路径图。
image005.png

图5- IAB初始权限获取路径图

通过上图我们可以看到,IAB产业初始权限获取方法主要分为以下几个路径:

1.以目标漏洞为途径:攻击者通过黑客搜索引擎来获取受害者对外暴露的资产,之后进行ip探测,域名探测,端口开放探测(如RDP端口)以及漏洞扫描,类似于红蓝对抗中攻击队前期对目标的资产梳理和信息搜集,期间会用到各类黑客搜索引擎如Shodan、Censys,在确定目标资产后进行漏洞扫描,漏洞扫描过程主要探测是否存在一些知名软件的历史CVE漏洞,相关软件产品如VPN产品SecureVPN、云桌面常用的Citrix软件、虚拟化产品Vmware、微软系列的Exchange、负载均衡设备F5以及路由器设备Cisco等。黑客一旦探测到相应产品存在的漏洞,就发起攻击,攻击成功后可获取目标权限,之后可以进行内网横向,植入后门等操作,最终获取有效的初始访问权限。具体使用到的漏洞如下图所示。

image006.png

图6- IAB产业常用CVE漏洞

2.以社会工程学为途径:在信息窃取活动中主要以获得目标门户网站登录相关的MFA验证码(多因子校验的秘钥或验证码)为主,攻击方式不限于语音电话钓鱼、短信钓鱼、近源攻击、伪造商业合作钓鱼等一系列社会工程学攻击,这些攻击手段层出不穷,较为值得关注是电话钓鱼,国外专注于人员安全意识培训和钓鱼模拟攻击服务的公司Terranova有总结到相关社工策略:“第一种常见的策略是一些网络犯罪分子使用强硬的语言,表示他们正在帮助受害者避免刑事指控;第二种常见的策略是犯罪分子留下威胁性的语音邮件,告诉收件人立即回电,否则受害者可能会被逮捕,银行账户被关闭,或者会发生更糟糕的事情。在网络犯罪分子使用威胁和令人信服的语言下让受害者觉得别无选择,受害者只能提供犯罪分子想要的信息。”

image007.png

图7- Terranova对Vishing的解读

3.以售卖信息的地下市场为途径:使用在地下市场上出售的用户信息获得访问权限,黑客通过著名论坛OGuser购买到关于受害者目标用户身份的访问权限后尝试登录受害者的相关网站。

image008.png

图8- OGuser上的账户交易服务

4.以第三方数据泄露为途径:使用来自第三方数据泄露的凭证获取访问权限,拿到相关泄露数据后,与上述第三种方式不同,第三方泄露数据需要“二次加工”,可以通过密码喷洒,撞库攻击,暴力破解等方式尝试登录受害者系统来获取目标系统访问权限。

image009.png

图9- DeHashed论坛数据泄露交易

5.使用网络钓鱼活动获取访问权限:以邮件钓鱼为主,通过恶意邮件投递一些恶意软件,如RedLine Stealer (RedLine Stealer是一种恶意软件,该恶意软件从浏览器收集信息,例如保存的凭据:自动填充的数据和信用卡信息等),Vidar( Vidar是一种基于Arkei 的分叉恶意软件),Taurus(Taurus是一种基于C/C++实现的信息窃取恶意软件),LokiBot(也称为 Lokibot、Loki PWS和Loki-bot,使用特洛伊木马恶意软件来窃取敏感信息,例如用户名、密码、加密货币钱包和其他凭据)等,这些钓鱼方式大部分都是以恶意文档为载荷,当受害者打开文档后利用宏去执行或下载被加密后的Shellcode,之后建立C2信道进行长期控制窃取信息,相关细节如下图。Malpedia对这些软件都有解释和记录,有兴趣同学可在Malpedia上查询。黑客在受害者不小心中招了相关恶意软件后可直接获得目标的初始访问代理权限。

image010.png

图10- 国外对MaliciousSpam 钓鱼技术解读

image011.png

图11- Trickbot的邮件木马执行过程

(图片来源:Hornetsecurity)

6.以内部威胁为途径:内部员工直接就有内部IT系统访问权限,心怀不轨的员工可以拿公司的权限或数据到论坛进行贩卖或用于其他意图。

“IAB”下企业如何做好防范措施

1. 外部资产安全:攻击者先通过信息搜集,通过漏扫工具进行漏洞扫描或者通过第三方泄露数据进行撞库攻击,根据这些攻击方式,企业外部安全要做到:(1) 及时发现和修护系统漏洞,做好系统加固与升级,做好边缘资产的收束,非必要服务与端口不对外开放。通过“监控”第三方网站如Github,及时查看哪些员工数据遭到了泄露,避免有“强弱口令”和无风控机制下的系统出现问题;(2) 系统与设备上线前要做好安全审计与安全测试,规避带着“问题”上线而遭受黑客攻击。

2. 内部安全建设:从攻击者社工相关攻击路径来看,攻击者通过携带恶意后门,广撒网方式来进行邮件钓鱼,以及遭受“内鬼”的威胁,因此内部安全建设要做到:(1)离职人员的账户权限要及时清除,员工访问内网系统的权限要进行严格隔离,不同层级的网络也要做好隔离;(2)对员工做安全意识培训,防止员工中招邮件钓鱼以及其他社会工程学的攻击;(3)日志系统的建设与健全:入侵后可以通过日志及时查漏补缺;(4)安全设备的安装尽量覆盖所有终端,这样可以抵挡大部分病毒与木马的威胁,可以有效防止黑客横向移动与权限提升等后渗透行为,及时更新病毒库可以有效防止黑客利用NDay攻击。

3.威胁情报建设:攻击者通过在各大论坛出售与企业相关的数据与权限,因此企业需要做到:(1)及时从外部论坛,威胁情报网站等获取企业威胁信息,做好风险控制,及时关注最新安全态势;(2)密切关注IAB和三方数据泄露的动态,防止数据与权限被出售后对企业形成“二次”伤害。

4.数据备份与容灾:如果上述所有防线均被突破,那么平时做好数据备份与容灾工作,建立完善的灾备机制,拥有良好的数据权限隔离方案,可以有效防止业务系统数据被加密后无法解密的尴尬局面出现。

参考链接:

国外:

https://www.curatedintel.org/2021/10/initial-access-broker-landscape.html?m=1

https://ke-la.com/all-access-pass-five-trends-with-initial-access-brokers/

https://www.blueliv.com/cyber-security-and-cyber-threat-intelligence-blog-blueliv/research/use-of-initial-access-brokers-by-ransomware-groups/ 

https://github.com/curated-intel/Initial-Access-Broker-Landscapehttps://terranovasecurity.com/what-is-vishing/

恶意软件相关:

https://us-cert.cisa.gov/ncas/alerts/aa20-266a https://securityboulevard.com/2021/05/an-in-depth-analysis-of-the-new-taurus-stealer/

钓鱼邮件活动:

https://isc.sans.edu/forums/diary/Dridex+malspam+seen+on+Monday+20170410/22280/

https://www.hornetsecurity.com/en/security-information/trickbot-malspam-leveraging-black-lives-matter-as-lure/

https://securelist.com/malicious-spam-campaigns-delivering-banking-trojans/102917/

国内:

http://www.mchz.com.cn/cn/about-us/Industry-News/info_366_itemid_5065.html

https://new.qq.com/omn/20210901/20210901A0524K00.html

产业互联网飞速发展,各行各业加速“上云”,相应的云上安全需求也正持续升温。

11月4日,2021腾讯数字生态大会·Techo Day技术峰会在武汉召开。Techo Day上,腾讯安全副总裁、腾讯安全云鼎实验室负责人董志强带来了《基建、研发、安全——腾讯云安全前沿技术探索和实践》的主题演讲,对数实融合时代下如何更好开展云上安全建设进行了观点与实践经验分享。过去几年,为了保障云的安全性,腾讯安全做了大量工作,以保障腾讯云平台本身的安全性,并逐渐形成了一整套面向云原生的全栈安全产品体系,满足云上租户不同形态的安全防护需求。

“腾讯云服务于百万级别的行业客户,小到几十人的初创公司,大到几万人的大型企业,很多客户把核心的业务和数字资产放在腾讯上,我们要为这些业务和数字资产搭好安全防线。”腾讯安全副总裁、腾讯安全云鼎实验室负责人董志强表示。

以下为董志强演讲实录:

1.jpg

数字化的重要性在今天几乎不言而喻。对于企业而言,数字化是在当下数字经济的环境中获得高质量发展、提高效能的必然选择。数字化过程中,“上云”是关键步骤。

越来越多企业将核心IT设施和工作负载迁移到云上,IDC的一个报告显示,到2025年,50%的中国企业IT基础设施支出将分配给公有云,四分之一的企业IT应用将运行在公有云服务上。“上云”是大势所趋,但在客观上也带来了安全隐患,目前网络攻击手法日益APT化,云上安全防护也成为了整个行业共同关注的焦点。

我们云鼎实验室从成立以来就致力于云安全的研究,过去几年我们也一直在承担腾讯云底层安全工作的建设,腾讯“930”架构升级、投入产业互联网之后,我们也通过腾讯云把积累多年的安全能力以SaaS服务的方式开放给行业。

我们从自己的实践角度,今天给大家分享三个方面的议题:

首先,我们如何保障云本身的基础设施安全。

其次,我们如何通过云原生安全产品和服务体系,为云租户提供安全保障。

第三,我们如何通过云原生安全托管服务,提升行业安全基线。

一、 云原生基础设施安全

首先是基础设施层面。这里面包含了云的基础设施本身安全、软件生命周期安全、云平台安全运营能力和红蓝演练等几个维度。

腾讯云服务于百万级别的行业客户,从几十人的初创企业到上市公司,各种规模都有,很多客户把核心的业务和数字资产放在腾讯上,我们要为这些业务和数字资产搭好第一道防线。

2.jpg

基础设施安全是整个安全体系的基础,也是上层应用安全、业务安全、数据安全的底座。基础设施包括数据中心、服务器硬件、操作系统和应用系统,只有全栈安全才是立体的、全方位的安全,也是云平台要达成的目标。腾讯云从硬件设计阶段开始,到租户应用系统,在平台的每一层都有大量安全技术的融入,并结合安全监控,安全运营确保云平台基础设置全栈防御、全栈监控,从而实现全栈安全。

在操作系统这层,我们内置了大量的安全加固机制,比如0day自动防御,可以实现无补丁的抵御0day攻击;在hypervisor这层,我们开发了HyperGuard,防范虚拟化逃逸漏洞攻击,当前已公布的逃逸类漏洞攻击全部可以免疫。

在云产品安全维度,我们基于腾讯云的研发运维模式建立了DevSecOps模型并落地实践,基于一站式DevOps平台与流程,在项目协同、编码、代码管理与分析、自动化测试、等各个环节嵌入安全活动;通过自研的方式建立安全工具链,建立安全门禁,实现安全度量,从不同阶段和维度收敛安全风险,并实现部分场景的默认安全,以此来实现腾讯云产品的出厂安全。

今年的可信云大会上,信通院牵头发布了一系列研发运营安全工具标准,我们也是也主要的起草单位之一。

为了保障云平台的安全,我们通过边界控制、防御加固、加强检测能力三方面来建设云平台基础安全能力,缩小云平台的风险攻击面,减少云平台的脆弱性。在云平台基础安全能力已经具备的基础上,为了提升安全运营效率,实现自动安全闭环,我们建设了安全运营平台。平台集成了安全告警黑白灰分离、专家策略、机器学习、红蓝检验等能力,遵循PDCA的闭环原则,从数据接入、加固防御、安全检测、告警处置等方面实现了“人+机+知识”协同交互的自动化,可视化的云平台安全运营管理。

通过前面说的几方面的的基础建设,腾讯云目前已经具备了百万级告警数据处理能力,通过持续跟踪安全指标并不断改进,建立了丰富的规则库,将平均MTTD降到了3小时以内,有效提升了云平台安全运营效率。截至目前,我们已经接入600多个基础设施审计日志,覆盖300多万资产,在加固方面已经适配30多种安全基线,漏洞修复率达到了99.9%;运营和安全策略方面也有较好的效果。

3.jpg

安全就是一个持续动态对抗的过程,实践是检验安全性的最好标准。正如木桶原理,最短的木板是评估木桶品质的标准,安全最薄弱环节也是决定系统好坏的关键。

对于腾讯云而言,不管是在安全体系建设初期还是完善之境,均需要一定的手段来测量最短木板的长短,红蓝对抗就是这样一种测量方式。

红蓝对抗演习是腾讯云安全体系建设的一个常态化工作,通过持续对抗演习来验证整体安全防御情况,发现疏漏的风险盲点与攻防场景,同时实现安全练兵与提升响应效率,并进一步提升腾讯云员工安全意识,从而实现整体安全体系的不断完善与安全水位线的持续提升。

二、云原生安全产品和服务

底层安全只是第一层保障,到了应用层面,对于不同行业、不同体量的企业来说,他需要的安全防护等级和内容是不一样的。腾讯过去也有海量的业务场景,我们把自己多年安全建设相关的经验进行了产品化,并联合我们的业务生态合作伙伴一起,为行业客户打造了一套云原生的安全“自助餐”。

4.jpg

我们从云原生安全、计算安全、应用安全、数据安全、治理安全几个维度,提供了一系列云上工具包。用户可以根据自己的行业属性,针对性进行组合搭配。

其中有一些产品和服务经过规模化应用,形成了自己的特色,我们在其中也沉淀了一些实践经验。我挑了几个比较有代表性的产品跟大家展开分享。

首先是容器安全。腾讯安全具有多年云原生安全领域的研究和实践运营经验,同时结合腾讯云容器平台TKE千万级核心规模容器集群治理经验,设计落地腾讯云原生容器安全体系。

腾讯云原生容器安全体系基于安全能力原生化、安全防护全生命周期、安全左移和零信任安全架构设计原则,实现从基础设施、容器平台、应用、DevSecOps、安全管理的完整安全防护方案。

确保用户实现容器业务上线即安全的目标,面向容器业务从构建部署到运行时,容器安全服务可以提供完整的全生命周期安全防护,更好地助力用户安全的实现云原生转型,享受云原生带来的红利我们也把一些容器安全相关的经验和方法沉淀下来。最近,腾讯安全云鼎实验室联合腾讯云容器团队共同撰写并发布了《腾讯云容器安全白皮书》。白皮书介绍了腾讯云在容器安全建设上的思路、方案以及实践,并希望以这样的方式,把我们的一些心得分享给业界,共同推动云原生安全的发展。

第二个要分享的是腾讯的云防火墙。

传统防火墙产品通常只能通过CVM镜像方式在云环境下部署,客户采用这类方案,通常有3个痛点:

1、实施部署比较麻烦。

2、性能受限于承载安全镜像的CVM,无法应对业务流量的突发需求。

3、需要进行负责的HA双机热备部署。

而云原生的防火墙,利用了云的优势,即开即用,分钟级即可完成部署,同时还可实现弹性的扩展,也无需客户关注复杂的双机HA部署,天然内置高可靠。

此外,腾讯云防火墙也提供了很多独有的原生安全能力,比如一键互联网资产暴露面分析全网的威胁情报联动,小时级别的网络虚拟补丁技术,让云防火墙成为云上流量的安全中心。

5.jpg

在战争中,情报是核心生产力。威胁情报的出现推动了传统事件响应式的安全思维向全生命周期的持续智能响应转变借助威胁情报,企业能从网络安全设备的海量告警中解脱出来,以更加智能的方式掌握网络安全事件、重大漏洞、攻击手段等信息,并在第一时间采取预警和应急响应等工作。

腾讯拥有全球最大的威胁情报库、黑产知识图谱,我们有顶级安全实验室和安全人才的加持,我们的情报质量在客户环境和实验室检测中,结果都经过验证的。

最近几年,零信任是安全行业的“风口”。腾讯是国内最早践行零信任的企业,去年疫情突然爆发的时候,我们IT部门只用了几天时间就把7万多员工全量切换成了基于零信任架构的远程办公模式。

在我们自己实践之后,也对外输出了行业解决方案,也就是腾讯iOA,目前我们已经推出了SaaS版的服务。

它是一款基于零信任架构的应用安全访问云平台,为企业提供安全接入数据中心的解决方案,企业客户通过iOA云控制台实现对数据中心访问权限管理和终端安全管控。

iOA SaaS版提供轻量级客户端或者无端版本,管理后台全部部署在腾讯云上,通过连接器即可实现iOA和企业数据中心的连接,部署非常方便。

腾讯iOA SaaS版的客户目前已覆盖多个行业,例如高校,他们比较典型的场景是内网的一些应用发布到外网不受保护,安全隐患很高,通过iOA SaaS方案实现了通过企微工作台快捷、安全的访问内部应用。管理员还可以进行访问权限的管控,禁止恶意/无权的访问。

再例如我们服务的一家国际比较知名的酒店,企业内部系统运行历史悠久,部署在内网且以单一帐号认证,爆破风险较高。iOA SaaS就为它提供了双因子认证的保护,帮助它进行内网应用快速迁移上云。

《数据安全法》正式实施了,企业用户对于数据安全方面的诉求也迅猛增长,要在短时间内完成数据安全合规要求,传统的私有化部署可能面临需要大幅度的系统改造以及性能损耗的问题。

我们结合云上数据安全防护经验,推出了云原生的数据安全解决方案,以云加密机为计算资源的底座,为用户和上层产品提供硬件级合规的密码计算资源,以KMS&SSM为云平台的密码基础设施,提供硬件级合规安全的密钥和凭据管理平台,通过云产品和KMS的无缝集成,为用户提供各类云产品的透明加密能力。

通过云访问安全代理CASB,可以在业务免改造的前提下,实现数据字段级加密、脱敏和数据分类分级等。云原生的数据安全方案为用户提供了更轻、更快更新的一站式数据安全能力。

目前,数据安全在各个行业都有广泛的应用,以某地的抗疫小程序为例,通过接入数据安全中台,快速实现了对2亿条国民敏感数据的安全保护,解决了数据加密改造难的问题,让业务方在应用免改造的情况下通过策略配置快速实现敏感字段的加密和脱敏。

数据加密的密钥通过腾讯KMS安全托管在硬件加密机,在解决数据安全的同时满足合规的要求。最大的优势就在于有效的降低了数据安全的接入门槛,让即使对数据安全技术不是太了解的团队也能够快速实现数据安全保护。

一个好的安全防御体系需要一个指挥中枢,安全运营中心就承担了指挥中心的作用。

腾讯云原生安全运营中心沿用经典自适应安全体系设计;多源数据的融合汇聚,包括自主可控的流量、端、云上数据采集,也支持开放的第三方数据采集;检测方面,依赖关联引擎、情报分析引擎及UEBA引擎能力,对内外威胁进行分析,可联动自动编排响应引擎。

云原生安全运营中心具备五大特点:

1、支持多角色、多租户的组织架构。

2、适配云上及云下多业务环境。

3、从实战中历练,多种检测手段与分析技术,流量侧与端侧的数据贯通分析。

4、充分利用腾讯在可视化方面的积累,娱乐级的可视效果。

5、从实战中历练,可靠的安全运营服务。

在云原生的框架下,我们前面提及的各种云安全产品各司其职,由安全运营中心统一调度,原厂、原装的强大产品体系,为企业用户提供一套坚实的安全防护网。

三、云原生安全托管服务

我们前段时间刚刚正式发布了安全托管服务MSS,这是我们过去几年工作内容的一个产品化成果,它可能代表了安全行业的一个发展趋势,即安全建设正在从传统的产品驱动转向服务驱动转变。

我们和各行业客户交流过程中,发现很多用户上云后,在安全运营方面都面临着如下问题:

1、安全产品告警剧增,导致运营处置成本增加;

2、企业业务增速增加,安全建设人力有些跟不上;

3、安全自动化程度不足,导致运营效率偏低。

针对这些问题,腾讯云从内外部产品研发、服务交付以及服务运营等多个环节进行安全流程设计和能力沉淀,构建了全链条的端到端的安全服务体系。

其中,针对客户上云后面临的安全运营方面的典型痛点和问题,我们推出了MSS安全托管服务。

腾讯云的安全托管服务MSS主要对云上各类租户的最佳安全实践场景进行沉淀,通过自研的安全编排和自动化响应系统,结合腾讯安全情报、全网攻击数据,提升云上攻防对抗能力,实现安全服务的标准化和高效化。

目前托管的服务品类包括2大类和十几项安全服务内容,分别面向日常安全运营场景及重大活动护航场景。

6.jpg

这是一个我们上半年服务的某政企客户攻防演练案例。当时,客户所有系统均放在不同公有云厂商,内部无专职安全团队,只有研发团队,业务需求紧迫,部分测试环境无法关闭,涉及业务种类繁多,同时之前还在攻防演练开始的第一天被攻破,在新的攻防演练活动背景下,找到我们,希望帮忙开展服务保障。

最终通过MSS服务人员对现状进行为期一周的梳理和推动修复、以及攻防开始后的实时监控和拦截防护,最终顺利防守住了攻击。

在前几个月刚结束不久的大型攻防演练项目中,腾讯MSS服务的灰度接入了部分云上重点用户,最终均顺利支撑这些服务目前累计支撑了几十家用户的大型攻防演练保障及日常运营,支撑的服务器规模达数万台。

我们在云服务托管上的能力也得到了国际研报的认证。头豹研究院联合Frost &Sullivan发布最新《2021年中国安全托管市场报告》,从风险趋势、供应商能力、市场前景和技术趋势等多个维度,对国内安全托管市场做了全面的调研与分析。

基于基础指数、成长指数、服务能力、市场影响力四个维度计算,沙利文认为中国安全托管市场竞争力梯队已经成型,腾讯云在其中居于行业领导者地位。

不管腾讯云自身的安全保障还是服务客户的过程中,我们发现,安全行业面临非常大资源缺口、人力缺口。面对这么多的制约,怎么解决这个问题?

全靠人驱动是不现实的,第一,没有这么多专业人力,第二,即使有足够多的安全专家,但人是会懈怠的、会疏忽的。

结合过去三年落在腾讯云自身的安全管理的基本路线,我们认为,只有把尽可能多的安全能力以云原生的方式纳入云平台自身的能力,才能比较好的应对当今数字经济全面发展过程中的安全风险。

产业互联网飞速发展,各行各业加速“上云”,相应的云上安全需求也正持续升温。

11月4日,2021腾讯数字生态大会·Techo Day技术峰会在武汉召开。Techo Day上,腾讯安全副总裁、腾讯安全云鼎实验室负责人董志强带来了《基建、研发、安全——腾讯云安全前沿技术探索和实践》的主题演讲,对数实融合时代下如何更好开展云上安全建设进行了观点与实践经验分享。过去几年,为了保障云的安全性,腾讯安全做了大量工作,以保障腾讯云平台本身的安全性,并逐渐形成了一整套面向云原生的全栈安全产品体系,满足云上租户不同形态的安全防护需求。

“腾讯云服务于百万级别的行业客户,小到几十人的初创公司,大到几万人的大型企业,很多客户把核心的业务和数字资产放在腾讯上,我们要为这些业务和数字资产搭好安全防线。”腾讯安全副总裁、腾讯安全云鼎实验室负责人董志强表示。

以下为董志强演讲实录:

1.jpg

数字化的重要性在今天几乎不言而喻。对于企业而言,数字化是在当下数字经济的环境中获得高质量发展、提高效能的必然选择。数字化过程中,“上云”是关键步骤。

越来越多企业将核心IT设施和工作负载迁移到云上,IDC的一个报告显示,到2025年,50%的中国企业IT基础设施支出将分配给公有云,四分之一的企业IT应用将运行在公有云服务上。“上云”是大势所趋,但在客观上也带来了安全隐患,目前网络攻击手法日益APT化,云上安全防护也成为了整个行业共同关注的焦点。

我们云鼎实验室从成立以来就致力于云安全的研究,过去几年我们也一直在承担腾讯云底层安全工作的建设,腾讯“930”架构升级、投入产业互联网之后,我们也通过腾讯云把积累多年的安全能力以SaaS服务的方式开放给行业。

我们从自己的实践角度,今天给大家分享三个方面的议题:

首先,我们如何保障云本身的基础设施安全。

其次,我们如何通过云原生安全产品和服务体系,为云租户提供安全保障。

第三,我们如何通过云原生安全托管服务,提升行业安全基线。

一、 云原生基础设施安全

首先是基础设施层面。这里面包含了云的基础设施本身安全、软件生命周期安全、云平台安全运营能力和红蓝演练等几个维度。

腾讯云服务于百万级别的行业客户,从几十人的初创企业到上市公司,各种规模都有,很多客户把核心的业务和数字资产放在腾讯上,我们要为这些业务和数字资产搭好第一道防线。

2.jpg

基础设施安全是整个安全体系的基础,也是上层应用安全、业务安全、数据安全的底座。基础设施包括数据中心、服务器硬件、操作系统和应用系统,只有全栈安全才是立体的、全方位的安全,也是云平台要达成的目标。腾讯云从硬件设计阶段开始,到租户应用系统,在平台的每一层都有大量安全技术的融入,并结合安全监控,安全运营确保云平台基础设置全栈防御、全栈监控,从而实现全栈安全。

在操作系统这层,我们内置了大量的安全加固机制,比如0day自动防御,可以实现无补丁的抵御0day攻击;在hypervisor这层,我们开发了HyperGuard,防范虚拟化逃逸漏洞攻击,当前已公布的逃逸类漏洞攻击全部可以免疫。

在云产品安全维度,我们基于腾讯云的研发运维模式建立了DevSecOps模型并落地实践,基于一站式DevOps平台与流程,在项目协同、编码、代码管理与分析、自动化测试、等各个环节嵌入安全活动;通过自研的方式建立安全工具链,建立安全门禁,实现安全度量,从不同阶段和维度收敛安全风险,并实现部分场景的默认安全,以此来实现腾讯云产品的出厂安全。

今年的可信云大会上,信通院牵头发布了一系列研发运营安全工具标准,我们也是也主要的起草单位之一。

为了保障云平台的安全,我们通过边界控制、防御加固、加强检测能力三方面来建设云平台基础安全能力,缩小云平台的风险攻击面,减少云平台的脆弱性。在云平台基础安全能力已经具备的基础上,为了提升安全运营效率,实现自动安全闭环,我们建设了安全运营平台。平台集成了安全告警黑白灰分离、专家策略、机器学习、红蓝检验等能力,遵循PDCA的闭环原则,从数据接入、加固防御、安全检测、告警处置等方面实现了“人+机+知识”协同交互的自动化,可视化的云平台安全运营管理。

通过前面说的几方面的的基础建设,腾讯云目前已经具备了百万级告警数据处理能力,通过持续跟踪安全指标并不断改进,建立了丰富的规则库,将平均MTTD降到了3小时以内,有效提升了云平台安全运营效率。截至目前,我们已经接入600多个基础设施审计日志,覆盖300多万资产,在加固方面已经适配30多种安全基线,漏洞修复率达到了99.9%;运营和安全策略方面也有较好的效果。

3.jpg

安全就是一个持续动态对抗的过程,实践是检验安全性的最好标准。正如木桶原理,最短的木板是评估木桶品质的标准,安全最薄弱环节也是决定系统好坏的关键。

对于腾讯云而言,不管是在安全体系建设初期还是完善之境,均需要一定的手段来测量最短木板的长短,红蓝对抗就是这样一种测量方式。

红蓝对抗演习是腾讯云安全体系建设的一个常态化工作,通过持续对抗演习来验证整体安全防御情况,发现疏漏的风险盲点与攻防场景,同时实现安全练兵与提升响应效率,并进一步提升腾讯云员工安全意识,从而实现整体安全体系的不断完善与安全水位线的持续提升。

二、云原生安全产品和服务

底层安全只是第一层保障,到了应用层面,对于不同行业、不同体量的企业来说,他需要的安全防护等级和内容是不一样的。腾讯过去也有海量的业务场景,我们把自己多年安全建设相关的经验进行了产品化,并联合我们的业务生态合作伙伴一起,为行业客户打造了一套云原生的安全“自助餐”。

4.jpg

我们从云原生安全、计算安全、应用安全、数据安全、治理安全几个维度,提供了一系列云上工具包。用户可以根据自己的行业属性,针对性进行组合搭配。

其中有一些产品和服务经过规模化应用,形成了自己的特色,我们在其中也沉淀了一些实践经验。我挑了几个比较有代表性的产品跟大家展开分享。

首先是容器安全。腾讯安全具有多年云原生安全领域的研究和实践运营经验,同时结合腾讯云容器平台TKE千万级核心规模容器集群治理经验,设计落地腾讯云原生容器安全体系。

腾讯云原生容器安全体系基于安全能力原生化、安全防护全生命周期、安全左移和零信任安全架构设计原则,实现从基础设施、容器平台、应用、DevSecOps、安全管理的完整安全防护方案。

确保用户实现容器业务上线即安全的目标,面向容器业务从构建部署到运行时,容器安全服务可以提供完整的全生命周期安全防护,更好地助力用户安全的实现云原生转型,享受云原生带来的红利我们也把一些容器安全相关的经验和方法沉淀下来。最近,腾讯安全云鼎实验室联合腾讯云容器团队共同撰写并发布了《腾讯云容器安全白皮书》。白皮书介绍了腾讯云在容器安全建设上的思路、方案以及实践,并希望以这样的方式,把我们的一些心得分享给业界,共同推动云原生安全的发展。

第二个要分享的是腾讯的云防火墙。

传统防火墙产品通常只能通过CVM镜像方式在云环境下部署,客户采用这类方案,通常有3个痛点:

1、实施部署比较麻烦。

2、性能受限于承载安全镜像的CVM,无法应对业务流量的突发需求。

3、需要进行负责的HA双机热备部署。

而云原生的防火墙,利用了云的优势,即开即用,分钟级即可完成部署,同时还可实现弹性的扩展,也无需客户关注复杂的双机HA部署,天然内置高可靠。

此外,腾讯云防火墙也提供了很多独有的原生安全能力,比如一键互联网资产暴露面分析全网的威胁情报联动,小时级别的网络虚拟补丁技术,让云防火墙成为云上流量的安全中心。

5.jpg

在战争中,情报是核心生产力。威胁情报的出现推动了传统事件响应式的安全思维向全生命周期的持续智能响应转变借助威胁情报,企业能从网络安全设备的海量告警中解脱出来,以更加智能的方式掌握网络安全事件、重大漏洞、攻击手段等信息,并在第一时间采取预警和应急响应等工作。

腾讯拥有全球最大的威胁情报库、黑产知识图谱,我们有顶级安全实验室和安全人才的加持,我们的情报质量在客户环境和实验室检测中,结果都经过验证的。

最近几年,零信任是安全行业的“风口”。腾讯是国内最早践行零信任的企业,去年疫情突然爆发的时候,我们IT部门只用了几天时间就把7万多员工全量切换成了基于零信任架构的远程办公模式。

在我们自己实践之后,也对外输出了行业解决方案,也就是腾讯iOA,目前我们已经推出了SaaS版的服务。

它是一款基于零信任架构的应用安全访问云平台,为企业提供安全接入数据中心的解决方案,企业客户通过iOA云控制台实现对数据中心访问权限管理和终端安全管控。

iOA SaaS版提供轻量级客户端或者无端版本,管理后台全部部署在腾讯云上,通过连接器即可实现iOA和企业数据中心的连接,部署非常方便。

腾讯iOA SaaS版的客户目前已覆盖多个行业,例如高校,他们比较典型的场景是内网的一些应用发布到外网不受保护,安全隐患很高,通过iOA SaaS方案实现了通过企微工作台快捷、安全的访问内部应用。管理员还可以进行访问权限的管控,禁止恶意/无权的访问。

再例如我们服务的一家国际比较知名的酒店,企业内部系统运行历史悠久,部署在内网且以单一帐号认证,爆破风险较高。iOA SaaS就为它提供了双因子认证的保护,帮助它进行内网应用快速迁移上云。

《数据安全法》正式实施了,企业用户对于数据安全方面的诉求也迅猛增长,要在短时间内完成数据安全合规要求,传统的私有化部署可能面临需要大幅度的系统改造以及性能损耗的问题。

我们结合云上数据安全防护经验,推出了云原生的数据安全解决方案,以云加密机为计算资源的底座,为用户和上层产品提供硬件级合规的密码计算资源,以KMS&SSM为云平台的密码基础设施,提供硬件级合规安全的密钥和凭据管理平台,通过云产品和KMS的无缝集成,为用户提供各类云产品的透明加密能力。

通过云访问安全代理CASB,可以在业务免改造的前提下,实现数据字段级加密、脱敏和数据分类分级等。云原生的数据安全方案为用户提供了更轻、更快更新的一站式数据安全能力。

目前,数据安全在各个行业都有广泛的应用,以某地的抗疫小程序为例,通过接入数据安全中台,快速实现了对2亿条国民敏感数据的安全保护,解决了数据加密改造难的问题,让业务方在应用免改造的情况下通过策略配置快速实现敏感字段的加密和脱敏。

数据加密的密钥通过腾讯KMS安全托管在硬件加密机,在解决数据安全的同时满足合规的要求。最大的优势就在于有效的降低了数据安全的接入门槛,让即使对数据安全技术不是太了解的团队也能够快速实现数据安全保护。

一个好的安全防御体系需要一个指挥中枢,安全运营中心就承担了指挥中心的作用。

腾讯云原生安全运营中心沿用经典自适应安全体系设计;多源数据的融合汇聚,包括自主可控的流量、端、云上数据采集,也支持开放的第三方数据采集;检测方面,依赖关联引擎、情报分析引擎及UEBA引擎能力,对内外威胁进行分析,可联动自动编排响应引擎。

云原生安全运营中心具备五大特点:

1、支持多角色、多租户的组织架构。

2、适配云上及云下多业务环境。

3、从实战中历练,多种检测手段与分析技术,流量侧与端侧的数据贯通分析。

4、充分利用腾讯在可视化方面的积累,娱乐级的可视效果。

5、从实战中历练,可靠的安全运营服务。

在云原生的框架下,我们前面提及的各种云安全产品各司其职,由安全运营中心统一调度,原厂、原装的强大产品体系,为企业用户提供一套坚实的安全防护网。

三、云原生安全托管服务

我们前段时间刚刚正式发布了安全托管服务MSS,这是我们过去几年工作内容的一个产品化成果,它可能代表了安全行业的一个发展趋势,即安全建设正在从传统的产品驱动转向服务驱动转变。

我们和各行业客户交流过程中,发现很多用户上云后,在安全运营方面都面临着如下问题:

1、安全产品告警剧增,导致运营处置成本增加;

2、企业业务增速增加,安全建设人力有些跟不上;

3、安全自动化程度不足,导致运营效率偏低。

针对这些问题,腾讯云从内外部产品研发、服务交付以及服务运营等多个环节进行安全流程设计和能力沉淀,构建了全链条的端到端的安全服务体系。

其中,针对客户上云后面临的安全运营方面的典型痛点和问题,我们推出了MSS安全托管服务。

腾讯云的安全托管服务MSS主要对云上各类租户的最佳安全实践场景进行沉淀,通过自研的安全编排和自动化响应系统,结合腾讯安全情报、全网攻击数据,提升云上攻防对抗能力,实现安全服务的标准化和高效化。

目前托管的服务品类包括2大类和十几项安全服务内容,分别面向日常安全运营场景及重大活动护航场景。

6.jpg

这是一个我们上半年服务的某政企客户攻防演练案例。当时,客户所有系统均放在不同公有云厂商,内部无专职安全团队,只有研发团队,业务需求紧迫,部分测试环境无法关闭,涉及业务种类繁多,同时之前还在攻防演练开始的第一天被攻破,在新的攻防演练活动背景下,找到我们,希望帮忙开展服务保障。

最终通过MSS服务人员对现状进行为期一周的梳理和推动修复、以及攻防开始后的实时监控和拦截防护,最终顺利防守住了攻击。

在前几个月刚结束不久的大型攻防演练项目中,腾讯MSS服务的灰度接入了部分云上重点用户,最终均顺利支撑这些服务目前累计支撑了几十家用户的大型攻防演练保障及日常运营,支撑的服务器规模达数万台。

我们在云服务托管上的能力也得到了国际研报的认证。头豹研究院联合Frost &Sullivan发布最新《2021年中国安全托管市场报告》,从风险趋势、供应商能力、市场前景和技术趋势等多个维度,对国内安全托管市场做了全面的调研与分析。

基于基础指数、成长指数、服务能力、市场影响力四个维度计算,沙利文认为中国安全托管市场竞争力梯队已经成型,腾讯云在其中居于行业领导者地位。

不管腾讯云自身的安全保障还是服务客户的过程中,我们发现,安全行业面临非常大资源缺口、人力缺口。面对这么多的制约,怎么解决这个问题?

全靠人驱动是不现实的,第一,没有这么多专业人力,第二,即使有足够多的安全专家,但人是会懈怠的、会疏忽的。

结合过去三年落在腾讯云自身的安全管理的基本路线,我们认为,只有把尽可能多的安全能力以云原生的方式纳入云平台自身的能力,才能比较好的应对当今数字经济全面发展过程中的安全风险。

俗话说“法网恢恢疏而不漏”,但法网似乎与如今的线上犯罪网络难以交织。作为密码学技术无心插柳的果实,勒索软件近年横扫互联网,使得下至小白网民上至各国政府无不闻风丧胆。在对受害者系统和主机入侵之后,勒索软件全盘扫描并加密特定类型的文件,对勒索受害者的筹码,也从给这些文件“解密”,发展为不给钱就“泄密”,倒是很符合昨天万圣节“不给糖就捣乱”的主题。

原本只能通过写破坏性病毒“炫技”的黑客们,在这种浪潮下找到了变现的途径,一个必要的契机,是加密货币的流通。以比特币为代表,加密货币原生具备匿名性,通俗说就是即便交易链路和历史都完全公开,但交易信息中的钱包地址和背后真实世界的人(在网络空间,“人”基本等同于IP地址)之间,完全没有任何关联和可追溯性。既然难以被定位稽查,勒索犯罪发起者自可高枕无忧。

德国时间28日,德国时代周报网络版(ZEITONLINE)刊发了编辑Kai Biermann的文章:《Coremember of ransomware gang identified》,整理了巴伐利亚广播的相关报道,公开了对臭名昭著的REvil勒索组织一关键成员的定位、跟踪和确认历程。这里我们特意根据公开的信息进行二次整理和解读,为读者呈现一个略显凑巧但又必然的故事:一个技术上完全匿名无从追踪的犯罪分子,是如何由“炫富”显形的。

背景:REvil与“现代化”勒索

当我们将勒索软件攻击背后那些看不见的人,笼统称为“勒索组织”时,已经高估了我们故事主人公的能力边界,但也低估了勒索犯罪这黑色产业的成熟度。

以文件加密为核心的勒索行为,实质只是完成复杂的脆弱分析、爆破渗透、横向移动和攻击持久化的完整入侵链路都完成后,一个简单的后入侵动作。一个犯罪组织独立完成完整的系列行动,对技术全面性要求很高,包括目标选定的广撒网的技术、历史与最新漏洞甚至0day漏洞的整合利用与迭代的系统工程,但某种程度上讲,也是传统的、模板化的体力活。

在高利润助推下,勒索进入产业分工合作化,形成所谓“勒索即服务”(Ransomware as a service,RaaS)形式。传统专精于入侵的组织是直接勒索攻击的主体,而勒索软件由专门的组织作为武器弹药供给;如此一来,勒索软件开发商专注于通过技术和代码的组合变化,保证弹药的持续有效,不被反病毒这种主机的最后一道防线防御甚至感知;而作为不直接发起攻击的后端,他们完全隐匿在重重迷雾后面,坐收其买家勒索成功所得赎金的分成。在某些事例中情况甚至更复杂:在勒索软件开发者和攻击黑产中间还产生所谓“代理商”,作为黑市的中间人,隐藏交易双方,同时加强供需要求的传递。

在RaaS模式下,勒索行动和组织无法简单根据所用勒索软件进行分类,因为多个组织可能采买具有相关性的软件,同一个供给和攻击者也可能改用完全不一样的弹药。而对后端不显山不露水的勒索软件供应商的定位和取证,也成了一个重要但几乎不可能的事情。

REvil即是这样一种勒索软件产物。不同时期不同发现该家族的反病毒机构对其有不同的命名,其它包括Sodinokibi等名字,同时也与其它某些家族,如Gandcrab,存在不能排除的同源可能。单此一个狭义定义的病毒家族样本相关的勒索攻击据信已经在世界范围内获利数十亿美金以上,攻击目标没有明确类型,包括政府组织、非营利组织甚至医疗机构。

明线:若隐若现的嫌疑人

在Zeit Online供稿中作者迫不及待地祭出目标嫌疑人的种种疑团,给人以“舍他其谁”的感觉,但是我们不妨从正向来看一下作为调查人员,面前摆的是怎样的证据链和猜疑网。

首先,虽然每一笔比特币交易的信息是公开的,但不是所有勒索攻击的受害者,甚至交付了赎金的单位,会选择上报其受害信息,因此无法根据受害者和攻击负载文件,明确刻画勒索组织与比特币钱包地址的对应关系。2019年德国斯图加特一家剧院受到Gandcrab勒索攻击,并据信支付了价值15,000欧元的赎金,且有一定证据证明Gandcrab勒索即是REvil的前身,根据此笔比特币交易,此处形成了疑似勒索组织比特币钱包地址的第一条弱证据。

顺着该钱包地址,调查人员定位到发布该地址的一个Telegram即时通讯应用账号,该账号关联到一个位于俄罗斯的手机号码,这个号码是与一些特定网站关联的大量手机号码之一,而其中一个或多个网站注册信息中给出了一个电子邮箱地址。证据链重重推演至这一步,在每一个环节都形成了一团由多个不可靠分支组成的迷雾;到最后这一步,可能衍生的可疑邮箱已经有较大集合,而这个邮箱地址值得注意的是——它在社交媒体上被一个俄罗斯用户关联,这就引向了报道中的主人公:Nikolay K. (化名)。

但是,仅仅根据目标的国籍吻合,以及重重猜疑的关联信息,显然是无法给出任何足以置信的结论的;这样的证据网络可能在每一例网络犯罪中被构建出来,又只得存档封存。

暗线:“此地有银三百两”

当锁定一个包括Nikolay K.在内的嫌疑人之后,调查人员就可以在合理的成本内,进行足够证实或证伪的取证。对于黑产从业人员,这种证据几乎肯定是不会有任何痕迹的;这也是本例故事的戏剧性所在。

经过目标人员画像,Nikolay K.与妻子住在俄罗斯一南部城镇,其可查的唯一合法收入来源仅是其所在城市一较新建筑内开办的小型酒吧,装潢简陋,主要服务于体育博彩。与如此简单甚至佛系的为生方式形成对比,Nikolay K.住所坐拥泳池,配备宝马超跑——而这还只是现实中的冰山一角。

在社交媒体上,Nikolay K.夫妇展示了极致奢华的生活方式。其本人账号并未公开,仅明示了他对于数字加密货币近乎宗教信仰一般的信念。但他的妻子Ekaterina K.似乎并不仅满足于获取高消费的感官感受:她社交媒体中的花花世界从迪拜的五星级酒店,到黑海的克里米亚半岛,再到马尔代夫;最新的一段视频展示了在土耳其南部海滨城市安塔利亚,二人组织的奢华游艇聚会,仅游艇的日租金就高达1300欧元。

虽然Nikolay K.本人可能在网络世界有意识低调,但在其妻子丰富的资料中,他日常身着Gucci T恤和太阳镜,痴迷宝马跑车。特别值得注意的是,从几个月前开始,他都戴着VanguardEncrypto奢侈手工定制腕表,价值至少七万欧元。支撑这极致奢华又无迹可踪的巨大财富,将他置于极大的怀疑之中。

而这块七万欧的腕表也就成了调查人员最终将Nikolay K.确认为关键嫌疑对象的证据。因为Vanguard Encrypto定制的首要噱头,就是会将所有者的比特币钱包地址二维码激光蚀刻在表盘上。如此极客的土豪,赤裸裸地宣誓了Nikolay K.对于从加密货币中攫取财富的得意。而对涉及加密货币的黑产交易中由匿名性带来的线上线下关联难的问题,似乎也很容易不攻自破:一旦到案,只需要翻过他的手腕,一切谎言和迷雾都将不再有效。

说到底,最终还是嫌疑人虽然克制但仍然漫溢的炫富欲望,变成了“此地有银三百两”的一声吆喝啊。

后续:所以又能怎么样呢?

在以上证据链形成后,调查人员和当事调查记者为了坐实猜疑,通过社交网络联系到了这个神龙见首不见尾的Nikolay K.。具体的试探消息我们不得而知,但是后者很快在社交媒体上撤回了他个人相关的信息:这将准星牢牢地套在了他的头上,但同时也不可避免地打草惊蛇了。

根据报告所述,这场调查持续了相当长的时间,据信至少在已经明确了目标的嫌疑之后,NikolayK.还在2020年内有过一次到土耳其的旅游,但出于未知原因,德国警方却并没有从土耳其将其引渡逮捕。至今Nikolay K.仍然逍遥法外,虽然记者显然仍然等待他下一次旅行到与德国有引渡条例的国家,但这至今再也没有发生——特别是在REvil基础设施被攻破之后,这趟可以让当事人和警方都感到兴奋的旅行,可能再不会发生了。

墓志铭.jpg

上图是Nikolay K.在社交媒体上发布的照片,德国警方定位到他的位置是在土耳其的安塔利亚,虽然德国和土耳其存在引渡条约,但是遗憾的是最终没能实现成功抓捕。这张照片同时也是Nikolay K.社交软件的Profile照片,当他嗅到被调查的风险后,他将所有照片一删而净。

尽管在本例事件中,调查人员几乎是像中彩票一般,关联到了这个本不可能被定位到的嫌疑人实人,但他的持续逍遥法外,仍然火辣辣地昭示着对于这种极端复杂的跨国网络空间犯罪中,对嫌疑人的逮捕是一件多么艰巨的挑战。预期中通过端掉勒索集团人员来根除祸患的结果没能出现,但我们仍然看到国际社会的一些合作与进展。根据10月21日路透社报道《EXCLUSIVEGovernments turn tables on ransomware gang REvil by pushing it offline》,在多方行动中,REvil组织的服务器基础设施遭到“反制”入侵和控制,勒索网站、支付渠道和服务被迫下线。这被官方与安全专家称为“标志性、毁灭性的行动”。但类似的反制行动在7月13日曾经成功实施过,当时该组织网站与支付渠道曾被迫下线;之后很快REvil就得以死灰复燃且更新迭代。对于这些以隐藏自身、不断更新为安身立命核心本领的犯罪对象,似乎在其人员落网或者赚的盆满钵满金盆洗手之前,反制与打击已经成了“杀不死他只会让他更强”的东西。

可以说,如今各国政府和安全行业与勒索组织之间的攻防,已经进入了无法速战速决的拉锯战态势,要打击收敛这个问题需要旷日持久的投入。直到决胜的方法和局面出现之前,我们仍然需要再三向所有依赖线上基础设施和资产的个人和企业用户进行明确:永远相信没有不能被攻破的系统,且你的系统不可能是其中最坚固的城池;只有采取任何可信的防护系统与机制、实时关注你的安全建设和最新安全态势,才能降低你成为下一个勒索软件受害者的“赔率”。

参考索引

文中援引德国时代周报网络版(ZEIT ONLINE)媒体原始报道,可参见:《Core member of ransomware gang identified》

俗话说“法网恢恢疏而不漏”,但法网似乎与如今的线上犯罪网络难以交织。作为密码学技术无心插柳的果实,勒索软件近年横扫互联网,使得下至小白网民上至各国政府无不闻风丧胆。在对受害者系统和主机入侵之后,勒索软件全盘扫描并加密特定类型的文件,对勒索受害者的筹码,也从给这些文件“解密”,发展为不给钱就“泄密”,倒是很符合昨天万圣节“不给糖就捣乱”的主题。

原本只能通过写破坏性病毒“炫技”的黑客们,在这种浪潮下找到了变现的途径,一个必要的契机,是加密货币的流通。以比特币为代表,加密货币原生具备匿名性,通俗说就是即便交易链路和历史都完全公开,但交易信息中的钱包地址和背后真实世界的人(在网络空间,“人”基本等同于IP地址)之间,完全没有任何关联和可追溯性。既然难以被定位稽查,勒索犯罪发起者自可高枕无忧。

德国时间28日,德国时代周报网络版(ZEITONLINE)刊发了编辑Kai Biermann的文章:《Coremember of ransomware gang identified》,整理了巴伐利亚广播的相关报道,公开了对臭名昭著的REvil勒索组织一关键成员的定位、跟踪和确认历程。这里我们特意根据公开的信息进行二次整理和解读,为读者呈现一个略显凑巧但又必然的故事:一个技术上完全匿名无从追踪的犯罪分子,是如何由“炫富”显形的。

背景:REvil与“现代化”勒索

当我们将勒索软件攻击背后那些看不见的人,笼统称为“勒索组织”时,已经高估了我们故事主人公的能力边界,但也低估了勒索犯罪这黑色产业的成熟度。

以文件加密为核心的勒索行为,实质只是完成复杂的脆弱分析、爆破渗透、横向移动和攻击持久化的完整入侵链路都完成后,一个简单的后入侵动作。一个犯罪组织独立完成完整的系列行动,对技术全面性要求很高,包括目标选定的广撒网的技术、历史与最新漏洞甚至0day漏洞的整合利用与迭代的系统工程,但某种程度上讲,也是传统的、模板化的体力活。

在高利润助推下,勒索进入产业分工合作化,形成所谓“勒索即服务”(Ransomware as a service,RaaS)形式。传统专精于入侵的组织是直接勒索攻击的主体,而勒索软件由专门的组织作为武器弹药供给;如此一来,勒索软件开发商专注于通过技术和代码的组合变化,保证弹药的持续有效,不被反病毒这种主机的最后一道防线防御甚至感知;而作为不直接发起攻击的后端,他们完全隐匿在重重迷雾后面,坐收其买家勒索成功所得赎金的分成。在某些事例中情况甚至更复杂:在勒索软件开发者和攻击黑产中间还产生所谓“代理商”,作为黑市的中间人,隐藏交易双方,同时加强供需要求的传递。

在RaaS模式下,勒索行动和组织无法简单根据所用勒索软件进行分类,因为多个组织可能采买具有相关性的软件,同一个供给和攻击者也可能改用完全不一样的弹药。而对后端不显山不露水的勒索软件供应商的定位和取证,也成了一个重要但几乎不可能的事情。

REvil即是这样一种勒索软件产物。不同时期不同发现该家族的反病毒机构对其有不同的命名,其它包括Sodinokibi等名字,同时也与其它某些家族,如Gandcrab,存在不能排除的同源可能。单此一个狭义定义的病毒家族样本相关的勒索攻击据信已经在世界范围内获利数十亿美金以上,攻击目标没有明确类型,包括政府组织、非营利组织甚至医疗机构。

明线:若隐若现的嫌疑人

在Zeit Online供稿中作者迫不及待地祭出目标嫌疑人的种种疑团,给人以“舍他其谁”的感觉,但是我们不妨从正向来看一下作为调查人员,面前摆的是怎样的证据链和猜疑网。

首先,虽然每一笔比特币交易的信息是公开的,但不是所有勒索攻击的受害者,甚至交付了赎金的单位,会选择上报其受害信息,因此无法根据受害者和攻击负载文件,明确刻画勒索组织与比特币钱包地址的对应关系。2019年德国斯图加特一家剧院受到Gandcrab勒索攻击,并据信支付了价值15,000欧元的赎金,且有一定证据证明Gandcrab勒索即是REvil的前身,根据此笔比特币交易,此处形成了疑似勒索组织比特币钱包地址的第一条弱证据。

顺着该钱包地址,调查人员定位到发布该地址的一个Telegram即时通讯应用账号,该账号关联到一个位于俄罗斯的手机号码,这个号码是与一些特定网站关联的大量手机号码之一,而其中一个或多个网站注册信息中给出了一个电子邮箱地址。证据链重重推演至这一步,在每一个环节都形成了一团由多个不可靠分支组成的迷雾;到最后这一步,可能衍生的可疑邮箱已经有较大集合,而这个邮箱地址值得注意的是——它在社交媒体上被一个俄罗斯用户关联,这就引向了报道中的主人公:Nikolay K. (化名)。

但是,仅仅根据目标的国籍吻合,以及重重猜疑的关联信息,显然是无法给出任何足以置信的结论的;这样的证据网络可能在每一例网络犯罪中被构建出来,又只得存档封存。

暗线:“此地有银三百两”

当锁定一个包括Nikolay K.在内的嫌疑人之后,调查人员就可以在合理的成本内,进行足够证实或证伪的取证。对于黑产从业人员,这种证据几乎肯定是不会有任何痕迹的;这也是本例故事的戏剧性所在。

经过目标人员画像,Nikolay K.与妻子住在俄罗斯一南部城镇,其可查的唯一合法收入来源仅是其所在城市一较新建筑内开办的小型酒吧,装潢简陋,主要服务于体育博彩。与如此简单甚至佛系的为生方式形成对比,Nikolay K.住所坐拥泳池,配备宝马超跑——而这还只是现实中的冰山一角。

在社交媒体上,Nikolay K.夫妇展示了极致奢华的生活方式。其本人账号并未公开,仅明示了他对于数字加密货币近乎宗教信仰一般的信念。但他的妻子Ekaterina K.似乎并不仅满足于获取高消费的感官感受:她社交媒体中的花花世界从迪拜的五星级酒店,到黑海的克里米亚半岛,再到马尔代夫;最新的一段视频展示了在土耳其南部海滨城市安塔利亚,二人组织的奢华游艇聚会,仅游艇的日租金就高达1300欧元。

虽然Nikolay K.本人可能在网络世界有意识低调,但在其妻子丰富的资料中,他日常身着Gucci T恤和太阳镜,痴迷宝马跑车。特别值得注意的是,从几个月前开始,他都戴着VanguardEncrypto奢侈手工定制腕表,价值至少七万欧元。支撑这极致奢华又无迹可踪的巨大财富,将他置于极大的怀疑之中。

而这块七万欧的腕表也就成了调查人员最终将Nikolay K.确认为关键嫌疑对象的证据。因为Vanguard Encrypto定制的首要噱头,就是会将所有者的比特币钱包地址二维码激光蚀刻在表盘上。如此极客的土豪,赤裸裸地宣誓了Nikolay K.对于从加密货币中攫取财富的得意。而对涉及加密货币的黑产交易中由匿名性带来的线上线下关联难的问题,似乎也很容易不攻自破:一旦到案,只需要翻过他的手腕,一切谎言和迷雾都将不再有效。

说到底,最终还是嫌疑人虽然克制但仍然漫溢的炫富欲望,变成了“此地有银三百两”的一声吆喝啊。

后续:所以又能怎么样呢?

在以上证据链形成后,调查人员和当事调查记者为了坐实猜疑,通过社交网络联系到了这个神龙见首不见尾的Nikolay K.。具体的试探消息我们不得而知,但是后者很快在社交媒体上撤回了他个人相关的信息:这将准星牢牢地套在了他的头上,但同时也不可避免地打草惊蛇了。

根据报告所述,这场调查持续了相当长的时间,据信至少在已经明确了目标的嫌疑之后,NikolayK.还在2020年内有过一次到土耳其的旅游,但出于未知原因,德国警方却并没有从土耳其将其引渡逮捕。至今Nikolay K.仍然逍遥法外,虽然记者显然仍然等待他下一次旅行到与德国有引渡条例的国家,但这至今再也没有发生——特别是在REvil基础设施被攻破之后,这趟可以让当事人和警方都感到兴奋的旅行,可能再不会发生了。

墓志铭.jpg

上图是Nikolay K.在社交媒体上发布的照片,德国警方定位到他的位置是在土耳其的安塔利亚,虽然德国和土耳其存在引渡条约,但是遗憾的是最终没能实现成功抓捕。这张照片同时也是Nikolay K.社交软件的Profile照片,当他嗅到被调查的风险后,他将所有照片一删而净。

尽管在本例事件中,调查人员几乎是像中彩票一般,关联到了这个本不可能被定位到的嫌疑人实人,但他的持续逍遥法外,仍然火辣辣地昭示着对于这种极端复杂的跨国网络空间犯罪中,对嫌疑人的逮捕是一件多么艰巨的挑战。预期中通过端掉勒索集团人员来根除祸患的结果没能出现,但我们仍然看到国际社会的一些合作与进展。根据10月21日路透社报道《EXCLUSIVEGovernments turn tables on ransomware gang REvil by pushing it offline》,在多方行动中,REvil组织的服务器基础设施遭到“反制”入侵和控制,勒索网站、支付渠道和服务被迫下线。这被官方与安全专家称为“标志性、毁灭性的行动”。但类似的反制行动在7月13日曾经成功实施过,当时该组织网站与支付渠道曾被迫下线;之后很快REvil就得以死灰复燃且更新迭代。对于这些以隐藏自身、不断更新为安身立命核心本领的犯罪对象,似乎在其人员落网或者赚的盆满钵满金盆洗手之前,反制与打击已经成了“杀不死他只会让他更强”的东西。

可以说,如今各国政府和安全行业与勒索组织之间的攻防,已经进入了无法速战速决的拉锯战态势,要打击收敛这个问题需要旷日持久的投入。直到决胜的方法和局面出现之前,我们仍然需要再三向所有依赖线上基础设施和资产的个人和企业用户进行明确:永远相信没有不能被攻破的系统,且你的系统不可能是其中最坚固的城池;只有采取任何可信的防护系统与机制、实时关注你的安全建设和最新安全态势,才能降低你成为下一个勒索软件受害者的“赔率”。

参考索引

文中援引德国时代周报网络版(ZEIT ONLINE)媒体原始报道,可参见:《Core member of ransomware gang identified》

一、背景

C/C++开发的应用程序,长久以来存在内存破坏类的安全问题。当攻击者掌握了目标程序的漏洞后,就可以开发漏洞利用程序劫持目标程序的控制流。早期的漏洞利用是采用代码注入的方式,通过在缓冲区置入一段代码(shellcode),然后控制pc寄存器跳入到缓冲执行这段代码。为了阻止此类攻击,后来计算机系统部署了DEP(Data Execution Prevention)机制,通过配置内存页属性,将缓冲区设置成不可执行,起到了很好的防御效果。为了绕过DEP,攻击者探索出了代码重用技术,在目标程序中搜索出一些攻击者期望的操作的代码片段,通过组织这些片段最终完成实现对目标机器的控制。这类攻击技术有Return-to-libc、ROP(Return OrientedProgramming)、JOP(Jump OrientedProgramming)等。如下图所示,代码有两条动态路径,在路径1存一个含有漏洞的节点。当攻击者通过漏洞修改这个节点的跳转逻辑,如果没有可靠的合法性验证机制,那么攻击者最终可以完全控制目标机器。

1.png

为了抵御上面的代码复用攻击,加州大学和微软公司于2005年提出了控制流完整性(Control-Flow-Integrity, CFI)的防御机制。Control-Flow-Integrity (CFI) 是一种确保软件必须在先前确定的控制流图上执行的安全策略。其核心思想就是在函数在发生不确定的跳转时,验证跳转的合法性。

CFI分为Forward Edges CFI和Backward Edges CFI。前者是在间接调用前验证控制流,而后者是在函数返回时验证返回地址是否属于调用者。下面罗列了Linux下相关实现,如下:

2.png

目前还有硬件实现的Backward CFI

* Intel CET 基于硬件的只读影子调用栈

* ARM V8.3a Pointer Authentication("signed return address")

二、struct sanitizer

我们通过分析一些常见的内核漏洞POC,发现这些POC对控制流的修改都集中在几种结构体内置函数指针的修改上。而上面的CFI的方案需要对所有代码进行插桩验证控制流,这样势必会带来明显的性能下降问题。所以我们提出了struct-sanitizer(struct_san)这种新的控制流完整性检测机制。

struct_san与上面的CFI方案相比,struct_san在对结构体指针的验证要比已有的CFI技术更严苛。当前主流的CFI技术主要是验证函数指针的类型,而struct_san在此基础上还要验证此函数指针是否还属于当前结构体实例。struct_san还可以做到非全量插桩,以减少一些非不必要的性能损耗。

三、实现原理

struct_san工作原理如下:

3.png

struct san 通过对在结构体里的函数调用前加入校验函数__sanitizer_struct_guard__(),来验证此函数指针是否属于当前结构体实例,如果验证合法则继续运行下面的间接调用函数,否则抛出ud2。

四、使用方法

struct_san为了避免非全量插桩,新增一个GNU Attributes __attribute__ ((sanitize_struct)) 。

使用方法是在想要保护的结构体类型声明处和调用此结构体的函数指针的函数前加入此关键字,例如想要保护内核中的pipe_buf_release()代码中的pipe_buf_operations->release()函数。

1.在结构体类型声明时加入此关键字

4.png

在类型声明完成以后,struct_san会将此类型的所有结构体实例保存到.sanitize_struct段内。

2.在需要保护的函数中也要加入上面的关键字。例如在pipe_buf_release()函数的声明和定义处加关键字,加入关键字后会在调用pipe_buf_operations->release()前插入校验函函数__sanitizer_struct_guard__()

下面是插桩前后在gcc的gimple IR中的不同表示:

5.png

插桩前

6.png

插桩后

五、检测算法

struct_san目前只在内核中完成了相关实现。其算法是在内核中开辟一个128M大小shadow memory用来保存结构体和结构指针的对应关系。__sanitizer_struct_guard__()在调用时会检测传入的struct和函数指针是否在shadow memory中,如果不在则抛出一个ud2异常,否则返回函数指针。实现方案如下:

7.png

这个算法参考了AddressSanitizer的实现,兼顾了效果和效率。

六、效果

以漏洞CVE-2021-22555的攻击代码为例,在启用struct_san的情况下,CFI阻断了攻击代码的执行,起到了有效的防御。

8.png

七、开源地址

我们对struct_san进行了开源,期望和业界一起探讨CFI技术的改进。后续我们也会推出一些其它的漏洞缓解技术。

https://github.com/YunDingLab/struct_sanitizer


一、背景

C/C++开发的应用程序,长久以来存在内存破坏类的安全问题。当攻击者掌握了目标程序的漏洞后,就可以开发漏洞利用程序劫持目标程序的控制流。早期的漏洞利用是采用代码注入的方式,通过在缓冲区置入一段代码(shellcode),然后控制pc寄存器跳入到缓冲执行这段代码。为了阻止此类攻击,后来计算机系统部署了DEP(Data Execution Prevention)机制,通过配置内存页属性,将缓冲区设置成不可执行,起到了很好的防御效果。为了绕过DEP,攻击者探索出了代码重用技术,在目标程序中搜索出一些攻击者期望的操作的代码片段,通过组织这些片段最终完成实现对目标机器的控制。这类攻击技术有Return-to-libc、ROP(Return OrientedProgramming)、JOP(Jump OrientedProgramming)等。如下图所示,代码有两条动态路径,在路径1存一个含有漏洞的节点。当攻击者通过漏洞修改这个节点的跳转逻辑,如果没有可靠的合法性验证机制,那么攻击者最终可以完全控制目标机器。

1.png

为了抵御上面的代码复用攻击,加州大学和微软公司于2005年提出了控制流完整性(Control-Flow-Integrity, CFI)的防御机制。Control-Flow-Integrity (CFI) 是一种确保软件必须在先前确定的控制流图上执行的安全策略。其核心思想就是在函数在发生不确定的跳转时,验证跳转的合法性。

CFI分为Forward Edges CFI和Backward Edges CFI。前者是在间接调用前验证控制流,而后者是在函数返回时验证返回地址是否属于调用者。下面罗列了Linux下相关实现,如下:

2.png

目前还有硬件实现的Backward CFI

* Intel CET 基于硬件的只读影子调用栈

* ARM V8.3a Pointer Authentication("signed return address")

二、struct sanitizer

我们通过分析一些常见的内核漏洞POC,发现这些POC对控制流的修改都集中在几种结构体内置函数指针的修改上。而上面的CFI的方案需要对所有代码进行插桩验证控制流,这样势必会带来明显的性能下降问题。所以我们提出了struct-sanitizer(struct_san)这种新的控制流完整性检测机制。

struct_san与上面的CFI方案相比,struct_san在对结构体指针的验证要比已有的CFI技术更严苛。当前主流的CFI技术主要是验证函数指针的类型,而struct_san在此基础上还要验证此函数指针是否还属于当前结构体实例。struct_san还可以做到非全量插桩,以减少一些非不必要的性能损耗。

三、实现原理

struct_san工作原理如下:

3.png

struct san 通过对在结构体里的函数调用前加入校验函数__sanitizer_struct_guard__(),来验证此函数指针是否属于当前结构体实例,如果验证合法则继续运行下面的间接调用函数,否则抛出ud2。

四、使用方法

struct_san为了避免非全量插桩,新增一个GNU Attributes __attribute__ ((sanitize_struct)) 。

使用方法是在想要保护的结构体类型声明处和调用此结构体的函数指针的函数前加入此关键字,例如想要保护内核中的pipe_buf_release()代码中的pipe_buf_operations->release()函数。

1.在结构体类型声明时加入此关键字

4.png

在类型声明完成以后,struct_san会将此类型的所有结构体实例保存到.sanitize_struct段内。

2.在需要保护的函数中也要加入上面的关键字。例如在pipe_buf_release()函数的声明和定义处加关键字,加入关键字后会在调用pipe_buf_operations->release()前插入校验函函数__sanitizer_struct_guard__()

下面是插桩前后在gcc的gimple IR中的不同表示:

5.png

插桩前

6.png

插桩后

五、检测算法

struct_san目前只在内核中完成了相关实现。其算法是在内核中开辟一个128M大小shadow memory用来保存结构体和结构指针的对应关系。__sanitizer_struct_guard__()在调用时会检测传入的struct和函数指针是否在shadow memory中,如果不在则抛出一个ud2异常,否则返回函数指针。实现方案如下:

7.png

这个算法参考了AddressSanitizer的实现,兼顾了效果和效率。

六、效果

以漏洞CVE-2021-22555的攻击代码为例,在启用struct_san的情况下,CFI阻断了攻击代码的执行,起到了有效的防御。

8.png

七、开源地址

我们对struct_san进行了开源,期望和业界一起探讨CFI技术的改进。后续我们也会推出一些其它的漏洞缓解技术。

https://github.com/YunDingLab/struct_sanitizer


前言

2021年4月,Kubernetes社区披露了一个编号为CVE-2020-8562的安全漏洞,授权用户可以通过此漏洞访问 Kubernetes 控制组件上的私有网络。

通过查阅此漏洞披露报告可发现,这个漏洞拥有较低的CVSS v3评分,其分值仅有2.2分,与以往披露的Kubernetes高危漏洞相比,这个拥有较低评分的漏洞极其容易被安全研究人员以及运维人员所忽视。但经过研发测试发现,在实际情况中,这个低风险的漏洞却拥有着不同于其风险等级的威胁:在与云上业务结合后,CVE-2020-8562漏洞将会为云厂商带来不可忽视的安全挑战。

在这篇文章中,云鼎实验室将为大家带来业内首个CVE-2020-8562漏洞分析报告,一同来看一下这个被忽视的低风险漏洞引发的“血案”。

CVE-2020-8555漏洞简述

Kubernetes为了缓解CVE-2020-8555等历史漏洞带来的安全问题,对APIServer Proxy请求进行域名解析以校验请求的IP地址是否处于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内,Kubernetes通过此方式禁止由用户触发的对Services,Pods,Nodes,StorageClass对象的内网Proxy访问权限。

但是在完成校验并通过校验之后,Kubernetes立即进行第二次域名解析,此次域名解析后并不再进行IP地址的校验,这将导致上述校验存在绕过问题,如果一个DNS服务器不断返回不同的非缓存解析请求,攻击者可以利用此方式绕过Kubernetes的API Server Proxy IP地址限制,并访问内网ControlPlane管控组件。
详细的漏洞细节可参见如下图Issue所示:
1.jpg
图 1 CVE-2020-8562漏洞细节

Issue地址如下:https://github.com/kubernetes/kubernetes/issues/101493

在正式开始介绍这个漏洞是如何对Kubernetes集群带来危害之前,我们先来看看这个漏洞中应用到主要攻击技巧:DNS重绑定攻击(DNS Rebinding)。

DNS重绑定攻击

DNS重绑定攻击技术的实现主要依赖于攻击者可将其自建的DNS服务器中DNS TTL配置为设置为0或者极小值。DNS TTL表示DNS记录的生存时间,数值越小, DNS记录在DNS服务器上缓冲的时间越小。

在攻击者将DNS TTL数值设置为一个极小值时,当受害目标第一次访问恶意域名时并发起域名解析请求时,恶意DNS服务器会返回一个ip地址A;当受害目标第二次发起域名解析请求时,却会得到ip地址B的解析结果。具体的原理,我们可以通过一道CTF题目,深入了解一下:

$dst = @$_GET['KR'];

$res = @parse_url($dst);

$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];

...

$dev_ip = "54.87.54.87";

if($ip === $dev_ip) {

    $content = file_get_contents($dst);
    
    echo $content;
    
}

这道CTF题目需要参赛者访问内网127.0.0.1地址并获取存储于其中的Flag。

从代码中可见,题目将会判断参赛者传入的域名解析后的ip,并仅允许访问54.87.54.87地址的内容。

如何绕过题目中的条件语句,利用到的就是DNS重绑定攻击技术。

从上文代码段可见,程序通过以下代码来执行第一次DNS解析以获取ip:

$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];

假设此时参赛者传入的域名为www.a.com,将会进行如下的解析:

2.jpg

图 2首次DNS解析流程

此时www.a.com域名解析出来的ip为54.87.54.87。

程序继续往下执行,执行到了如下代码块:

$dev_ip = "54.87.54.87";

if($ip === $dev_ip){}

此时ip参数为54.87.54.87,满足条件分支判断,程序执行进入if条件分支。

随后,程序执行到如下语句:

$content = file_get_contents($dst);

注意,此时file_get_contents方法内的参数为参赛者控制的域名dst,而非ip地址。

也就是说,程序执行file_get_contents方法时,需要获取此域名的ip地址解析。由于攻击者将DNS TTL设置的数值极其小,从程序第一次获取ip到执行file_get_contents方法处时,DNS缓存早已失效,CTF服务器此时需要重新发起域名解析请求以获取www.a.com的ip,此时参赛者修改DNS解析结果以完成DNS重绑定攻击,见下图:

3.jpg

图 3重绑定DNS解析

此时获取到的解析ip值为127.0.0.1,参赛者通过此方式绕过限制并访问127.0.0.1资源,实现重绑定攻击。

KuBernetes中DNS重绑定攻击的应用

Kubernetes为了防止用户对Services,Pods,Nodes,StorageClass对象的内网Proxy进行非法访问,采用了域名解析的方式解析并校验Proxy请求的IP地址是否位于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内。

Kubernetes通过此方式防止恶意内网资源的Proxy访问行为,但是Kubernetes在校验通过之后,会进行第二次域名解析,获取IP地址访问而不再进行IP地址的校验。

联想到上一章节的DNS重绑定攻击方式:攻击者可以控制DNS解析的IP地址,在第一次校验时返回一个合法值,随后在第二次获取IP地址时,返回一个本地链路或 localhost地址,详见下图:

4.jpg

图 4 Kubernetes中DNS重绑定流程

通过这个技术方式,攻击者可以绕过apiserver proxy的内网限制,构造恶意请求访问集群中的资源。

这种攻击技术将为云服务商带来了极大的安全问题:大多数云服务商提供Kubernetes托管版集群服务,采用此服务的用户Master节点将由云厂商创建并托管,如果攻击者通过方式访问到本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8)地址,则有可能访问同为托管模式下其他用户的apiserver。

CVE-2020-8562漏洞原理

首先,使用云厂商提供的Kubernetes托管版集群服务创建一个集群。在此场景下,我们创建的集群的Master节点将与其他采用托管服务的用户一并,由云厂商创建并托管管理,这为后续的利用提供了先决条件。

5.jpg

图 5 Kubernetes托管版集群服务

在集群创建完毕后,通过编写如下yaml来创建一个名为cve-2020-8562的node,见下图:

6.jpg

图 6 使用yaml创建node

通过上图可见,在此yaml中,将只能在集群内进行路由的节点的IP地址InternalIP设置为攻击者可控的www.attacker.com。

创建完毕后,可以通过kubectl get nodes查看到此节点:

7.jpg

图 7 通过kubetctl查看cve-2020-8562节点

从上图红框处可以发现,此时我们创建的cve-2020-8562节点的状态为NotReady,但即使此时cve-2020-8562节点的状态为NotReady,也并不影响后续的利用流程。

使用如下命令启动Kubernetes API 服务器的代理:

8.jpg

图 8 通过kebuectl开启代理

在成功启动Kubernetes API 服务器的代理之后,通过如下命令使用apiserver proxy来访问cve-2020-8562节点的apiserver:

9.jpg

图 9访问cve-2020-8562节点的apiserver

通过上文来看,cve-2020-8562节点处于NotReady,我们可以正常的访问其apiserver吗?

我们来看一下Kubernetes是如何完成接下来的访问:

首先,为了可以访问cve-2020-8562节点,Kubernetes首先需要获取cve-2020-8562节点的InternalIP,我们通过如下指令查看一下cve-2020-8562 的InternalIP:

10.jpg

图 10 查看cve-2020-8562节点详情

通过上图可知,cve-2020-8562节点的InternalIP值与生成此节点yaml中配置项一致,为我们配置的www.attacker.com。

由于InternalIP为域名而非IP地址,Kubernetes需要对其进行域名解析,随后校验获取到的IP地址是否位于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内,如果获取到的IP属于此范围,则禁止访问。

在第一次DNS解析时,攻击者自建的DNS服务器将会返回一个合法的IP地址(非本地链路或 localhost范围),例如172.x.x.x,流程见下图:

11.jpg

图 11 第一次DNS解析

通过此方式,可以绕过k8s的本地链路/localhost范围IP校验。

在通过安全校验之后,K8s将会发起第二次域名解析。由于攻击者将DNS TTL设置的数值极其小,此时DNS缓存已失效,k8s需要重新发起域名解析请求以获取www.attacker.com的ip地址,流程见下图:

12.jpg

图 12 DNS重绑定攻击

从上图可见,此时攻击者可以将 www.attacker.com域名的IP解析为一个localhost范围内的IP地址并返回,在此例中,我们返回一个127.x.x.x地址。

此时,k8s apiserver proxy访问情况可以类比于下图情况:

13.jpg

图 13当前访问可抽象成此情况

如果127.x.x.x这个节点的apiserver 存在未授权访问情况,我们就可以通过此方式直接访问其apiserver,见下图:

14.jpg

图 14 攻击者访问托管服务中Master

通过此方式,可以访问其他使用Kubernetes托管集群服务的租户的apiserver。

总结

在安全研究以及运维中,一些低风险的集群漏洞极其容易被安全以及运维人员所忽略,但是这些漏洞在一些特定场景中仍为云上安全带来了极大的安全挑战,正如本文中所举例的CVE-2020-8562安全漏洞,这个仅有2.2评分的Kubernetes安全漏洞,在与实际业务结合后,仍可为业务带来极大的安全风险。因此与云上安全相关的漏洞,无论严重与否,都应得到安全人员以及运维人员的相应重视。

参考链接

https://github.com/kubernetes/kubernetes/issues/101493

https://zhuanlan.zhihu.com/p/89426041

https://cloud.tencent.com/developer/article/1400018

前言

2021年4月,Kubernetes社区披露了一个编号为CVE-2020-8562的安全漏洞,授权用户可以通过此漏洞访问 Kubernetes 控制组件上的私有网络。

通过查阅此漏洞披露报告可发现,这个漏洞拥有较低的CVSS v3评分,其分值仅有2.2分,与以往披露的Kubernetes高危漏洞相比,这个拥有较低评分的漏洞极其容易被安全研究人员以及运维人员所忽视。但经过研发测试发现,在实际情况中,这个低风险的漏洞却拥有着不同于其风险等级的威胁:在与云上业务结合后,CVE-2020-8562漏洞将会为云厂商带来不可忽视的安全挑战。

在这篇文章中,云鼎实验室将为大家带来业内首个CVE-2020-8562漏洞分析报告,一同来看一下这个被忽视的低风险漏洞引发的“血案”。

CVE-2020-8555漏洞简述

Kubernetes为了缓解CVE-2020-8555等历史漏洞带来的安全问题,对APIServer Proxy请求进行域名解析以校验请求的IP地址是否处于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内,Kubernetes通过此方式禁止由用户触发的对Services,Pods,Nodes,StorageClass对象的内网Proxy访问权限。

但是在完成校验并通过校验之后,Kubernetes立即进行第二次域名解析,此次域名解析后并不再进行IP地址的校验,这将导致上述校验存在绕过问题,如果一个DNS服务器不断返回不同的非缓存解析请求,攻击者可以利用此方式绕过Kubernetes的API Server Proxy IP地址限制,并访问内网ControlPlane管控组件。
详细的漏洞细节可参见如下图Issue所示:
1.jpg
图 1 CVE-2020-8562漏洞细节

Issue地址如下:https://github.com/kubernetes/kubernetes/issues/101493

在正式开始介绍这个漏洞是如何对Kubernetes集群带来危害之前,我们先来看看这个漏洞中应用到主要攻击技巧:DNS重绑定攻击(DNS Rebinding)。

DNS重绑定攻击

DNS重绑定攻击技术的实现主要依赖于攻击者可将其自建的DNS服务器中DNS TTL配置为设置为0或者极小值。DNS TTL表示DNS记录的生存时间,数值越小, DNS记录在DNS服务器上缓冲的时间越小。

在攻击者将DNS TTL数值设置为一个极小值时,当受害目标第一次访问恶意域名时并发起域名解析请求时,恶意DNS服务器会返回一个ip地址A;当受害目标第二次发起域名解析请求时,却会得到ip地址B的解析结果。具体的原理,我们可以通过一道CTF题目,深入了解一下:

$dst = @$_GET['KR'];

$res = @parse_url($dst);

$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];

...

$dev_ip = "54.87.54.87";

if($ip === $dev_ip) {

    $content = file_get_contents($dst);
    
    echo $content;
    
}

这道CTF题目需要参赛者访问内网127.0.0.1地址并获取存储于其中的Flag。

从代码中可见,题目将会判断参赛者传入的域名解析后的ip,并仅允许访问54.87.54.87地址的内容。

如何绕过题目中的条件语句,利用到的就是DNS重绑定攻击技术。

从上文代码段可见,程序通过以下代码来执行第一次DNS解析以获取ip:

$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];

假设此时参赛者传入的域名为www.a.com,将会进行如下的解析:

2.jpg

图 2首次DNS解析流程

此时www.a.com域名解析出来的ip为54.87.54.87。

程序继续往下执行,执行到了如下代码块:

$dev_ip = "54.87.54.87";

if($ip === $dev_ip){}

此时ip参数为54.87.54.87,满足条件分支判断,程序执行进入if条件分支。

随后,程序执行到如下语句:

$content = file_get_contents($dst);

注意,此时file_get_contents方法内的参数为参赛者控制的域名dst,而非ip地址。

也就是说,程序执行file_get_contents方法时,需要获取此域名的ip地址解析。由于攻击者将DNS TTL设置的数值极其小,从程序第一次获取ip到执行file_get_contents方法处时,DNS缓存早已失效,CTF服务器此时需要重新发起域名解析请求以获取www.a.com的ip,此时参赛者修改DNS解析结果以完成DNS重绑定攻击,见下图:

3.jpg

图 3重绑定DNS解析

此时获取到的解析ip值为127.0.0.1,参赛者通过此方式绕过限制并访问127.0.0.1资源,实现重绑定攻击。

KuBernetes中DNS重绑定攻击的应用

Kubernetes为了防止用户对Services,Pods,Nodes,StorageClass对象的内网Proxy进行非法访问,采用了域名解析的方式解析并校验Proxy请求的IP地址是否位于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内。

Kubernetes通过此方式防止恶意内网资源的Proxy访问行为,但是Kubernetes在校验通过之后,会进行第二次域名解析,获取IP地址访问而不再进行IP地址的校验。

联想到上一章节的DNS重绑定攻击方式:攻击者可以控制DNS解析的IP地址,在第一次校验时返回一个合法值,随后在第二次获取IP地址时,返回一个本地链路或 localhost地址,详见下图:

4.jpg

图 4 Kubernetes中DNS重绑定流程

通过这个技术方式,攻击者可以绕过apiserver proxy的内网限制,构造恶意请求访问集群中的资源。

这种攻击技术将为云服务商带来了极大的安全问题:大多数云服务商提供Kubernetes托管版集群服务,采用此服务的用户Master节点将由云厂商创建并托管,如果攻击者通过方式访问到本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8)地址,则有可能访问同为托管模式下其他用户的apiserver。

CVE-2020-8562漏洞原理

首先,使用云厂商提供的Kubernetes托管版集群服务创建一个集群。在此场景下,我们创建的集群的Master节点将与其他采用托管服务的用户一并,由云厂商创建并托管管理,这为后续的利用提供了先决条件。

5.jpg

图 5 Kubernetes托管版集群服务

在集群创建完毕后,通过编写如下yaml来创建一个名为cve-2020-8562的node,见下图:

6.jpg

图 6 使用yaml创建node

通过上图可见,在此yaml中,将只能在集群内进行路由的节点的IP地址InternalIP设置为攻击者可控的www.attacker.com。

创建完毕后,可以通过kubectl get nodes查看到此节点:

7.jpg

图 7 通过kubetctl查看cve-2020-8562节点

从上图红框处可以发现,此时我们创建的cve-2020-8562节点的状态为NotReady,但即使此时cve-2020-8562节点的状态为NotReady,也并不影响后续的利用流程。

使用如下命令启动Kubernetes API 服务器的代理:

8.jpg

图 8 通过kebuectl开启代理

在成功启动Kubernetes API 服务器的代理之后,通过如下命令使用apiserver proxy来访问cve-2020-8562节点的apiserver:

9.jpg

图 9访问cve-2020-8562节点的apiserver

通过上文来看,cve-2020-8562节点处于NotReady,我们可以正常的访问其apiserver吗?

我们来看一下Kubernetes是如何完成接下来的访问:

首先,为了可以访问cve-2020-8562节点,Kubernetes首先需要获取cve-2020-8562节点的InternalIP,我们通过如下指令查看一下cve-2020-8562 的InternalIP:

10.jpg

图 10 查看cve-2020-8562节点详情

通过上图可知,cve-2020-8562节点的InternalIP值与生成此节点yaml中配置项一致,为我们配置的www.attacker.com。

由于InternalIP为域名而非IP地址,Kubernetes需要对其进行域名解析,随后校验获取到的IP地址是否位于本地链路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范围内,如果获取到的IP属于此范围,则禁止访问。

在第一次DNS解析时,攻击者自建的DNS服务器将会返回一个合法的IP地址(非本地链路或 localhost范围),例如172.x.x.x,流程见下图:

11.jpg

图 11 第一次DNS解析

通过此方式,可以绕过k8s的本地链路/localhost范围IP校验。

在通过安全校验之后,K8s将会发起第二次域名解析。由于攻击者将DNS TTL设置的数值极其小,此时DNS缓存已失效,k8s需要重新发起域名解析请求以获取www.attacker.com的ip地址,流程见下图:

12.jpg

图 12 DNS重绑定攻击

从上图可见,此时攻击者可以将 www.attacker.com域名的IP解析为一个localhost范围内的IP地址并返回,在此例中,我们返回一个127.x.x.x地址。

此时,k8s apiserver proxy访问情况可以类比于下图情况:

13.jpg

图 13当前访问可抽象成此情况

如果127.x.x.x这个节点的apiserver 存在未授权访问情况,我们就可以通过此方式直接访问其apiserver,见下图:

14.jpg

图 14 攻击者访问托管服务中Master

通过此方式,可以访问其他使用Kubernetes托管集群服务的租户的apiserver。

总结

在安全研究以及运维中,一些低风险的集群漏洞极其容易被安全以及运维人员所忽略,但是这些漏洞在一些特定场景中仍为云上安全带来了极大的安全挑战,正如本文中所举例的CVE-2020-8562安全漏洞,这个仅有2.2评分的Kubernetes安全漏洞,在与实际业务结合后,仍可为业务带来极大的安全风险。因此与云上安全相关的漏洞,无论严重与否,都应得到安全人员以及运维人员的相应重视。

参考链接

https://github.com/kubernetes/kubernetes/issues/101493

https://zhuanlan.zhihu.com/p/89426041

https://cloud.tencent.com/developer/article/1400018