ysoserial
ysoserial copied to clipboard
frohoff
CLI improvements
CLI arg/param parsing should support the following:
- reusing payload param definition/processing from within exploits
- relatively easy addition of gadgets/payloads/exploits and interoperability with existing (compatible) gadgets/payloads/exploits
- have a reasonable chance of supporting unforeseen exploits/chains/bypasses/etc with minimal changes
- wider variety of gadgets (non-RCE types)
- arbitrary parameters for exploits/gadgets (exploit target host/port/path, remote load gadgets, file paths/contents, etc)
- nesting of payload objects (for wrapping with bypasses, etc) and binding into nested structures
- annotating payload objects with serialization format and peer/child payload object compatibility
- automatically generate help text that shows allowable values for fixed-option parameters
Some ideas:
- Annotate "bindable" classes and fields/properties
- Bind command line parameters into object structure using dotted property notation (a la web frameworks)
- Use annotation parameter to limit choices if necessary (limit to specific payload classes, serialization formats, etc)
- Bound implementation choices instantiate specified class and inject sub-parameters as appropriate
Example:
@Bind public class SomeExploit {
@Bind private Payload payload;
@Bind private URL url;
...
}
@Bind class SomeExecPayload {
@Bind private String cmd;
...
}
@Bind class SomeFileWritePayload {
@Bind private String path;
@Bind private String contents;
...
}
@Bind class SomeBypass {
@Bind private Payload inner;
...
}
$ java ... SomeExploit
Usage:
-payload [CHOICE]
* SomeExecPayload
* SomeFileWritePayload
* SomeBypass
-url [URL]
$ java ... SomeExploit -payload SomeExecPayload
-url [URL]
-payload.cmd [String]
$ java ... SomeExploit -url http://someurl -payload SomeExecPayload -payload.cmd "somecommand"
[Successfully executed]
$ java ... SomeExploit -url http://someurl -payload SomeBypass
Usage:
-payload.inner [CHOICE]
* SomeExecPayload
* SomeFileWritePayload
* SomeBypass
$ java ... SomeExploit -url http://someurl -payload SomeBypass -payload.inner SomeFileWritePayload
Usage:
-payload.inner.path [String]
-payload.inner.contents [String]
$ java ... SomeExploit -url http://someurl -payload SomeBypass -payload.inner SomeFileWritePayload -payload.inner.path "app/webshell.jsp" -payload.inner.contents "<html>webshell-here</html>"
[Successfully executed]
Might be able to abbreviate option names where it wouldn't introduce ambiguity as well. For example, -payload.inner could be specified as -p.i, -inner, or just `-i'. Similar unambiguous abbreviation might be able to be performed with fixed-choice values.
$ java ... SomeExploit -u http://someurl -p SomeBypass -i SomeFileWritePayload -path "app/webshell.jsp" -contents "<html>webshell-here</html>"
[Successfully executed]
Something like this seems like it would accommodate pretty much anything in the future, but I'm concerned that it may be to complex or confusing.
Another useful CLI parameter could be the encoding of the serialized exploit.
Based on the real word scenario I saw, useful encoding could be:
- Raw
- Base64
- ASCII HEX
Thank you for your great job!
I think the approach is very flexible and should allow future gadgets with special needs.
The only thing I would add is that gadgets should also define what output formats they support so they can be generated in different formats as JavaSer (default and mandatory), XStream, Kryo, etc
