在草稿里躺了有些日子了，不躺了，恢复更新

[BugBountyTips]如何挖掘Gitlab漏洞

https://twitter.com/joaxcar/status/1567617283215720449

1. 作者是如何在短时间内发现多个Gitlab漏洞的思路

3. Step1. 最简单的方法是寻找最新的安全版本。看看其他人现在发现了什么，通常有更多的相同类型的bug存在；
4. Step2. 在15.3.2中有5个DOS错误，都是中等严重程度。最近，几乎每一个GitLab安全版本中都出现了这样的DOS bug。它们很容易复制，而且可以静态和动态地寻找它们；
5. Step3. 转到GitLab问题跟踪器，搜索旧的DOS安全问题。然后在docker容器中安装任何有漏洞的版本复制一些问题；
6. Step4. 现在想想这些问题是如何解决的，又是什么导致了这些问题。并阅读它们是如何被缓解的。试着看看你是否能在修复中找到一个漏洞，或者是否有任何东西可以指向其他脆弱的地方；
7. Step5. 如果你遵循这些步骤，你会学到很多关于安全、DOS问题、GitLab、设置环境和复现漏洞的知识。你也很有可能在GitLab中找到你的第一个bug；
8. Step6. 关键是要找到一个可以专注的领域，然后去寻找。

[CloudSec]在AWS、Azure、GCP 和 Kubernetes 上的 7 个云攻击路径

https://blog.lightspin.io/the-2022-top-7-cloud-attack-paths

1. 攻击者利用公共工作负载中的漏洞并在云环境中获得初步立足点；

2. 访问私有工作负载使已经在云环境中初步立足的攻击者或授权员工成为云环境中的管理员成为可能；

3. 在工作负载上发现的明文云凭证；

4. 实体的不良信息，如用户、角色、组等不完善的安全控制和适当维护；

5. 对数据存储的未授权公开访问；

6. 第三方跨环境/帐户访问导致权限提升；

7. 在导致横向移动的工作负载上发现SSH密钥。

[CloudSec]Cloud SQL escape to host

https://www.cloudvulndb.org/cloudsql-escape

概述：在 GCP 的案例中，他们对 Cloud SQL 的 PostgreSQL 引擎进行了修改，允许分配给租户的角色 (cloudsqlsuperuser) 任意将表的所有权更改为数据库中的任何用户或角色。因此，攻击者可以 (1) 创建一个新表，(2) 创建一个带有恶意负载的索引函数，以及 (3) 将表所有者更改为 GCP 的超级用户角色 (cloudsqladmin)。接下来，通过启动 ANALYZE 命令，恶意函数以 GCP 的超级用户高权限执行。然后，攻击者可以使用符号链接攻击获得本地特权升级到 root，最后，获得 CAP_NET_ADMIN 和 CAP_NET_RAW 功能，通过 TCP 注入来自包含攻击者控制的 SSH 密钥的元数据服务的虚假配置响应来逃逸他们的容器（这仅是由于与 GCP 的元数据服务的通信未加密和未签名的事实才有可能）。

学习这几个漏洞的过程整理了下，跳转到这篇：

《Cloud Native PostgreSQL攻击面分析 》

https://mp.weixin.qq.com/s/uYJqM8pXJJF85LTW08r48Q

[CloudSec]云 DNS 安全 – 如何保护云中的 DNS

https://sysdig.com/blog/dns-security-cloud-protection/

攻击者在 Internet 上建立了一个 DNS 服务器，并注册了一些听起来很无辜的域名，例如“windows-server-update-microsoft.net”，在这篇博文发表时，它恰好可以以大约 12 美元的价格获得。

DNS 安全最佳实践

DNS 特别容易受到体积 DDOS 攻击（作为目标和棋子），可以通过各种方式被黑客攻击和利用，并且在错误配置（包括未能跟上补丁）可能会导致中断甚至更糟。

有一些低级、非常具体的 DNS 最佳安全最佳实践，例如将主 DNS 服务器隐藏在代理后面。你必须把这些做对。

但是，即使您正确掌握了所有低级配置细节，如果您不遵循战术级别的高级最佳实践，您仍然可能会遇到麻烦。我们研究了可用信息并提出了以下高级别的最佳 DNS 安全最佳实践：

安全的配置和修补

如果您自己构建 DNS 基础设施，您有责任跟上 CVE 和其他对您的 DNS 软件的更新。鉴于 DNS 中存在重大漏洞的历史（BIND 我在看你）对待你的 DNS 补丁就像你对待你最关键的服务一样。部署 DDOS 保护和 DNS 防火墙。在适当的情况下使用 DNSSEC 并考虑 DoH 的隐私影响。对有权访问配置的每个帐户使用多重身份验证 (MFA)，并使用 TLS 1.2 或更高版本与管理界面进行通信。

了解您的域名（以及谁在注册它们）

一个非常基本的步骤是了解您的所有域名，以及它们如何映射到您的应用程序。想象一下，如果这种情况失控会发生什么。对所有 DNS 服务器、所有区域以及 DNS 架构和拓扑进行编目。一个很好的策略是通过查看本博客文章中描述的云日志来实时掌握域名创建。

部署 DNS 监控解决方案

即使是最大的组织也可能发生 DNS 中断。这就是为什么就像您监控应用程序正常运行时间一样，您将受益于更精细的 DNS 监控，以及了解 DNS 本身是否导致问题与其他问题（如应用程序堆栈不执行或数据库中断）相比。此处提供了 DNS 监控解决方案列表，但还有许多其他解决方案。

了解您的 DNS 安全功能

了解您现有的 DNS 解决方案或服务提供商提供的安全功能。从您的 DNS 供应商处获取您的安全路线图，并确认他们致力于跟上 DNS 安全的发展。如果您没有提供安全功能的 DNS 解决方案或服务提供商，请转储它们并找到提供安全功能的解决方案。请参阅本文前面介绍的 DNS 功能表。

大量有效地记录

正如您在应用程序的各个方面都依赖日志一样，您需要收集和分析具有相同优先级的 DNS 日志。您的 DNS 日志可能会显示威胁检测的早期指标，并且对于使用您的安全信息和事件管理 (SIEM) 或类似工具进行补救至关重要。使用 AWS CloudTrail 设置 API 和用户活动日志记录。

部署威胁防护

使用威胁源阻止对恶意域的请求。在杀伤链的早期使用 DNS 威胁过滤将防止攻击对您的 Web 服务器进行 TCP SYN。DNS 的威胁源也可以应用于 DNS 如何影响电子邮件服务。您需要在适当的地方部署允许列表和阻止列表，并监控 DNS 流量是否存在异常。从相反的角度来看，您可以使用https://www.dnsbl.info/等服务来查明其他组织是否错误地阻止了您的域。

采用云优先 DNS 策略

十多年来，随着组织推动数字化转型和现代化，云优先一直是推荐的方法。DNS 也不例外。

很容易为托管 DNS 提供支持。云中 DNS 的简单性、安全性、稳健性、性能和有效性应该是默认的部署方式。考虑“堆叠”您的 DNS 提供商也是一个好主意，这样如果另一个 Mirai 发生，您就有一个备份提供商。

云提供商知道许多客户无法在一夜之间关闭他们自己开发的 DNS 架构。AWS Route 53 甚至包括将您的私有 DNS 与 AWS 集成的高级功能，称为AWS Route 53 Resolver for Hybrid Clouds。

对于某些极端情况，例如高安全性、黑暗环境等，100% 云 DNS 并不适合，但它仍然应该是您的默认设置。