This was a fun, yet painful case. In the past we have written a few different posts targeting search engine poisoning attacks (SEP) that like to use Pharmaceutical keywords and their associated links to poison your search engine results.
Today we had an interesting scenario where Google had not yet blacklisted the client, but our free scanner, SiteCheck, was in fact picking up the injection. From what we could see it was being triggered by a referrer but it wasn’t the typical referrers you’d expect, it’s condition was if it came from itself.
If you’re wondering why that is, allow me to explain. That meant that the payload would not show up the first time you visit the page, only when you visit the same page and the referrer was set to itself. This actually a very good evasive technique, it would make detection that much harder by most conventional scanners. In short, if the user clicks on the paeg once, it wouldn’t appear. This makes it very hard to detect and replicate unless you start testing every option. In this case, it wasn’t until you clicked on the option two consecutive times that the injections would appear.
You could try any other variation and it’d never work, only if you clicked on it two consecutive times. How annoying is that !!! This probably explains why Google and many others never picked it up.
In either event, this was a Joomla site and so the question was, where the heck is this thing.
We searched high and low through out the websites directory nothing. We forgoed our normal scripts and began performing manual reviews and inspections. An advantage of a system that is driven by human intelligence. We checked all the normal places, and extended the search by disabling the entire site and enabling components manually. It was not the most exciting of processes.
There I was with a brand new skeleton of Joomla, no templates, extensions, plugins, modules, etc.. completely clean install. I added the configuration file, as I normally don’t like to mess with the database, and check things out. Low and behold, alarms start going off. I open the configuration file to see what might have triggered things and look at what I find:
@require_once(JPATH_SITE.DS.'../../../.fontconfig/cache.ini');
Those little buggers…
If you’re wondering what that is, it’s telling the site to load the cache.ini file. If you use FileZilla or other equivalent FTP client you’re likely not going to be able to see the .fontconfig directory as it’s showing up as a hidden directory. Even enabling hidden files and directories, unclear why at the moment. In these cases knowing that I have access to that level, ../../../, I know that I should be able to see that .fontconfig directory. I then turn to my handy dandy NCFTP client.
If you’re not familiar with NCFTP you should check it out, it allows you to work in a terminal environment and makes things a bit easier if SSH isn’t available.
Finally getting access to the directory and it’s content I find this:
If you’re not familiar with what this is, all I’m doing is listing out the content of the .fontconfig directory and using the cat command to take a look at what’s in the cache.ini file.
You should also notice the long random file and directory, they start with 2ad…, 41909…,e13b20f…. and so on. Just to confirm this is the payload, I jump into the 9713fd4a2ef1aae518ebaeacdk4033d2b directory and find:
And the final step, is to take a look at one of those new random files and see what they contain:
And just like majic you find all the payloads injections.
Food For Thought
This payload was nowhere near the websites directory. It was bundled many layers above the websites directory and being included with something many might assume to be a benign reference in any PHP file. Unfortunately, @include, @require and its many variations are commonly used, whether we like it or not, and the file name in it of itself is not malicious, only its content.
So what do you do?
This is today’s reality and where the real value of a system and process built on human intelligence comes into play.
If you have any questions leave us a comment or send us an email at info@sucuri.net. If you find yourself dealing with this mess and prefer not deal with it, no problem, just sign up with us and we’ll get it squared away for you.
4 comments
Just for a quick typo feedback (not for a post):
text: it’s condition was if it came from itself.
text: it’s content
error: it’s
fix: its
Thanks.
Seen it before, many times, and the audit tools at http://www.Joomla-Security.com already identify this type of hack – but then thats the difference between “scanning from the outside” and “auditing from the inside” 🙂 This is not an advert – just making that point 🙂
Phil how can this be true – doesnt joomla-security only scan public_html?
Thanks for giving me the useful information. I think I need it. Thank you
Comments are closed.