July 28, 2015

While visiting Google Maps I saw what is(at least to me) a new noscript warning. A screenshot of it is below, the message is:

When you have eliminated the JavaScript, whatever remains must be an empty page.

I got a kick out of somewhat proverbial warning. Sure beats the common “we have detected that javascript is disabled in your browser” warning that is so often used. They even came up with a graphic for it. Can’t argue with them about it either on Maps…you need Javascript for that. Now if it were Google groups… ;)

July 16, 2015

Recently, an old client contacted me because emails were not being sent from their Godaddy hosted wordpress site. A quick look at the folders in their webroot made it clear that the site had been hacked and most likely the emails not working was a side-effect of godaddy noticing and blocking their email function.

After a bit of investigation, it looked like the most likely avenue was from the CherryFramework, which is a bootstrap wordpress theme/plugin framework. A bit more digging and I discovered a recently patched vulnerability in cherry-plugin/admin/import-export/upload.php

As you can see from the above, which is the first version uploaded to git, the ONLY checking this file does is whether or not you are sending it some files to upload and telling it where to send it. So, it conveniently lets you upload any file to any directory on the webserver. Similarly, their download-content.php file also let you download arbitrary files from the webserver, with 0 checks in place to prevent abuse. You can see a screenshot of the github repository here.

This was fixed in later versions of CherryFramework and shows that the developer better understands wordpress now, as they not only implement a nonce and checks the logged in user’s capabilities by calling current_user_can, but also adds the code to an ajax action rather than just a malware installer like it was before.

Without casting too many stones, as no-one is perfect least of all me, I just can’t understand how something like this could get written, if not intentionally(which is entirely possible.)

Everyone makes mistakes and it is easy to miss something that can be abused…mistakes happen, get fixed, and we move on. But, something like that or SQL queries written with 0 thought to injection blow my mind.

July 3, 2015

After updating to Fedora 22, the File Chooser in Firefox XFCE, like you would see when you click ‘Open File’ or upload a file, was broken.

Specifically, while the open file dialog does open and let you select files, the quick find was not working properly. Normally, you can start typing the first letter(s) of a file name and the file browser will jump to files that start with that letter in your current folder. However, this was not working for me in Firefox and instead typing a letter did nothing. Further, the files were not grouped by folders, but rather displayed files/folders together(although this might not be a setting.)

It turns out this isn’t a bug with Firefox, but rather a problem with GTK3’s Filechooser Dialog. A bug is currently open here, so hopefully it will be addressed soon.

In Fedora 22, Firefox is compiled to use GTK3 instead of GTK2, along with Gedit and I would imagine a few other programs. So, anything using GTK3 has this bug for me.

A Temporary Solution: Since this makes using Firefox and selecting files incredibly painful, a quick fix is to uninstall Fedora’s version of Firefox and install Firefox separately(by downloading or compiling.) The version available directly from Mozilla does NOT use GTK3, so works fine. Just make sure to stay on top of updates and keep an eye out for when Fedora updates GTK3, as this will probably get fixed soon.

Hopefully, this will save someone the amount of time I spent trying to figure out why it was broken…

The GTK3 Filechooser, shown on right, does not currently work correctly in Fedora 22.

March 13, 2015

While doing a Google search this morning, I noticed an interesting message from Google above the search results. It said, ‘Switch your default search engine to Google.’

Clicking the Learn how button takes you to a page with steps and screenshots showing how to change your default search engine in Firefox.

This is in response to a recent deal between Firefox and Yahoo, where Yahoo replaced Google as Firefox’s default search engine. According to reports the change has provided a small boost to Yahoo’s already rather small percent of the search market, with Google also loosing 1 percent during the same time.

Whether this is due to actual concerns over loosing customers or just not letting their competition have anything easy is anyone’s guess. However, this is not the only time Google has used it’s market position to attack their competition. For years, Google has been pushing Google Chrome on Firefox and Internet Explorer users.

Update 03/20/2015: The following adblock element hiding rule seems to work to get rid of it: google.com##DIV#taw

November 30, 2014

After cleaning up a recent WordPress hack, I believe there is another Revolution Slider vulnerability making the rounds. If you are using an old version of Revoltion slider, you should update immediately or disable the plugin.

From what I can tell, it affects two Themepunch plugins, Revslider and Showbiz Pro. According to a proof-of-concept exploit posted this month, versions 3.0.95 and before of Revslider, as well as versions 1.7.1 and before of Showbiz Pro are vulnerable.

The issue allows for unauthenticated ajax calls sent /wp-admin/admin-ajax.php to trigger Revolution Slider’s onAjaxAction function, which in turn can be used to delete slides, import/export slides, and update the plugin(among other tasks.) In the case of the site I cleaned up, they used it to trigger an update to the plugin, which uploaded a remote shell to the site.

From looking around, this vulnerability appears to have been posted relatively recently on several sites and is currently being exploited.

The Vulnerability

This is part of revslider_admin.php. In affected versions, the below gets called, which adds wp_ajax and wp_ajax_nopriv callbacks for the onAjaxAction function.

Since there is no check on whether the user is actually logged in or allowed to make changes to the plugin, it is possible to(among other things) upload files to the server.

revslider_admin.php:

self::addActionAjax("ajax_action", "onAjaxAction");

This in turn calls the addActionAjax function, which creates the wp_ajax and wp_ajax_nopriv callbacks.

As a result of this, the revslider_ajax_action action gets added, allowing for unprivileged updates. This is not terribly surprising as, at least in early versions of Revolution Slider, security and a deep understanding of wordpress do not seem to have been a concern.

Working Example

The following is a working example. On a vulnerable site, the following will print an ajax response similar to: {“success”:false,”message”:”wrong ajax action: asdf “}.

If you see something to the effect of {“success”:false,”message”:”Wrong request”}, you are probably not vulnerable, but should still verify you are running the most recent version, as there are several known vulnerabilities at this point!

The reason you see this response is because the switch is called and since asdf is not a recognized action, it triggers the default: self::ajaxResponseError(“wrong ajax action: $action “);

Affected Versions

As stated above, this does not appear to impact newer versions 3.0.95 of revolution slider, as well as versions 1.7.1 and below of Showbiz Pro.

In a newer version I checked, Themepunch appears to have added a nonce called revslider_actions and check that the nonce is present in onAjaxAction prior to actually executing the ajax calls.

Temporary Fix

If you are using an old version of revolution slider, you should update immediately and/or disable the plugin.

As stated before, since this plugin is often included with themes and is a premium plugin, updating it presents several difficulties and is something that a non-tech website owner might not even know they need to do. I feel this leaves something to be desired.

The below should be a quick way to stop the attack.

**Note that the below will only allow people with the privilege to install plugins to work with Revslider’s Ajax calls. You may want to adjust what permission you allow.

September 4, 2014

Yesterday, a vulnerability in an old version of Revolution Slider was reported. The vulnerability allows visitors to view arbitrary files on the web server, like wp-config.php, without being logged in. All you need to view any file on the server is to know the location of the file and for the web-server user to have permission to view it.

According to ThemePunch, the plugin developer, the vulnerability was patched 29 versions ago in February, but they decided not to publicize the severity of the issue, aside from a single ‘fixed security issue’ line in their change log. This was because:

“[We were] told not to make the exploit public by several security companies so that the instructions of how to hack the slider will not appear on the web.”

As a result of this negligence and the way that Revolution Slider is Updated and bundled with themes, this simply left any website not running a recent version of Revolution Slider vulnerable for months to an extremely serious file inclusion vulnerability.

Its Your Fault For Not Updating

This seems to be the company line for this issue. After the vulnerability was made public, they have stated:

“You should always keep the slider up to date like any other WordPress component but urgently need to do this when using Version 4.1.4 or below in order to fix the security issue. […] We are sorry for you guys out there whose slider came bundled with a theme and the theme author did not update the slider. Since you cannot use the included autoupdate function please contact your theme author and inform him about his failure!”

And it is true, you should keep your plugins updated.

However, this is a paid plugin and doesn’t allow easy updates like a normal wordpress plugin does. Further, on all of the sites I fixed, they didn’t appear to have a nag telling the user an update was available from the backend. So, unless you are a developer and actively visited the plugin’s website, you wouldn’t even know the plugin needs to be updated, let alone an extremely serious security vulnerability.

As they mention, they sell a developer license that allows developers to include the plugin in their theme. When the plugin is included with themes, you can’t update it without updating the theme. So, any theme that isn’t regularly updated is at risk. And, since some shoddy developers edit the theme directly, rather than making a proper child theme, it isn’t always easy to update the theme. This, of course, isn’t the fault of ThemePunch, nor is it good practices to develop like this, but it does happen and is going to be a legitimate problem for people.

Even if you actually have the premium plugin itself, you can’t just update it. There is no auto-update feature(at least not in the vulnerable versions I saw,) so you can’t update it like you would a regular WordPress plugin. Nor, to my knowledge, is there an update nag on the plugin page telling users they need to update. Instead, you need to download the premium plugin, which requires a login to the site that sells it.

The catch here is that most website owners aren’t going to have access to the login information needed to update the plugin. Your average website owner isn’t a developer. They probably paid someone to create the theme, who presumably installed a valid copy of the plugin. Unfortunately due to the nature of web design, this simply means that hundreds(thousands?) of sites are silently vulnerable to an extremely serious vulnerability and won’t even know it, unless they have a responsible web developer or host. Again, this isn’t the fault of ThemePunch, but is a fault with the premium plugin model when it doesn’t allow for quick/easy updates.

Negligence Through Security Through Obscurity

According to the plugin author, this vulnerability was fixed in February, but they chose not to report it. It has been reported that this vulnerability was publicly disclosed months ago and regardless, it is safe to say that it was known by some people for the past few months.

By choosing not to report the vulnerability and making site owners aware of this huge security risk, they effectively pushed back the date where we found out about it leaving their customer’s sites vulnerable to a known attack. And, now that is is released and being exploited like mad, we are left scrambling to fix it anyway. So, not reporting it only helped the bad guys.

I understand fully that this is a paid plugin and the need for them to protect it. I get that. And, I understand that you should keep your plugins updated. Nothing in their statements that I have seen is untrue.

However, in the event of a serious vulnerability like this, not making a valid attempt at reporting it, especially when you know that your plugin doesn’t get updated frequently and the vulnerability likely impacts a large number of sites, is negligent.

Updating a Plugin You Can’t Update

I don’t use this plugin on WordPress templates I develop, but it is used by several clients that I host. I found it bundled in two client’s themes and installed as a plugin for two other clients. All 4 had their wp-config.php file downloaded already and all sites on my servers have been scanned for this vulnerability already.

I wrote a quick and dirty patch for the outputImage function, which you can view here. This is only meant as a temporary fix, until you can assess the issue and do a proper update, but since this attack is ongoing and widespread, you should take some sort of action asap.

April 9, 2014

If you have visited windows.microsoft.com lately using Internet Explorer 7, you would probably see the “It’s time to upgrade your browser” nag, which explains that IE7 and IE6 no longer supported and blocks you from browsing their site until you upgrade.

This is a great step, as even with XP support going away, Vista shipped with Internet Explorer 7, so it will not be dead for some time. When they first started doing this on the Windows site, I thought it was cool that they were finally doing something to clean up the mess they created with their fragmented browser ecosystem.

However, Internet Explorer 8 is still a pretty bad browser…certainly better than IE7, but that isn’t saying much.

If you are going to break your website to force an upgrade, it would be great to use that as a platform to get them into the latest version of Internet Explorer that you can. So, if they are on Vista, go ahead and tell them to upgrade to IE9. Better yet, go ahead and add an optional tool they can use to verify automatic updates is on and set to update automatically, as if they are running IE7, they may not be getting security updates either. And, if they are on IE8, go ahead and add a nag for that too! Although, I think that one may be trickier, as in a in corporate environments, upgrading past Internet Explorer 8 may not be possible. So, rather then fully breaking the site, probably a nice warning would suffice. Be a nice kick in the butt for companies that haven’t upgraded yet as well.

This seems like the right thing to do, especially as dropping support for IE8 has already begun on a number of popular websites. Even Microsoft’s Office 365 has recently announced they are no longer supporting IE8.