0

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 don't know how your rule would detect anything, is there a typo in your first and last content match? I haven't looked into the vulnerability, but it looks like you are trying to match the POST request and uri. The first content match that you have will never match a uri (there are spaces?), and neither would the last content match (os execute). From looking at the reference the uri would be something like "/admin_lua_script.html". Is this what you are trying to do? – johnjg12 Feb 18 '15 at 03:01
  • Here is a revised edit of my rule; alert tcp any any -> any 5466 (msg:"FTP command execution"; flow:to_server,established; content:"\admin_lua_script.html"; content:"os.execute"; content:"Wing_FTP Server"; nocase;) but when i put it into snort it doesnt seem to agree with it. – BuffetOverFlow Feb 19 '15 at 11:04
  • its the format i'm having issues with, is it something simple such as having no spaces between each argument. Such as; content:"\admin_lua_script.html";content:"os.execute"; with no gap inbetween? – BuffetOverFlow Feb 19 '15 at 16:39
  • Your revised rule is using a backslash \ in the first content match. This needs to be a forward slash (/) because that's what http uses and this is probably what is causing the problem. backslash is for escaping, so you're trying to escapse "a" which is invalid. – johnjg12 Feb 19 '15 at 16:57
  • Thank you kindly, that has solved my problem :) – BuffetOverFlow Feb 19 '15 at 17:22
  • Can you edit your original post and put your revised rule in now? – johnjg12 Feb 19 '15 at 19:40
  • sorry if this shouldn't be posted in here, i have got the rule to load into snort now, but unfortunately its not getting detected when the exploit is run. I have been playing around with the rule and this what I have got now; alert tcp any any -> any 5466 (msg:"FTP command execution"; content:"/admin_lua_script.html"; content:"command=os.execute"; nocase; classtype:shellcode-detect; sid:1001; rev:1;) – BuffetOverFlow Feb 19 '15 at 19:59

1 Answers1

0

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

johnjg12
  • 1,083
  • 8
  • 17
  • Thank you that rule is exactly what I was looking for, snort is accepting the rule, however its not alerting when the exploit is run for some reason – BuffetOverFlow Feb 26 '15 at 11:50
  • I didn't set up the exploit, I can do this but no time at this moment. If you need a quicker answer can you provide the content from a packet capture? i.e. execute the exploit while taking a tcpdump, open the capture in wireshark and follow the tcp stream and paste the uri portion in a comment for me. – johnjg12 Feb 26 '15 at 15:14
  • POST /admin_lua_script.html HTTP/1.1 Host: 192.168.202.179:5466 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Cookie: UIDADMIN=a351e7b3e3005e935b455db1096c926e Content-Type: application/x-www-form-urlencoded Content-Length: 1552 command=os.execute%28%27cmd%20/c%20echo% – BuffetOverFlow Feb 26 '15 at 16:42
  • The command=os.execute part is part of the payload i think so i tried removing http_uri after os.execute but its still not alerting – BuffetOverFlow Feb 26 '15 at 16:45
  • Can you upload the pcap somewhere that I can download it? Also how are you actually testing this against snort? Play the pcap, monitoring an interface passively? – johnjg12 Feb 27 '15 at 01:45
  • I have got snort running on a kali linux virtual machine which is also the attacker and a windows 7 virtual machine as the victim, I am then running wireshark on the host machine. In regards to testing against snort I am checking the alert log after the exploit has run to see if it has been alerted with the given message in the alert rule. I know this methos works as if i just have the rule as alert tcp any any -> any any / (msg:"FTP command execution"; / content:"/admin_lua_script.html"; /content:"command=os.execute";) it is alerting – BuffetOverFlow Feb 27 '15 at 10:10
  • Ah yes, this is a cookie, so you could use http_cookie, or just remove the http_uri all together, which it looks like you did. That rule should trigger on this so something else may be going on. I'm going to try to see if I can get this module loaded when I have a chance. We'll get to the bottom of this! – johnjg12 Feb 27 '15 at 15:12
  • Sorry, I completely missed that this is running over a non standard http port. I figured it out, please see my final answer above, this should resolve your problems :) – johnjg12 Feb 28 '15 at 01:00