微慑信息网

业界快讯 第2页

美国NIST发布首批四种抗量子密码算法

微慑管理员阅读(976)

美国国家标准与技术研究院(NIST)选择了第一批旨在抵御未来量子计算机攻击的加密算法,这些算法被设计成能够抵御未来量子计算机的攻击,这种攻击可能会破解用于保护隐私的密码安全,比如网上银行和电子邮件等软件。这四种选定的加密算法将成为NIST后量子加密标准的一部分,预计将在两年内最终确定。

美国商务部长Gina M. Raimondo表示,“今天的公告是保护我们敏感数据免受未来量子计算机网络攻击的一个重要里程碑,由于NIST的专业知识和对尖端技术的承诺,我们能够采取必要的步骤来确保电子信息的安全,这样美国企业可以继续创新,同时保持其客户的信任和信心。”

在此之前,NIST曾在2016年呼吁全球密码学家设计并审查加密方法,以抵御来自未来量子计算机的攻击,这种计算机比目前相对有限的计算机更强大,此次选择标志着后量子密码标准化项目最终阶段的开始。

加密算法的两种方式

加密算法设计用于两个主要方式:一般加密,用于保护通过公共网络交换的信息,还有数字签名,用于身份验证,这四种算法都是由多个国家和机构的专家合作创建的。

对于我们访问安全网站时使用的一般加密,NIST 选择了 CRYSTALS-Kyber 算法,优点之一是相对较小的加密密钥,双方可以轻松交换,以及它的运行速度。

对于数字签名,通常在我们需要在数字交易中验证身份或远程签署文件时使用,NIST选择了三种算法CRYSTALS-Dilithium、FALCON和SPHINCS+。NIST推荐CRYSTALS-Dilithium作为主要算法,FALCON用于需要比Dilithium提供的更小的签名的应用,第三种,SPHINCS+,比其他两种算法更大更慢,但它作为一种备用算法很有价值,主要原因是它基于一种与NIST其他三种选择不同的数学方法。

所选的三个算法基于一系列称为结构化格的数学问题,而SPHINCS+使用散列函数,仍在考虑中的另外四种算法是为一般加密而设计的,它们的方法中不使用结构化格或散列函数。

在标准制定过程中,NIST鼓励安全专家探索新的算法,并考虑他们的应用将如何使用这些算法,但目前还不能将其嵌入到他们的系统中,因为在标准最终确定之前,这些算法可能会有轻微的变化。

另外四种算法被考虑纳入标准

另外四种算法正在考虑纳入该标准,NIST计划在未来的某一天宣布该轮的最终结果,另外四种是:BIKE、Classic McEliece、HQC、SIKE,NIST分两个阶段宣布其选择,因为需要各种强大的防御工具,正如密码学家从NIST的工作之初就认识到的,有不同的系统和任务使用加密,一个有用的标准将提供针对不同情况设计的解决方案,使用不同的加密方法,并为每个使用情况提供一个以上的算法,以防一个算法被证明有漏洞。

“我们的后量子密码学项目充分利用了全世界密码学领域的顶尖人才,产生了这第一批抗量子算法,这将导致一个标准,并大大增加我们数字信息的安全性。” -NIST主任Laurie E. Locascio

加密技术利用数学来保护敏感的电子信息,包括我们浏览的安全网站和发送的电子邮件,广泛使用的公钥加密系统,所依赖的数学问题即使是速度最快的传统计算机也难以解决,这确保了这些网站和信息不会被不受欢迎的第三方访问。

然而,一台足够强大的量子计算机,它的技术将不同于我们今天拥有的传统计算机,可以快速解决这些数学问题,击败加密系统,为了应对这一威胁,四种抗量子算法依赖于传统计算机和量子计算机都难以解决的数学问题,从而保护现在和未来的隐私。

相关链接
[1].https://thequantuminsider.com/2022/07/05/nist-announces-first-four-quantum-resistant-cryptographic-algorithms/
[2].https://csrc.nist.gov/Projects/post-quantum-cryptography/round-4-submissions

end
————————————————
版权声明:本文为CSDN博主「云安全联盟大中华区」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/CCSA2018/article/details/125780486

NIST发布四种抗量子密码算法

微慑管理员阅读(888)

导读
近日,美国商务部国家标准与技术研究所(NIST)公布了首批四种抗量子加密算法,这是自2016年启动后量子密码标准化项目以来,NIST首次发布入围标准的抗量子算法。

抢占抗量子算法的标准阵地

抗量子算法旨在抵御未来量子计算机的攻击,后者能够破解我们今天所依赖的数字系统(量子霸权),例如网上银行和电子邮件软件。四种选定的加密算法将成为NIST后量子密码标准的一部分,预计将在大约两年内完成。

“NIST不断展望未来,以预测美国工业和整个社会的需求,并防御未来可能强大到足以破解当今加密信息的量子计算机对我们的信息系统构成的严重威胁,”NIST主任Laurie E. Locascio说道:“我们的后量子密码学计划利用全球密码学领域的顶尖人才来生产第一组抗量子算法,从中产生相关标准并显著提高我们数字信息的安全性。”

NIST正在考虑将另外四种算法纳入标准,并计划在未来宣布第二拨决赛入围者。由于需要多种强大的防御工具,NIST分两个阶段宣布获胜算法。NIST的密码学家一开始就认识到,对于不同的系统和加密任务,一个适用的标准需要为不同的应用场景提供不同的加密方案并为每个用例提供不止一种算法,以防止其中一种算法失效。

加密技术使用数学方法来保护敏感的电子信息,包括我们浏览的网站和发送的电子邮件。目前广泛使用的公钥加密系统采用的数学方法即使是最快的传统计算机也难以破解,但量子计算动摇了这种加密方法的基石。

一台功能足够强大的量子计算机将基于与我们今天拥有的传统计算机不同的技术,可以快速解决这些数学问题,击败加密系统。为了应对这种威胁,四种抗量子算法依赖于传统计算机和量子计算机都难以解决的数学问题,从而保护现在和未来的隐私。

首批抗量子算法的两大用途

首批入围NIST后量子加密标准的四种抗量子算法(Crystals-Kyber、CRYSTALS-DILITHIUM、FALCON、SPHINCS+)主要有两大用途:通用加密,用于保护通过公共网络交换的信息;数字签名,用于身份认证。NIST表示所有四种算法都是由来自多个国家和机构的专家合作开发的。

对于访问安全网站时使用的一般加密,NIST选择了CRYSTALS-Kyber算法。它的优点之一是相对较小的加密密钥,双方可以轻松交换,以及它的操作速度。

对于数字签名,通常在需要在数字交易期间验证身份或远程签署文档时使用,NIST选择了三种算法CRYSTALS-Dilithium、FALCON和SPHINCS+。NIST评审专家强调了前两者的高效率,NIST推荐CRYSTALS-Dilithium作为主要算法,FALCON用于需要比Dilithium提供的更小的签名的应用程序。

第三个算法SPHINCS+比其他两个更大且速度稍慢,但它作为备份算法很有价值,主要原因是:它选择了与NIST推荐的其他三个算法不同的数学方法。

其中三个选定的算法基于称为结构化格(structured lattices)的一系列数学问题,而SPHINCS+使用散列函数。仍在考虑的另外四种算法是为通用加密而设计的,并且在其方法中不使用结构化格或散列函数。

虽然后量子加密标准正在开发中,但NIST鼓励安全专家探索新算法并考虑他们的应用程序将如何使用它们,但不要着急将它们应用到系统中,因为在标准最终确定之前算法可能会略有变化。

为了做好进入后量子时代的准备,用户可以先清点系统中使用公钥密码的应用程序资产,这些公钥在量子计算机出现前夕面临更换。用户还可以提醒他们的IT部门和供应商即将发生的变化。要参与制定迁移到后量子密码的指南,请参阅NIST的国家网络安全卓越中心项目页面。

NIST在网站上提供了所有(候选)算法(https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/round-3-submissions)。

GitLab远程代码执行漏洞风险提示(CVE-2022-2884) -- vulsee.com

微慑管理员阅读(2301)

GitLab远程代码执行漏洞风险提示(CVE-2022-2884)


漏洞公告

近日,安恒信息CERT监测到GitLab官方发布了安全公告,修复了GitLab社区版(CE)和企业版(EE)中的一个远程代码执行漏洞(CVE-2022-2884),CVSS评分9.9,该漏洞允许经过身份验证的用户通过从GitHub API端点导入方式实现远程代码执行,成功利用此漏洞的攻击者可获得服务器权限。目前官方已发布安全版本,建议受影响的用户尽快采取安全措施。


参考链接:

https://about.gitlab.com/releases/2022/08/22/critical-security-release-gitlab-15-3-1-released/



影响范围


受影响版本:

GitLab CE/EE 15.3 版本:< 15.3.1

GitLab CE/EE 15.2 版本:< 15.2.3

GitLab CE/EE 15.1 版本:< 15.1.5


安全版本:

GitLab CE/EE 15.3.1

GitLab CE/EE 15.2.3

GitLab CE/EE 15.1.5



漏洞描述


GitLab是由GitLab Inc.开发,一款基于Git的完全集成的软件开发平台,且具有wiki和issue跟踪功能。使用Git作为代码管理工具,并在此基础上搭建起来的web服务。


GitLab远程代码执行漏洞(CVE-2022-2884):该漏洞允许经过身份验证的用户通过从GitHub API端点导入方式实现远程代码执行,成功利用此漏洞的攻击者可获得服务器权限。

细节是否公开 POC状态 EXP状态 在野利用
未知 未知 未知




缓解措施


高危:目前漏洞细节和测试代码暂未公开,但恶意攻击者可以通过补丁对比分析出漏洞触发点,建议受影响用户及时更新安全补丁。


处置建议:

1. 目前官方已发布安全版本修复上述漏洞,建议受影响的用户升级至安全版本。

下载地址:

https://about.gitlab.com/update/



安恒信息CERT

2022年8月

原文始发于微信公众号(安恒信息CERT):GitLab远程代码执行漏洞风险提示(CVE-2022-2884)

HW2022- 微步捕获Coremail邮件客户端0day攻击

微慑管理员阅读(3441)

图片

01 漏洞概况

近日,微步捕获到 Windows 版 Coremail 邮件客户端的 RCE(远程代码执行)漏洞在野利用,漏洞利用过程简单且稳定,攻击者可以通过执行任意代码完全控制受害者主机,危害巨大,影响范围较广,我们建议相关政企单位高度重视,并启动漏洞应急流程尽快升级修复,相关修复建议参考处置建议部分内容。

经分析验证,攻击者给受害者发送一封精心构建的邮件,当受害者用Coremail客户端打开邮件,即可自动运行邮件附件中的恶意可执行程序,全程不需要受害者点开任何邮件中的链接或附件,打开邮件即中招

漏洞复现:

图片
据Coremail官网介绍,Coremail 是国内拥有邮箱用户最多的邮件系统,已有超过20000家企业及政府机构、高校在使用。Coremail 邮件客户端是 Coremail 旗下的邮件客户端产品,可替代 Outlook 等邮件客户端产品。

在发现漏洞后,微步在线第一时间联系 Coremail 并协助修复,在本文发布之前,Coremail 已发布相应的修复补丁

VULSEE.COM

02 漏洞评估

 
受影响版本:Coremail Air 客户端3.0.5版本及以上,3.1.0.303(不含)以下版本

公开程度:已出现在野利用

利用条件:无权限要求

交互要求:1 Click

漏洞危害:高危、远程代码执行

03 处置建议

1、紧急临时缓解措施:

  • 暂停使用受此漏洞影响的 Coremail 客户端版本,如需使用,可临时改用网页版等其他平台客户端。

  • 如果企业部署了桌面管理系统,可以限制 Coremail 客户端执行包括exe、bat、ps1、vbs 等可执行文件/脚本。

  • 微步在线旗下的终端检测与响应平台 OneEDR 已支持检测及防护该漏洞。

2、官方修复方案:

Coremail 官方已经发布该漏洞相关修复补丁,我们建议尽快将 Window 版 Coremail 客户端更新至最新版。Coremail 官方提供的下载链接如下:
https://lunkr.cn/dl?p=pc
https://lunkr.cn/dl?p=mail&arch_type=win64.exe
‍‍

04 时间线

 
2022.07.25 微步在线捕获到漏洞在野利用

2022.07.26 微步在线分析确认并向相关厂商报告
2022.07.26 微步在线主机检测与响应平台 OneEDR 支持检测与防护相关漏洞
2022.07.26 厂商发布官方补丁通告
2022.07.26 微步情报局发布漏洞通告

VULSEE.COM

 

 

风险评估标准迎重大更新,7大变化安全从业者必知

微慑管理员阅读(1099)

风险评估标准迎重大更新,7大变化安全从业者必知


风险评估标准迎重大更新,7大变化安全从业者必知

一、何为信息安全风险评估?

通过运用科学方法和手段,系统地分析信息系统所面临的威胁及其存在的脆弱性,评估安全事件一旦发生可能造成的危害程度,提出有针对性的抵御威胁的防护对策和整改措施,防范和化解信息安全风险,将风险控制在可接受的水平,最大程度保障信息系统安全。

风险评估标准迎重大更新,7大变化安全从业者必知

二、标准修订背景

近年来我国越来越重视网络安全,颁布了《中华人民共和国网络安全法》、等保2.0标准体系、《关键信息基础设施保护条例》等一系列法律法规和政策标准,这些法律法规、政策标准中均提到了网络运营者要定期进行风险评估工作,以提高业务系统抵御安全风险的能力。

GB/T 20984-2007《信息安全技术 信息安全风险评估规范》(以下简称“原标准”)作为我国开展风险评估工作的主要依据已颁发15年之久,这15年,国际国内网络安全形势不断变化,技术发展日新月异,原标准的应用也越发显得局限。终于,GB/T 20984-2022《信息安全技术 信息安全风险评估方法》(以下简称“新标准”)在2022年4月份正式发布,于2022年11月1日正式实施,全面代替原标准,指导新形势下的信息安全风险评估工作。

风险评估标准迎重大更新,7大变化安全从业者必知

三、标准适用范围

本文件主要适用于各类组织(如:国家网络安全主管部门、行业监管机构、各重要行业网络安全保障单位、第三方网络安全检测评估机构、安全服务厂商等、各企业单位)开展信息安全风险评估工作,内容包含信息安全风险评估基本概念、风险要素关系、风险分析原理、风险评估实施流程和评估方法、风险评估在信息系统生命周期不同阶段的实施要点和工作形式。

风险评估标准迎重大更新,7大变化安全从业者必知

四、主要变化内容

01

标准名称变化

  • 内容变化

由原来GB/T 20984-2007《信息安全技术 信息安全风险评估规范》修改为GB/T 20984-2022《信息安全技术 信息安全风险评估方法》

  • 解读说明

原标准采用“规范”命名,指明的是进行风险评估活动所遵循的标准;新标准采用“方法”命名,说明的是为了达到风险评估的目的而采取的方式方法,有着更为现实的指导意义。

02

相关术语和定义变化

新标准删除了2007原版标准中“业务战略”“资产”“资产价值”“可用性”“保密性”“信息系统”“完整性”“残余风险”“安全事件”“威胁”和“脆弱性”的相关术语和定义。

03

风险基本要素关系图变化

  • 关键内容变化

新标准中简化了风险评估过程中的基本要素关系图,没有在图中体现业务战略、安全事件、残余风险、安全需求、资产价值的相关属性。


风险评估标准迎重大更新,7大变化安全从业者必知

图1 原标准(左图)-新标准(右图)风险评估基本要素变化图


  • 解读说明

新标准整体上和原标准一样都是围绕资产、脆弱性、威胁、安全措施进行风险评估工作的开展,但从上图可以看出,原标准的基本要素图更为复杂,不同风险评估执行者势必会有不同的理解,从而在风险评估执行过程中会存在这样那样的差异。

相比而言,新标准的基本要素关系图更为简洁,风险评估者更加容易理解,不会产生不同的解读,具有更明确的指导意义和价值。

04

风险评估实施流程变化

  • 关键内容变化

原标准中实施流程主要包括:风险评估准备、资产识别、威胁识别、脆弱性识别、已有安全措施确认、风险分析六个方面。

新标准中实施流程包括:评估准备、风险识别、风险分析、风险评价四个方面。

风险评估标准迎重大更新,7大变化安全从业者必知

图2 原标准(左图)-新标准(右图)风险评估实施流程对比


  • 解读说明

虽然新标准在实施流程上简化了2个环节,但并未真正删除,而是将资产识别、威胁识别、已有安全措施识别和脆弱性识别汇总为风险识别,同时,根据实际风险评估实施逻辑,将资产识别前置,并作为风险评估过程中的核心环节。

组织在开展风险评估工作时,前期风险评估准备、评估过程以及后续的文档记录等工作与原标准大体相仿,但是在资产识别和风险分析过程中有重大变化,分别加入了业务识别和业务风险值计算内容,需在风险评估工作中重点注意,下文也会对具体变化内容进行解读。

05

资产识别变化

  • 关键内容变化

原标准中,通过资产不同的表现形式将资产分类为:数据、软件、硬件、服务、人员、其他(企业形象、客户关系)等。强调由评估者根据具体的评估对象和要求,灵活把握。

新标准中,将资产按照层次分为业务资产、系统资产、系统组件和单元资产,要求评估者进行资产识别时从这三个方面进行。如图3所示:


风险评估标准迎重大更新,7大变化安全从业者必知

图3 GB/T 20984-2022《信息安全技术 信息安全风险评估方法》资产层次图


  • 解读说明

资产是业务系统的载体,而业务系统的安全稳定运行是企业组织的重中之重,风险评估的最终目标也是保障业务系统 。因此新标准中完善了风险识别的方法,新增加业务识别要求。强调业务在组织发展过程中的重要性,将业务识别视为风险评估的关键环节,要求在业务内容识别过程中应包括业务的属性、定位、完整性和关联性识别四个方面。


风险评估标准迎重大更新,7大变化安全从业者必知

表格1 业务识别内容表

业务识别的另外一个重要环节是对业务的重要性进行赋值,在企业的业务规划中重要性更高的业务系统赋值更高,同时因为业务系统相互之间存在关联关系,若被评估业务与高于其重要性赋值的业务具有紧密关联关系,则被评估业务的重要性赋值在原赋值基础上要进行调整。 

风险评估标准迎重大更新,7大变化安全从业者必知

表格2 业务重要性赋值表 


06

风险分析及风险评价

  • 关键内容变化

原标准中根据安全事件发生的可能性以及安全事件出现后的损失,计算安全事件一旦发生对组织的影响,即风险值。

新标准中,将风险值分为了资产风险值和业务风险值两个,资产风险值与原标准保持一致,新增根据业务所涵盖的系统资产风险综合计算得出业务风险值。

  • 解读说明

同样,基于业务系统在企业组织中的重要性,在风险评价方面,新标准中同步新增业务风险评价,要求在进行业务风险评价时,从社会影响和组织影响两个层面进行分析。社会影响方面参照等级保护标准中受侵害客体,涵盖国家安全,社会秩序,公共利益,公民、法人和其他组织的合法权益等方面;组织影响主要考虑业务系统一旦受到攻击对企业组织造成的影响,涵盖职能履行、业务开展、触犯国家法律法规、财产损失等方面。表格2所示为基于后果的业务风险等级划分方法。

风险评估标准迎重大更新,7大变化安全从业者必知

表格3 业务风险等级划分表


在风险值计算方面,新标准突破了原标准只计算资产风险值的局限,从业务角度出发,业务系统是由多个资产所承载,那业务风险值计算则是由其所涵盖的所有系统资产风险综合计算得出,其计算方式如下:

业务风险值=Rb[系统资产风险值,系统资产风险值,…,系统资产风险值]=Rb(RA_1,RA_2,…,RA_n)。


其中,Rb表示业务风险计算函数;RA_1,RA_2,…,RA_n表示业务所涵盖系统资产的风险值。 


07

资料性附录变化

新标准中给出了评估对象生命周期各阶段的风险评估方法,风险评估的工作形式,风险评估的工具,资产识别、威胁识别和风险计算示例。可帮助评估者在风评过程中对信息安全风评把握更加准确和细化。

风险评估标准迎重大更新,7大变化安全从业者必知

表格4 原标准和新标准资料性附录差异化对比


风险评估标准迎重大更新,7大变化安全从业者必知

五、对企业安全建设的指导意义

原标准风险评估主要关注资产维度,新标准风险评估过程中在资产维度的基础上更为关注业务系统的安全风险,新增了业务识别部分并且要根据业务所涵盖的系统资产风险值综合计算得出业务风险值,更能真实的反应出企业用户面临的安全风险,这对企业用户的业务系统安全风险评估和建设整改更有现实指导意义。

1、资产脆弱性凸显,设备入网安全检测势在必行
资产的脆弱性一定会影响业务系统的安全运行。仅在OT领域,2021年业界共检测发布了20175个新漏洞,创下年度新增漏洞数量新高。比漏洞增长更可怕的是攻击者正加快漏洞利用的速度。2021年发布的168个漏洞在12个月内被迅速利用,这意味着攻击者和恶意软件开发人员在漏洞武器化方面做得越来越好。

提前发现并解决设备漏洞是企业解决业务系统安全风险的根本途径。在设备入网前采用已知漏洞发现和未知漏洞挖掘专用工具进行安全检测,尽可能发现并敦促设备厂家修复设备漏洞,从根本上提升设备自身安全属性,行之有效的解决设备脆弱性带来的安全风险。

2、安全威胁众多,主动防御体系建设迫在眉睫
现今网络安全形势复杂,勒索病毒泛滥且变种繁多,攻击工具容易获取同时不需要太高的技术水平即可使用,导致企业面对的安全威胁与日俱增。国内外众多大型企业发生的安全事件无不在说明单点式、被动的防御措施难以达到应有的防护效果,企业应从主动防御、动态防御、体系化防御等方面着手,形成企业安全综合防护能力,全天候全方位监测业务系统安全状况,构建贴合企业业务系统实际防护需求的一体化主动防御体系。

风险评估标准迎重大更新,7大变化安全从业者必知

六、结语

威努特作为中国工控安全领军企业,多年深耕工控行业,深刻了解工控领域各行业业务系统,拥有信息安全领域最全资质和覆盖全国的专业安全服务团队,以自主研发的全系列工控安全产品为基础,为电力、轨道交通、石油石化、市政、烟草、智能制造、军工等国家重要行业用户提供咨询、评估、设计、建设、运维、废弃、培训、应急服务8个维度的全生命周期安全服务。


风险评估标准迎重大更新,7大变化安全从业者必知

图4 威努特安全服务包含内容






需要GB/T 20984-2022《信息安全技术 信息安全风险评估方法》和GB/T 20984-2007《信息安全技术 信息安全风险评估规范》相关标准,后台回复“风险评估”即可下载。





风险评估标准迎重大更新,7大变化安全从业者必知
威努特简介
风险评估标准迎重大更新,7大变化安全从业者必知

北京威努特技术有限公司(简称:威努特)是国内工控安全行业领军者,是中国国有资本风险投资基金旗下企业。凭借卓越的技术创新能力成为全球六家荣获国际自动化协会ISASecure 认证企业之一和首批国家级专精特新“小巨人”企业。

威努特依托率先独创的工业网络“白环境”核心技术理念,以自主研发的全系列工控安全产品为基础,为电力、轨道交通、石油石化、市政、烟草、智能制造、军工等国家重要行业用户提供全生命周期纵深防御解决方案和专业化的安全服务,迄今已为国内及“一带一路”沿线国家的4000多家行业客户实现了业务安全合规运行。

作为中国工控安全国家队,威努特积极推动产业集群建设构建生态圈发展,牵头和参与工控安全领域国家、行业标准制定和重大活动网络安全保障工作,始终以保护我国关键信息基础设施网络空间安全为己任,致力成为建设网络强国的中坚力量!

风险评估标准迎重大更新,7大变化安全从业者必知


风险评估标准迎重大更新,7大变化安全从业者必知
风险评估标准迎重大更新,7大变化安全从业者必知
风险评估标准迎重大更新,7大变化安全从业者必知
风险评估标准迎重大更新,7大变化安全从业者必知
渠道合作咨询   陈女士 15611262709
稿件合作   微信:shushu12121

原文始发于微信公众号(威努特工控安全):风险评估标准迎重大更新,7大变化安全从业者必知

如何应对车联网网络和数据安全检查

微慑管理员阅读(1060)

近日,上海市通信管理局下发《关于开展车联网网络和数据安全专项检查的通知》(下文简称《通知》)。为了指导集团车联网企业做好网络和数据安全自查工作及车联网网络安全攻防演练相关准备,上汽集团网络安全应急响应中心(SAIC-SRC)于6月17日举行了专场霄享·网络安全技术沙龙(第四期),协同平台成员企业的30余人应邀参加。


本期沙龙以【车联网企业网络安全攻防】为主题,分别就“红蓝演练中的攻击方技战法分析和防御方对抗技术”、“2022年车联网网络和数据安全专项检查——企业工作要点”“企业攻防安全产品部署最佳实践”三个话题展开分享与交流。


  • 腾讯安全资深专家田立,结合自身多年红蓝实战演练经验,介绍了“知攻”方能“善守”的技战法应对思路,对红蓝演练中的攻击方技战法和防御方对抗技术进行分析,用真实案例形象地展现了红蓝双方的对抗。


【霄享·沙龙】第4期:如何应对车联网网络和数据安全检查


  • SAIC-SRC安全运营专家魏敏敏分享了《2022年车联网网络和数据安全专项检查——企业工作要点》,解读了《通知》要求,互联网暴露面梳理、防护评估加固、安全专项排查、特权账号管控等重点内容,为企业自查和红蓝演练提供了切实的建议。

【霄享·沙龙】第4期:如何应对车联网网络和数据安全检查


  • 帆一云安全专家潘宇璇以《企业攻防安全产品部署最佳实践》为题,分享了帆一云的运营策略和红蓝经验,包括告警和规则运营、分析研判、溯源取证等,并结合业务和运营需求,介绍了帆一专项安全运维服务。

【霄享·沙龙】第4期:如何应对车联网网络和数据安全检查



霄享·网络安全技术沙龙作为与集团企业搭建网络安全技术培训与交流的平台,未来将持续聚焦行业高热度话题,围绕相关议题举办霄享·沙龙系列活动,分享网络安全实践经验与创新应用方案。欢迎大家积极参与话题讨论与后续相关活动!


原文始发于微信公众号(上汽集团网络安全应急响应中心):【霄享·沙龙】第4期:如何应对车联网网络和数据安全检查

【漏洞情报】Confluence OGNL表达式注入远程命令执行漏洞(CVE-2022-26134) -- vulsee.com

微慑管理员阅读(1215)

0x01  漏洞介绍


Confluence为团队提供一个协作环境。在这里,团队成员齐心协力,各擅其能,协同地编写文档和管理项目。从此打破不同团队、不同部门以及个人之间信息孤岛的僵局,Confluence真正实现了组织资源共享。通过某空间搜索引擎,可以得知,在互联网测,Confluence即有数十万个ip资产,使用面巨大。

【漏洞情报】Confluence OGNL表达式注入远程命令执行漏洞(CVE-2022-26134)

近日,锋刃科技从互联网监测到Confluence OGNL表达式注入远程命令执行漏洞。远程攻击者在无需任何授权的情况下,可以在远程通过注入OGNL表达式实现远程命令执行,从而接管服务器。漏洞评分为10分,漏洞等级为严重。


0x02  漏洞等级


洞等级:严重 | 10


0x03  影响范围


  • 1.3.0 <= Confluence Server and Data Center < 7.4.17

  • 7.13.0 <= Confluence Server and Data Center < 7.13.7

  • 7.14.0 <= Confluence Server and Data Center < 7.14.3

  • 7.15.0 <= Confluence Server and Data Center < 7.15.2

  • 7.16.0 <= Confluence Server and Data Center < 7.16.4

  • 7.17.0 <= Confluence Server and Data Center < 7.17.4

  • 7.18.0 <= Confluence Server and Data Center < 7.18.1

0x04  修复建议


1、建议升级到修复版本

官方建议用户升级至最新版本,以保证服务的安全性及稳定性。下载链接:https://www.atlassian.com/software/confluence/download-archives


2、临时修复建议

如果用户不便升级版本,可采用临时修复方法。该临时修复建议存在一定风险,建议用户可根据业务系统特性审慎选择采用临时修复方案:


Atlassian Confluence 7.15.0 – 7.18.0 的用户:

如果在集群内运行 Confluence 则需要在每个节点上重复以下过程:

1.关闭 Confluence

2.下载https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar

3.删除或者将 /confluence/WEB-INF/lib/xwork-1.0.3-atlassian-8.jar 移出 Confluence  安装目录

注:不要在目录中留下旧的  JAR  文件

4.将下载的 xwork-1.0.3-atlassian-10.jar 文件复制到 /confluence/WEB-INF/lib/ 目录中

5.检查新的 xwork-1.0.3-atlassian-10.jar 文件权限是否和所在目录的其他文件权限一致。

6.启动 Confluence


Confluence 7.0.0 – Confluence 7.14.2 的用户:

如果在集群内运行 Confluence 则需要在每个节点上重复以下过程:

1.关闭 Confluence

2.下载

https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar

https://packages.atlassian.com/maven-internal/opensymphony/webwork/2.1.5-atlassian-4/webwork-2.1.5-atlassian-4.jar

https://confluence.atlassian.com/doc/files/1130377146/1137639562/3/1654274890463/CachedConfigurationProvider.class

3.删除或者将 /confluence/WEB-INF/lib/xwork-1.0.3.6.jar

/confluence/WEB-INF/lib/webwork-2.1.5-atlassian-3.jar

移出 Confluence 安装目录

注:不要在目录中留下旧的  JAR  文件

4. 将下载的 xwork-1.0.3-atlassian-10.jar 文件复制到 /confluence/WEB-INF/lib/ 目录中

5.将下载的 webwork-2.1.5-atlassian-4.jar 文件复制到 /confluence/WEB-INF/lib/ 目录中

6.检查两个新文件权限是否和所在目录的其他文件权限一致。

7.切换到目 录/confluence/WEB-INF/classes/com/atlassian/confluence/setup

a.创建一个名为的新目录 webwork

b.将 CachedConfigurationProvider.class 复制到/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

c.确保 CachedConfigurationProvider.class 文件和/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork 目录权限正确

8.启动 Confluence


详细操作请参考官方:

https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html


0x05  漏洞复现



【漏洞情报】Confluence OGNL表达式注入远程命令执行漏洞(CVE-2022-26134)

0x06  参考链接


https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html

原文始发于微信公众号(锋刃科技):【漏洞情报】Confluence OGNL表达式注入远程命令执行漏洞(CVE-2022-26134)

Apache Struts2远程代码执行漏洞风险提示(CVE-2021-31805) -- vulsee.com

微慑管理员阅读(1612)

Apache Struts2远程代码执行漏洞风险提示(CVE-2021-31805)


漏洞公告

安恒信息CERT监测到国外安全研究员披露了Apache Struts的OGNL表达式注入漏洞(CVE-2021-31805)的攻击代码,攻击者可利用该漏洞从OGNL实现沙盒逃逸完成命令执行,目前Apache Struts官方已发布安全更新,建议使用该框架的用户尽快采取安全措施。

细节是否公开

POC状态

EXP状态

在野利用

已公开

已公开

未知


影响范围

受影响的产品版本:

Struts 2.0.0 – Struts 2.5.29


补丁情况:

Struts 2.5.30

https://struts.apache.org/download.cgi#struts2530



漏洞描述

Apache Struts< 2.5.30 存在OGNL表达式注入漏洞(CVE-2021-31805),如果开发人员使用%{…} 语法强制OGNL解析时,当对标签属性中未经验证的原始用户输入进行二次解析时,可能会导致远程代码执行,攻击者可利用该漏洞从OGNL实现沙盒逃逸完成命令执行。


安恒信息CERT已验证该漏洞的可利用性:

Apache Struts2远程代码执行漏洞风险提示(CVE-2021-31805)


缓解措施

严重:目前漏洞细节和利用代码已经公开,攻击者可利用该漏洞实现远程代码执行,目前官方已发布新版本修复了此漏洞,请受影响的用户尽快更新进行防护。


官方建议:

1、升级到 Struts 2.5.30或更高版本。官方已发布新版本修复此漏洞,下载链接:

https://struts.apache.org/download.cgi#struts-ga


漏洞自查方法

1、可通过排查struts-core-版本号.jar来判断是否受此漏洞影响,如果没有版本号可以在jar文件的META-INF/MANIFEST.MF中搜索Bundle-Version,如果struts-core < 2.5.30则存在该漏洞。

Apache Struts2远程代码执行漏洞风险提示(CVE-2021-31805)


产品侧防护方案

目前安恒信息的安全产品已经集成漏洞的检测和防护能力,可通过前往“安恒社区”下载对应产品的策略升级包进行升级。


1. AiLPHA大数据平台&AXDR平台

AiLPHA大数据和AXDR的流量探针默认支持对该漏洞的检测,无需进行升级。


2.明御APT攻击预警平台

明御APT攻击预警平台默认支持对该漏洞的检测,无需进行升级。


3.明御Web应用防火墙

明御Web应用防火墙3.0.4.3.3(含)以后系统版本,2022年以后的规则版本,默认支持对该漏洞的防护,请检查并升级至符合要求的系统版本、规则版本。


4. 明鉴漏洞扫描系统、明鉴Web应用漏洞扫描系统7.0

明鉴漏洞扫描系统、明鉴Web应用漏洞扫描系统7.0支持该漏洞的检测,检测策略同S2-061。


5.玄武盾websaas

玄武盾websaas已支持对该漏洞的检测和防护,策略同S2-061。

安恒信息CERT

2022年04月

原文始发于微信公众号(安恒信息CERT):Apache Struts2远程代码执行漏洞风险提示(CVE-2021-31805)

【漏洞预警】Spring框架远程命令执行漏洞 -- vulsee.com

微慑管理员阅读(1636)

【漏洞预警】Spring框架远程命令执行漏洞

漏洞名称:Spring框架远程命令执行漏洞

组件名称:Spring Framework

影响范围:

Spring Framework 5.3.x< 5.3.18

Spring Framework 5.2.x< 5.2.20

漏洞编号:CVE-2022-22965

漏洞类型:远程命令执行

利用条件:

1、使用Spring 框架以及衍生的框架

2、JDK>= 9.0

3、使用Apache Tomcat容器

4、存在spring-webmvc或spring-webflux依赖

综合评价:

<利用难度>:低

<威胁等级>:高危  能写入任意文件或执行命令获取服务器权限

#1 漏洞描述

Spring 是一款目前主流的 Java EE 轻量级开源框架,为JavaEE应用提供多方面的解决方案,用于简化企业级应用的开发。
近期锦行安全团队监测到Spring 框架存在远程命令执行漏洞,攻击者可利用该漏洞获取服务器控制权,目前漏洞相关利用poc/exp已经小范围公开,后续可能会造成大范围传播,造成严重危害。

#2 解决方案

目前,参照spring官方更新至安全版本(v5.3.18或v5.2.20),或者采用以下临时方案进行防护: 
1、新建全局类,调用dataBinder.setDisallowedFields方法添加黑名单:
@ControllerAdvice@Order(Ordered.LOWEST_PRECEDENCE)public class BinderControllerAdvice {    @InitBinder    public void setAllowedFields(WebDataBinder dataBinder) {         String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};         dataBinder.setDisallowedFields(denylist);    }}

2、使用waf防护设备,根据实际业务情况实现对“class.*”“Class.*”“*.class.*”“*.Class.*”等相关字符串的规则过滤
3、临时回滚jdk版本至9以下,并注意其他漏洞影响情况。

#3 参考资料

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
https://github.com/spring-projects/spring-framework/tags

 

 

 

原文始发于微信公众号(锦行信息安全):【漏洞预警】Spring框架远程命令执行漏洞

微慑信息网 专注工匠精神

微慑信息网-VulSee.com-关注前沿安全态势,聚合网络安全漏洞信息,分享安全文档案例

访问我们联系我们

登录

找回密码

注册