-
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-2020-28653 (ManageEngine OpManager RCE) #15670
Conversation
|
||
COPY find_ysoserial_offsets.rb / | ||
|
||
CMD ruby /find_ysoserial_offsets.rb -a | ||
ENTRYPOINT ["ruby", "/find_ysoserial_offsets.rb"] |
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.
Any context on this change? 🕵️
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.
Yeah in the "Java Deserialization Updates" section I mentioned switching the docker container and dropping runme.sh
. This removes the -a flag used by runme.sh
since we shouldn't be updating all payloads at once anymore and makes the script the entry point so the container can be more easily used with user specified arguments.
Admittedly once I fixed the diff-lcs 1.4 compatibility issue, I just ran the offsets tool natively on my system but I could see why some people might want to run it in docker so I kept the file and made it more flexible. Downloading specific versions of the built jars is handy to know what revision the payload data was generated with.
Github tests are failing for unrelated reasons, if you rebase against master and push it up again, they should go green 👍 |
* Apply rubocop suggestions for style * Support patching an existing JSON file * Use an OptionParser
Remove the runme script because we should no longer be updating all of the gadget chains at once because doing so would require that quite a few different modules be updated. Moving forward we should be updating individual chains using an incremental approach to allow us to validate the results of the find_ysoserial_offsets tool which is error prone.
4b360f9
to
d82ed7d
Compare
@msjenkins-r7 test this please. |
@@ -317,6 +317,17 @@ | |||
}, | |||
"Wicket1": { | |||
"status": "unsupported" | |||
}, | |||
"frohoff/ysoserial#168": { |
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.
Named to point to frohoff/ysoserial#168 so both PRs can move forward independently of each other.
Tested various versions on both Linux and Windows: Version 12.5.328 on Ubuntu 20.04Linux Dropper Target
Python target
Version 12.3.238 on Ubuntu 20.04 - Failing on "Could not identify the remote version number"
Version 12.5.231 on Ubuntu 20.04Python and Linux Targets
Version 12.5.328 on Windows 10 x64Windows Command and Dropper Targets
Version 12.3.295 on Windows Server 2019 - Failing on "Could not identify the remote version number"
Version 12.5.328 on Windows Server 2019Powershell Target
|
1. Download an affected version for either Windows or Linux from the [archive][0] | ||
1. Run the installer executable as root | ||
1. Accept the default values for all settings (skip registration) | ||
1. Navigate to `/opt/ManageEngine/OpManagerCentral/bin` |
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.
Looks like older Linux versions might be under the /opt/ManageEngine/OpManager/bin
path, so that could be added here
For the 12.3.295 on Windows Server 2019 which is failing because it can't identify the version number, you'll have to set it to the 2020 CVE. Unfortunately the version detection uses an aspect of the logon page that isn't present in the older versions. After the CVE option is set, it should work just fine though. |
That worked great, thanks!
|
Added the older path for the Linux installations and fixed a typo in 327aefd. Code looked good to me, and the module worked across a large number of versions (all that I had previously tested after leveraging the |
Release NotesThe |
This adds an exploit for CVE-2020-28653 which is an unauthenticated RCE in Manage Engine's OpManager platform. The vulnerability is a Java deserialization flaw in the Smart Update Manager. The exploit itself is pretty straightforward, 2 HTTP requests are made before the serialized Java blob is sent to the server to trigger the vulnerability. The first sets up an HTTP session by obtaining a session cookie, the second puts the established HTTP session in an exploitable state. CVE-2021-3287 is a patch bypass for CVE-2020-28653 which is also supported by this module.
Tested:
The
Msf::Exploit::JavaDeserialization
mixin can't be used for this exploit because the YSoSerial payload isn't available in the modified version which has the shell-specific variants. Each target was tested to ensure that the module is setting the shell and escaping the arguments as necessary.Java Deserialization Updates
This PR makes some updates to the tooling around the YSoSerial payloads.
--json
option)runme.sh
script that would regenerate and overwrite all of the payloadsThis will be the 13th module using either the
Msf::Exploit::JavaDeserialization
orMsf::Util::JavaDeserialization
utility directly. The payloads that are currently used by those modules are known to work. It doesn't make sense to update all of the YSoSerial payload blobs at once anymore when changes need to be made because each payload should really be tested to ensure that the offsets are correct. The changes to the tool allows individual YSoSerial payloads to be regenerated and merged into the JSON data file. This means only modified payloads need to be tested, while the rest remain the same.In the context of this exploit, this functionality was used to generate and add the
frohoff/ysoserial#168
payload which is a derivative ofCommonsBeanutils1
but has been updated per the vulnerability analysis to remove the dependency on the commons-collections lib. The name should make it future proof since AFAIK GitHub Pull Requests can't be deleted and the final name is unknown at this point since the changes have only been submitted. If the changes are merged in, the name should be updated. This allows the two PRs to proceed independently of one another, there's no need to wait for frohoff/ysoserial#168 to be merged first.The gadget chain was generated by:
docker cp IMAGEID:/app/ysoserial.jar tools/payloads/ysoserial/ysoserial-original.jar
copying the built ysoserial.jar file to the tools directoryfind_ysoserial_offsets.rb -p CommonsBeanutils1
data/ysoserial_payloads.json
, using the new nameVerification
use exploit/multi/http/opmanager_sumpdu_deserialization
RHOSTS
,TARGET
,PAYLOAD
and payload-related options as necessaryrun
Demo