-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Exploit For CVE-2022-41082 (ProxyNotShell) #17275
Add Exploit For CVE-2022-41082 (ProxyNotShell) #17275
Conversation
bbece45
to
29d57dd
Compare
This updates the HttpSsrf class to retry requests to the Powershell backend when they fail because they were routed to a new server. Now when the transport is initialized, it will store the backend used by the first successful request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @zeroSteiner for this module! I just left a few minor comments for you to review when you get a chance. I tested both modules (exchange_proxyshell_rce
and exchange_proxynotshell_rce
) against Exchange 2019 CU9 Build 15.2.858.5 and they work great.
For the exchange_proxynotshell_rce
module, I notice an error each time the cmdstager
sends a request,, this error is only visible when verbose
is set to true
. Is it expected?
[-] PSRP error received:
Cannot process argument transformation on parameter 'Identity'. Cannot create object of type "Microsoft.Exchange.Configuration.Tasks.MailboxIdParameter". The LaunchCalch property was not found for the Microsoft.Exchange.Configuration.Tasks.MailboxIdParameter object. The available property is: [EnableGroupMailbox <System.Boolean>] , [RawIdentity <System.String>]
+ CategoryInfo : InvalidData: (:) [Get-Mailbox], ParameterBindingArgumentTransformationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-Mailbox
if datastore['AutoCheck'] && !datastore['ForceExploit'] && (version = exchange_get_version) | ||
vprint_status("Detected Exchange version: #{version}") | ||
if version < Rex::Version.new('15.2') | ||
fail_with(Failure::NoTarget, 'This exploit is only compatible with Exchange Server 2019 (version 15.2)') | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to have this version check in the check
method instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, because the difference is in vulnerability versus exploitability. In this case, we're filtering out instances where the target is vulnerable, as proven by our ability to execute the Get-Maibox
CmdLet using the SSRF however older versions of Exchange look like they need an alternative Xaml gadget in order to be exploitable for arbitrary command execution.
Or are you saying you just want to print the version in the check method and assign the value to an instance variable to be checked here.
end | ||
end | ||
|
||
@ssrf_email ||= Faker::Internet.email |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this might generate non-unique emails. I assume it is fine to have duplicate emails, but I just wanted to double check if it is not an issue for this exploit.
Also, is the domain part of the email important? I was wondering if it would be useful to have an option for this, in case a specific domain has to be provided. I'm not sure if all of this is relevant for this exploit, but just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-unique emails work just fine. All the public PoCs for the SSRF use a hardcoded value here like @evil.com
, @localhost
etc. I've tried using static values myself, and it works just fine. Technically the part to the left of the @
is unnecessary but IMHO it just makes the request look more sketchy because the email is obviously invalid.
Yes, that's expected because the object is being deserialized as part of the exploit. The result isn't what exchange expects because it's the payload. |
Thanks for updating this @zeroSteiner. Everything looks good to me now. I tested against Exchange 2019 CU9 Build 15.2.858.5 and verified I got a session. I also make sure the
|
Release NotesThis adds an exploit module for |
This adds an exploit for CVE-2022-41082, AKA ProxyNotShell. This vulnerability is a deserialization flaw in Microsoft Exchange's PSRP backend. The PSRP backend can be accessed by an authenticated attacker leveraging the SSRF flaw identified as CVE-2022-41040. Together, these vulnerabilities allow an authenticated attacker to execute arbitrary commands on a Microsoft Exchange Server. If the "Windows Command" target is selected, no files are written to disk. The deserialization gadgets and their usage details were released this week by ZDI in their blog.
This module has been tested on:
There's a fair bit of code reuse with the original ProxyShell exploit I wrote so I combined them into a ProxyMaybeShell library to avoid duplication of ~150 lines as well as a datafile. The original ProxyShell exploit was retested.
Troubleshooting
Edit: This should no longer be necessary if the
EemsBypass
option is set to 'IBM037v1'.If a vulnerable version isn't exploitable because EEMS M1 is enabled, the check method will report it as safe. You can disable the rule using the IIS manager.
Verification
RHOSTS
,USERNAME
, andPASSWORD
optionsDemo