Hi folks,

I'm in the midst of fending off a malware attack that adds a hidden iframe to the index.php file. (It's likely the result of compromised FTP login credentials, which is what the malware sniffs out on infected clients.) More generally, this malware is known to make the malicious code insertion into any index and default pages it can find on the Web server.

The "good" thing, if that's possible with malware, is that the code injection simply causes all Drupal-related pages to error out with everyone's favorite error:

"Parse error: syntax error, unexpected '<' in /f1/content/[site]/public/index.php on line 38"

On one of the two Drupal sites I'm fixing, deleting the iframe insertion (which was below the footer code in index.php) does the trick. But on a second Drupal site, fixing the index.php page hasn't solved the problem. I'm still getting the same syntax error, and I don't believe it's a caching issue. I looked through my entire installation for any changed files but couldn't find any, though it's possible I've missed something somewhre.

Any advice would be greatly appreciated about where else to look in my Drupal installation for index files or others that could be creating the syntax error.

My thanks for your help,
ITG3000

Comments

pobster’s picture

Index.php in your webroot, this is the only one. Everything else is served out of the db other than the update and install pages and these require security anyway.

Pobster

dman’s picture

Beware, I saw a rash of these last year, and yes, the first ones just broke Drupal.
I've seen others on the same vector that are a bit more clever and no longer kill index.php. Yeah, compromised ftp login is the best guess.
Depending on just how clever or directed it is, of course ANYTHING could potentially be broken. A directed attack would and could know to hit page.tpl.php or worse.
So far, I've only seen it on index.php in the root. but take care.

IT Guy 3000’s picture

Great. Thanks for this info. When I've got everthing resolved and buttoned up, I'll post a summary here for everyone's reference.

It seems this kind of attack is becoming more prevalent as spreading malware via e-mail has become more difficult, and sniffing out saved FTP information (and other saved username/password combos) on improperly secured client machines is surprisingly easy. I've also discovered that Internet Explorer sometimes saves certain FTP login information inside some registry keys, and not just in the places that can be removed via Internet Properties/Delete Files.../ Which is, to my mind, kinda dumb. I need to investigate that further.

beautifulmind’s picture

Do you get the same error on second site? on what paths?

Regards.

Regards.
🪷 Beautifulmind

IT Guy 3000’s picture

After reviewing every bit of code on the (second) site, it now seems like it is a host/caching issue. (Neither site has the Drupal caching enabled.)

Not to go too far off-topic, but are there other caching issues I should know about with Drupal, as I dig into it? I understand that 6.x has a button in the admin tool to clear the Drupal cache. I'm wondering if there's anything I should know about how a typical Web host's caching might impact how quickly new pages are served. After I repaired the hacked code, it did take some time before the fixed site was served properly.

Also, on caching, does enabling and using "Clean URLs" have any impact on when pages get refreshed?

Thanks,
ITG3000

beautifulmind’s picture

well, clean urls are for SEO.
To clear the cache, just go to db and remove all the records from the tables which have 'cache' in the name.

I don't think that your host can help you about caching.

Regards.

Regards.
🪷 Beautifulmind

netceo’s picture

Very valuable information. Had similar problem, solved in a jiffy.

Thanks

osherl’s picture

index.php and every single .js file in folders /misc, /modules and /sites/all/modules altered with injected code. Happened twice already. Very annoying!

pobster’s picture

Are you using FTP? If so... Don't... That's the most likely thing to be hacked.

Pobster