Hashemian Blog
Web, Finance, Technology, Running

WordPress Global Replace http to https

by @ 12:00 pm
Filed under: web — Tags: ,

If you are dealing with the pain of migrating your site from non-secure plain http to secure SSL/TLS https, then you are also dealing with the headache of making sure the elements on your pages such as images have https sources instead of http.

The reason is that if your pages are accessed over https but they contain http elements they are considered broken (mixed content) by just about all browsers. The point is that if a page is secure, everything in that page must be secure as well.

Different page elements are treated differently by browsers. As of now, Chrome loads non-secure images in the page, but the URL color goes grey instead of the reassuring green with the secure lockpad. Non-secure scripts are not even loaded, leading to page malfunction in many cases.

If you use WordPress, you know how much of a pain it is to mass replace all the image sources in your past posts from http to https. You can manually update posts which will take forever, update the backing MySQL database via SQL but that’s risky, or use a plugin but that may be overkill.

A quick way to handle this is to add a filter to transform all http occurrences to https on the fly. It won’t change the actual posts, only how they are sent to the browser. And it’s not 100%, but it’s good enough for most sites, including this one. And worst case, you can always remove it and you’ll be back to where you started.

As for the filter code, it’s a one-liner that you add to the functions.php file of your theme. It actually converts http URLs for image src’s to protocol-relative, and that does the job. Here it is and good luck:

add_filter('the_content',function($a){return preg_replace("#src=([\"'])http://#i","src=$1//",$a);});

Wordpress 'page_option' Hack

by @ 1:21 pm
Filed under: hacking,web — Tags:

wordpress-hackWordpress is a great publishing product but its popularity is also its Achilles heel. It's notorious for being a favorite target of hackers and many have been successful in compromising plenty of installations out there, including this one.

Having automated monitoring software is certainly a prudent way to stay on top of things, but in the end vigilance and bit of common sense seems to be a good way of detecting and removing attacks. Thwarting them is of course another story.

Staying with the vigilance theme, for some time I had noticed that this blog was very slow. I just attributed it to the server load or bandwidth issues but like everything else after a prolonged time of sluggish performance I turned my attention to the installation itself.

That's when I discovered the 'page_option' hack. The 'functions.php' file in my theme folder had been appended with a block calling the 'add-action' with the 'wp_head' parameter. The second parameter was from a deserialized array coming from a newly added row in the 'wp_options' table (in MySQL) with the 'option_name' field set to 'page_option'. The whole thing smelled of a hack, you know the mysterious call to decode and slice up some long encoded string. Why do hackers waste so much time with these idiotic obscurity schemes? Just dump the damn payload in. the layman won't see it and the rest can spot it from miles away, totally pointless.

A Google search brought up this reference, and the blogger's experience was very similar to mine and indeed I found the offending '/wp-includes/page.php' file just as he had. He has very good tips and hints on dealing with this hack, so head on over and give it a read.

As for me, I removed the offending block from the 'functions.php' file, delete the '/wp-includes/page.php' file, deleted the 'page_option' row from the 'wp_options' table and removed all unused themes and plugins, in case those were the hacker's conduit.

The page load times are now back to normal and for good measure I updated Wordpress to the latest version, always a wise move as they always plug new security holes.

Stay vigilant…

Wordpress Base64 Hack or PHP-CGI Hack? part III

by @ 5:37 pm
Filed under: hacking,web — Tags: , , ,

After being hit by the Wordpress base64 hack twice within a couple of weeks, it finally dawned me that the PHP CGI flaw was the culprit. The attack robots (a la Metasploit) use the knowledge of PGP CGI flaw together with the well-known scripts of popular products (Wordpress, Joomla, Drupal, etc.) to penetrate sites and that's how this site was breached as well.

Most sites run PHP as a module, so those were spared the headache. I used to run PHP as a module many moons ago, but chose to move to CGI for several reasons. Here's a an explanation of the difference between the two modes. What's disconcerting is that the CGI vulnerability had been around or some 8 years and no one seemed to have noticed during all that time and it was my PHP version 5.3.5 that did me in. It was time to move to version 5.3.14. But where to find that php-cgi version for my Fedora install.

I went hunting for php-cgi 5.3.14 all over the net, from user websites, to rpm repositories, but no dice for my Fedora version. Now sometimes you can use an off version, but then you run the risk of crashes, library mismatch and other problems. So why not download the source from php.net and build it myself? Simple, I'm too lazy and hate building/rebuilding programs. There's the big download, long waits, missing libraries, warnings and errors. I had just come off a build hell of Varnish cache, and I wasn't about to plunge myself into another. But, in the end I had no choice.

The Linux build world is a 3-word expression: configure, make, 'make install'. I'll add another word, loop. You download the source code, run configure to adjust the config and make files for your particular platform. Then you run make to build the program(s). finally you run 'make install' to install the program(s) on your system. Sounds easy enough until you realize that a million things can and will go wrong and that's where 'loop' comes in as you configure and make repeatedly to get things right.

Building PHP 5.3.14 didn't disappoint. I ended up running configure and make tens of times until I finally got the binary I wanted with all the necessary libraries included. Building php using make renders a number of binaries including the main command line program (interpreter) as well as php-cgi and it was the latter I was interest in.

I copied the newly-made php-cgi over the old version, tested the site and called it a day. Now I know this sort of installation is a cardinal sin to many techies, no argument there. Think about it, I am running a php-cgi version that is out of sync with the main php interpreter on the same machine and then the rpm (package manager) has no clue about which version of php is really installed on the system. At the first rpm update, the whole system could come crashing down. I just have to be cognizant of the fact that I have a fragmented php installation. Eventually when I migrate the site to a new Fedora version all will be back to good. For now, it's good enough to have been hack-free for a couple of months.

Part I, Part II

Wordpress Base64 Hack or PHP-CGI Hack? part II

by @ 7:15 pm
Filed under: hacking,web — Tags: ,

To be factual about it, my site was hacked twice in exactly the same way over a period of couple of weeks. The first time around I noticed it when the feeds coming via Feedburner kept crashing the RSS readers because of a javascript malware block inserted right at the top of the feed. Turns out that the php files in my wordpress installation were altered to emit the offending javascript block.

Surely the hacker must have exploited some wordpress vulnerability, I thought. A quick search on the web for wordpress base64 hack, brings up plenty of pages covering such hacking cases.

I started out by examining the MySQL tables by doing a global search for terms such as base64 or eval. The wp_options table had plenty of such entries. At first it seemed like I had found the hacker's stash. wp_options is where wordpress and the plugins save their parameter data. There were also lots of entries with the "transient" keyword. In the end they turned out to be innocuous. Transients could become real nuisances, but that's a different topic.

With the database search behind me, I put the focus on the files. Deep searching for base64_decode and eval, produced a number of them. Here's a simple command to achieve this search:

$ grep -rl base64_decode *

Some of the hits were legitimate, but eventually I ran into two types of files that were obvious hacks. The first type were mostly legitimate index.php files that had been altered with a giant code block right at the top. The blocks were of the base64_decode(eval(long-hex-string)); variety. Removing the block appeared to restore the files back to their original form. The other type were small-sized php files with varied names containing one or two lines of code like eval(stripslashes($_REQUEST['a']));. This code would basically execute raw code passed in as a parameter to the page, very simple, very effective, and very dangerous.

Armed with that knowledge I went snooping around the site looking for small-sized files and any files that had been altered recently.

$ find -size -1k -name *php
$ find -mtime -7 -name *php

The first command returns php files that are 1kb or less in size. The second returns php files that are modified in the last 7 days. I dug through the long list of files, fixed the altered files by removing the malicious code blocks and then deleted the small dropped-in files.

Finally I upgraded the wordpress installation to the latest version and everything was back to good, or so I thought. Within about two weeks I was hacked again in almost the same way as the first time. How did I recover from it and plugged the hole? Hint: PHP was the actual culprit. Stay tuned …

Wordpress Base64 Hack or PHP-CGI Hack?

by @ 10:57 pm
Filed under: hacking,web — Tags: , , ,

A couple of months ago I started noticing that this blog's RSS feed, which is via Feedburner, wasn't coming through on some RSS readers. After some tests I discovered that the feed actually contained a malicious javascript block at the top. That was breaking the XML format, causing the RSS readers to fail. Turns out that It was my own site that was hacked, replicating over to Feedburner.

After a bit of investigating I found a number of files, specially those named index.php, that had been modified by a code block at the top that started with something like "eval(base64_decode(…" followed by a long string of hex numbers. I decoded the hex string and I ended up with a php code block that looked pretty devious with references to Chinese sites.

This is what was happening. A blog page is accessed by a user. Since most Wordpress activity is funneled through the index.php file the malware at the top is executed and after a couple of iterations a javascript block is produced and sent to the browser. No idea what the javascript code was doing, but safe to assume its goal was to infect the users with malware, steal data and eventually turn them into zombies in some botnet.

Do a search for Wordpress base64 hack and you'll find thousands of sites around addressing this issue. Wordpress doesn't exactly have a good security reputation but its latest versions were thought to be more secure. But in this case Wordpress wasn't at fault. Turns out the real culprit was php-cgi 5.3.5 and a nasty security hole stretching back for 8 years. The bug would allow the attacker to view the source code of a page, run arbitrary code, and generally be a pain in the a$$.

I suspect in some cases where Wordpress (or Joomla or Drupal or phpMyAdmin) has been hacked, the true culprit has been php-cgi. The reason these popular programs are targets is that their structures and operations are well-known to all including the hackers. All it takes to exploit vulnerable sites is to write simple scripts targeting known pages and letting it loose on the internet. The robot crawls around infecting sites as it find them and then those infected sites infect their users by extension. An old concept, but pretty neat in a distorted sort of a way.

There are some of questions to be answered here. Why was such a gaping hole allowed to remain in php for 8 years? Why was it publicized before it could be plugged? Why do some sites still use CGI? After all, this vulnerability didn't affect php ran as a module. Those are good questions and there are plenty of discussions about them online, so no need to rehash here.

What might be useful is explaining what I did to plug this hole on my site. Stay tuned …

Powered by

Read Financial Markets  |   Home  |   Blog  |   Web Tools  |   News  |   Articles  |   FAQ  |   About  |   Privacy  |   Contact
Donate Bitcoin: 1K9TzBvQ2oaEb4tX9t2vKDtZouMcpfV6QF
© 2001-2018 Robert Hashemian   Powered by Hashemian.com