SILENTTRINITY icon indicating copy to clipboard operation
SILENTTRINITY copied to clipboard

[BUG] `BindIP` option doesn't validate IP

Open jeffmcjunkin opened this issue 4 years ago • 6 comments

Issue Template

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

jeff@blue:~/dev/SILENTTRINITY$ git branch
* master
jeff@blue:~/dev/SILENTTRINITY$ git rev-parse HEAD
c3b397d85dbb471c4f202151d30100e4222215eb
  • SILENTTRINITY Version: Latest master branch
  • OS running the Client: Ubuntu 18.04 x64
  • Python Version Running the Client: Python 3.7.4+
  • OS running the TeamServer: Ubuntu 18.04 x64 (same system as client)
  • Python version running the Teamserver: Python 3.7.4 (same system as client)

Expected Behavior

Either as BindIP is set, or before saying the server has been started with the start command, I'd expect ST to validate that the BindIP given is one that can be bound.

Current Behavior

Currently there's no feedback given about improper BindIP options in the client:

Failure Information

[1] ST (listeners)(http) ≫ options                                                                                                                                                                                 
┌Listener Options─────────┬───────────────────────────┬───────────────────────────────────────────────┐
│ Option Name  │ Required │ Value                     │ Description                                   │
├──────────────┼──────────┼───────────────────────────┼───────────────────────────────────────────────┤
│ Name         │ True     │ http                      │ Name for the listener.                        │
├──────────────┼──────────┼───────────────────────────┼───────────────────────────────────────────────┤
│ BindIP       │ True     │ 192.168.252.192.168.252.1 │ The IPv4/IPv6 address to bind to.             │
├──────────────┼──────────┼───────────────────────────┼───────────────────────────────────────────────┤
│ Port         │ True     │ 80                        │ Port for the listener.                        │
├──────────────┼──────────┼───────────────────────────┼───────────────────────────────────────────────┤
│ CallBackURls │ False    │                           │ Additional C2 Callback URLs (comma seperated) │
├──────────────┼──────────┼───────────────────────────┼───────────────────────────────────────────────┤
│ Comms        │ True     │ http                      │ C2 Comms to use                               │
└──────────────┴──────────┴───────────────────────────┴───────────────────────────────────────────────┘

The stager does give the following errors:

From PowerShell stager:

[*] Attempting HTTP POST to http://192.168.252.192.168.252.1/705213ab-e9e7-4f0d-8942-5b61719af2f4
[-] Attempt #1
        [!] The remote name could not be resolved: '192.168.252.192.168.252.1'
[-] Attempt #2
        [!] The remote name could not be resolved: '192.168.252.192.168.252.1'

Steps to Reproduce

Please provide detailed steps for reproducing the issue.

  1. Start listener and ST client as normal
  2. Create a new listener with an invalid IP (like 1.2.3.4.5.6, which is not how IPv6 works) set to BindIP
  3. Start the listener with the start command

Failure Logs

I think I've given all the relevant logs in Failure Information, but I can provide more information if needed.

jeffmcjunkin avatar Sep 11 '19 23:09 jeffmcjunkin

Thanks! Good catch, we should def be validating these

byt3bl33d3r avatar Sep 12 '19 00:09 byt3bl33d3r

I'd expect ST to validate that the BindIP given is one that can be bound.

Maybe not one that can be bound? Might affect people using any sort of proxy in front of ST and expect callbacks to that IP. But probably a good idea to at least make sure the IP is a valid IP.

daddycocoaman avatar Sep 12 '19 08:09 daddycocoaman

Didn't think of that! Yeah I'll def just add a check to make sure the IP is valid.

byt3bl33d3r avatar Sep 12 '19 12:09 byt3bl33d3r

I just had a weird moment of clarity. Maybe there should be a listener IP value and a callback IP value.

The listener should be something that can be bound to, since that's immediately exposed to ST.

The callback value doesn't have to be exposed to ST, and generating stagers should use the callback value if it's set. Otherwise, use the listener value.

..unless that's already what happens with CallbackUrls. I haven't tried that. 🤷🏾‍♂️

daddycocoaman avatar Sep 12 '19 12:09 daddycocoaman

I just had a weird moment of clarity. Maybe there should be a listener IP value and a callback IP value.

The listener should be something that can be bound to, since that's immediately exposed to ST.

The callback value doesn't have to be exposed to ST, and generating stagers should use the callback value if it's set. Otherwise, use the listener value.

..unless that's already what happens with CallbackUrls. I haven't tried that. 🤷🏾‍♂️

This is what CallbackURLs is for.

glides avatar Jan 30 '20 20:01 glides

I cannot reproduce this. Without supplying a valid BindIP the listener won't start (which makes sense). It's easy enough to add validation to the inputs when being set...but I'm curious how you managed to start the listener without a valid address.

image

glides avatar Jan 30 '20 20:01 glides