We have seen a few of our customers experience malicious bots making repeated efforts to break into their WordPress login page. There are a few issues that arise from this activity. Not only is it annoying but this can eventually crash your site by using up your server resources. It can also lead to your WordPress site getting hacked since that’s what the bots are trying to accomplish.
To prevent experiencing these issues, you can use Cloudflare‘s Firewall rule feature.
Let’s get started:
Assuming you have a Cloudflare account, log into your Cloudflare account.
Click on the Firewall icon
Click on the “+ Create Firewall rule” link on the upper right corner.
In the “When incoming requests match…” section select “URI” in the drop-down menu under Field. For the Operator field, select “Contains“. In the Value field, enter “/wp-login.php” as shown above.
In the “Then…” action select “Challenage (Captcha)“.
Now when someone goes to your wp-login.php page they will be met with a Captcha challenge they must enter first in order to log into your WordPress site.
The best part of using this firewall rule on your Cloudflare account is that it generally stops the bad guys from getting into your WordPress site. And, as a bonus, your server resources are also protected.
Over the past few months, we have seen a large number of hacking attempts against our customer sites using an old Telerik component vulnerability. More specifically, the Telerik Web UI component, widely used in different applications like DotNetNuke, Sitefinity and custom built ASP.NET sites, is being targeted. One codename given to this hack is Blue Mockingbird. Hackers are finding success in compromising sites using this exploit because many site owners never patched their websites. Telerik has even recently blogged about the increase in hacking activity and provides some guidance.
What hackers are doing with compromised sites There appears to be different individual hackers and hacker groups that are using this exploit and they are doing different things. In our experience, we have seen the following:
Hacker attempts to compromise the website/database. The hacker
Uploads phishing/malware site which can result in the site getting blocked by anti-virus software and browsers.
Gains access to the database which could contain sensitive information.
Installs scripts that attack other systems (e.g., brute force attacks)
Modifies scripts to skim sensitive information, like credit card numbers.
Hacker attempts to compromise server in order to
Install a cryptominer and use the server resources
Compromise the hosting infrastructure
Hijack the server and use the server for other attacks
Hacking activity mitigation Mitigating this vulnerability has proven to be difficult, but we have been observing and learning from all the hacking activities. Now, along with our intrusion prevention detection system, we’ve made security tweaks on our webservers, and trained a diligent team. As a result, we have been able to protect our customers and our infrastructure.
Hacking activity background We first noticed there was an issue when our intrusion detection system indicated a potentially malicious process being started on one of our servers. Our team immediately investigated and after some work we pinpointed the site that was compromised, determined how the site was compromised, and addressed the hack.
We soon started to notice similar incidents and after further investigation some of the flagged activities turned out to be false positives (legitimate activities), while others were hacking attempts. The attempts started to increase to almost daily at its peak.
Why the hack is nasty What makes this hack nasty is that it uses built-in functionality of the Telerik control to upload a payload to the compromised site. The control functionality is used by the website so it is extremely difficult to tell which use case is legitimate and which activity is a hacking attempt.
To make things harder to detect, much of the hacking activity uploads a payload that does not interfere with the website and many times the payload appears to do nothing but sit there. Presumably, the payload will “wake up” when the hacker decides to activate it at a future time. Therefore, the website owner would never know they got hacked and the host will never know unless specifically looking for this type of activity.
Another thing we’ve seen recently is a site being compromised but the hacker did not upload anything. The hacker is just probing and logging which sites are “hackable” for some future plan. It’s like if someone breaks into a home using a key, looks around but doesn’t move anything or take anything and leaves. How are you to know someone who should not have access had entered the home?
Windows hosts beware Windows hosting providers really need to pay attention to this hacking activity going forward. This vulnerability may be old but it’s still very much alive and hackers are exploiting it to compromise Windows servers and leaving virtually no footprint.
What website owners should do In order to stop this attack from occurring in the first place, website owners must patch the Telerik Web UI component within their application which is typically found within the /bin folder.
You can check the table below on what actions to take depending on the application using the Telerik Web UI Control and where you host your website.
Application
Website hosted with DiscountASP.NET
Website hosted elsewhere
DotNetNuke
Contact our technical support team and we can check if your site is vulnerable and our staff can apply a patch to secure your DNN instance.
Contact our technical support team and we can check if your site is vulnerable and provide you with guidance on the next steps.
Check if you are using the insecure Telerik Web UI versions listed here. Check your website files on the server and make sure there are no weird files (that you did not upload). If you own the Telerik license, contact Telerik and patch your site. If your developer owns the Telerik license, have them contact Telerik and patch your site.
I’m proud to announce that we have successfully renewed our Microsoft Silver Partner status for 2020-2021. We renewed with two competencies – Silver Datacenter Solutions competency and the Silver Cloud Hosting Platform competency.
We’ve updated to the latest build of SmarterMail which includes some highly requested features. One of these features is the option to enable Two-Factor Authentication to help prevent unauthorized access to your email accounts.
If you want to enable Two-Factor Authentication, first contact our support department to have this feature enabled for you Then log into the mail server either through the DiscountASP.NET control panel or accessing webmail directly via your domain.
Then go to: Settings (Gear icon) Look for 2-Step Authentication Option Click Enable.
You will then be able to select if you would like the verification code to be sent via email or with an authenticator application.
If you select email, please make sure that you have access to the email you chose since the verification codes will be sent to that email address. If you do not receive the verification email, check your Spam and Junk folders.
Once Two-Factor Authentication is enabled, you will be prompted to enter the verification code the next time you access your email.
Over the past years, Microsoft has been continuing their rapid deployment initiative and releasing minor versions of .NET Core on their own schedule and without much fanfare as was the case with past releases of ASP.NET. (In the past, Microsoft ran entire conferences to push out new ASP.NET versions – remember MIX?)
While we have been keeping pace – as much as we can – with the cadence of .NET Core releases, because of the frequency and low fanfare from Microsoft, we haven’t been making announcements about it. Lately, we’ve seen an increase in questions from customers and potential customers alike on whether or not we support a particular version of .NET Core. So we will start to announce server support for particular .NET Core versions.
So, I’m announcing today that .NET Core 3.0.3 and .NET Core 3.1.3 are both installed on DiscountASP.NET servers. This means that you can deploy apps built with .NET Core 3.0.3 and .NET Core 3.1.3 using framework-dependent deployment (FDD).
We keep a list of the .NET Core versions that are installed on the servers in this knowledge base article.
You’ve no doubt have been keeping up to date about coronavirus and all the precautions being taken across the world. We had to make some adjustments like many of you.
Lat week, the day after COVID-19 was declared a pandemic, we asked our staff to start working from home to keep our DiscountASP.NET staff safe and healthy. Yesterday, California instituted a “stay at home” order which means for the foreseeable future our staff will be working from their homes. We’ve always had the systems set up to work remotely, but this will be the first time ALL of our staff will be working from home. So there is going to be a little learning curve as we get used to this new normal.
Please be assured that the level of service you expect from us will not change during this unprecedented time, even though our staff may be working in their pajamas.
If you have questions or concerns, please feel free to contact us.
We have seen a few of our customers experience malicious bots making repeated efforts to break into their WordPress login page. There are a few issues that arise from this activity. Not only is it annoying but this can eventually crash your site by using up your server resources. It can also lead to your WordPress site getting hacked since that’s what the bots are trying to accomplish.
