今年早些时候，我有幸参加了 LocoMocoSec 2024夏威夷安全会议，该会议的重点是产品安全。在这次会议上， Ron Perris （该会议的联合创始人和软件安全工程师）和我就漏洞的来源进行了讨论。这次讨论得出的结论是，安全问题的主要来源只有两个：软件缺陷和配置错误。
虽然我们都没有提出这个概念，但我们都认为这是一个非常有见地的角度。
这篇文章详细讨论了这一观点，解释了为什么会出现这种情况，得出了"左移"运动行不通的结论，并分享了对未来的展望。我非常感谢Ron在会议上和会后的精彩讨论，没有这些友好的头脑风暴和思想交流，这篇文章肯定无法完成。
漏洞是软件缺陷，即软件的编写方式没有执行预期的安全机制。例如，JSON Web 标记（JWTs）允许工程师在 JWT 标头中指定签名算法，如 RSA 或 HMAC。不过，有些实现也允许使用"空"算法，即不对令牌进行签名。如果应用程序接受 JWT 标头中指定的算法而不进行验证，攻击者就可以将算法设置为"空"，使令牌在没有签名的情况下看起来有效。为防止此漏洞，接收方应在其端执行预定义算法，忽略 JWT 标头中指定的算法。否则会陷入软件缺陷，导致安全事故。
我们经常看到的情况是，软件本身具有所有正确的设置，但有人错误配置，使入侵成为可能或极有可能。
例如，当 SSH 设置为允许所有用户使用基于密码的身份验证，而 root 帐户的密码为空时，就会出现常见的配置错误。这种组合允许任何人在不需要凭证的情况下以 root 身份登录，这是一个严重的安全风险。另一个常见的配置错误例子是 WiFi 接入点：一些制造商在出厂WiFi 接入点时进行了不安全的默认设置。例如，这些设备可能被默认设置为在公共网络上广播，以 root 权限运行，允许无限制访问而不需要密码。在这两种情况下，所有正确的设置都是存在的，但有人对它们进行了配置，使入侵极有可能发生。
区分这两者的一个简单方法就是看要如何修复相关漏洞。如果需要修改软件，那就是漏洞；如果需要更改设置，那就是配置错误。
为了说明安全问题有两个来源，即软件缺陷和配置错误，我们可以看看 MITRE ATT&CK 框架。
MITRE ATT&CK 是一个可在全球范围内访问的关于对手战术和技术的知识库，它试图让我们能够更加严谨地识别和描述对手为实现目标可能采取的步骤。它以矩阵的形式总结了相关知识，描述了对手为实现其目标而经历的高级阶段（侦察、资源开发、初始访问、执行、持久化等），以及他们在每个阶段会采用的战术。
可以说，最关键的阶段是访问目标系统。MITRE 将其称为 "初始访问"，并描述如下："初始访问包括使用各种进入路径在网络中获得初始立足点的技术。获得立足点的技术包括有针对性的鱼叉式网络钓鱼和利用面向公众的网络服务器的弱点。通过初始访问获得的立足点可能允许持久访问，如有效账户和使用外部远程服务，也可能由于更改密码而限制使用。
Image Source: MITRE ATT&CK
如果我们仔细研究一下坏人在组织内获得初始立足点的技术，就会很快发现，这些技术可能是由于软件缺陷或配置不当造成的：
-
内容注入。OWASP 对其解释如下 ："当应用程序不能正确处理用户提供的数据时，攻击者可以向网络应用程序提供内容（通常是通过参数值），并将这些内容反射给用户。这里的关键在于应用程序没有以应有的方式处理数据，这是一个软件缺陷。
-
偷渡式破坏。有多种方法 可以实现这种攻击。这只是因为浏览器中存在安全漏洞。
-
利用面向公众的应用程序。只有当面向公众的应用程序存在可利用的安全漏洞时，才有可能被利用。
-
外部远程服务。在这种情况下，要么是远程服务中存在错误，要么是配置不当，允许用户在本不应该登录的情况下登录，就像以前发生 VPN、Citrix 等工具一样。
-
硬件插件。尽管这种技术顾名思义依赖于硬件，但可以说，软件的编写方式应该是在未验证计算机附件、网络硬件或其他计算设备是否可信前不信任它们。因此，它仍然是一个导致可利用性的软件缺陷。
-
网络钓鱼。如果登录系统可以利用窃取的凭据进行入侵，则可以通过添加软件或配置来增加入侵难度或无法入侵。
-
通过可移动介质复制。这种技术可通过操作系统的错误配置实现。
-
供应链入侵。正如 MITRE 所解释的 ，"虽然供应链破坏可能会影响硬件或软件的任何组件，但希望获得执行权的对手通常会将重点放在软件分发或更新渠道中对合法软件的恶意添加上"。事实上，有时并没有控制措施来处理这些情况，这就是软件漏洞的一个明显例子。
-
信任关系。必须以信任某些人的方式对系统进行配置，而 "真正的零信任"（即使存在这种东西）可能很难实现。尽管如此，工具还是有的。问题是，我们经常看到一些错误的配置，在不应该信任的地方假定信任，而且很多软件的编写方式允许对手颠覆系统，让系统做它本不应该做的事情（错误）。
-
有效账户。这些通常是配置错误问题。例如，MITRE 指出："在某些情况下，对手可能会滥用非活动账户：例如，那些属于不再属于某个组织的个人的账户。有大量的工具可以帮助 IT 和安全团队解决这些问题，因此当问题仍然存在时，并不是因为缺乏解决方案。
由此可见，除非存在配置错误或软件漏洞，否则攻击者无法进入机器。而且，由于初始访问是他们采取所有其他行动（权限升级、横向移动、渗透等）的先决条件，因此消除软件缺陷和错误配置将使网络攻击变得不可能。
作为一个行业，我们为解决软件缺陷和配置错误问题做了很多尝试。到目前为止，我们还没有找到可行的解决方案。原因很简单--缺乏激励机制。
技术公司要投资安全领域，市场就必须对安全软件有需求。换句话说，市场必须奖励安全。到目前为止，似乎还没有出现这种情况。令人欣慰的是，不仅是安全问题，软件质量总体上也没有像我们希望的那样得到回报。性能、可维护性、可访问性以及高质量代码的其他属性并不会直接迫使客户支付更多的费用。
当我们意识到，与其投入大量资源来安全地构建软件，公司只需在其产品组合中添加安全产品，让客户支付更多费用，这就变得更加有趣了。在极端的例子中，市场不仅不会因为科技公司创建了不安全的代码而惩罚它们，反而会因为它们出售解决自己所制造的问题的方案而奖励它们。而且，由于问题的创造者通常比其他人更了解这些问题，因此他们也最有能力设计出比其他人更能解决这些问题的产品。
另一个值得一提的因素是，根本没有合适的时机来关注安全问题。当初创企业规模较小时，它需要专注于快速迭代和寻找产品与市场的契合点（而且没有客户，也没有有价值的知识产权，因此没有什么需要保护的）。如果成功了，就需要专注于扩大规模，这自然需要全神贯注。一旦公司上市，它就需要捍卫自己的估值，保持精简，并确保人均收入保持在较高水平，所以现在也不是增加更多安全人员的时候。不难看出，关注安全似乎永远没有合适的时机。
尽管安全行业一直在谈论 "左移"，但现实情况是，软件工程师在十年前没有任何动力去关注安全问题，而现在他们仍然没有任何理由去关注安全问题。激励机制的错位是 "左移 "运动失败的核心原因：软件工程师不会因为更安全地编写代码而获得更多报酬，也不会因为减少漏洞数量而获得晋升。
Jeremiah Grossman等业内资深人士早在十多年前就注意到了这一现实，而自那时以来，情况几乎没有发生任何变化。
Image Source: Jeremiah Grossman
安全从业人员也缺乏解决核心问题的动力。二三十年前，安全爱好者们试图做正确的事，从第一原则出发关注问题。随着曾经的业余爱好者空间发展成为最大的技术市场之一，现实也发生了变化。如今，有成千上万的厂商和数十万的安全从业人员，他们的生存依赖于安全问题的长期存在。这并不是说这些人不诚实：就个人而言，绝大多数安全从业人员都是以使命为导向、充满热情的人。但是，如果把他们作为一个整体来看待，他们肯定希望这个行业能够存在下去（没有人愿意被裁员，几十年的心血瞬间贬值）。
听起来似乎一切都很悲观，但事实并非如此。 我们有很多理由对整个行业持乐观态度，我们也有很多理由对解决软件缺陷和配置错误问题持乐观态度。重要的是，我们要继续测试我们的假设，做更多有效的事情，并停止做无效的事情。
解决软件缺陷问题的第一步是最终承认左移是行不通的（在不重新调整激励机制的情况下是行不通的，而这不会在短期内发生）。今年早些时候，规模最大、最知名的应用安全会议之一 OWASP Global 不得不取消他们的 DevDay 时，我们清楚地认识到，没有软件工程师是我们 "转移 "的对象。换句话说，如果我们无法在世界技术之都湾区找到足够多的有兴趣学习安全知识的软件工程师，那么是时候重新思考我们的一些核心假设了。
我们可以而且应该从一开始就注重设计的安全性。我们可以而且应该尽最大努力在软件开发生命周期的早期阶段解决漏洞问题。然而，我们也必须现实一点：如果今天我们把 100 名软件工程师和 100 名安全从业人员聚集在一个房间里，请能够安全地构建产品的人举手，可能最多只有 10 或 15 人举手。其余的人要么不会编程（不足以构建产品），要么不懂安全。
我们不能寄希望于每个开发人员都会学习安全知识并能够实施 XSS 防御、构建 Auth 系统或进行 JWT 验证。相反，我们应该让安全工程师构建安全默认设置，并使其易于采用。例如，早在 2013 年，Jason Chan 就 谈论了护栏和铺设道路的概念 - 我们现在终于开始讨论和采用这一概念，即使速度很慢。
好消息是，随着 Chainguard 和 Resourcely 等公司为安全违约铺平道路，厂商市场正在慢慢跟上步伐。
只有当安全专家专注于构建可提供安全默认值且难以滥用的系统时，我们才能在提高软件安全性方面取得进展。
Ron Perris 是一位长期从事软件安全工作的工程师，他对产品安全有着独到的见解。在他看来，应用安全是指发现单个错误并推动解决这些错误，无论是单个还是大规模的。而产品安全则是要消除整类错误，例如 React 在许多网站上消除了 XSS。这正是LocoMocoSec （他与他人共同创办的一个安全会议）的目的所在。
Image Source: Lukas Weichselbaum, LocoMocoSec keynote slides on "Google's Recipe for Scaling (Web) Security"
我们需要制定技术、标准和工具，以消除导致软件不安全的所有漏洞。
为了解决错误配置的问题，我们需要构建默认安全的软件。Chris Hughes 对 CISA 如何定义这一问题进行了 精彩总结 ：CISA 在讨论 "默认情况下的安全 "时强调了配置的作用。
CISA 甚至引入了一个新概念，他们称之为 "松动指南"，即组织在收到固有安全和加固的产品后，需要通过更改默认配置来松动产品，以防止恶意活动或使最终用户面临被利用和发生事故的风险，而不是为产品/服务/软件提供 "加固指南"。
我们都知道，在拥有产品后，需要应用 CIS 基准、DISA STIG、厂商指南等来加固产品/软件，以确保减少攻击面。
这种模式的转变将改变这种模式，使产品在到达时处于加固状态，并要求客户将其回滚，或放松加固配置以满足其需求。这当然会在用户体验方面造成摩擦，因为用户认为有必要对产品进行定制，使其完全符合企业的需要或要求，即使其中某些功能可能不符合安全的最佳利益。
例如，在考虑云计算时，我想到的一个最显著的 "默认安全 "实例就是 AWS 简单存储服务（S3）。由于 AWS S3 存储桶的公开暴露，我们看到了多起备受瞩目、影响广泛的安全事件，这些事件往往会暴露敏感数据"。
我们不能寄希望于培训全球数百万人和组织如何安全地配置软件；软件厂商应该承担起责任，从第一天起就对产品进行加固。
虽然安全漏洞确实只有两个主要来源，但实际上有三个主要攻击载体。除了软件缺陷和配置错误，安全问题的一大来源是社会工程学。这个话题过于宽泛，无法在本篇文章中讨论，但我以前曾撰文讨论过其中的一些方面：安全意识培训，压根没用（https://mp.weixin.qq.com/s/rc_420i4yVwEN-ACJ6RlLg）。
https://ventureinsecurity.net/p/there-are-only-two-sources-of-security
原文始发于微信公众号（安全喵喵站）：安全问题，只有两个来源
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/3531814.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论