Recently we began to experience attacks in our Magento 1.9 store. Can someone help us how to detect the entry point and how to fix it?
These are the files affected by the malware.
Files affected
The files are injected with some encoded base 64, that send data to this address: https://103.233.11.28/analytics.php
Thanks in advance.
It's hard to determine the root cause just with this input, I do not think someone can answer to question like this
You need to analyze access logs and finding the steps hackers take and implement the patch. It's not necessary Magento - could be environmental issue as well
As Magento 1 is not supported anymore it's better to upgrade to Magento 2
Related
one of my clients complained that she cannot log into her Joomla installation anymore. So I checked the database and saw, that all the user names and passwords (md5 value, I used a rainbowtable to check) are set to "harun". Did anyone ever hear about that? Google doesn't...
Also: what do I need to to now (besides changing passwords)? I'm not that "big" in web-dev and never faced such a problem.
Any help appreciated.
Clearly you have a great deal of cleanup to do....I hope you have a database backup! We had the same kind of thing happen to us a couple of years back, and installed RSFirewall. While attacks still occasionally occur, this wonderful extension has cut the damage by 99% for us. Good luck!
You need to clean up the website and find and fix the point of entry.
1. clean up the website
You could restore from a backup but it can be difficult to determine the exact date the website was compromised.
You could spend days trying to find and fix compromised files yourself.
The best option is probably to use a commercial service like www.myjoomla.com or sucuri.net which cost very little and are usually effective at finding and fixing infected websites. In particular, the myJoomla security tool can identify core Joomla files that have been changed and replace the changed ones with the original files.
2. find and fix the point of entry
Update Joomla to the latest version in the series.
Update all third party extensions to the latest versions.
Update Joomla, FTP/cPanel and Database passwords.
Check the Vulnerable Extensions List at vel.joomla.org to ensure you are not using any vulnerable extensions.
Also see the Official Security Checklist at http://docs.joomla.org/Security_Checklist and https://stackoverflow.com/a/19139389/1983389 and https://joomla.stackexchange.com/a/180/120 for tips on keeping your Joomla website secure.
For long time solution its an suggestion please change your server or host. As you said MD5 are set as "harun" as per my opinion its change by some kid's hacker by sim-link or some local jommala vul. attack . If its sim-link attack then you need to worried about host else if its jommla vul. then simply change the version or update it and make cleanup on your publichtml/ or soo on .And make sure there is no other php script or perl / python script not found on your Host.
I've got a whole load of EE sites under my belt and generally don't have much of a problem with spam. However, one site that I look after is getting bombarded by registration spam lately. It is an extremely low traffic site and was a bit neglected which meant it was running an old version of EE.
I've now updated the site to the latest EE version and gone through double checking that everything was locked down. I've even tried installing Low NoSpam but I'm still getting the attempted registrations.
My initial thoughts were that there was some security hole in this old version of EE. But since I have now updated everything I'm not so sure.
What is the best way to deal with this other than turning registrations off?
I personally find that RECAPTCHA is the best captcha system out there:
http://devot-ee.com/add-ons/recaptcha
It's ADA compliant, your visitors help translate books and its probably the most popular. Snaptcha would do the trick as well, but I personally think that if you need a captcha (which I hate :)) then go with RECAPTCHA :)
Oh and it's completely FREE too!!
Have you changed the Profile Member trigger word to something other than 'member'?
I had excellent results with Snaptcha for comment spam - it works for registration spam too. Worth a look.
If I build a site using Wordpress, is there a straightforward way to restrict access to the whole site to only those who I specify?
I've looked a few plugins that attempt to redirect unregistered users to the login page, but most seem old, fragile, or generally just hacks.
I want to know if a standard Wordpress installation lets you do this, or otherwise if there's a decent and secure plugin to do it. I need a solution that doesn't involve changing the default wordpress PHP scripts as I don't have direct access to the server. It's quite important that the solution is secure.
Any help or past experience would be appreciated.
EDIT: Apologies if this is better suited to http://wordpress.stackexchange.com, wasn't aware this existed. Please move if necessary :-)
The new version of WP, I believe v 3.1.2, has this option for pages and posts under the quick edit.
You can set a password per post / page or mark them as private.
Are there any special security measures to take when deploying a Drupal site to a production server?
For instance: I can imaging that we need to remove install.php from the root directory. Are there any more actions?
Or is there maybe a module available which checks the site for "world readiness"
The status report on http://your-site/admin/reports/status will tell you if anything is not quite right.
Under the performance admin page you can turn on various caching settings, but test your site with them turned on before deploying.
There is a book by greggles for securing drupal, which may be worth a look.
Ideally you've tested your code for insecurities before deploying, but configuration can often be missed. There's a mode for analyzing your Drupal site for misconfiguration that would lead to vulnerabilities http://drupal.org/project/security_review
Security Review makes the following checks:
Safe permissions on system files
PHP in comments or nodes
Whether error reporting is on
Unsafe input formats
If private files is on and if the files directory is outside webroot
Allowed upload extensions
Admin permissions granted to untrusted users
In addition to other suggestions, remove update.php also.
I'd also (re)move /scripts from the webroot
It's a minor thing, but you could remove the text files in the root of the distribution which leak the version number. Such as CHANGELOG.txt etc.
I don't remember how safely cron.php protects itself from flood-calling. You may want to look into whether it is worth limiting that to local-only or command-line-only access.
Ensure that .inc files are processed by PHP.
all this answers make you stop thinking after your install is done - but software has a history and after installing drupal you have one more baby to watch - in drupal´s case watch VERY closely! This means you MUST subscribe to the drupal security mailing list and read all mails that are coming form there - be prepared to get many emails. It is good, that the drupal team is providing these informations fast, but it is sad that there are really too many of these mails, what might be related to drupals programming style. be prepared to get up more than once in the middle of the night to update your drupal installation because some extension developer never did understand, why input from the web must be sanitized (yes, these kind of security problems are still happening in the drupal world.)
So "hardening" means "keeping up with updates", in drupals case these come quite often. Think about this if you have many sites and want to deploy to multiple servers - automatic deploymemts will help you save a lot of time.
Here's an excellent rundown for Drupal 7: http://www.madirish.net/242.
Most of its suggestions are relevant to Drupal 6 as well.
You should also remove the Theme registry rebuilding setting.
It rebuilds your theme registry on every pageload, so it makes your site very slow.
How exactly do you do this? The reason is my CMS has been breached, well, mainly because the username and password is fairly common (my bad). But I've always thought that it is save, since the directory name is pretty un-common and hard to guess (not the usual /cms/ or /admin/). Brute-forcing from a script? or maybe some Google tricks?
update : my CMS is in PHP and I developed it myself. I don't remember putting the link to it everywhere, except once in email I sent to my friend via gmail.
update 2 : as this could be used by some people to attack a site, please don't put any script in the answer. My intention is just to know the general ways to do it, so that I could prevent further attacks like this.
Thanks in advance.
Did you ever surf somewhere via a link from your CMS? Your browser would have sent a referer (note the misspelling) header, indicating where you came from.
Maybe you had a link to administrative area somewhere?
Or maybe accessing main directory without filename renders directory index?
I.e. you're using mod_autoindex?
My guess is, that somebody linked to your CMS URL and an automated (evil) script found it using Google search results looking for some common patterns.
Search in Google using this query
link:http://www.example.com/myCmsFolder
to verify if your link/pages are contained in Google.