There are some situations where the default framework flags should be able to be overwritten by the exploit. Since the flag.Parse() call is done from RunProgram any flags that are set prior to that call are overwritten by the default value when called.
This arises in scenarios such as the fileplant.Cron usage which triggers every 1 minute and will almost regularly fail on timeout being reached. It would be advantageous to be able to override that setting for payloads that need strict defaults.
An example of how I solved this for one of our exploits was to check the default config.C2Timeout value at prior to Parse and either set a default or allow the overwritten value: https://github.com/vulncheck-oss/go-exploit/pull/173
Two problems arise from this:
This is only one of flags and we should enumerate and see if we should change this for other flags (see below).
Default struct values are assigned by Go, which means that we are relying on that value to not be logical for validity. This is a safe assumption for things like bport and c2 timeout, since those values being 0 wouldn't make much sense, but any values where the default struct value will not work.
The exploit related flags that we should consider for this:
flag.IntVar(&conf.Bport, "bport", 0, "The port to attach the bind shell to")
flag.IntVar(&conf.C2Timeout, "t", 30, "The number of seconds to listen for reverse shells.")
flag.BoolVar(&conf.ThirdPartyC2Server, "o", false, "Indicates if the reverse shell should be caught by an outside program (nc, openssl)")
flag.StringVar(&c2Selection, "c2", c2Default, c2Available)
Based on that list I think that the C2Timeout and maybe the Bport (think of a situation where "secure" lower TCP/UDP ports are used for remote verification, a la NFS or Lustre that check that the target are listening < 1024) configurations might make sense.
There are some situations where the default framework flags should be able to be overwritten by the exploit. Since the
flag.Parse()call is done fromRunProgramany flags that are set prior to that call are overwritten by the default value when called.This arises in scenarios such as the
fileplant.Cronusage which triggers every 1 minute and will almost regularly fail on timeout being reached. It would be advantageous to be able to override that setting for payloads that need strict defaults.An example of how I solved this for one of our exploits was to check the default
config.C2Timeoutvalue at prior toParseand either set a default or allow the overwritten value: https://github.com/vulncheck-oss/go-exploit/pull/173Two problems arise from this:
The exploit related flags that we should consider for this:
Based on that list I think that the
C2Timeoutand maybe theBport(think of a situation where "secure" lower TCP/UDP ports are used for remote verification, a la NFS or Lustre that check that the target are listening < 1024) configurations might make sense.