-
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
Add Nexus Repository Manager Java EL Injection RCE (CVE-2020-10199) #13195
Conversation
|
||
# https://www.exploit-db.com/docs/english/46303-remote-code-execution-with-el-injection-vulnerabilities.pdf | ||
def el_payload(cmd) | ||
%(${"".getClass().forName("java.lang.Runtime").getMethods()[6].invoke("".getClass().forName("java.lang.Runtime")).exec("#{cmd}")}) |
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.
As this module does not define BadChars
it might be a good idea to hard code a base64 decode in Java here, and Base64 encode cmd
, presuming there is sufficient space. While Base64 encoding may increase NIDS detection, the use of java.lang.Runtime
in combination with getClass
and exec
is more telling. Optionally, as java.lang.Runtime
is a string it could also be base64 encoded, presuming sufficient space.
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.
I didn't notice any badchars, especially with to_json
, but that's a valid concern.
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.
I didn't notice any badchars, especially with
to_json
, but that's a valid concern.
Presumably use of "
will not end well here: exec("#{cmd}")
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, you're right. Looks like it's one level too deep for the to_json
escaping:
[1] pry(#<Msf::Modules::Exploit__Linux__Http__Nexus_repo_manager_el_injection::MetasploitModule>)> puts json_payload('echo "hi"')
{"name":"internal","online":true,"storage":{"blobStoreName":"default","strictContentTypeValidation":true},"group":{"memberNames":["${\"\".getClass().forName(\"java.lang.Runtime\").getMethods()[6].invoke(\"\".getClass().forName(\"java.lang.Runtime\")).exec(\"echo \"hi\"\")}"]}}
=> nil
[2] pry(#<Msf::Modules::Exploit__Linux__Http__Nexus_repo_manager_el_injection::MetasploitModule>)>
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.
Good point, but I was thinking about what happens when the Java code is executed on the server side at both the Java level and the system shell level.
exec("echo pot"ato")
will not end well.
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.
I shouldn't even be committing to this PR anymore, but I've still got some time to squeeze. I'll use the last two examples as a lead. Thanks.
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.
Why not ARCH_JAVA?
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.
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.
Funny enough, I'm actually working on a remote classloading exploit right now. So maybe. :P
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.
And https://www.exploit-db.com/docs/english/46303-remote-code-execution-with-el-injection-vulnerabilities.pdf has a potential example:
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.
If you don't want to test the changes to the other modules, that's fine. I've tested them again, all targets.
c7cc9ca
to
60e9ae0
Compare
16d5fe0
to
08054bc
Compare
1f31c90
to
6ff3d51
Compare
@wvu-r7 Will take a look at this given I'm also looking into the LifeRay PR which is related. |
There are a lot of changes in this PR. I apologize. This should not happen in a normal PR, but the changes were related to the work I was doing (such as in #13213), and I couldn't stop myself from making them. The modules have been retested, so don't feel the need to test everything. Or do! If you'd like me to explain any changes, feel free to ask! |
baf24a9
to
c5b6ef1
Compare
Miscellaneous module fixes moved to #13259. Cheers! |
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.
@wvu-r7 Overall looking very good, a few areas to fix up as it seems some extra code was left in there and I wanted some clarification on a few things, then should be able to retest it and merge.
documentation/modules/exploit/linux/http/nexus_repo_manager_el_injection.md
Show resolved
Hide resolved
And comment some methods used by it.
@gwillcox-r7: This is how it should look with
I'm running into some issues disabling |
Hmm odd this looks exactly the same as the output above, so not seeing what |
Oh, it's different. It's less verbose. :P |
Confirmed that this exploit works and setup instructions are correct:
|
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 good, changes approved :)
Release NotesA new module, |
You can read the writeup this module is based on: https://securitylab.github.com/advisories/GHSL-2020-011-nxrm-sonatype.
https://help.sonatype.com/repomanager3/system-requirements#SystemRequirements-HostOperatingSystem
Currently, Linux is the only supported platform for this module.
To-do
Example