Hashemian Blog
Web, Finance, Technology, Running

PHP - echo'ing String Fragments Using Periods Vs. Commas

by @ 10:18 pm
Filed under: computers — Tags:

One of the mysteries of PHP's echo function is the supposed equal treatment of multiple strings separated by periods (.) vs. those separated by commas (,). Actually echo is a language construct, but I digress. In both cases echo appears to concatenate the string fragments and output the resulting string.

In actuality, the period is the real concatenation operator in PHP. The comma on the other hand signifies echo's ability to accept variable-length arguments. Judging by Google search, most people just accept the fact that they can use either periods or commas with the echo function to get the job done.

But there's a subtle difference that's mostly overlooked because it rarely mucks up the results. Take a look at the two code lines below. You might expect to see 12 for both cases, but that is not so.

php echo

The reason is that with periods, some or all expressions are evaluated first and the results are concatenated. Then echo outputs the result after all fragments are concatenated. With commas echo walks the argument list, evaluating expressions and spitting out the results as it goes along.

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
paypal.me/rhashemian
© 2001-2019 Robert Hashemian   Powered by Hashemian.com