WAF Attack Signature Level
Hi, I have a specific URL defined in the ASM Allowed URLs ("/path01/page.aspx" for our example), which has "Check attack signatures" checked. In the Parameters we have only Wildcard with Ignore Value set. We found this melicious attempt request wasn't detected: /path01/page.aspx?a=%3Cscript%3Ealert%28%22XSS%22%29%3B%3C%2Fscript%3E&b=UNION+SELECT+ALL+FROM+information_schema+AND+%27+or+SLEEP%285%29+or+%27&c=..%2F..%2F..%2F..%2Fetc%2Fpasswd which decodes to this: /path01/page.aspx?a=<script>alert("XSS");</script>&b=UNION SELECT ALL FROM information_schema AND ' or SLEEP(5) or '&c=../../../../etc/passwd So I understand the melicious code is in the parameter context, so it's not checked due to the wildcard settings. But on the other hand, under the specific URL context, there are several "XSS (parameters)" signatures enabled. Doesn't that mean that under that specific URL it should check for XSS in parameters signatures? Thanks
F5 Rules for AWS WAF - Rule ID to Attack Type Reference
F5 offers security solutions for AWS customers who use the platform's hosting and load balancing services along with the AWS WAF offering. F5 Rules for AWS WAF - Web exploits OWASP RulesF5 Rules for AWS WAF - Bot Protection RulesF5 Rules for AWS WAF - Common Vulnerabilities and Exposures (CVE)F5 Rules for AWS WAF - API Security Rules With the recent addition of logging capabilities of requests that had a match with one of the rule sets, there is now an option to: See the full request that had a match with the rule ID. Understand the attack type that relates to the rule ID. Remove specific rule ID from the rule set in the case it generates false positives. The following CSV maps between rule IDs and attack types, and will help customers of the F5 Rules for AWS WAF products to better manage rule exclusions in their Access Lists. For more details on AWS-WAF logging configuration please visit:https://docs.aws.amazon.com/waf/latest/developerguide/logging.htmlDrupal Core SA-CORE-2018-002 Remote Code Execution Vulnerability
The Drupal community woke up to a worrisome morning with the SA-CORE-2018-002 security advisory (CVE-2018-7600). The highly critical vulnerability mentions remote code execution vulnerability applicable to multiple Drupal core subsystems. The vulnerability resides in the Drupal core, which means all installations of Drupal, regardless of any installed plugin, are vulnerable. Drupal is reporting on over a million installs across the internet: https://www.drupal.org/project/usage/drupal Open-Source Investigation The security advisory does not mention full details regarding the vulnerability, nor have any publicly available exploits been spotted in the wild yet. However, due to the open-source nature of Drupal, security researchers are able to understand the context of the change using the git commit. The code change shows an alarmingly named library added to the code: request-sanitizer.inc. The main function in the library is called “stripDangerousValues”. This gives an obvious hint that there are user input sanitization issues with Drupal. This means that user input could end up unsafely evaluated in unprotected code execution methods – or in other words, arbitrary remote code execution.A deeper look at the code change shows a specific issue with Form API handling of attributes such as #type, #description and more. Therefore, an example exploit may look similar to the following: index.php?page['#payload']=home.php Source: https://blog.appsecco.com/remote-code-execution-with-drupal-core-sa-core-2018-002-95e6ecc0c714 ASM Mitigation ASM is able to detect this attack vector using the “SQL-INJ "' #" (SQL comment) (Parameter)” signature: Nonetheless, an ASU containing signatures specific for this vulnerability has been released and ready for download. The relevant signature IDs are: 200004423, 200004424, 200004440, 200004441, 200004442, 200004443, 200004444.Joomla! SQL Injection Vulnerability
Recently, details about three serious CVE vulnerabilities in the Joomla CMS platform were released to the public (CVE-2015-7297, CVE-2015-7857, CVE-2015-7858). These CVE’s were discovered by Trustwave SpiderLabs researchers, and full details of the vulnerability can be found in the article that was published: https://www.trustwave.com/Resources/SpiderLabs-Blog/Joomla-SQL-Injection-Vulnerability-Exploit-Results-in-Full-Administrative-Access/ The truth about these vulnerabilities is that they don’t present anything new regarding SQL Injections. This article shows how F5 ASM deals with this kind of zero day attacks. The Joomla! CMS Platform Joomla is a free and open-source content management system (CMS) for publishing web content. It has been downloaded over 50 million times, and there are over 7,700 free and commercial extensions for it. According to Wappalyzer, there are over 500,000 different websites using the Joomla Platform. According to Alexa, 25,000 out of the top 1 Million websites use Joomla. This makes Joomla one of the most popular CMS platforms today, second only to WordPress. Weakness in the Core As mentioned previously, there are thousands of community maintained plugins and extensions for Joomla. It’s not uncommon for vulnerabilities to be discovered in those plugins, even on a weekly basis. However, the vulnerabilities mentioned in this article were found in Joomla core platform – this makes the severity of this vulnerability very high since it affects 100% of Joomla installations (only vulnerable versions of course). The vulnerabilities allows a remote unauthenticated attacker to retrieve sensitive data from within the Joomla database, including active administrator session tokens. This basically allows complete site takeover with very little effort. Probe and Exploit Most of the attack attempts that have been seen in the wild (Source: https://blog.sucuri.net/2015/10/joomla-sql-injection-attacks-in-the-wild.html) follow a similar pattern. This pattern includes sending innocent probe requests prior to sending the actual exploit. Some examples for these probe requests: /index.php?option=com_contenthistory&view=history&list[select]=1 POST /index.php HTTP/1.1 User Agent: “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” BODY:option=com_contenthistory&view=history&list[select]=testsearch /plugins/system/cache/cache.xml As we can see, the probe requests are varied, but they all have a common goal of discovering whether or not the target website is vulnerable to this attack. The first request is providing the website with an erroneous SQL query, expecting the site to return an SQL error. The second request is similar to the first one, but tries to masquerade itself as a “Googlebot” request. The third request attempts to uncover the actual Joomla version installed on the website. Note: In the latest ASM version, fake Googlebot requests are blocked using the Bot Detection feature. Those requests are being validated by checking the source IP of the request. ASM Mitigation The actual exploitation attack vectors used in this vulnerability were found to be blocked by ASM SQL-Injection attack signatures: As we can see, the attack vectors use various SQL keywords and an SQL query format, which ASM detects and is able to block. We recommend installing the latest ASM signature update file, and making sure your policy is protected with the “SQL Injection Signatures” set.
Multiple ASM Attack Signature Sets Applied to a Policy
I have multiple attack signature sets applied to a policy. 1) When I look at the list of all the signatures applied to a specific policy, is there a way of telling which "attack signature set" an individual attack signature belongs to? 2) If an attack signature belongs to two signature sets which are applied to my policy,is it possible that a specific signature is in one state in attack signature set "A" and another state in attack signature set "B"?As an example if an attack signature is set to staging in set "A" and set to enforced in set "B", whathappens? If that is possible, which setting takes precedence? 3) Is there an easy way to identify those attack signatures that are assigned to two or more signature sets within the policy? Is there a filter that can identify those?
Attack Signature Staging Audit / History
Hi Team, I have just started my attack signature journey being automatically pushed out via Big-IQ and loving the fact that I no longer have to deal with change windows etc! Currently my production system is just setup for auto updates and still require manually activation out of staging to be enabled. In my Nonprod environment, I have the same autoupdate of attack signatures for the last few months and have setup autostaging ( I think I have! ) by setting my staged time to 14 days. The question is, is there a log/history/event that I can view that shows when attack signatures move out of staging and where the heck do I find it ?
CM control of ASM attack signature updates - how to revert?
Env: LTM 11.5.2 I can't find any info on how to revert a whole ASM attack signature update file - only on how to disable specific signatures. Is there any configuration mgmt control that would let us "back out" a signatures update file? We are doing manual updates, and have HA pairs for all the LTMs affected - and I wondered if synching from the standby, which shouldn't yet have the update, to the standby would do it (i presume so). But ... we don't want to hold the pair in stasis for long enough to be sure there are no issues. I do understand about staging, and know that we have 7 days to identify and disable any specific signatures causing issues, btw. But if we're seeing a lot of false positives/negatives suddenly after an update, it would be helpful to be able to back out the whole update. Any way to do this? thx!ASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr
ASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr
