A few days ago, a client of ours emailed us and told us that some of the pages on her company website were displaying content that was not theirs. The content was not technically malicious, but it consisted of ads, which had nothing to do with the client’s business. Clearly, the website was hacked.
Since only a few pages were affected, we had a hunch that it was a database hack, so we searched the database for the modified content, and, oddly enough, we didn’t find the modified content in the #__content table, but we found it in a table called #__finder_data. We’ve never seen this table before. To the untrained eye, the table seemed to be part of the Smart Search extension, but, as Joomla experts, we knew that it couldn’t be the case, as the Smart Search does not use any such table.
So we looked at the content of the table, and we noticed that most of the rows were benign and were just a copy of some rows in the #__content table. A few rows, however, had some altered (hacked) content.
We quickly (and wrongly) assumed that the #__finder_data table was used by a 3rd party extension for some caching reasons (although it seemed pretty useless, as it was just a copy of the #__content table), but we needed to know which extension it was used by. So, we did a grep on the filesystem which quickly revealed that the table was used in the file query.php which is located under the libraries/joomla/database folder. Yes, you’ve guessed it, the query.php is a core file, which means that the whole #__finder_data is likely part of the hack. So, we opened the query.php, and we searched for finder_data, and we found the following code:
if (!isset($GLOBALS['issebot'])) $GLOBALS['issebot']=$this->is_sebot(); if ( @$GLOBALS['issebot'] AND preg_match('/#__content(\s|$)/', $tables) AND in_array($db_px.'finder_data', $this->db->getTableList() ) ) { $tables=str_replace('content', 'finder_data', $tables); }
The above code was located in the from function, and it checked if the traffic was coming from a bot (the method is_sebot was also added to the query.php file), and if it was, then it displayed content with matching ID from the #__finder_data table. Clearly, the method to check if the traffic was coming from a bot or not wasn’t exactly working properly, as the website was displaying the modified content for regular, non-bot traffic.
We quickly did the following:
- We overwrote the hacked query.php file with a clean query.php file from a matching Joomla version (actually, we used our super fast method to clean Joomla sites and overwrote the whole core).
-
We deleted the #__finder_data table as it had nothing to do outside the hack.
Doing the above solved the problem, but, of course, it didn’t answer the question, how did this happen in the first place even though the site was using a very secure version of Joomla? We don’t know for sure, but we suspect the host. We’re not saying that the host did this, but what we are saying that the host that the client uses is notorious for bad security (the host has the word giant in its name, you figure the rest).
If your Joomla website displays (even slightly) different content than the real content, then likely your website is hacked. Try our simple cleanup instructions above and see if that fixes the problem. If it doesn’t, then please contact us. We will clean your website, we will secure your website, and we won’t charge you much.