request filtering

[DarkC0ntributor]

Wenn exposing this profile to the internet I always get scanned and thus get a lot of errors in mythic (as everything gets forwarded to mythic).

Errors like this:

Error! Mythic received an anomalous request. Check the following details for more information about the request:
Connection to: http://<IP>/.env via GET Request
From: <IP>
With query string: 
With extra headers: ...

This change allows you to whitelist requests based on IP and/or Path. No filter:

{
    "allowed_ips": [],
    "get_uri":"/<uri:path>",
    "post_uri":"/<uri:path>",
}

Filter on default Paths and the IP of googles DNS:

{
    "allowed_ips": ["8.8.8.8"],
    "get_uri":"/index",
    "post_uri":"/data",
}

[its-a-feature]

Hey! This is an awesome request :) I have a couple of questions though -

• allowed_ips: is the idea here that you're only specifying specific IPs (rather than CIDR blocks) because you anticipate this to be filtering requests that specifically come from a redirector?
• get/post_uri: currently, the tough part about specifying get/post URIs like this is getting the coordination between the c2 profile and the payloads that you're building. I can add into the back-end some functionality to ship an agent's configuration to the c2 profile to help automate some of this configuration, but it could easily become out of sync with the operator. If we go this route, then when we start the c2 profile and print out the initial message, we should also print out that there are specific URIs (and IPs) that are allowed and that all else are blocked.

In the case that the c2 profile blocks a message, do you think it'd be a good idea to record that somewhere so that if an operator needs to go back and troubleshoot why they're not getting callbacks, they can easily see what's been blocked.

[DarkC0ntributor]

Hm, my initial idea was to just go for specific IPs. However, it should be strait forward to change it to blocks/networks using ipaddress.ip_network. The out of sync thing is indeed true - I will add some logging on this.

As for the blocked messages... Not sure. The Idea was not to spam the operator :smile: But it might be useful. Any suggestion where to log to?

[its-a-feature]

ah yeah, i'd suggest expanding it to allow CIDR notation checks just in case. I find that if people are using redirectors in front of the http profile, then they typically restrict the connections at the redirector level; but if there's no redirector, then you might not know the very specific IP you'll be getting your callback from, so client CIDR ranges would be necessary.

Yeah, i get not wanting to spam the operator. That's why the new UI collapses those messages and just increases the count associated with them. I want to still inform the user in some way, even if we end up making it a flag in the config.

[DarkC0ntributor]

Ok, so now there is the additional parameter verbose that starts out as true. If it is set, all filtered requests are reported to the Operator (as they would without the PR, but) with an error like

HTTP C2: Path '/blup' is not whitelisted
http://<host>/blup?
From: <ip>
<Header('host': '<host>, 'user-agent': 'Wget/1.21.3', 'accept': '*/*', 'accept-encoding': 'identity', 'connection': 'Keep-Alive')>

Should there still be logging when the server is started?