attack signatures
19 TopicsF5 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.html2.2KViews1like9CommentsASM Flagging JSON Payload Base 64 encoded data as a violation
Hello I have some policies that are accepting encrypted data which has then been encoded with Base64 and sent in a JSON document. However sometimes however this data gets rejected as an attack signature has been triggered. I would really like to leave Attack signature checking on the JSON profile but would like to find a way of filtering out just these signatures that get triggered without blocking legitimate traffic. Currently the URL is in Staging which is allowing them through but I should really enforce this at some point and at that time these violations will get blocked. Has anyone got any suggestions on how I could achieve this. I have been looking at iRules that would unblock a request if a certain criteria is met. James1KViews0likes6CommentsWAF 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? Thanks1KViews0likes3CommentsJoomla! 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.926Views0likes2CommentsMultiple 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?804Views0likes5CommentsASM detecting but not blocking the attack
Hello all, I am using ASM and a Apache Tomcat based web application behind it. I am testing negative security accuracy of the ASM and realized that it is not blocking the attacks even it detects that the request is violating the attack signature. The security policy is configured in blocking and manual mode. The signature staging is disabled with all available signatures included to the policy. The issue is once the attack (for example SQL injection) is launched ASM is detecting that the request matches the attack signature and showing it on the Manual Traffic Learning -> Attack signatures detected page. When you go one step further and check the details of the incidents listed under this page you see that ASM is considering the request as legal! No logs are available under Event Logs tab. It will be highly appreciated if anyone explains this behaviour. Is it expected or sth like a bug?724Views0likes5CommentsExporting a full list of Attack Sigantures
Hi. I am looking to export a full list of the current signatures I have in blocking mode. If possible, I would like to separate these lists in to their signature sets. If I navigate to "Security ›› Options : Application Security : Attack Signatures : Attack Signature Sets" then I can view the different signature set types. Let's take the High Accuracy Signatures for instance. If I click on those, I get a list of signatures that are a part of that set, but I cannot copy and paste them. I have people asking me for a list of these signatures so I am hoping there is an easy way to extract these. They want to be able to share it within their team to show what the WAF is doing for them, and what it is blocking so they can test it out for themselves. Is it a possibility that a file exists in the console that I can pull down through WinSCP that has a list of these? Similarly if I go to "Security ›› Application Security : Attack Signatures" I would like to be able to export the full list of 2857 signatures I have for this policy. Thanks.619Views0likes2CommentsASM 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? Piotr600Views0likes1CommentCustom Attack Signature to block request with No UA or Referer
I want to be able to check and see if the request is missing both the User-Agent String and the Referer, and possibly block the request. So I know I can do this with an iRule, but I am wanting to try and perform this check with an Attack Signature. Reason being, that I would like to put the Signature in staging to see how much traffic is getting logged against it before I move it to blocking. I am running 12.1.1 HF1 currently.565Views0likes5CommentsSome questions about ASM module from a beginner
Hello Everyone, My company recently bought some ASM licences for our F5 Big IP and i'm in charge of defining the security policies but I have no experience in it so far and a read only account so it's pretty hard to run some tests and that's why i have some questions for you: 1/What's the difference between Transparent and blocking in Enforcement mod and what suits the most with both of them in signature set (learn/alarm/block)? 2/What does "staging signature" means? What if i dont set a signature set, what does the policy block? 3/ What's the difference between Block in policy (enforcement mod) and block in signature set option? Also correct me if i'm wrong but learn allows me to use the "manual traffic learning" option to see which threats the policy has detected and alarm is a log system-like? 4/What happen if i activate both block option? 5/Scenario that would be much alike what i will do to deploy my policies: I want to observe which threats and who are doing them on my VS already in production before deciding what to block, what would be the best configuration: Transparent as "enforcement mod", "attack signatures configuration" in learn/alarm mod with and ERP of let's say 30 days or something else? After finishing my analyzes, where can i see what have been signaled by the signatures and where can i decide if i block then or not. 8/What happen once the ERP is over? Do I have to change the enforcement mod once the analyse is over (Transparent ->blocking for exemple). Will my policy keep checking if new threat will be detected? I know it's a lot of questions to answer but i have no one else to turn to so thank you very much in advance. Regards,556Views0likes5Comments