lammert - 8:09 am on Jan 31, 2010 (gmt 0)

Good point UserFriendly, because some things in this post don't add up. If the hacker had obtained the password via a trojan, there is no connection with the directory security settings on the server side because he would have entered the server as a normal user with full access rights via FTP, unless the hacker had specific reasons to alter the directory settings for future purposes.

Either the directory settings were already wrong from the beginning, or they have been changed by the attacker to create a back door via Apache to re-hack the computer once the original hole would have been closed. In the latter case there is also a big chance the hacker installed a root-kit on your server. After all it seems that you use user name root to enter your server which is a big no-no in security terms.

For the same reason, the example of AlexK is wrong:

ls -al drwxr-xr-- 7 root apache-group 4096 Dec 13 00:17 . drwxr-xr-x 22 root root 4096 Dec 9 17:34 .. -rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.html -rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.php -rwxrw-r-- 1 root apache-group 36336 Dec 12 13:17 bad_file.php -rwxrwxr-- 1 root apache-group 36336 Dec 12 13:17 even_worse_file.php

It should read:

ls -al drwxr-xr-- 7 some-user apache-group 4096 Dec 13 00:17 . drwxr-xr-x 22 root root 4096 Dec 9 17:34 .. -rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.html -rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.php -rwxrw-r-- 1 some-user apache-group 36336 Dec 12 13:17 bad_file.php -rwxrwxr-- 1 some-user apache-group 36336 Dec 12 13:17 even_worse_file.php

where some-user is an unprivileged user account which has only very few rights and is not associated with the user account used to run the apache server.