My website (hosted on a Windows/Apache(XAMPP) server) seems to suffer from an iframe injection attack. The iframes appear at the top of pages and disappear at times for no obvious reason. There are also several other symptoms:
The html code for the iframe does not actually appear in any of the html/php files (no base64 code either)
The iframe appears in the directory listings generated by apache. (i.e. there are no html/php files to investigate)
The problem seems to disappear when the website is accessed through HTTPS.
Nothing noticeable in htaccess files.
FTP password has been changed and FTP access monitored, doesn't seem to be the issue.
Any idea on what is causing it or how to stop it?
Well, this might be a man-in-the-middle attack.
Unlikely, I know, but possible.
If you are accessing from public WiFi or have a mysterious van outside your building, this could be it.
Basically, a man-in-the-middle attack injects code into webpages after they come back from the server and before they reach the client.
However, MITM attacks usually only work on HTTP (unless they're using SSLStrip, sorry, got off topic for a moment). This could explain the problems going away on HTTPS.
Related
Recently our website went from http to https. I, and others, are randomly getting "The Site Can't Provide a Secure Connection" page. Upon refresh, the page loads just fine. Why are we getting this initial page randomly?
FYI... We have http to https redirects in place.
Impossible to say without more details, but some things I can suggest are:
You have multiple servers and some are configured correctly and some incorrectly.
You are not including the full certificate chain. Sometimes your browser has the missing intermediary cached and sometimes not (see this answer for more info here: https://serverfault.com/questions/826100/ca-certificate-trouble-with-squid-on-centos7/826321#826321)
A bug in browser/software. I had this issue on Chrome when using Apache HTTP/2. Never did figure it out but a Chrome update fixed it.
Run https://www.ssllabs.com/ssltest/ on your site to confirm not a problem with your https set up and, if that doesn't work, or you don't understand the results it gives, then update your question with more details (what Server and Browser you are using and what version, if you have any proxy in place between your Browser and the site and, ideally the website name) if you want people to help you.
Also be aware this is a programming site and some people don't like these questions here and will suggest other Stack Exchange sites but honestly don't know where this question is best placed: serverfault.com maybe, but is for professional SysAdmins only, Unix and Linux seems a little generic (not even sure if you are using a Linux webserver!), Webmasters is more for content and SEO questions, Information and Security is more for theoretical SSL/TLS questions...
My server has been compromised recently. This morning, I have discovered that the intruder is injecting an iframe into each of my HTML pages. After testing, I have found out that the way he does that is by getting Apache (?) to replace every instance of
<body>
by
<iframe link to malware></iframe></body>
For example if I browse a file residing on the server consisting of:
</body>
</body>
Then my browser sees a file consisting of:
<iframe link to malware></iframe></body>
<iframe link to malware></iframe></body>
I have immediately stopped Apache to protect my visitors, but so far I have not been able to find what the intruder has changed on the server to perform the attack. I presume he has modified an Apache config file, but I have no idea which one. In particular, I have looked for recently modified files by time-stamp, but did not find anything noteworthy.
Thanks for any help.
Tuan.
PS: I am in the process of rebuilding a new server from scratch, but in the while, I would like to keep the old one running, since this is a business site.
I don't know the details of your compromised server. While this is a fairly standard drive-by attack against Apache that you can, ideally, resolve by rolling back to a previous version of your web content and server configuration (if you have a colo, contact the technical team responsible for your backups), let's presume you're entirely on your own and need to fix the problem yourself.
Pulling from StopBadware.org's documentation on the most common drive-by scenarios and resolution cases:
Malicious scripts
Malicious scripts are often used to redirect site visitors to a
different website and/or load badware from another source. These
scripts will often be injected by an attacker into the content of your
web pages, or sometimes into other files on your server, such as
images and PDFs. Sometimes, instead of injecting the entire script
into your web pages, the attacker will only inject a pointer to a .js
or other file that the attacker saves in a directory on your web
server.
Many malicious scripts use obfuscation to make them more difficult for
anti-virus scanners to detect:
Some malicious scripts use names that look like they’re coming from
legitimate sites (note the misspelling of “analytics”):
.htaccess redirects
The Apache web server, which is used by many hosting providers, uses a
hidden server file called .htaccess to configure certain access
settings for directories on the website. Attackers will sometimes
modify an existing .htaccess file on your web server or upload new
.htaccess files to your web server containing instructions to redirect
users to other websites, often ones that lead to badware downloads or
fraudulent product sales.
Hidden iframes
An iframe is a section of a web page that loads content from another
page or site. Attackers will often inject malicious iframes into a web
page or other file on your server. Often, these iframes will be
configured so they don’t show up on the web page when someone visits
the page, but the malicious content they are loading will still load,
hidden from the visitor’s view.
How to look for it
If your site was reported as a badware site by Google, you can use
Google’s Webmaster Tools to get more information about what was
detected. This includes a sampling of pages on which the badware was
detected and, using a Labs feature, possibly even a sample of the bad
code that was found on your site. Certain information can also be
found on the Google Diagnostics page, which can be found by replacing
example.com in the following URL with your own site’s URL:
www.google.com/safebrowsing/diagnostic?site=example.com
There exist several free and paid website scanning services on the
Internet that can help you zero in on specific badware on your site.
There are also tools that you can use on your web server and/or on a
downloaded copy of the files from your website to search for specific
text. StopBadware does not list or recommend such services, but the
volunteers in our online community will be glad to point you to their
favorites.
In short, use the stock-standard tools and scanners provided by Google first. If the threat can't otherwise be identified, you'll need to backpath through the code of your CMS, Apache configuration, SQL setup, and remaining content of your website to determine where you were compromised and what the right remediation steps should be.
Best of luck handling your issue!
Well the main question says it all, why are the files loaded via https. I am just adding some new libraries to the website, and noticed that the links are all https://.
Now from what I understand you use https when there is some sensitive information, and I do not think that is the case with these libraries I guess. I think nobody is interested in getting the content of these files.
Is there any explanation for this ?
People asked for it so they could use the libraries on things like e-commerce sites, which eventually require an SSL connection. They provide links to the https version by default to make it easier for everyone overall (automatically avoids mixed-content warnings), and for most people the slight performance cost won't matter. But if you know you won't have any need for it, just strip it down to a regular http connection:
https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
They did actually publish the http URLs at one point, but I'd imagine that the resulting mixed-content warnings etc that came about as a result of people adding SSL connections and not thinking it through just created a bunch of support questions, so it was simpler to default to showing https and let people hack it if they really wanted.
I'm wondering how I can find out where the culprit is, as to what is NOT being transmitted over SSL on my website. It's blowing my mind, because I use relative URLs or explicitly choose HTTPS:// for all links, images, etc...
Any ideas/tools to find out what the issue is?
Thanks.
If you mean that some resources are transferred over HTTP without encryption, you can check for this in Chrome's Developer tools in the tab Resources - that should tell you which parts come from where - look for those with address starting with http:// .
Alternately, use Fiddler: by default, it won't decrypt HTTPS connections, so you'll be seeing CONNECT requests for HTTPS, and GET/POST for HTTP - those are your culprits.
For those, like myself, who run into this issue i suggest a few tips while designing your website.
Always use relative paths when ever possible "images/someimage.png" instead of using domain paths like http://someDomainName/images/someimage.png so on. Any one of these and it will cause the browser to throw that warning at you.
When linking to external content, Google/other Ads, javascript sources(such as jquery, so on), or any other media... make sure you use a https:// link if they have one available. Myself, i had one tiny image for a link to an external site but they did not offer a https link to the image, so i simply downloaded it and put it in my images folder. Problem solved.
The Chrome resources list is a very helpful tool, not sure if Firefox has something similar in its tool box. Another method, if you have shell/command line access, is to use grep to search the files for "http:". This, most often, will show anything that is linking to non secure content.
I have a site and i implemented ssl there. but when i browse it, the security seals dont come. i asked to godaddy, they replaid:
Thank you for contacting online support. I cannot replicate the issue you have described. The error you described is caused by the way your site has been designed. If you receive this error, you have a combination of secure and non-secure objects on the page. For example, if your secure website was https://www.domain.tld and you added an object (an image, script, flash file, etc.) to that page that was located at http://www.domain.tld/image.jpg, you would break the seal.
You will need to change your design to
link to objects using https (ie
https://www.domain.tld/image.jpg) or
modify your site design to use
relative paths (/image.jpg).
This error can only be corrected by
modifying your site design. Please
contact your web designer or the
manufacturer of your web design
software if you require additional
assistance modifying your site design.
but the problem is i made everything,all my images javascripts are unders https, but the seal still not coming, saying: some content insecure. what is the problem.
Your problem is in line 8 of jqueryslidemenu.js:
var arrowimages={down:['downarrowclass', 'http://lendersutopia.com/images/down.gif', 23], right:['rightarrowclass', 'images/right.gif']}
You should change it to
var arrowimages={down:['downarrowclass', 'images/down.gif', 23], right:['rightarrowclass', 'images/right.gif']}