Vansah — DevOps Security

Introduction

As part of a university project, we, a small working group of students, have continued to work on an existing website on, which the user can search for food trucks in his area and order food from them in advance as well as pay via PayPal. Upon completion of payment, the user chooses a pick-up slot of 10 minutes. On the one hand, this should enable food truck owners to better plan in advance how many meals they need to prepare each day and thus produce less waste. On the other hand, customers do not have to wait long for their food and have already paid for everything when they pick it up.

You can check out the website at www.vansah.de.

Architecture

The website was created with WordPress. In the backend runs a SQL database, which contains all relevant data (food truck data, user data, food prices, etc). The development and implementation of new features is currently still done directly on the live system, which of course implies some risks.
During this course at the university I started to build up a CI/CD (Continuous Integration/Continous Delivery) pipeline. For this purpose, several Docker containers are used, each of which contains a part of the system. Docker already offers usable images for this, which allow the use of for example WordPress or a mySQL database. To commonly use several of these containers, one creates a docker-compose.yml file, which defines the dependencies of the containers among each other.

The purpose of this setup is to run a local version of the live system at each of the individual developers, where they can develop and test new features without running the risk of crashing the whole website.

From this local environment, new features are uploaded directly to the Git repository. In the future, the deployment to the live system will be done from that repository via GitHub Actions, thus accelerating the development process and reducing the risk of faulty builds. The goal is to include the later presented security solution into this pipeline.

Where do we need Security?

According to the latest content management system usage data from W3Techs, WordPress powers 34% of all websites today. So WordPress vulnerabilities are inevitable, because not all users are careful, thorough, or security-conscious when it comes to their websites. If a hacker makes his way into one of the hundreds of millions of WordPress websites on the web, he can look for other websites that also use similar insecure setups of old or insecure WordPress versions and breach them as well.

WordPress is based on open source code and has a dedicated team specifically dedicated to finding, identifying and fixing WordPress security issues that occur in the core code. As soon as security vulnerabilities become known, fixes are immediately released to address any newly discovered vulnerabilities in WordPress.

It’s important to note, that WordPress security vulnerabilities often extend beyond the WordPress core and specifically affect the plugins and themes you install on your site. For example, they allow you to easily integrate a payment process via PayPal, or translate your website into another language.
According to a recent report by wpscan.com, of the approximately 3,000 known security vulnerabilities:

• 75% originate from WordPress plugins
• 14% originate from WordPress core
• 11% originate from WordPress themes

Furthermore, of course, there are still the same threats that non-WordPress are exposed to. The most common attacks include:

• Brute Force Attacks, where the attacker tries to gain access to the administration area, in our case the WordPress backend, by automatically testing various username and password combinations. There are multiple tools out there, like “Hashcat” oder “John the Ripper”, that allow even inexperienced people to launch a brute force attack.
• File Inclusion Exploits, after Brute Force Attacks, are the next common security issue, especially in WordPress projects. Any WordPress project runs on PHP, which also powers all of the used plugins and themes. File inclusion exploits occur when vulnerable code is used to load remote files that allow attackers to gain access to your website. These exploits are one of the most common ways an attacker can gain access to your WordPress website’s wp-config.php file, one of the most important files in your WordPress installation, as it holds most of WordPress configuration parameters. For this reason, the plugins are currently the biggest security risk of a WordPress website.
• SQL Injections, which aims to attack the SQL database that is used by almost any WordPress website. SQL Injections can be used to insert new data into your database, including links to malicious or spam websites. This works by the attacker attempting to log into the attacked database either via a brute force attack or by exploiting an insecure login and then inserting any new malicious data.
• Cross-Site Scripting (XSS), which are the most occurring attacks on the entire internet and also the most common vulnerability found in WordPress plugins. The basic idea of Cross-Site Scripting works like this: an attacker finds a way to get a victim to load web pages with insecure javascript scripts. These scripts load without the knowledge of the visitor and are then used to steal data from their browsers. An example of a Cross-Site Scripting attack would be a hijacked form that appears to reside on your website. If a user inputs data into that form, that data would be stolen. The injection of these unsafe JavaScript scripts are often possible via input fields on a website where the entered string is not sanitized, which in this case means checking the entered string for the HTML <script> tag, for example, which would allow the injection of foreign code on that page.

So, which of these possible attacks is likely to be executed on our website, or further, how can we ensure that there are at least no major security vulnerabilities?And how can we integrate the verification of this into our development process and the CI/CD pipeline?

Analysis

In order to find a solution to these problems, we will now step by step analyze exactly which attacks an adversary would be capable of and what the requirements for website security are accordingly. Afterwards, two tools for solving our requirements will be presented and one of them will be described in more detail.

What may attackers try?

With the knowledge of the just listed vulnerabilities of WordPress and websites in general, you can relatively quickly get an overview as an attacker. In the case of our website, one notices that there are almost no input fields. The risk for a successful cross-site scripting attack is therefore very low. Also the administrator passwords are not easy to guess and an access to the WordPress backend is difficult for an attacker.If you try to gain access to the SQL database, also with brute force, you also have to realize that secure passwords are used and an easy access to the database is not possible.

The bigger problem, instead, are the plugins that are used. Their relatively high number makes it difficult to always keep a good overview of whether all plugins are on the latest version and to inform oneself about possible security vulnerabilities of individual plugins. An outdated plugin containing potentially vulnerable code could be used by an attacker to include malicious files (File Inclusion Exploit). This might enable them to gain access to the wp-config.php file and thus possibly access passwords.

Consequently, the task is to find a way to automatically monitor the plugins in use and thus minimize the risk of an attacker exploiting any vulnerabilities in outdated code.

Solution ideas

If you’re looking for penetration testing tools for testing your WordPress and/or websites in general, that integrate well with a CI/CD pipeline, you can’t go past two tools:

WPScan and Nikto.

WPScan

WPScan is developed by open source volunteers led by Ryan Dewhurst. It is written in Ruby and is a vulnerability scanner designed specifically for WordPress. It is very easy to use and can be very effective, especially for WordPress websites that have problems updating their WordPress version or used plugins and themes. WPScan checks the core, theme and plugin versions of a website and alerts the tester if there are any vulnerabilities. In most cases, if a website has updated all elements to the latest versions, WPScan is unlikely to find any problems.
However, WPScan does not examine the source code of WordPress or its plugins. It is a remote scanner and is therefore well suited for black box testing, which means testing an application without actually seeing the exact technical setup. It therefore virtually simulates what a possible attacker would see without knowledge of the site’s infrastructure.

By default, the results of the scans are output directly to the Console. However, by specifying the log argument when running a scan, it is also possible to save the output in a text document for further processing.

It is possible to use WPScan completely for free, but if one wishes to access WPScan database, where all of the latest security issues are listed, one has to register to their API to get a user token. Up to 50 requests a day are free, anything above that costs a few dollars.

Nikto

Nikto is a free to use website vulnerability scanner. It takes much longer than WPScan, about 30 minutes for an average sized website, as it is testing much more possible vulnerabilites of the scanned website. Also, Nikto contains many security testing plugins, all of which are enabled by default when a scan is performed. This generates a significant number of requests to the tested website during a scan. Nikto tends to generate many false positives, so you need to evaluate the data found by Nikto to verify which are real vulnerabilities and which are not.
As with WPScan, it is possible to have the output of the scan written to a text file and use the result that way.

Which solution suits us best?

The security feature to be built into the workflow when developing the website has two requirements. The first is to focus on the scan of possible outdated software versions of WordPress and the plugins as well as themes used. On the other hand, the time required for a development cycle should not be too great, so that the deployment of new features is possible within a few minutes.
Nikto covers a large number of possible security risks, but the scans are also correspondingly lengthy and the output is difficult to process due to its sheer size. Furthermore, many of the possible vulnerabilities scanned are not of interest to Vansah’s relatively small website at the moment.
WPScan, on the other hand, is tailored to scan WordPress websites and search for outdated plugins, and the like. A scan only takes up to a few minutes and provides a clear output summarizing the issues found. The only disadvantage of WPScan is that the use of the database, in which all known vulnerabilities of various WordPress plugins as well as themes are stored, costs something after a certain number of API calls (as described above). But in view of the fact that the scan and further processing of the output should be as automated as possible and the developer should only see which software needs to be updated, WPScan is probably the better solution for our use case. However, should the website grow larger and perhaps no longer run on WordPress, it might be worth taking another look at Nikto.

WPScan in detail

WPScan can be installed in several ways. However, Ruby must be installed on the executing machine in any case, since WPScan was written in Ruby. WPScan itself can be installed either with the Packet Mangager “gem” of Ruby or under MacOS with homebrew. To do this, run “gem install wpscan” respectively “brew install wpscanteam/tap/wpscan”. WPScan is also available as a Docker application, which requires the installation of Docker and the command “docker pull wpscanteam/wpscan”.

As already mentioned in the previous section, you need your own API token for full access to the WPScan database. WPScan can also be used without this, but only offers a rudimentary scan. To generate such a token, you need to register at the WordPress Vulnerability Database API. Up to 25 API calls per day are free of charge. Once you have generated your personal token, you can start using WPScan. A scan is started with the simple command “wpscan” and the passing of several parameters, such as the URL of the WordPress site to be tested, as well as the generated API token. After executing the command, WPScan starts analyzing the WordPress website and documents the results in the console. Based on these results, developers can then fix security vulnerabilities or verify that their website is up to date and secure.

But what exactly does WPScan scan now? Basically, all data that is publicly accessible is scrutinized and analyzed. The biggest part of it is examining whether the latest version of WordPress is installed and which plugins, as well as themes, are up and running to see if there are any known security vulnerabilities associated with them. Furthermore, WPScan offers the possibility to simulate a password brute force attack by testing the strength of the passwords used. Finally, WPScan can also examine whether there are backup files that are publicly accessible and reveal sensitive data. Thus, a good all-around check of the WordPress project is performed to ensure a good overview of the website’s security situation. It is also possible to use only some of the features just listed by passing certain parameters to the “wpscan” command.

Implementing WPScan into the developing process

As mentioned in the intro, as part of the course at my university, I set up the entire WordPress project locally with Docker to provide a development environment where all developers can develop hazard-free and easily. Also, eventually there should be a complete CI/CD pipeline so that the workflow can be further optimized. The security feature that WPScan offers is now to be built into this process. Since WPScan also offers the use of the software in Docker and the local project also runs in Docker, it only makes sense to use the Docker interface offered by WPScan. For this, it is necessary to update the docker-compose.yml and add the WPScan Docker image to it, so that the containers can communicate with each other via the defined ports.

The workflow now looks like this:
A developer starts building a new feature for Vansah.de. He starts his local development environment, which pulls the current state of the page from the Git repository and sets up the website for him locally with Docker. For this, there is a so-called “makefile” in the project, which starts all further commands under one command (in this case “make run”). Now he develops the desired feature or installs new PlugIns and so on. As soon as he is done with his work, the local development environment will be closed with another command (“make done”) and the new code will be pushed to GitHub to be deployed from there. However, in the logic of the makefile, before the new features are uploaded, WPScan is now run. The results of WPScan are stored in a text file, where a text analysis script summarizes and analyzes them for relevant security vulnerabilities. If everything is in order, the newly developed feature is uploaded to GitHub and the development cycle can start all over again. If a security risk has been discovered, it must first be fixed before the upload is permitted.

Conclusion

Implementing a security feature already within the development processes is not that difficult after a little research. It is more difficult to know which security gaps your own application may have and to find and integrate the right security software accordingly.

Focusing on the security of an application already within continuous development is a concept called DevSecOps, which is essentially a renewal of DevOps. In the past, development was a linear process, meaning that the software was first planned, then implemented and delivered, and afterwards security vulnerabilities were checked for. With the increased emergence of agile development cycles, DevSecOps has evolved, which has the premise of already including security in every development cycle.

This requires not only reengineering and redesigning development processes, but also making all developers aware that the security of the software is their responsibility. Software security must be an integral part of every development project. To introduce developers to the topic of security in a playful way, the site OWASP, for example, offers a project called “Juice Shop”, which is basically a dummy website with various security vulnerabilities on which developers can experiment and try to track down leaks as a team and thus score points.

I think that it will be highly rewarding and indispensable in the future to familiarize your development team with the principles of DevSecOps and thus build better, more secure applications.