Happy Holidays everyone. Did you know that the United States Post Office left an unpatched security vulnerability in an API that let users scrape information about any one of the millions of people in their database, and more terrifyingly, update that information? This hole was in place for over a year since its discovery. Despite the fact that the USPS swears it has no evidence that someone abused this hole, I’d be surprised if someone didn’t.

So, let’s jump back to a topic that we first discussed back in August, and that’s how people break into your website (or API) in the first place. Back then, we discussed JPEG images that can be uploaded with a completely valid shell inside of them, but let’s talk about a method that is a lot more common, remote code execution.

This can take a lot of different forms. We’ve noticed a number of WordPress plugin authors do it, mostly by mistake. It’s especially common in systems meant to patch or update from a centralized server. But sometimes its as simple as not double checking that the image you’re loading into an element really is an image, and not some kind of executable document. In every case, the problem is that some code is loaded, either into the server process or the client browser, that can be replaced with malicious code.

Remote code execution is the same type of exploit that Spector and Meltdown allowed on processors.

Give me some real-life examples.

Okay, I’m going to discuss these in the abstract, but each of the following really happened.

In older versions of some popular homepage slider plugins, the plugin could be tricked into loading remote JavaScript or PHP code, allowing attackers a relatively simple way to get full access to your file system and database without ever having to upload their code.

Several popular modification extensions of OpenCart and WordPress scripting files to apply modifications to your framework, and these files can just as easily completely break your website as easily as they can install a new payment processor for you. You’re relying on the developer you got that script from to have your best intentions at heart.

Sometimes, developers will allow code execution to facilitate debugging certain features, maybe something as limited as reading out the contents of certain files, but look, they forgot to limit that to certain file extensions. Which means I can just have that debug flag read me your database credentials, and if you’re running MySQL on the default port with remote access enabled, the jig is up.

It can even be as simple as downloading a JavaScript library from a CDN. All of the large reputable CDNs work hard to ensure that their files are well maintained and only updated by authorized users, but all it takes is one mistake on their part and then malicious files are caching to millions of users.

This may not just be the bane of your users, but your security. If you aren’t using your update/maintenance scripts, consider disabling them.

So What Do You Do?

First of all, update your software as often as you are able. A lot of vulnerabilities occur due to simple errors that are caught and fixed in relatively short order, but a single exploit can have a lifetime of years because website owners and webmasters are frequently not on top of keeping their software up to date. It’s often a thankless job that never gets noticed until it sits undone for months or years, but it is vital to the continued security of your website or web application. If your application does have compatibility issues with an update (which is not uncommon for major version updates), you should work with your team to come up with a solid upgrade plan and a strategy for minimizing risk until the plan can be enacted.

Next, you should be an informed consumer. Before you install a plugin or a modification for your website, you should do some research into it. Look for known vulnerabilities, but also look into how compatible it is with what you are already using. You can accidentally introduce new vulnerabilities through plugin combinations.

Additionally, you should periodically audit your security. Audits can take several forms. Simple self-audits can involve nothing more than doing the research mentioned previously every couple of months to see if anything new has been discovered. A little more in-depth process could have you or a hired professional actually attempting to break into your website to identify potential flaws in your current security. It really depends on the needs of your business, the information you have that can be stolen, and the budget you can put into this task. Please don’t misread that last item as justification for not doing your due diligence on security, but it is a reality that not every business can afford a team of pen-testing experts to ensure the best security in the world.

You should also consider the necessity of having certain systems available for use on your website at all times. If you worry that an update script might leave your site vulnerable but still need it to apply updates, a solution may be to disable it completely when you aren’t actively using it. Security is all about minimizing risk, and if a system can only be used when you need to use it, it drops the risk off substantially, but be warned, it cannot remove it completely.

Lastly, be aware that no solution is perfect. You should always have a plan for what you need to do if things go wrong.

With updates being released all the time, it can be a hassle to keep up, but the benefit to your security cannot be understated.

How Can We Help?

We are passionate about security. We provide penetration testing services. We can be contracted to do periodic updates to your website for you. We have several security solutions that can be purposed to the security problems your business faces. Contact us for more information on our security recommendations and how we can help you achieve them.