Last summer I wrote about Mitigating Security Concerns if you couldn't update your environment to a known "fixed" version. Over the past ten months since writing that post, I have been monitoring the various known security exploits for the platforms I interact with and mitigation methods. In doing so, I have identified a key pattern and options to help reduce your risks in the interim.
Recent Patterns
In recent months, I have noticed a pattern of continued automated attacks being issued against websites that are using specific software platforms. These attacks are often 100% automated, with the attacker's process "flagging" those sites that were successfully compromised for later exploit via manual processes.
Chained Exploits
This pattern of attacking in multiple steps was less common years ago but can be incredibly dangerous. When initially attacking the site, the automated process will typically do NOTHING that visually changes the web application. The usual attack vector is to upload a Rootkit that will allow users to perform various actions later.
These rootkits typically provide an interface for users to upload/modify files, run SQL queries, and do other sorts of actions. Since the initial attack is often un-noticed, these files can live on servers for MONTHS before they are finally exploited. From the sites, I have personally cleaned in the past year, the longest time from initial hack until actual exploit was just over 11 months.
This creates a huge issue as many people do not keep their logs for that long, so our ability to track back to the initial activity can be hard. Taking this a step further, let us dive into one of the most common exploits we see today.
Telerik CVE's Exploitation
Over the past year, numerous CVE (Common Vulnerabilities & Exposures) notices have been published for a wide swath of Telerik versions from 2009 through 2019. Telerik is one of the most popular providers of UI components for .NET developers and is leveraged in many forms of both commercial and even some open-source software, such as DNN; this provides a great target for those that want to do things maliciously.
The crux of the issues exposed in the Telerik CVE's are methods that allow unauthenticated file upload. Since Telerik provides services with common file paths, it is possible for someone to totally automate attacks by simply trying the same thing, site-after-site, until it works. They can use services such as BuiltWith or similar to get lists of sites that are using various technologies. They might even be able to do a simple Google search to obtain a list.
The exploit process from here is quite simple; they exploit Telerik and upload a .aspx file to the server and check to see if it was created. If so, they have planted their channel in and flag the site as exploited. The added file will be something simple, maybe skin.aspx, or even default.aspx but in an unusual directory. Uploads of this manner will often go unnoticed; however, if you look at file the actions it often supports can be alarming.
Fine - Lets Mitigate It
The first assumption that everyone always jumps to is to mitigate the issue by following the Telerik suggestions. Well, this can often be more complicated than you might imagine as reading into the suggestions many times you must UPGRADE Telerik versions to accomplish this task which can be met with issues.
- Breaking Changes - Many of the upgrades have breaking changes, for example, upgrading from 2013 to 2020 has more than 300 breaking changes that could impact development teams.
- License Issues - This could be in the form of expired licenses, defunct agreements, or otherwise.
Obviously, this is the best course of action, but what else can we do?
Web Application Firewalls
This is where the world gets interesting. We have known about services such as CloudFlare or otherwise. However, many people have been focused on performance or DDoS preventions. However, the true power comes from their automated bank of known protections that you automatically get as subscribers.
As a subscriber on the $20/month plan with Cloudflare, they have a built-in firewall rule that blocks the Telerik CVE exploits at the firewall, preventing your application from being accessed. I have tested their rules against running sites that were actively being attacked, and every time it has stopped the attacks. You might have to remove any prior hack files from the site, but after implementing Cloudflare, it will buy you time.
Great! Lets Just Do Cloudflare
This is the most common response that I will get when talking to folks after demonstrating how Cloudflare has fixed the issue. It is imperative to understand that this is a TEMPORARY fix for the issue. The ultimate best solution is to remove the vulnerable components from your system as soon as practical. For some, that is as simple as updating your software to the latest versions. For others, it will require third-party solutions to update, removing the dependency on the older versions of the vulnerable solution. But the key is to understand that you are not magically "in the clear."
Identification of Prior Actions
Once protection has been added to your site, it is imperative to review and remove any signs of prior malicious activity. You will want to pay special attention to types of files that can be executed depending on the software installed on your environment.
- .aspx, .ashx, .asmx - Traditionally for .NET Support
- .php for servers with PHP enabled
- .asp - For all servers, as you MIGHT still have classic ASP enabled
The key here is to have your entire environment secured, especially including disallowing operation of languages/technologies you are not using. This audit process can be tedious but is very important. Often pulling the site locally and searching is the best course of action to identify files.
CAUTION: DO NOT rely on modification dates to identify potentially malicious files. The various rootkits can modify these dates, or the exploit could have been done months ago.
Closing Out
If you are running on a system with known vulnerabilities, the inclusion of a Web Application Firewall could be a key step in protecting your website's integrity. Even if not, Web Application Firewalls have many great long term benefits in the ever-changing world of internet security. However, it is important to remember that you are only as protected as your weakest link, block one door they might try to go after another or go through the already open window. Regular audits/review of your applications for integrity can be a key part of being safe, even on vulnerable systems.
Although this blog is primarily about sharing knowledge, should you find yourself suffering from a security crisis always remember that I am available for consultation through my company IowaComputerGurus.