Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 5 commits into from
Aug 31, 2022
Merged

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

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
5db7415
Update jenkins_script_console.rb
bojanisc Jul 6, 2022
3d13dab
Update jenkins_script_console.rb
bojanisc Jul 6, 2022
2e8e15e
Fail back to the old method using error handling
smcintyre-r7 Aug 25, 2022
8a79128
Switch to using Rex::RandomIdentifier
smcintyre-r7 Aug 25, 2022
324fb69
Resolve rubocop issues
smcintyre-r7 Aug 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions modules/exploits/multi/http/jenkins_script_console.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,12 +108,10 @@ def http_send_command(cmd, opts = {})
end

def java_craft_runtime_exec(cmd)
decoder = Rex::Text.rand_text_alpha(5, 8)
decoded_bytes = Rex::Text.rand_text_alpha(5, 8)
cmd_array = Rex::Text.rand_text_alpha(5, 8)
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"
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@bojanisc bojanisc Jul 6, 2022 •
edited
Loading

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

@smcintyre-r7 smcintyre-r7 Aug 25, 2022 •
edited
Loading

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.


jcode << "String [] #{cmd_array} = new String[3];\n"
if target['Platform'] == 'win'
jcode << "#{cmd_array}[0] = \"cmd.exe\";\n"
Expand Down