Category Archives: security

Blogposts on blog.futtta.be about IT- and more specifically web application security (e.g. about some dangers in PHP, xss, …)

Code snippet to block author pages

So you can remove the author-pages with an author.php file in your (child) theme, but what if you don’t want to touch the theme you ask? Well, I just added this code snippet to two of the sites I manage to stop user-enumeration (which can be done on any WordPress site by going to /index.php?author=1):

add_action('wp','no_author_page');
function no_author_page() {
  if (is_author()) {
    global $wp_query;
    $wp_query->set_404();
    status_header( 404 );
    get_template_part( 404 );
    exit();
  }
}

Disclaimer: the bulk of above code was shamelessly copy/ pasted from https://wordpress.stackexchange.com/a/27124

No REST for the wicked

After the PR-beating WordPress took with the massive defacements of non-upgraded WordPress installations, it is time to revisit the point-of-view of the core-team that the REST API should be active for all and that no option should be provided to disable it (as per the decisions not options philosophy). I for one installed the “Disable REST API” plugin.

Lykke Li – No Rest For The Wicked

Watch this video on YouTube.

Warning WordPress plugin users about their old PHP

After my initial disbelief about the amount of WordPress installations still on the slow and vulnerable PHP 5.2.17 (or older), I decided to warn users of my plugin with an non-dismissable warning on the plugin’s settings-page (and only there, so it’s not a default WordPress admin notice) cluttering the entire backend):

php52_warning_aoThis is going in AO 2.0.2 (out later today) and will in the future also be added to WP YouTube Lyte and WP DoNotTrack (both of which have a smaller reach).

If you’re a plugin or theme developer and want to warn your users as well (without blocking them), here’s the code I used (do change the translation-domain from “autoptimize” into one that is applicable to your plugin):

<?php if (version_compare(PHP_VERSION, '5.3.0') < 0) { ?>
    <div class="notice-error notice">
        <?php _e('<strong>You are using a very old version of PHP</strong> (5.2.x or older) which has <a href="http://blog.futtta.be/2016/03/15/why-would-you-still-be-on-php-5-2/" target="_blank"> serious security and performance issues</a>. Please ask your hoster to provide you with an upgrade path to 5.6 or 7.0','autoptimize'); ?>
    </div>
<?php } ?>

Why would you still be on PHP 5.2?

For Autoptimize 2.0.1 I declared a pretty complex regex to extract font-face’s from CSS using the nowdoc-syntax which is supported from PHP 5.3 onwards. Taking into account that the first PHP 5.2 release was over 9 years ago and support ended with the release of 5.2.17, over 5 years ago I assumed using a nowdoc would not be a problem for anyone. How naive I was; several people contacted me with this ugly error-message PHP 5.2 throws;

Parse error: syntax error, unexpected T_SL in /wp-content/plugins/autoptimize/classes/autoptimizeStyles.php on line 396

There is a workaround and even a more fundamental fix for that already, but who would still want to run PHP 5.2, which has this huge list of security issues? Moreover PHP 5.5 and 5.6 seem approximately twice as fast as 5.2 according to these test results and PHP 7.0 is even over three times as fast as 5.2! And still almost 9% of all WordPress sites are running on that old version (so I could have known this was coming really, bugger).

I you are one of those, do urge your hosting company to urgently provide you with an upgrade path to PHP 5.6 (or even 7.0)!

Clam AV flagging CSS as Html.Exploit.CVE_2016_0108

So I had a bit of a scare yesterday, when a couple of users posted on the Autoptimize support forum that their hoster warned them about malware in autoptimized CSS-file. ClamAV flagged those files as being infected with Html.Exploit.CVE_2016_0108, which turned out to be a MS IE 11 specific memory corruption issue.

As Autoptimize only aggregates CSS and never adds any in and of it’s own and I was not too worried, but set out to investigate anyway (I’m curious like that). I soon found similar reports of users that were not on Autoptimize and some people kindly copy/pasted their “infected” CSS on pastebin. A quick inspection showed no signs of abnormal things going on and I submitted the files as false positives on Clam AV’s site. This evening I got a (vague) automated mail from ClamAV confirming that my

submissions have been processed and published

I just reached out to a user on AskUbuntu who had the same issue to test if his CSS was now not flagged any more, upon which he replied;

I can confirm that the CSS files no longer trigger a false positive!

So all’s well that ends well. I’m convinced ClamAV is doing a great job, but boy do I hate false positives!

My Adventures on OpenShift

openshiftI have always been a fan of Red Hat, even if have never used their products extensively. They were one of the original movers in Linux-market back when Slackware was big and when InfoMagic CD-rom boxes with multiple distro’s were popular. And I have remained a fan because they succeeded in building a solid company built on and around open source & services.

So I was very happy to read that Red Hat had entered the PAAS-market with OpenShift, that that platform was built on open source(d) solutions and that a small-timer like me could deploy apps for free on their application cloud. I signed up, installed the WordPress instant application, added some tried & tested plugins and imported my content. Half an hour works, tops and performance proved to be great. Everything was just peachy, until I received this message in my mailbox;

We believe your use of OpenShift violates the Services Agreement and Acceptable Use Policy both of which can be found here: https://openshift.redhat.com/app/legal/

Infected file(s):
/var/lib/openshift53bcc3fd5973cabac00000d1/.tmp/53bcc3fd5973cabac00000d1/just_test_bc: Perl.Shellbot-8

And ZAP, my application was removed. As I had no idea how “just_test_bc” ended up in a temp-folder, the only possibility was a successful hack-attempt, so I contacted the security team to get more information. It took some time (and an escalation via the Customer Enablement Team), but I eventually got in touch with Stefanie at Red Hat, who was able to provide me with more information:

It looks like we had a one-off error in the script that emailed you. Your application was still flagged, but on a different file than we emailed about. This is the actual file:

/var/lib/openshift/53bd21435973cad637000080/mysql/data/ib_logfile0: PHP.ShellExec

So there was something in the mysql database log that set off the scan. […] It looks like mysql may have logged someone’s attempt to inject some bad PHP code into your app.

ib_logfiles are MySQL’s innodb replay log files and as Stefanie provided me with a tarball with my entire application, I extracted ib_logfile0 and used “strings” to extract readable information from the binary file. The result (from my mail to Stefanie);

Although php’s exec (and similar functions) can be found [in the logfile], this is always due to … blogposts about web security and specifically this one; http://blog.futtta.be/2007/12/02/php-security-eval-is-evil/. The content of that article was inserted in the DB and [thus] added to ib_logfile. Your scanner finds the content [in that innodb replay logfile] and flags this as a problem. I would think the OpenShift scanner needs some finetuning, [as now] anyone is at risk of having their app auto-removed if the mysql-redo-logfile happens to contain vaguely “offending” strings such as shell_exec?

OpenShift confirmed this analysis;

You’re absolutely right that our scanner needs work. So what I’m going to do is get you onto a whitelist so this thing doesn’t flag you again. […] All takedowns are currently on hold until I can implement pre-removal notifications [and] improve our standard operating procedure for this kind of thing. That should give people a chance to tell us that their apps are not malicious, so that we can whitelist others too, if needed. As long as they notice an email saying “OpenShift Terms Of Service Violation” within a few days, I think they should be safe. If they do get flagged as a false positive like your app did, they’ll email us back and let us know it’s a mistake, and then they’ll be added to the whitelist too.

Now wasn’t that an interesting adventure? If ever you get a notification-mail from OpenShift related to security issues, check if the problem isn’t with benign content being inserted in the database and if so be sure to contact OpenShift so they can add you to their whitelist.