Tag Info

Hot answers tagged

5

A configuration file is not publicly viewable over the internet as long as the permissions are setup correctly. Configuration files usually do not output any data directly anyway. They are able to download a copy of the configuration file if they exploit your server and gain access via methods such as SSH, FTP or through a web-based control panel. Keeping ...


4

How can I figure out what caused the problem? Basic forensic steps for this type of breach are as follows: Establish basetime - when did the files that were modified change? Use 'find' to search your webroot for files that changed before basetime but not more than (say) 24 hours before basetime - use "touch" to create files with the start and end ...


3

Support for Joomla 1.5 LTS ended in Dec 2012. This usually means that no more security patches (or any other maintenance patches) will be released. The "solution" is to migrate content from a known good backup to a supported Joomla version, or some other current Content Management System. Even if someone here were able to figure out a fix, you would have ...


3

I'd bet the TinyMCE addon is how they got in. Here's how I'd clean it up without trashing the whole box: Make a full database backup. Check the users table and delete any you don't recognise. Back up all media files (uploaded directory) and check through them for any shells / PHP files. Download version 1.5.14 and install it. Restore the old database. ...


2

With a normal web server configuration (at least in most web hosting companies), any PHP files cannot be access directly by visitors over the Internet. All they get are the one that interpreted in HTML. This also meant as well for configuration.php (or config.php) for any web apps.


2

@Dasun What steps should I take to prevent happening this in the future? First: Accept the fact your website will never be "unhackable". After you cleaned up the mess (usually means, start over from scratch), update your Joomla core and update all your components, extensions, et cetera. And keep it updated. Don't forget to double check your file ...


2

Below script did the hack No - that's what got left behind after the attack. I removed the script and site happens to work fine. But you haven't fixed the vulnerability. The current Joomla version is reasonably secure (older versions are not) but there are a large number of badly written extensions out there. And maybe the attacker didn't even ...


2

Don't host customers who decline to keep their software updated. There is no other option if you don't want your sites to be hacked. It is impossible to secure vulnerable software. Also, any site that has been hacked needs to be wiped out completely and reinstalled from scratch or a known-good backup. Again, no other option is safe.


2

My investigations brought me to this link: http://forum.joomla.org/viewtopic.php?f=432&t=341064&view=next It seems the problem is related to that information, and removing the code at the bottom labelled as ""This code use for global bot statistic" seems to have fixed the problem. Weird is, that file changes for that file are from 21.July 2012...So ...


1

Some daemons traditionally use nobody, so that if they are comprimised, the access they have is limited. If you start assigning files to the nobody user, then if you do have a daemon running as that user, and it was comprimised in some way, then the attacker could potentially gain access to the files. Given that the files are a website, and Joomla ...


1

Most of the above answers seem to be missing one vital piece of information, which is that Joomla 1.7 is no longer supported and is open to vulnerabilities. Joomla 1.7 was a short term release and was end-of-lifed in Feb 2012. My advice would be to consider upgrading as soon as possible. For notes how to upgrade to 2.5 stable ...


1

While the eval() command you show seems relatively benign (although it makes your server download things), the presence of this command in your index.php file indicates that the attacker got a write access to at least some files in your site. He may then have bugged it in various ways, possibly escalating his access into a more thorough system-wide access. ...


1

For a stronger security of configuration PHP files you can also lock file for preventing of changing or manipulating them. This will add stronger security. On a linux server function are chattr and on a VPS server you should lock a file of configurations: chattr +i /home/user/configuration.ini



Only top voted, non community-wiki answers of a minimum length are eligible