Need help removing iFrame hack from website?
Question
Ok, so somewhere on my site is a Javascript file that after a few seconds, injects an iframe to an unknown site into the page. What it injects fails miserably and the HTML is a bit messed up, but it's concerning because the iframe src has changed since the last time I checked.
Code Injected:
<divstyle="height:2px;width:111px;">
<iframe style="height:2px;width:111px;" src="http://nleskoettf.com/index.php?tp=001e4bb7b4d7333d"></iframe>
</divstyle="height:2px;width:111px;">
For an up-close and personal glance: http://caseconsultant.com is where it injects (see bottom of page). Don't worry, the URL in the iframe src is dead (downforeveryone.com/nleskoettf.com) , it's not even a working website which is the really confusing part.
Anyone know how I can track back the injected HTML to the source? Anyone able to do that?
3 answers
solution1
4 ACCPTED 2011-11-17 01:28:46
You may use a tool like Noscript to block domains for scripting and localize the script that injected the iframe.
Then you will see that the iframe will not be present when you block twitter.com
There is a function inside http://caseconsultant.com/wp-content/plugins/contact-form-7/scripts.js?ver=2.3.1 (see the last line) that loads some JSON-data from twitter and creates the iframe(maybe using data from the twitter-response, may be a reason for the changing url).
This also may be interesting to you: Is this dangerous Javascript? (It's the same function)
I'm not sure if this is malware, maybe there is only a bug inside the function that creates invalid HTML/URL But the function has nothing to do with a contact-form, and also isn't a part of the original scripts.js(you'll find it here: http://downloads.wordpress.org/plugin/contact-form-7.2.3.1.zip ), so I'm afraid the site has been hacked(except you put the function there on your own).
So what you can do:
- Read this (removing the function will not be sufficient, as long as you didn't remove the vulnerability)
- Check the Server-Logs, script.js has been modified on 11 Nov 2011 19:57:00 GMT , has there been something suspicious-looking? If not you may assume there is no server-side vulnerability(but server-logs can be modified too), ....
- Change your FTP-Password
- Scan your PC for malware
solution2
2 2011-11-17 02:41:29
I'd recommend using Chrome's Developer Tools to figure this out. If you load your site in Chrome, you can then open the tools by hitting the wrench button, then Tools -> Developer Tools (Or Ctrl+Shift+I ).
From there, you can use the Resources tab to see everything thats being loaded for that page, or the Scripts tab to focus on just javascript. For this problem, neither of those seem that useful, so I recommend a different method: breaking on DOM changes. Take a look in the Elements tab, right click on the <body> tag and choose Break on subtree modifications . Then, refresh the page (might need to refresh twice, Chrome bugged out for me on the first time).
You should arrive at a call to jQuery.append in the Scripts window (if not, hit F10 until you are, sometimes Chrome picks up on more or less modifications on load), and if you look at the a variable under Local in the Scope Variables sub-window, you'll see that this is trying to insert the offending div/iframe.
Now you can step through the javascript using the buttons at the top-right, or F10 and F11. If you hit F10 a few times ('Step Over'), you'll end up in the offending script, referred to by Chrome as '(program)' (means its been dynamically loaded). This has been obfuscated, so its a bit hard to read/understand, but you can use the console window to run things from the script.
For instance, the jsn function is being used to translate obfuscated text. You can use this to see all of the different strings it is using, for instance on this line:
jsg = jsn('Ch') + jsp(jsb).substring(0, jsa) + '.com/' + jsAJ($);
That constructs the url for the iframe.
This means we've identified the offending script for sure, but the fact that this is identified as '(program)' by Chrome means it has been loaded dynamically into memory to be run. This means the actual script part is most likely compressed and further obfuscated somewhere in your other script files. If you look through those script files in the Resources file, you should be able to find a line or lines that don't fit in, that look very obfuscated/compressed, and are perhaps inside of an inline function call, IE:
(function() { ... } )();
They may also look somewhat similar to the script file inside the '(program)' view. It can also help to search for things that would be hard to compress/optimize further, such as the obfuscated strings. I searched for one of those strings, haDWDosestnsdlDjfqcq , and found it at the bottom of scripts.js . Delete that line and your site should be fine!
solution3
1 2013-02-17 02:40:38
I recently had this happen, iframe injections into the javascript files (and others!). First thing I did was a grep -n for the url on my entire server to find every instance of the injection. Just one line and fairly simple to remove. Then came the matter of tracking it down.
It turns out it was a rogue apache module that had been planted due to a vulnerability. In my case it was mod_aclr.so
Go through your /usr/lib/httpd/modules/ or /usr/lib64/httpd/modules/ directory and compare your list to the list of real apache modules here: http://httpd.apache.org/docs/2.2/mod/
If you have some modules that don't appear on that list, vi them to see what they contain, or simply do a google search to see if they are affiliated with actual modules. In my case, mod_aclr.so returned about 10 pages of Russian commentary, so I quarantined it and will be watching to see what happens now.
Here's a good writeup on the subject: http://blog.unmaskparasites.com/2012/09/10/malicious-apache-module-injects-iframes/
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.