Simple WordPress login protection, using cookie insert
I'm trying to deny access to the default login page on our WordPress site, when going straight to the login page (/wp-login.php), by redirecting you to /access-denied. But if you know the "secret" page, https://[HTTP::host]/secretpage , then the iRule should put a cookie in your browser, then redirect you to the actual login page, and now allow you to login. Any suggestions on how this could be done? Tried something like this, but not getting the expected result: when HTTP_REQUEST { if {[string tolower [HTTP::path]] equals "/secretpage"} { HTTP::cookie insert name "SecretWP" value "1" HTTP::redirect https://[HTTP::host]/wp-login.php } if {[string tolower [HTTP::path]] contains "/wp-login.php" and (![HTTP::cookie exists "SecretWP"])} { HTTP::respond 200 content "Rejected! Cookie names: [HTTP::cookie names]" } } In the end I added a HTTP::respond 200 content, for HTTP::cookie names, for troubleshooting, but the cookie I tried to insert was not in the list. Made this iRule sort of based on an example I found on the F5 site, but most other example seems to always add the cookie insert when HTTP_RESPONSE, so I'm wondering if that's the problem? Can't do an insert when HTTP_REQUEST? / Per
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 Zero-day WordPress Attacks with F5 Essential App Protect
Overview A recent ZDNet article reports that millions of WordPress sites are being probed and compromised due to a vulnerability with the popular "WP File Manager" plugin. Defending against the attacks of this type is one of the fundamental use cases for F5 Essential App Protect, which can block the malicious request and prevents the site from being compromised. This proof-of-concept article demonstrates what happens to a vulnerable WordPress site with and without F5 Essential App Protect. Attack without Essential App Protect Our test WordPress site at http://blog.haxrip.net was previously used in a blog post where we set up protection in less than 5 minutes. For this test we removed the instance that protected our site, and activated an older vulnerable version of the WP File Manager plugin: We’re now ready to send a payload via a Python script that exploits connector.minimal.php on our test site. This results in executing an upload of an arbitrary file and thus exposing possibility of remote code execution as per this vulnerability report. The end-result, the upload of a file: hacked.php, which you can see in this “before” and “after” view of the directory into which we’ll upload an arbitrary file via an exploited vulnerability This allows us to execute remote code by running hacked.php from a browser, which is a bad thing! Besides completely opening this WordPress site to modifications, this exposes potentially sensitive information like passwords, credentials, file structure, certificates & keys, and other info on the remote system, which is likely to enable an attacker to grow their attack footprint. So how can you avoid this? Enter Essential App Protect Now let’s “roll back” our attacked WordPress deployment by removing the hacked.php file from our system, and let’s try the same attack after we deploy an instance of Essential App Protect. This takes just a few minutes, with the below screenshots highlighting the main 3 steps of our deployment (a full deployment walk-through is available in the documentation): 1. Set up protection by using the FQDN of our WordPress site: blog.haxrip.net 2. Confirm the deployment region, use http / port 80 listener (for simplicity), and all of the default configuration options: 3. Use the generated CNAME value to configure the DNS entry for our blog to point traffic to our new Essential App Protect instance: That’s it! We are using Route 53 for our DNS management, so the change propagates in just a few minutes. While that happens we will switch our service from “Monitoring” to “Blocking” mode, to give our vulnerable site the protection it so badly needs! Now we’ll re-run the same Python script that was previously used to explore the vulnerability, which fails as the payload gets detected and blocked by our instance of F5 Essential App Protect. Inside the main dashboard Events View, we can see that our attempt has been flagged, as 4 signatures were picked up to correctly assess this request as an attack and block it. At this point, our site is protected from this and many other attacks based on thousands of signatures that are continuously updated from the F5 Threat Labs. The beauty of this platform is that it also uses predictive intelligence to detects abnormalities in the requests even if that exact attack signature hasn’t been captured yet. This means that we have a much higher chance of successfully detecting and preventing zero-day attacks on web applications. Conclusion F5 Essential App Protect is an effective platform to quickly protect potentially vulnerable instances of WordPress based on the particular exploit that’s making the news rounds this week. Note that in our tests an already exploited site is likely to be vulnerable to this & other attacks, so please set up protection and/or make sure your deployments and all of the plug-ins are up-to-date! Essential App Protect takes just a few minutes to deploy and sits between a hacker and a targeted website, scrubbing the requests across a number of pre-configured attack vectors, using signatures and predictive intelligence that provide holistic protection for externally-facing web apps. Find out more and get a trial set up today!Deploy a full app stack with a domain in under 5 mins.
Background Sometimes you just need a web app. Now! Whether for dev/test, a demo, or even a project where a “canned” app will suffice – nothing beats getting a full stack deployed for you in a matter of minutes. I needed a web-facing app for a demo, and decided to give Amazon Lightsail a try. It did not disappoint! Below is my experience (and the steps) for standing up a WordPress blog plus a domain registered with Amazon Route 53 service – all in under 5 minutes. Pre-requisites Amazon AWS subscription: I started with an existing subscription, if you have one -- follow along! Address/Email: For domain registration I used Amazon Route 53, but similar domain registration & configuration can be done with another registrar like GoDaddy. Part A: Get the domain We’ll start with buying the domain for our web app. In my case I decided to stand up a blog running WordPress, with the domain name: haxrip.net 1. Find the domain: use Route 53 to find the available domain(s) & add to cart. 2. Register the domain: complete registration with your address / email (used to verify the registrant contact info). 3. Verify email: click on the link in the verification email, and that should be it for domain registration. Mine returned as registered in just 3 minutes, your mileage may vary ;) Part B: Stand up the app stack While the domain is being registered we’ll create our WordPress deployment using Amazon Lightsail . Below are the minimum options to create the deployment. 4. Amazon Lightsail: find the Lightsail service in the AWS console (search by name/feature or under the “Compute” category). Click “Create Instance”. 5. Choose location, platform, blueprint: as with most other AWS services we need to pick the region where our resources will be deployed. Since we’re in Seattle, Oregon is the closest option. Next we’ll select Linux as the platform, and under “Apps + OS” I’ll select WordPress 5.3.0, which is the only available version at the time of the writing. 6. Choose instance plan & name: naturally we need to pay for the convenience of the cloud infrastructure, and the lowest priced plan will suffice. Finally, we’ll pick a fancy name for our deployment, and click “Create instance” at the bottom . That is it! 7. Get the IP: within seconds we see the deployment information (greyed out initially), which already contains the IP address assigned to our Linux instance. Everything should go live within a minute. 8. Check the site: it’s truly satisfying to be able to start working on our very own WordPress app within seconds of creating an instance. We can also “Connect using SSH” feature in the Lightsail portal or use our own SSH client to easily retrieve WordPress admin credentials. The good folks at Bitnami, who create and maintain app stacks automatically set up the username: “user” with a password that’s contained in a file “bitnami_application_password”, which we find in the root directory of our instance. Part C: Update domain 9. Create domain record: once we have the IP address of our Lightsail instance, we can update the domain’s A-record with this IP. We’ll need to edit the hosted zone for our domain (pick the one you’ve registered), and click “Create Record Set”. Next, we choose Type: “A – IPv4 address” and enter the IP of our instance. We’re using TTL (time to live) value of 60, but you may want to choose what’s right for you. Click “Create”, and we are done! 10. Enjoy! Conclusion Cloud makes it easy to stand up a full app stack with a domain. While there are many other ways to deploy a full stack, Amazon Lightsail and Amazon Route 53 make it super easy. In my case, I was able to kick off a registration of a domain, stand up an Amazon Lightsail instance and log into my WordPress site - all in ~3 minutes. By the time I updated my domain’s zone with a new record, my domain registration had completed. The entire thing was up and running with a domain in under 5 minutes. That’s cloud speed!
[Solved] F5 ASM learning new parameters while being in blocking mode
Hello, I'm using a cluster of F5 BIG-IP in version 13 w/ ASM in order to protect a Wordpress website. The ASM module is in blocking mode for the Wordpress ASM profile. I have manually added 2 new allowed parameters in the ASM profile and have enabled the staging mode on them. Will the F5 cluster be able to do some learning on these parameters even though ASM is in blocking mode ? Thank you.
