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.
