Hi Im writing some custom rules for a university project and I wondered if anyone could check my rule for this vulnerability; http://www.exploit-db.com/exploits/34517/
here is my rule;
alert tcp any any -> any 5466 \ (msg: "FTP command execution"; content: " / admin lua script html"; content: "POST"; http_method; content: "os execute";)
Revised rule; alert tcp any any -> any 5466\ (msg: "FTP command execution"; content:"/admin_lua_script.html"; content:"POST"; http_method; content: "os execute";)
I would recommend something like the following:
alert tcp any any -> any 5466 /
(msg:"FTP command execution"; flow:to_server,established; /
content: "POST"; http_method; nocase; /
content:"/admin_lua_script.html"; fast_pattern; http_uri;/
content:"command=os.execute"; http_client_body; nocase; /
metadata: service http;)
Explanation:
dest port 5466:
You should always specify a port when possible. When you have rules that are "any/any" for source/destination snort treats them differently than rules with ports defined.
Important: Since this exploit module runs over port 5466 and is http you NEED to make sure that this port is in your http preprocessor configuration for ports. Specifically, your snort.conf should have a configuration line similar to the following:
preprocessor http_inspect_server: server default profile all ports { 80 ... 5466 ...}
(obviously don't put the dots, just representing other ports you should have in there). If you do not have this port in your preprocessor config for http, all of your http content modifiers will NOT match because snort will not treat traffic on this port as http, which is likely the main issue you're having.
flow:to_server,established;
You only want to check established sessions where the flow is going to the server. This will be more efficient as snort won't have to check random traffic for unestablished sessions and it won't have to check traffic going to the client, since you know the direction for this exploit will always be going to the server. The only way the request would be successful would be if the connection was already established between client and server, if it's not the exploit won't succeed and it's pointless to alert on this.
content: "POST"; http_method; nocase;
You want nocase for the post match because it is not required by http for the method to be all capital letters.
content:"/admin_lua_script.html"; fast_pattern; http_uri;
Adding the fast_pattern option will make the rule more efficient as it will put it into the fast pattern matcher in snort. You know this content is static and never changing (case included) so this is eligible for the fast pattern matcher. Since this is the only content match in the rule that is case sensitive snort would put this into the fast pattern matcher on it's own, but if you modify the rule later on with another content match you would want this to be the content match to use for the fast_pattern matcher.
content:"command=os.execute"; http_client_body; nocase;
This is going to be in the client body, so add the http_client_body option.
metadata: service http;
If you are using target based (which now a days you should be), you need to add the service http keyword. Having this in the rule will no prevent the rule from triggering if you aren't using target based, so it's also a good practice to put this in if you know the service this traffic is.
Additional Note:
Your custom rule sids should be 1000000 or above, anything below this is reserved for the snort distribution rules. See more on that here