-
Notifications
You must be signed in to change notification settings - Fork 13.8k
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
Struts2 Multi Eval OGNL RCE #14521
Struts2 Multi Eval OGNL RCE #14521
Conversation
Seems to be working nicely for CVE-2020-17530:
And here is the normal non-dropper version:
|
CVE-2019-0230 also appears to be working well:
|
…add in missing documentation for some options, plus to make some explanations a bit clearer.
…ument, edit the wording on the module to match the documentation, and do final touch ups.
Release NotesNew module |
Thanks @gwillcox-r7! |
@gwillcox-r7 Just confirming if this line is accurate from the release notes, I thought this exploit was application dependant? So in theory you could get |
Yeah seems like you are right and I may have just assumed it was as Updated the release notes so long. |
This adds an exploit for CVE-2019-0230 and CVE-2020-17530 which are both issues resulting in Struts2 evaluating OGNL expressions multiple times. These vulnerabilities are inherently application dependant. Users will want to set the
NAME
parameter appropriately and use the check method to ensure that the evaluation takes place within an HTML attribute.I think it makes sense to keep these vulnerabilities together. They use different OGNL chains and HTTP verbs but are otherwise pretty similar in the sense that they both are the result of multiple evaluations of OGNL expressions in HTML attributes. The CVE-2019-0230 OGNL chain for RCE requires a one time chain to enable the RCE gadget, this is handled automatically in the exploit.
The check method is a bit finicky. The OGNL gadget chain for CVE-2020-17530 will echo the command output, while the other doesn't so they both use a simple mathematical expression to ensure the evaluation takes place. This came from the public PoCs and seems to be a pretty common technique. The limitation I found with this was that the simple evaluation would yield false positives when trying to identify which of the CVEs the system is vulnerable to which is why there is no "Automatic" target. The user will need to know which CVE they're targeting for, with the default being the more recent of the pair.
I also updated the docs for the
exploit/multi/http/struts2_namespace_ognl
to improve how they are rendered in markdown. You'll notice that the changes are related to the markdown formatting not the content. The XML tags must be escaped in the markdown to not break the rendered output from msfconsole'sinfo -d
command.Verification Steps
cd struts2/s2-059
docker-compose up -d
msfconsole
anduse exploit/multi/http/struts2_multi_eval_ognl
NAME
parameter at its default value ofid
CVE
datastore option based on the one you're testingcheck
and make sure it's identified as "Appears" vulnerableExample