SILENTTRINITY
SILENTTRINITY copied to clipboard
[BUG] `BindIP` option doesn't validate IP
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.
- Start listener and ST client as normal
- Create a new listener with an invalid IP (like 1.2.3.4.5.6, which is not how IPv6 works) set to
BindIP
- 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.
Thanks! Good catch, we should def be validating these
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.
Didn't think of that! Yeah I'll def just add a check to make sure the IP is valid.
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. 🤷🏾♂️
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.
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.