Our 3.x site recently was attacked by a very similar exploit to what's documented in this link from another thread except that ours had a lot more files changed. We took these repair actions:
Note: We are repairing with a fresh copy of Joomla on a new server at a new host. We have no expectations of 'fixing the problem.' However, I would still like to understand the mechanism of the exploit because it's really frustrating that I can't catch the mechanism in the act.
Despite this, the site still redirects to a spam site when referred from a search engine. When I use FirefoxAurora's network inspector to watch it happen, I see that my site loads a complete document with a status code of 200. This document is *identical* to the non-redirecting copy that loads just fine for direct traffic. However, it still redirects to the spam site, which also loads with a 200.
I know Javascript is involved because disabling Javascript prevents the redirect. However, I can't find the offending code and I have looked at everything in the source panel and that's included in the response. More puzzling is that dev tool event monitors to watch for an unload do not trigger, so I can't inspect the code as it happens - but there isn't any way to go to a new URL without an unload, right? And it can't be a PHP redirect because that can't come after output and it wouldn't need Javascript enabled anyway, right?
Has anyone successfully diagnosed the way this is happening or can give a hint how to detect it? Again, we are preparing a fresh copy of the site on a new server, so I'm not under any illusion I can permanently fix the site, but I want to understand what it's doing.
Would be happy to share the specific URL by PM if you're curious enough to observe this yourself. Thanks very much for reading, if you're still with me.
via Joomla! http://ift.tt/1D2m4Om
Note: We are repairing with a fresh copy of Joomla on a new server at a new host. We have no expectations of 'fixing the problem.' However, I would still like to understand the mechanism of the exploit because it's really frustrating that I can't catch the mechanism in the act.
- We searched for all eval and base64_decodes that differed from a staging site and removed the offending files.
- Wherever a directory was created just to store exploits (fake module, etc.) we removed the directory.
- We inspected all the sibling and children in the deep directories where exploits were stored.
- The attacker also spoofed most changed dates to the same two dates so we removed all of those.
- We also replaced several files from a staging site that were compromised with redirects and/or encoded characters to be evaled (index.php, .htaccess, template index.php, etc.)
- We inspected every Javascript file loaded by the site and compared obscured files (like jQuery minified) to known good copies.
Despite this, the site still redirects to a spam site when referred from a search engine. When I use FirefoxAurora's network inspector to watch it happen, I see that my site loads a complete document with a status code of 200. This document is *identical* to the non-redirecting copy that loads just fine for direct traffic. However, it still redirects to the spam site, which also loads with a 200.
I know Javascript is involved because disabling Javascript prevents the redirect. However, I can't find the offending code and I have looked at everything in the source panel and that's included in the response. More puzzling is that dev tool event monitors to watch for an unload do not trigger, so I can't inspect the code as it happens - but there isn't any way to go to a new URL without an unload, right? And it can't be a PHP redirect because that can't come after output and it wouldn't need Javascript enabled anyway, right?
Has anyone successfully diagnosed the way this is happening or can give a hint how to detect it? Again, we are preparing a fresh copy of the site on a new server, so I'm not under any illusion I can permanently fix the site, but I want to understand what it's doing.
Would be happy to share the specific URL by PM if you're curious enough to observe this yourself. Thanks very much for reading, if you're still with me.
Statistics: Posted by cornchip — Thu Feb 05, 2015 5:30 pm
via Joomla! http://ift.tt/1D2m4Om
No comments:
Post a Comment