在ws1.aholdusa.com的远程代码执行——危及Ahold Delhaize美国员工登录凭据超3.5年（甚至18年？）
背景
Ahold Delhaize自称是全球最大的食品零售集团之一。他们每周服务6000万客户，拥有150年历史，是超过414，000名员工的雇主。他们声称是超市和电子商务领域的领导者，并在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这样规模的公司来说，建立适当的身份管理系统是一个巨大的挑战。他们一直在收购公司，可能需要与旧的遗留系统合作。这些系统管理着所有员工的用户名、密码和访问级别。
如果你攻陷了这样一个服务器，游戏就结束了，因为你可以利用它进行横向攻击，并在不同的公司资产上冒充其他用户。
所以，让我们来寻找这些资产。
一个好的开始是尝试找出员工登录的位置。让我为你谷歌一下。
快速浏览一下网页设计，给我们带来了90年代的感觉，这是我们安全研究人员喜欢的氛围，因为它闻起来像是遗留代码，因此存在安全问题的可能性很高。
LDAP，即轻量级目录访问协议，是一种用于通过IP网络访问和维护分布式目录信息服务的协议。它通常用于组织和定位网络中的不同项目，如用户、组、设备和权限，是许多组织IT基础设施的核心部分。
LDAP-WS-VIP.aholdusa.com 是该服务器的CNAME。
由于我们想要发现此LDAP服务器上所有有趣的路由点（URL），我们需要确保也捕获那些不再被主动链接的旧的遗留路由点。
用于此目的的一个很好的工具是TomNomNom制作的https://github.com/tomnomnom/waybackurls。
该工具抓取所提供域名的所有archive.org索引数据，并显示它能找到的所有URL/路由点。这会产生大量噪音（也会显示图像和其他文件），但是当你根据特定单词过滤列表时，可以快速获得良好的结果。
这些记录看起来像Perl，一种过去用于创建网站的编程语言，90年代的产物！扩展名.pl给了我们这个线索。
访问该页面时，我们看到一个可以提交的表单。
Archive.org在2007年左右首次索引了这个页面。
发现服务器端模板注入漏洞
下一步是在Burp浏览器中打开此页面，以便捕获所有浏览器流量。
我经常做的一件事是寻找能实际改变响应输出的参数。这很容易导致XSS和其他类型的漏洞。一个简单的方法是使用Burp Intruder或Param Miner。
今天我们使用Burp Intruder，我们将请求发送给Intruder（在请求窗口中右键单击，发送给Intruder）。在POST正文中添加一个新的模拟参数，添加一些随机值，选择参数名称作为我们注入payload的位置，并将payload列表设置为“Form fields names - Long”。
我们看到我们的值被反射在源代码中，我们有了反射型XSS！
我们可以通过按“Length”排序来快速浏览响应列表，这使我们能够查看页面是否比正常情况长/短。正常长度是7095，所以任何其他长度都是有趣的。其中一个命中的参数是“version”，我们可以在源代码中看到它将我们的12345<a> payload作为HTML反射！
我们可以将payload设置为某个XSS payload，并接管任何被诱骗访问我们特定URL的用户的浏览器会话。一个快速的方法是创建一个好的payload：12345<script>alert\Hi-mom!`，回到Repeater，并在请求中添加&version=12345`。在请求窗口中右键单击，选择Engagement Tools -> Generate CSRF PoC。
现在Burp会为你创建一个可用的PoC，你可以用它来触发漏洞，将HTML上传到某个Web服务器，诱使受害者打开该网站，漏洞就会执行。
但如果我们能用这个反射漏洞做更多事情呢？每当你遇到反射型XSS漏洞时，你还应该检查是否存在服务器端模板注入漏洞。这些漏洞的影响通常要大得多，因为它们允许你在服务器上执行代码，并反映在源代码中。
在收件箱中获取Jonathan Bouman的故事
加入Medium免费获取此作者的更新。
订阅 订阅
由于我们知道该路由点运行Perl（记住URL中的扩展名），我们现在只扫描与Perl相关的代码注入。
首先在Burp中创建一个新的Live Task，转到Dashboard并点击那个橙色按钮。
现在选择列表中的所有项目（Ctrl + A），然后右键单击，点击Enabled。这实质上禁用了它将进行的其他所有扫描，这是减少服务器噪音和请求的好方法。现在搜索Perl并选择Perl Code injection选项。点击保存，你就可以准备扫描代码注入了！
现在回到带有我们反射版本参数的中继器。选择我们的XSS payload的值，然后点击保存。
现在是时候喝杯咖啡（或好茶），看看Burp Active Scanner能否找到代码注入漏洞。奖励：检查Burp中的Logger选项卡，了解Burp使用了哪些payload。
所以我们现在有一个请求，通过注入payload {${sleep(lc(20))}} 让服务器休眠20秒。
我们可以通过将请求发送到中继器（打开Request选项卡，右键单击请求并发送到中继器，在中继器中重新发送请求并查看加载需要20秒）来轻松确认这一点。
由于sleep(20)作为payload很无聊，并且无法向非技术人员展示实际影响，我们需要创建一些payload来实际展示我们可以在服务器上执行任何代码。
这需要时间和责任感（不要破坏东西并保持适度）。只需确保公司管理层能够理解该漏洞确实是CVSS 10分，但不要通过窃取所有用户数据来证明这一点。
我经常做的是尝试演示我可以运行任何代码，并将/etc/passwd文件泄露到外部（攻击者控制的）服务器。该文件不包含真实的密码，但包含内部服务器信息。外部服务器可以是Burp Collaborator（或者更好的是你自己的私有Collaborator）。
经过两个小时的尝试，我想出了以下泄露/etc/passwd文件的payload：
|
|
让我解释一下它的作用：
- Perl代码执行：
${exec('...')}内的payload是Perl代码，经过URL编码以确保通过HTTP正确传输。如果服务器易受SSTI攻击，它会解释并执行此代码。 - LWP::UserAgent模块：此Perl模块允许代码发出HTTP请求。
my $ua = LWP::UserAgent->new;部分创建一个新的用户代理对象，能够发送HTTP POST请求。 - 发出POST请求：
$ua->post(...)函数向指定的URL发送POST请求，附带/etc/passwd文件的内容。这是攻击者的常见目标，因为它包含用户账户信息。
有人可能认为“先生，你需要广泛的Perl知识才能做到这一点”。错了！
我尝试了所有这些选项，第三个选项（在将jo.ax.com域替换为我们的burp collaborator URL后）触发了一个传入的DNS请求。解析域名通常是发现服务器上是否存在代码执行的最快方法。只需在Burp Collaborator中监控任何传入的DNS请求！
之后，就是给ChatGPT 4正确的提示来创建一个实际泄露/etc/passwd文件的payload的问题了。
奖励payload
获取执行perl进程的当前linux用户（’nobody’）：
|
|
显示/etc/的目录内容（一长串文件和备份文件）：
|
|
结论
我们今天证明了我们可以完全攻陷ws1.aholdusa.com服务器，一个身份管理系统/LDAP服务器。我3.5年前发现了这个漏洞，但它很可能自2005年12月15日起就存在了。
使用此服务器的所有用户/员工/客户/供应商的数据都应被视为已泄露，因为我们展示了完整的远程代码执行能力，并能够向我们的服务器建立出站连接。
无法知道服务器是否未被恶意行为者攻陷，因为这需要广泛的日志。在这种情况下，需要包含POST正文值的日志。在这个应用程序中，你会不惜一切代价避免这样做，因为这也会以明文形式泄露用户名和密码（记住受影响的路由点用于用户登录）。此外，这些日志需要追溯到18年前，才能证明此漏洞从未被利用过。
时间线
- 2020年4月23日 — 向Ahold安全团队报告了该漏洞，见下文电子邮件。
- 2020年4月23日 — Ahold确认了该漏洞，承诺会通知我。
- 2023年11月2日 — Ahold请求我确认漏洞修复并提供修复证明。
- 2023年11月6日 — Ahold再次发送电子邮件请求我确认漏洞已修复（我没有时间更早回复）
- 2023年11月6日 — 回复表示对漏洞未及时修复感到惊讶，要求提供相关信息，并承诺检查是否已修复。
- 2023年11月9日 — 确认漏洞仍然存在，创建了一个完整的RCE payload并撰写了此博客。与安全团队共享。要求在30天内负责任地披露，因为可能有许多员工的凭据因此漏洞而泄露。
- 2023年11月9日 — 告知Ahold Delhaize数据保护官此报告的存在，因为它涉及大量员工。
- 2023年11月10日 — Ahold要求我的Paypal以发送奖励。
- 2023年11月13日 — Ahold为此漏洞奖励300欧元。
- 2023年11月13日 — 路由点仍然存在漏洞，通过电话联系Ahold Delhaize的隐私官，分享我的担忧并请求将此报告升级。
- 2023年11月15日 — Ahold通知我路由点已修复。然而经过一些测试；该路由点并未修复。它只是在使用GET HTTP方法请求路由点时重定向到404。但漏洞利用仍然有效，因为漏洞利用使用的是POST HTTP方法。添加了两个新的payload（检查当前用户；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日 — 披露了上述报告。