渗透测试您的AWS环境-CTO指南

哈客cc lv.2

发布时间：2022-02-28 08:56:56 771

外部基础设施

好消息是，默认情况下，AWS会尽力帮助您保持安全。例如，默认安全组不允许您的EC2实例接收来自外部世界的通信，除非您通过添加其他规则来主动指定。

也就是说，如果你不小心的话，AWS仍然允许你用很多绳子来吊死自己。工程团队更改安全组以允许所有入站访问等经典错误仍然是一个问题，而DevOps的性质意味着服务可以定期上下波动，而不是总是在团队经理知道的情况下。

尽管如此，对于黑客来说，没有比在你面向互联网的基础设施中发现一个简单的安全漏洞更容易的方法了，无论是暴露的数据库还是具有已知漏洞的软件。攻击者以最小的努力获得最大的回报，因此发生这种情况的可能性最高—；因此，它应该是您要修复的第一个调用端口。

由于这些系统的动态特性和环境的持续变化，每天都会有新的漏洞发布，因此保持云漏洞管理的领先地位可能是一个挑战。然而，入侵者等现代漏洞扫描解决方案是根据您的云环境定制的。在运行渗透测试之前，您应该考虑使用这些工具中的一种，因为它们有助于在自动扫描中不断地管理基础设施中的漏洞。

入侵者可以同步主要云提供商的目标，并在使用CloudBot功能将新系统添加到云帐户时保持目标同步。这确保了在未来的漏洞扫描中包括新系统。

由于它是最容易暴露的攻击面，您可能不想将外部基础设施从任何pen测试的范围中移除。尽管如此，如果可能的话，你不应该把很大一部分预算分配给它，也不要期望看到很多超出你从漏洞扫描工具中预期的结果。

Web应用程序

许多公司使用AWS为客户、员工或合作伙伴托管web应用程序。不幸的是，web应用程序本质上是公开的，如果它们没有安全地开发，则会给攻击者提供进入系统的第二种最简单的方法。这使它们成为仅次于外部基础设施的第二个最重要的攻击面。

此类攻击的例子包括2021的Kasya事件，攻击者成功地将Kasya和分布式勒索软件在供应链攻击中向其客户妥协。右翼社交媒体网站GAB在2021年初也受到了损害，由于SQL注入漏洞，70GB的敏感用户数据泄露。再往回看，著名的TalkTalk黑客，一位17岁的客户设法进入了他们的客户数据库，并提取了数百万条记录。

始终考虑攻击和攻击的可能性在这一层。无论您的应用程序是完全可供公众访问，还是仅限于有限的一组客户，都应该考虑到您的决策。例如，具有“免费试用”的应用程序将允许攻击者注册并开始尝试。为付费客户/合作伙伴提供的B2B服务的威胁程度可能较低，但仍不可忽略，员工的应用程序也较低。另一方面，一些应用程序包含敏感信息，其影响可能严重超过其可能性。

因此，根据应用程序的风险状况，您可能会发现，如果您只负担得起渗透测试人员几天的工作，那么这很可能是您应该花时间的地方。虽然存在用于此类测试的自动化工具，可以有助于弥补渗透测试之间的差距，但当今市场上的任何东西都无法取代能够理解应用程序的业务逻辑并寻找影响应用程序的方法的人工测试人员的素质。

入侵者使用一种独特的算法来优先处理让你的系统暴露在外的问题，从而特别容易找到风险最高的问题。

内部基础设施

下一层攻击是构建应用程序的基础设施。在屏蔽了外部基础设施之后，只有在攻击者以某种方式突破了您的防御时，才能访问内部。因此，这里的威胁概况是前两个的次要部分。

对数据中心或企业网络的老派渗透测试通常围绕着获得立足点，然后从一个系统“转向”到另一个系统，最终导致管理员帐户或关键系统全面受损。这里是AWS环境不同于传统渗透测试的地方，因为AWS网络的软件定义特性通常意味着网络之间保持更严格的控制，而横向移动是一个挑战。例如，默认的“启动向导-#”安全组不允许EC2实例相互通信，除非您通过将它们添加到VPC或添加其他规则来主动指定。然而，除了最简单的AWS帐户之外，其他所有帐户都可以通过这种简单的配置获得成功。此外，如2019年的Capital One漏洞所示，攻击者可以破坏IAM角色凭据并使用这些凭据访问资源。

此外，AWS中内置的访问和安全控制意味着您不太可能通过任何EC2实例创建危害环境的“管理员”帐户。相反，更可能的情况是，您使用的是AWS特权帐户，因此，AWS配置审查可以比“内部”基础设施测试增加更多的价值。

类似地，虽然内部系统上未修补的软件和不安全的服务可能是一个问题，但这取决于您在AWS环境中创建了多大程度的专用网络，以及哪些系统可以访问其他系统。如果您在本地网络和云环境之间有一个点对点VPN，也值得了解。如果您这样做了，内部渗透测试可能适合于查明攻击者是否能够弥合这两个网络之间的鸿沟。

你的复杂性越高，内部渗透测试可能增加的价值就越大。例如，假设您运行的每个EC2都有自己的安全组，或者使用AWS的一些共享/托管服务（如lambda函数）——您可能希望跳过传统的“内部”渗透测试，而不是考虑配置检查。

AWS配置

如前所述，开箱即用的AWS在安全方面为您做了很多事情，但是AWS配置检查可以告诉您是否以一种可靠的方式设置了东西。

AWS配置不佳的典型例子是经常听到的暴露的S3存储桶，或者缺乏访问AWS控制台的多因素身份验证。但是，它也可能包括管理员帐户这样的内容，有太多的用户能够访问这些帐户，或者更复杂的IAM规则，比如只读访问策略如何允许攻击者在您的环境中获得额外的权限。

再一次，这通常会演变为付钱给某人，让他告诉你你已经知道的（或者很容易发现的）。在你进行渗透测试之前，试一下一些免费的工具（快速的谷歌会提供多种选择）。方法可能是一样的，你可能已经有了问题的答案。

如果您对安全利害关系没有信心，或者出于合规性原因需要第三方审计，那么与入侵者等网络安全专家联系，了解他们可以如何提供帮助是很有价值的。

机密管理

机密管理是指人员和应用程序如何存储和使用机密，如访问令牌。它在我们的清单的底部，但它影响到前面的所有领域，值得考虑。AWS配置审查应包括并告知用户和服务如何访问AWS环境，以及如何与AWS环境交互，包括分配给这些用户和服务的权限。然而，此配置审查可能只能评估AWS帐户中的配置，这意味着过程中的机密管理可能会被忽略。

您的团队使用持续集成还是持续部署（CI/CD）？如果确实如此，那么在CI/CD过程中使用的管道很可能会在一定程度上集成到AWS环境中。例如，他们可能必须启动新的EC2实例或部署新的lambda。与您的环境集成的内部应用程序或服务如何存储机密？你的管理人员如何保守秘密？

如果攻击者能够访问这些机密，他们将能够访问您的AWS环境，并能够在清除内部网络后升级权限或保持对云环境的访问。

因此，当您考虑对AWS环境进行渗透测试时，您可能有兴趣将其他集成系统的配置包括在测试范围内。或者，您可以将流程拆分为多个工具/评估，以关注各个风险领域。AWS配置审查将让您了解有多少东西使用访问密钥和AWS API连接到您的AWS环境。

结论

AWS中的渗透测试应谨慎对待，因为很容易在错误的地方花费时间和金钱。AWS是一个庞大的生态系统，很难在一个时间点评估中涵盖所有不断增加的服务，尤其是如果你有一个重要的AWS存在的话。明智地使用自动化应该总是在昂贵的咨询时间之前，当需要这些时间时，它们应该总是以最具成本效益的方式使用。你可能会发现最具成本效益的方法是混合方法；您可以访问您的AWS配置，它可以通知并指导对您的整个AWS财产进行手动审查。

入侵者漏洞扫描器

入侵者是一个基于云的漏洞扫描平台，用于检查AWS环境中的已知漏洞，以减少攻击面。

特别声明：以上内容（图片及文字）均为互联网收集或者用户上传发布，本站仅提供信息存储服务！如有侵权或有涉及法律问题请联系我们。