In the world of WordPress plugins, security vulnerabilities can have far-reaching consequences, especially when they affect widely used tools like Really Simple SSL. A recent vulnerability in versions 9.0.0 to 9.1.1.1 exposed websites to the risk of authentication bypass. However, the vulnerability only affected sites where the Two-Factor Authentication (2FA) feature was enabled.

This blog post explores how the vulnerability occurred, the steps taken to fix it in version 9.1.2, and key takeaways for developers to prevent similar issues in the future.

Understanding the Vulnerability

The vulnerability existed in the plugin’s Two-Factor Authentication (2FA) feature, which is disabled by default. Specifically, it affected the API endpoint reallysimplyssl/v1/two-fa/skip_onboarding, which was designed to allow users to bypass the 2FA onboarding process.

Interestingly, it was possible for an unauthenticated user to probe whether the site has the 2FA feature enabled by querying the WordPress REST API for the reallysimplyssl/v1/two-fa endpoint (note the namespaces below).

Root Cause

1. Improper Error Handling:
   • The function check_login_and_get_user validated the login_nonce parameter and attempted to retrieve a user object.
   • However, the calling function, skip_onboarding, ignored the result of this validation. Even if check_login_and_get_user returned an error, the process continued to authenticate the user and set an authentication cookie.
2. Unrestricted Access:
   • The endpoint was configured with a permission_callback set to __return_true, meaning any unauthenticated user could interact with it.

Exploitation

An attacker could exploit this vulnerability as follows:

1. Send a POST request to the skip_onboarding endpoint with:
   • A valid user_id (e.g., 1 for administrators).
   • An invalid or empty login_nonce.
2. The plugin would authenticate the user regardless of nonce validity, allowing the attacker to log in as the specified user and gain full access to the site.

It’s been given a 9.8 CVSS score as it’s really trivial to exploit. Some proof-of-concept code was developed to test and evaluate the issue further. It was possible re-create the issue and generate an admin cookie on demand. This cookie can then be used to access ‘/wp-admin’ as an administrator user.

The Fix

In version 9.1.2, the developers implemented two key changes to eliminate the vulnerability.

Immediate Termination on Validation Failure

The check_login_and_get_user function was updated to terminate execution immediately if nonce validation failed:

if ( ! Rsssl_Two_Fa_Authentication::verify_login_nonce( $user_id, $login_nonce ) ) {
    wp_die();
}

Stricter User Validation

The function also throws an exception if the user_id does not correspond to a valid user:

$user = get_user_by('id', $user_id);
if (!$user) {
    throw new Exception('User not found');
}

Outcome

These changes ensure that invalid requests are terminated early, preventing unauthorized access. The calling function no longer proceeds to authenticate or redirect the user if the validation fails.

Key Takeaways

1. Validate Inputs at Every Layer

Never assume that validation has already been performed. Validate inputs at each layer of your application, especially for public-facing endpoints.

For example:

• Check that required parameters (like user_id and login_nonce) are present and valid.
• Ensure retrieved data (e.g., get_user_by) is valid before proceeding.

2. Never Ignore Validation Results

If a function performs critical validation, its return value must always be checked. For example:

$user = $this->check_login_and_get_user( $user_id, $login_nonce );

if ( is_a( $user, 'WP_REST_Response' ) ) {
    return $user; // Stop execution if validation fails
}

3. Use Secure permission_callback Logic

While some endpoints, such as those for authentication, need to allow unauthenticated access, avoid setting permission_callback to __return_true without additional safeguards.

Consider adding checks for specific parameters or conditions:

'permission_callback' => function( $request ) {
    $user_id = $request->get_param('user_id');
    return is_numeric($user_id) && ! empty($user_id);
},

4. Handle Errors Gracefully

Avoid generic termination methods like wp_die() in REST API contexts. Instead, return structured error responses to help users debug issues securely. It’s likely that the current fix was to stop the vulnerability from being exploited, and that the code will be revised in subsequent versions.

5. Explore Endpoint Discovery Prevention

Developers may also consider measures to prevent unauthenticated users from discovering sensitive endpoints, such as limiting unauthenticated access or introducing additional authentication layers. While this wasn’t implemented in this fix, it’s a concept worth exploring for added security.

Conclusion

The authentication bypass vulnerability in Really Simple SSL underscores the importance of rigorous validation, secure API design, careful handling of public-facing endpoints, and ongoing training and awareness for developers.

Version 9.1.2 of the plugin successfully addresses this issue with stricter validation and improved error handling. It’s unknown how many users are using the 2FA feature, but the lessons here are relevant for any developer working with authentication or REST API functionality within WordPress.

This case highlights a broader truth: security testing must be an integral part of the development process. By thoroughly testing code for potential vulnerabilities, developers can proactively address risks before they become issues.

At BlogSecurity, we’re working on tools to make security testing easier and more accessible for developers. Sign up for our beta program to be the first to try it when it launches.

References

WordPress.org. (n.d.) Really Simple SSL. Available at: https://wordpress.org/plugins/really-simple-ssl/ (Accessed: 15 November 2024).

Montti, R. (2024, November 15). WordPress Security Plugin Vulnerability Endangers 4 Million+ Sites. Search Engine Journal. Retrieved from https://www.searchenginejournal.com/wordpress-security-plugin-vulnerability-endangers-4-million-sites/532701/

Wordfence. (2024, November 14). 4,000,000 WordPress Sites Using Really Simple Security Free and Pro Versions Affected by Critical Authentication Bypass Vulnerability. Retrieved from https://www.wordfence.com/blog/2024/11/really-simple-security-vulnerability/

SQL injection vulnerabilities are a persistent threat in web application security, particularly in platforms like WordPress where plugins often handle dynamic user input, and where a single bug could lead to millions of websites being impacted.

In this post, we’ll examine an SQL injection vulnerability discovered by Vincenzo Migliano in Perfect Survey v1.5.1 back in 2021. This was fixed a while back in versions greater than v1.5.1. Let’s dig in.

Understanding the Vulnerability

Understanding the vulnerability in Perfect Survey v1.5.1 requires a look into how SQL injection attacks exploit insufficient input handling within database queries. When applications accept user input without proper sanitization or parameterization, they risk allowing attackers to manipulate SQL queries directly. This lack of filtering and control can lead to vulnerabilities like SQL injection.

The vulnerability stems from how the question_id parameter is handled within the plugin. Specifically, the parameter is directly concatenated into SQL queries, opening the door for SQL injection attacks. What makes it particularly nasty is that it can be triggered by an unauthenticated user.

In the file PerfectSurveyPostTypeModel.php, the following line demonstrates the vulnerability:

$question = $this->wpdb->get_row('SELECT * FROM ' . $this->sql_table_questions . ' WHERE question_id = ' . $question_id, ARRAY_A);

Here, the $question_id variable is directly inserted into the SQL query. If an attacker manipulates this variable, they can alter the SQL command, potentially accessing or modifying sensitive data.

The Attempted Sanitization with prsv_input_fetch

The plugin attempts to sanitize input using the prsv_input_fetch function, which includes a switch statement designed to handle different data types:

function prsv_input_fetch($key, $default = 0, $type = 'int') {
$var = isset($_REQUEST[$key]) ? $_REQUEST[$key] : $default;

switch(gettype($var)) {
    case "boolean": $var = boolval($var); break;
    case "double":  $var = doubleval($var); break;
    case "float":   $var = floatval($var); break;
    case "string":  $var = sanitize_text_field($var); break;
    case "integer": $var = intval($var); break;
}
return $var;

The function casts variables based on their detected type. However, PHP’s gettype function determines the type based on the current value, which can be manipulated by an attacker. For example, if an attacker passes a string that looks like an integer (1 OR 1=1), gettype might still return string, causing the function to apply sanitize_text_field, which is ineffective in this context, but why?

The sanitize_text_field function is designed to clean text for HTML output, not for SQL queries. It doesn’t escape characters in a way that prevents SQL injection, especially when numeric values are expected and concatenated without quotes.

In the SQL query, the $question_id is not enclosed in quotes. Therefore, even if sanitize_text_field removes some malicious characters, an attacker can craft input that remains effective for injection without needing quotes.

While the intention behind the switch statement is to sanitize input based on type, it is not an effective method for preventing SQL injection. Sanitization should be context-specific and, for SQL queries, should involve parameterized queries rather than generic input cleaning. That said, I think the approach has merit, just not in isolation.

Testing for SQL Injection

To verify the vulnerability, we can craft a Proof of Concept (PoC) query that injects SQL code via the question_id parameter.

http://localhost:80/wordpress/wp-admin/admin-ajax.php?action=get_question&question_id=1 AND (SELECT 4595 FROM (SELECT(SLEEP(5)))x)

This URL attempts to inject a SQL command that will cause the database to pause for 5 seconds (SLEEP(5)). If the response is delayed by approximately 5 seconds, it confirms that the SQL injection is successful. For further confirmation, the timer can be changed to different values.

Please note: Perform this test only in a controlled environment where you have permission to test for vulnerabilities.

Fixing the Vulnerability

To address the vulnerability, you should use parameterized queries provided by WordPress’s $wpdb class, specifically the prepare method.

$question = $this->wpdb->get_row(
$this->wpdb->prepare('SELECT * FROM ' . $this->sql_table_questions . ' WHERE question_id = %d', $question_id),
ARRAY_A
);

$wpdb->prepare safely escapes the input and ensures it is treated as an integer (%d), preventing any injected SQL code from being executed.

Conclusion

This case study highlights the critical importance of proper input handling and query parameterization in preventing SQL injection vulnerabilities. The attempted sanitization using a switch statement in Perfect Survey v1.5.1, although useful, was insufficient. Here were the key takeaways:

Sanitize Appropriately: Use sanitization functions that are appropriate for the context in which the data will be used. In this case, the switch statement attempts to handle multiple datatypes, but the datatype is determined by user-input and may lead to unexpected behavior.

Parameterize Queries: Always use parameterized queries for database interactions to prevent SQL injection. An example fix was provided above.

Understand Limitations of Sanitization Functions: Functions like sanitize_text_field are not substitutes for proper query parameterization.

Ongoing education and continuous testing enable developers to identify bugs early on, strengthening applications and reducing security risks before they reach end users.

Do you want to simplify plugin security quality assurance? Sign-Up to the BlogSecurity Beta program to learn more.

Because WordPress provides so much power and flexibility, plugins and themes are key points of weakness. (WordPress, 2024)

The quote above highlights the significant pros and cons in the WordPress architecture. On the one hand, any developer in the world can contribute to the plugin or theme database; this supports the WordPress mission to democratize publishing and eCommerce. On the other hand, it has resulted in many plugins and themes with varying levels of code quality.

In 2022, a widely used plugin left an estimated half a million websites vulnerable to attack (TechRadar, 2024). Similarly, this year, a different plugin left more than one hundred thousand websites exposed (The Hacker News, 2024). In fact, while writing this, yet another plugin is affected, this time impacting over 6 million websites (Goodin, 2024).

Summary of Security Resources for Users & Developers

Some excellent resources are provided to assist developers in creating more secure and reliable code. Firstly, developers should make extensive use of the official developer documentation provided by WordPress (2024).

Secondly, WordPress has a plugin review process. Each plugin is checked to ensure that it at least meets some sort of minimum baseline before it is approved. Full details of this process aren’t clear, but if issues are identified, it could result in delays in getting the project published.

Finally, a number of supplementary resources exist to support individual WordPress installs (see Security on WordPress.com: A Developer’s Guide – WordPress.com Developer Resources). Options include hosted solutions, security plugins, website scanners, firewalls and much more. As plugin and theme developers, these resources are no substitute for creating high quality code.

Enhancing Code Quality

There’s a vast difference in the effort required to discover a vulnerability versus the effort to verify that a vulnerability exists. Verification is relatively straightforward, but the discovery process can be time-consuming and complex. For this reason, “prevention is better than a cure”.

To increase code quality, let’s begin by considering the Guiding Principles found in the WordPress (2024) developer handbook.

Guiding principles

1. Never trust user input.
2. Escape as late as possible.
3. Escape everything from untrusted sources (e.g., databases and users), third-parties (e.g., Twitter), etc.
4. Never assume anything.
5. Sanitation is okay, but validation/rejection is better.

Never trust user input

When creating a form that accepts user input, such as a comment form or a contact form, never assume that the input is safe. For instance, if a user submits a form to update their profile, their inputs, such as username or email, could be manipulated. Therefore, you must always sanitize and validate these inputs before processing or storing them.

// Bad practice: trusting user input
$username = $_POST['username']; // Potential security risk

// Good practice: sanitizing user input
$username = sanitize_text_field($_POST['username']);

Escape as late as possible

Escaping should be done right before the data is output. For example, when displaying user-submitted content on a webpage, like a blog post or a comment, escape it as late as possible — just before rendering it in HTML to ensure no malicious code is executed.

// Escaping as late as possible (before output)
echo esc_html( $user_input );

Escape everything from untrusted sources (e.g., databases and users), third-parties (e.g., Twitter), etc.

Any data coming from users, third-party APIs (e.g., Twitter), or even your own database should be considered untrusted and must be escaped before displaying it. For instance, if you pull tweets from Twitter using their API, you should escape the content before rendering it on the webpage.

// Escaping third-party API content before displaying
echo esc_html( $tweet_content );

Never assume anything

Assume that all data could be manipulated. For example, when using the $_GET or $_POST superglobals, never assume the data will be in the expected format. Always validate the input against what you expect, such as checking if a supposed integer really is an integer.

// Never assume that an input is valid, always validate
$post_id = isset($_GET['post_id']) ? (int) $_GET['post_id'] : 0;

Sanitation is okay, but validation/rejection is better

While sanitation is helpful, rejecting invalid data is more secure. For instance, if you are expecting an email address, don’t just sanitize the input — validate it using functions like is_email(), and reject any data that doesn’t pass validation.

// Validation is better than sanitation
if ( ! is_email( $_POST['email'] ) ) {
    wp_die( 'Invalid email address!' );
}

Conclusion

Following WordPress’s guiding principles for input and output handling is essential for creating secure plugins and themes. The core idea behind these principles is defensive coding, where you treat all input as potentially malicious, ensuring that it’s properly validated, sanitized, and escaped as needed.

By adhering to these practices, such as never trusting user input, escaping data at the last possible moment, and validating over sanitizing, you significantly reduce the risk of common security vulnerabilities like cross-site scripting (XSS) and SQL injection.

Ultimately, these principles foster safer code, a more secure WordPress ecosystem, and a better experience for users and developers alike.

Do you want to simplify plugin security quality assurance? Sign-Up to the BlogSecurity Beta program to learn more.

References

TechRadar, 2024. WordPress plugin exposes half a million sites to attack. [online] Available at: https://www.techradar.com/news/wordpress-plugin-exposes-half-a-million-sites-to-attack [Accessed 2 October 2024].

The Hacker News, 2024. GiveWP WordPress Plugin Vulnerability Exposes 130,000 Websites to Attacks. [online] Available at: https://thehackernews.com/2024/08/givewp-wordpress-plugin-vulnerability.html [Accessed 2 October 2024].

WordPress, 2024. Common APIs Handbook: Security. [online] Available at: https://developer.wordpress.org/apis/ [Accessed 2 October 2024].

Exploit Database, 2024. Exploit Database: Search for WordPress vulnerabilities. [online] Available at: https://www.exploit-db.com/ [Accessed 2 October 2024].

WordPress.com, n.d. About. [online] Available at: https://wordpress.com/about/ [Accessed 4 October 2024].

OpenBSD Project, 2024. OpenBSD: Secure by Default. [online] Available at: https://www.openbsd.org/ [Accessed 6 October 2024].

W3Techs (2024). Usage statistics and market share of WordPress [Online]. Available at https://w3techs.com/technologies/details/cm-wordpress (Accessed 7 October 2022)

Goodin, D., 2024. Single HTTP Request Exploit Hits 6 Million WordPress Sites. Dark Reading. [online] Available at: https://www.darkreading.com/endpoint-security/single-http-request-exploit-6m-wordpress [Accessed 6 October 2024].