Gehaxelt – How WordPress Plugins Leak Sensitive Information Without You Noticing – 10 minute mail

Sebastian Neef (@gehaxelt) is a IT security freelancer and a top contributor from the Disposable mail Crowdsource community. In this guest blog, he looks at ways WordPress plugins leak sensitive data in the wild:

Guest blog post from Crowdsource hacker gehaxelt

The OWASP Top 10 puts Sensitive Data Exposure on the 3rd place of the most common web security issues. In this blog post we will have a look at sensitive data exposure that you might not be aware of. 

WordPress is probably one of the most used Content Management Systems out there. The vast amount of available WordPress plugins certainly plays a huge role, as it allows your WordPress blog to become a full-fledged online shop (i.e link: woocommerce). But relying on 3rd-party plugins to customize your blog or shop comes with certain security risks. There are no restrictions on who can publish a plugin on wordpress.org, so the code quality and therefore security can vary a lot. 

I have analyzed how the most popular WordPress plugins leak information with remediation tips so you can continue using WordPress in a more secure way. 

This research was part of my attempt to get some more valid submissions to the Disposable mail Crowdsource platform, so my focus was only on the top-ranking WordPress plugins. To qualify as a valid submission for Disposable mail Crowdsource, the vulnerable plugin needs to have at least 300,000 active installations and the issue needs to be exploitable remotely without any form of authentication. At least for the information disclosure the criteria was met for the following plugins: 

* A module for this plugin was not implemented due to an increased request complexity.

Taking all installation counts from the above list together and assuming that one installation equals one website, we end up with about 19 million websites that are potentially affected by an information leak issue.  

Let’s first have a look on what kind of information is leaked by those plugins. I think there are three categories of leaked data, which also seem to match with certain CWE (Common Weakness Enumeration Database) categories:

    • Credentials (CWE-200: Information Exposure)
    • Personal Identifiable Information (PII) (CWE-359: Exposure of Private Information (‘Privacy Violation’))
    • System Information (CWE-215: Information Exposure Through Debug Information)

Credentials

From the attacker’s perspective, gaining access to credentials is the jackpot. It might allow them to obtain usernames, passwords or API keys that could be used to escalate their privileges. A WordPress administrator account is allowed to edit themes or plugins, thus gaining remote code execution is trivial. Leaked API keys are no better, because they might allow the attackers to abuse them, gain unauthorized access or just create huge financial damage.

Here’s a list of things that fall into this category and that I’ve seen leaked:

    • Passwords to protected posts
    • Backup files or zips
    • SMTP credentials

Personal Identifiable Information (PII)

The next level in the hierarchy is, in my opinion at least, personal identifiable information. Especially in 2020 with the new digital information processing laws and GDPR, it might become a company’s nightmare if customers’ PII become public due to hefty fines. For that reason, I was even more surprised to find several plugins to leak the following customers’ or users’ data:

    • Names
    • Email addresses
    • Usernames

System Information

The third category comes down to the remainder of information about the system running WordPress or its configuration. Most of the following types might not have direct, critical security implications, but could still give the attacker useful information for more sophisticated exploitation chains. Most of the WordPress plugins were leaking the following information:

    • Internal host names 
    • Database tables, SQL queries
    • Security logs
    • Full path disclosures
    • File names
    • Software versions (OS, PHP, MySQL, WordPress)
    • PHP Configuration (safe_mode, memory limits, execution limits, etc)

So far we have discussed what plugins leak information and what kind of information is leaked, but we haven’t looked at how this information is potentially exposed to the attackers. 

At the core, the issue lies within WordPress’ file permission scheme which mentions that the wp-content/ folder should be writable, because some plugins might need write permissions there. Depending on how secure you or your WordPress administrator is, the whole wp-content/ might have full rwx permissions, and therefore most plugins choose to create directories and files there. 

This is not a problem by itself, but becomes one as soon as some plugins begin to create log files with the above discussed information that the web administrator does not know about. Plugin developers are not guaranteed a writable “data” folder outside the document root, where they could securely store such log files containing sensitive information in a non-volatile way. PHP’s sys_get_temp_dir could be an option, because it is system agnostic (not everyone runs Linux), but it might not offer persistence. The latter is pretty important for log files. Therefore, most plugin developers opt for a folder that they can assume to be writable on most WordPress installations as this stackoverflow thread suggests:

    • wp-content/uploads/
    • wp-content/*

The former works in most cases, because files uploaded through WordPress’ media library end up there, so it is writable to not break core functionality. The latter includes all subfolders, such as wp-content/plugins/ or wp-content/themes, if the administrator wants to easily install new plugins or edit themes.  

If you are a security-minded person and you are running a WordPress instance, now is the time to ask yourself if you have reviewed the source code of all active plugins, or did you simply install a plugin, because someone needed it to change the website’s functionality? You should review your plugins, but first continue reading to know what you should look for.

I have noticed two different patterns that developers use to create log files, and only one of them has basic security principals in mind. However, both approaches become ineffective security-wise once the administrator forgets to properly configure the web server. Therefore, we cannot just put all blame onto the WordPress plugin developers for leaks, but we need to reinforce basic security principles at any time.  

Static file paths

Developers are not naturally security experts, and often they focus on building solutions that work. There is nothing easier than using WordPress’ wp_upload_dir() or WP_CONTENT_DIR to obtain the path a writable folder and appending a plugin specific suffix. 

Here is a list of example paths:

/wp-content/all-in-one-seo-pack.log
/wp-content/uploads/mc4wp-debug.log
/wp-content/uploads/wp-google-maps/error_log.txt
/wp-content/plugins/ewww-image-optimizer/debug.log
/wp-content/plugins/all-in-one-wp-migration/storage/error.log
/wp-content/plugins/all-in-one-wp-migration/storage/import.log
/wp-content/plugins/all-in-one-wp-migration/storage/export.log
….

Let’s recall that the wp-content/ folder lives in the DocumentRoot is accessible from the internet, thus all the files within it are usually accessible, too. This makes it trivial for an attacker to access those log files and their content by navigating to the well-known paths.

Random file names

A good portion of the plugins implemented their logging functionality with more security in mind. By adding a random portion to the file name, it cannot be requested directly without knowing the random part.

Depending on the implementation, the portion’s randomness varied greatly:

  • an incremented 6-digit number (not really random)
  • a randomly generated string
  • a cryptographic hash (MD5 or SHA)
/wp-content/cache/log/000000/dbcache.log
/wp-content/logs/newsletter/antibot-2018-09-87agc333.txt
/wp-content/uploads/wc-logs/geoip-2019-03-17-57e9aab19e941762b0e731c2f65dc325.log
….

To a developer, this approach might look pretty robust and secure, but it disregards the fact administrators also play a role. Given that WordPress is an entry-level CMS, it might be set up and operated by novice administrators, who just followed a tutorial “to make things work”.

The file name randomization is instantly defeated if the administrator (accidentally) forgets to turn off “directory listing” on their web server. In such a case, an attacker just needs to browse to the respective folders to get a list of the random file names. 

index of /wp-content/uploads/wc-logs

While working on this topic, I have found several examples of such misconfigured web servers on the internet. It is not just a hypothetical scenario. 

If you have made it this far, you might be asking yourself how I discovered all those log file disclosures. I will happily answer this question in this section, so that you can review your own plugins.  There were basically three approaches to this topic: 

    • Find existing files
    • Review the plugins’ source code
    • Use a search engine

While the first method did not show anything interesting in particular, the second one was the most fruitful, but also the most time-intensive. There were over 115 plugins to review, so naturally I could not invest the time to do a thorough in-depth source code review, but rather took some shortcuts and educated guesses. Last but not least, I used search engines to discover files that I might not have seen with the two methods before. 

Let’s have a look at them in detail. 

Find-ing existing files

find is a small linux command line tool to quickly find files or directories in a file system hierarchy. After installing some plugins, I ran it on my test WordPress instances like this:

$> cd path-to-wordpress/wp-content/
$> find . -type f -name ‘*log*’ -ls 
$> find . -type f -name ‘*txt*’ -ls
987828	4 -rw-r--r--   1 gehaxelt gehaxelt  	229 Feb  9  2018 ./sc_cache.txt 

This showed me a few files containing log or txt, thus matching either of the two regular expressions. It is by far the most efficient method to check if such files exist on your web server. If you are administering any WordPress instances, take a note and check your web servers  after you have finished reading.

Source Code Review

Most of the work done was source code review using a few lines of bash, grep and less. 

As the first step, I downloaded all plugins with more than 300k installation from the wordpress.org website and extracted them into separate folders. A few lines of python helped with that task. 

The next step was to look for and identify paths where log entries are written to. PHP offers a few methods such as file_put_contents or fopen to create files. By having access to the source code, using the command line text searching tool “grep” was a suitable choice. Keywords such as “file_put_contents”, “file_get_contents”, “fopen”, “log”, gave a good idea where to look for. 

From there, it became going bottom-up through the code and deducing where the file would be written and if it is randomized or not. 

Google Dorks

(Ab-)using search engines and their specific search keywords for security purposes is often referred to as “dorking”. No sophisticated hacking tools are required for such an attack, just a web browser, a search engine such as google and a query like inurl:"/wp-content/uploads/wp-google-maps/error_log.txt" would be enough to find a whole lot of affected websites.

I took the route of searching for a plugin’s directory name while adding keywords like log or txt etc. It gave mediocre results, but that was better than nothing and also helped to verify the findings from the previous step. 

Overall the results using this method are limited to web sites that usually have DirectoryListing enabled and make their contents indexable by certain search engines. 

We all know that breaking things is much easier than fixing it. I tried to come up with ideas for how to prevent such information leaks to make the ecosystem more secure.  

Rule #1: Use randomized file names

Static file paths make it insignificant for an attacker to check the existence of a file and download it. Using randomized file names might take a bit more time for a developer to implement, but boosts the security immensely. Especially since the majority of web servers should have directory listing disabled, so that an attacker cannot guess the correct file name. 

Rule #2: Prevent directory listing

Even the scenario of a directory-listing enabled web server can be mitigated by the plugin developer: For every folder that is created and where plugin-specific log files are written, an empty index.php file should be created. On literally every web server the index.php file is configured as the DirectoryIndex, meaning instead of showing all contents of a directory, this file will be executed. As an empty file has no content, the attacker won’t see a list of file names, but an empty page. 

Rule #3: Workaround

If Rule #1 and Rule #2 are not followed by a plugin, then one could try to move the created folder outside the “DocumentRoot” (i.e. using a symlink). Alternatively, explicit rules must be created to prevent access to static or randomized log files. Depending on the used web server, simple “.htaccess” files could be used. 

Rule #4: WordPress hardening

The WordPress developers have a lengthy article on WordPress security and hardening. At the time of writing it contained a neat statement which fits this topic perfectly: 

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. 

It is always a good idea to go over this article and check if oneself has considered and implemented the given hardening tips.

To round this section up, I firmly believe that most plugins should be able to implement and follow Rule #1 and Rule #2. The other two rules, Rule #3 and #4, lean more towards the side of the system administrators, but we cannot take them out of the equation. If a WordPress instance is provided for you, don’t forget to ask the responsible administrator to go over the issues mentioned in this article.  

All of the initially listed WordPress plugins and their potentially leaked log files have been implemented into Disposable mail’s automated security and asset monitoring since September – November 2019. The security modules will give you insight into which log files on your web server are discoverable by an attacker. That means, the modules can:

    • easily identify the “static file path” log files 
    • detect the “randomized file path” log files, too, as long as the randomization can be circumvented with the method discussed earlier

My research doesn’t stop here. I am continuously pursuing this topic in order to bring more log file disclosures to users to secure more websites through the Disposable mail and the Crowdsource platform.

 

Written by:
Sebastian Neef
IT Security Freelancer and Disposable mail Crowdsource hacker

Sebastian Neef (@gehaxelt) is a security researcher at heart and has been interested in IT security since the age of 15. He became an IT security freelancer and consultant during his A-Levels back in 2012 when bug bounty and responsible disclosure programs were just starting out. Sebastian enjoys sharing his knowledge on conferences or his blog 0day.work, breaking things, playing CTFs with ENOFLAG and helping companies to improve their security. 


How can Disposable mail help?
Disposable mail works with highly skilled ethical hackers like Gehaxelt to crowdsource the most up-to-date security research. Check for the latest WordPress vulnerabilities and 1500+ other known vulnerabilities with a start of a Disposable mail scan. Begin your 14-day free trial today.

Additional reading:
Improving WordPress plugin security from both attack and defense sides

How to Improve Your WordPress Security: Plugins and Themes


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

OWASP TOP 10: Sensitive Data Exposure – 10 minute mail

Sensitive Data Exposure, an OWASP Top 10 vulnerability that often affects smaller players, can put critical sensitive data at risk. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series. 

Description

Sensitive Data Exposure occurs when an application does not adequately protect sensitive information. The data can vary and anything from passwords, session tokens, credit card data to private health data and more can be exposed.

A few examples would be exposed data that someone mistakenly uploaded somewhere, weak crypto that means an attacker would be able to read the data if they successfully compromised the target and the lack of headers that prevent browser caching. In short, every possible way where it would have been possible to better protect the sensitive data.

Prevalence

When building an application, many are going to down-prioritise protection of sensitive data, and even if the developer is aware of the fact that they should, for example, hash passwords, it is common to plan to do this afterwards. A workable application is the top priority and once the application is working, the planned protection is forgotten, or simply skipped.

Dealing with crypto is also one of the most difficult things to do. It is therefore common to make mistakes when implementing a self-built solution, which will result in insufficient protection of data.

Sensitive Data Exposure is therefore a typical vulnerability that is worst for small players, like hobby projects and smaller companies. However, as can be seen by looking at some well-known events, big players are affected by these vulnerabilities as well, but not as often.

Potential impact

As the finding only applies to sensitive data, the potential impact is always considered high. What the data consists of varies and so does the impact. The danger lies in the data being exposed, and the potential impact reflects the data’s sensitivity.

For example, if credit card data is stolen, the attacker can empty the victim’s bank account. If passwords are exposed, the attacker can abuse these credentials. If certificates are stolen, the attacker can pretend to be the target. It all depends on what kind of data is at risk of being exposed.

Exploitability

Most crypto-related vulnerabilities are considered hard to exploit, especially on a larger scale. With that said, some of the vulnerabilities that fall into this category are really easy to “exploit”. If an attacker were to get hold of a database that had been left unencrypted, they would not need to do anything special at all to access sensitive data. With a layer of protection removed from the attack process, exploiting the vulnerability can be considered easy.

In general, with the exception of strictly crypto-focused ones, the vulnerabilities within this category are likely to get exploited.

Well-known events

100 million passwords in plain text from VK.com have recently been leaked. That means that the attacker could, after getting access to the database, login as any user of choice. It also means that if a user were to use the same password on VK.com as on another site, anyone (as the leak is public) would be able to use these credentials to logon to that service and cause great harm.

Another example of a different vulnerability still within this category are exposed tokens in public source code. Many companies have mistakenly exposed private sensitive tokens on Github, which we have written about before. By searching for publicly available code, an attacker could get full access to internal communication.

How to discover

This is not a vulnerability that you can look for in the same sense as other more traditional vulnerabilities. Most vulnerabilities within this category cannot be scanned for due to two main reasons:

  • To determine risk, it must be decided what information is considered sensitive, which can be a hard task to carry out automatically.
  • An external pentester cannot know whether internal data is encrypted or not as that is not exposed.

To assess whether you are vulnerable to Sensitive Data Exposure, read the steps under Prevention and establish if any of the steps have not yet been taken. In most cases, this is the only way to identify this vulnerability type.

However, some of the findings can be automatically scanned for, such as lack of sufficient headers to prevent caching behind pages that require authentication or lack of HTTPS on logins.

How Disposable mail can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Disposable mail is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable » 

Example of vulnerable application

As the finding includes every case where sensitive data is exposed or insufficiently protected, the examples are many. To get an idea, here are a few of the most common ones:

  • Data stored in plain text, such as passwords or credit card data (see the first well-known event)
  • Lack of HTTPS on authenticated pages
  • Hashed passwords with lack of salt, making the password easily cracked
  • Tokens disclosed in public source code (see the second well-known event)

Prevention

The first step is to figure out what data can be considered sensitive and therefore important to protect.

When that is done, go over each of these data points and make sure that:

  • The data is never stored in clear text.
  • The data is never transmitted in clear text. Example between database and server, or over the internet.
  • The algorithms used to encrypt the data are considered strong enough.
  • The generation of the keys is secure.
  • Browser headers are set to not cache when the sensitive data is presented to end-user.

There are more things to look for when securing data, but what matters most is understanding what data is considered sensitive, and make sure it is treated as such in every instance.

Read more

OWASP:
https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.