The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases fixing the vulnerability is quite easy, so it seems that many developers are just not too concerned about keeping their plugins are secure.

Let’s take a look at recent example of this. Back in March g0blin Research discovered an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin AddThis Sharing Buttons (formerly Smart Website Tools by AddThis). This plugin currently has over 200,000 active installs according to WordPress.org, has 12 listed authors, and is developed a private corporation of the same name. The vulnerability was caused by an Ajax function that should only be accessible to Administrator level users being accessible to any registered user. That severely limits the potential danger of the vulnerability since most WordPress based websites do not allow the public to create accounts, so someone relatively trusted with malicious intent would be required for the vulnerability to be exploited. It also should make it quite easy to fix, but as the timeline included with advisory (show below) shows it took the developers over two months to fix the issue:

2015-03-19: Discovered
2015-03-19: Vendor notified
2015-03-19: Vendor responded – link to report provided
2015-03-20: Version 4.0.7 released – issue still present
2015-03-26: Vendor responded with intent to fix
2015-03-31: Update requested from Vendor
2015-04-07: Vendor responded stating that a fix is in progress
2015-04-13: Update requested from Vendor
2015-04-16: Vendor states that fix is undergoing QA
2015-05-04: Update requested from  Vendor
2015-05-11: Update requested from Vendor
2015-05-12: Vendor states that fix was rejected by QA, has been redeveloped and has been passed back to QA for re testing.
2015-06-01: Notified vendor of intention to contact WordPress Plugins team
2015-06-03: Version 5.0.4 released – issue resolved
2015-06-10: Advisory released

So what does it take to get this type of issue fixed?

There are two functions that are often used to check if someone is Administrator level user. The more widely used is to check if the user has the capability to manage_options:

current_user_can( ‘manage_options’ )

That capability is normally only provided to Administrator level and above users, and allows access to WordPress settings pages. That would be particular relevant for fixing this vulnerability as the vulnerable Ajax function is something that would have normally be accessed from a settings page.

The second function checks if a user is a Super Admin or Administrator:

is_super_admin()

With that function if network mode is enabled (WordPress MutliSite) it will return true if the user is a Super Admin and when network is not enabled it will return true if the user is an Administrator. Beyond the implications that this has with MultiSite websites, there is a potential that someone will accidentally use is_admin when they meant to user is_super_admin. That would be a security problem of its own, as is_admin only checks if an administrative page is being requested and “does not check if the user is logged in, nor if the user even has access to the page being requested”.

So what did the AddThis Developers come up after months and having a fix rejected by quality assurance?

First up is the relevant function before being fixed:

public function addthisAsyncLoading()
{
if ($this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Here is the fixed version (fix bolded):

public function addthisAsyncLoading()
{
if (current_user_can( ‘manage_options’ ) && $this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Why it two months to add less than a line of code is something we don’t understand. It could have been worse, in another case with the same failure to check on a user level, it to  the plugin being pulled the plugin from the Plugin Directory for the vulnerability to be fixed (following us reporting it to Plugin Directory).

Hack of cloud-based LastPass exposes hashed master passwords

LastPass officials warned Monday that attackers have compromised servers that run the company's password management service and made off with cryptographically protected passwords and other sensitive user data. It was the second breach notification regarding the service in the past four years.

In all, the unknown attackers obtained hashed user passwords, cryptographic salts, password reminders, and e-mail addresses, LastPass CEO Joe Siegrist wrote in a blog post. It emphasized that there was no evidence the attackers were able to open cryptographically locked user vaults where plain-text passwords are stored. That's because the master passwords that unlock those vaults were protected using an extremely slow hashing mechanism that requires large amounts of computing power to work.

"We are confident that our encryption measures are sufficient to protect the vast majority of users," Siegrist wrote. "LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side. This additional strengthening makes it difficult to attack the stolen hashes with any significant speed."

Read 5 remaining paragraphs | Comments

Stuxnet spawn infected Kaspersky using stolen Foxconn digital certificates

Some of the malware that infected the corporate network of antivirus provider Kaspersky Lab concealed itself using digital certificates belonging to Foxconn, the electronics manufacturing giant and maker of the iPhone, Xbox, and other well-known products.

Cryptographically generated credentials are required to install drivers on newer, 64-bit versions of Windows. Foxconn used one such certificate when installing several legitimate drivers on Dell laptop computers in 2013. Somehow, the attackers who infected the Kaspersky Lab network appropriated the digital seal and used it to sign their own malicious drivers. As Ars explained last week, the drivers were the sole part of the entire Duqu 2.0 malware platform that resided on local hard drives. These drivers were on Kaspersky firewalls, gateways, or other servers that had direct Internet access and were used to surreptitiously marshal sensitive information in and out of the Kaspersky network.

Not the first time

The Foxconn certificate is the third one used to sign malware that has been linked to the same advanced persistent threat (APT) attackers. The Stuxnet malware, which reportedly was developed by the US and Israel to sabotage Iran's nuclear program, used a digital certificate from Realtek, a hardware manufacturer in the Asia Pacific region. A second driver from Jmicron, another hardware maker in the Asia Pacific, was used several years ago to sign Stuxnet-related malware developed by some of the same engineers. Like the previous two certificates, the one belonging to Foxconn had never been found signing any other malicious software.

Read 9 remaining paragraphs | Comments