Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Recently on one of my clients servers running apache and php, I have noticed a bunch of random files which were placed throughout every folder on the website. They are named with random numbers such as 205492.php.

There are also .htaccess files which have been placed along with these randomly numbered files. My host tells me its the clients upload script in php, but the owner/group of the files are set to httpd. I think this means its the apache daemon which placed the files here. The creation time of these files are all set to the exact same timestamp.

There are a lot of CURL and base64_encode functions throughout the random php file. I did notice the person who built my clients website had chmod to 777 on the entire folder. I've since changed to 755 thinking that could have been the problem.

I am wondering if anyone has heard of something like this before and if anyone has any suggestions. Thanks a lot for your time.

share|improve this question

migrated from stackoverflow.com Jul 17 '09 at 20:27

This question came from our site for professional and enthusiast programmers.

3 Answers 3

up vote 2 down vote accepted

Not only bad or average, quite often good PHP programmers forget about security goals.

Although it's not carved into stone, hacking sites can be made way more difficult with introducing some rules

  • code/data/workfile segmentation and permission enforcement
    • code: a directory where you keep your executable files: this directory HAVE to be accessible but MUST NOT be writable by the user running apache (www-data or httpd in different systems) (php_admin_flag engine on)
    • data: place of css, pictures, and static file coming with the page: this directory MUST NOT be writable or executable by Apache (php_admin_flag engine off)
    • a directory for user-uploadable files, temporary files and so on: this direcotory MAY be writable but MUST NOT be executable by Apache (php_admin_flag engine off)
  • disabling .htaccess files: one third of a time, site 'hacks' are only about rewriting .htaccess files, so it's like a privilege escalation. Also speeds up Apache if it does not have to check if any .htaccess file is residing in _any_ level of the path being served.
  • introducing non-obstuctive restrictions in PHP, like
    • disabling non-used functions (system, exec at the beginning),
    • introducing open_basedir (strictly stating directories where php exec is not allowed)
    • php_admin_flag engine off in Directory / and allowing only specific dirs (or better, specific files)
    • display_errors strictly OFF
    • with virtualhosting many sites, it's becoming handy if one introduces a sendmail wrapper, in order to watermark every outgoing letter, making easier to find which virtualhost floods the system with spam
  • and of course avoiding common errors like including a GET/POST variable

A simple sendmail wrapper:

#!/bin/sh
umask 077
TEMP=/tmp
CHROOT=${1:-unspecified}

trap "rm -f msg.$$ ; exit 1" 0 1 2 3 15

rm -f msg.$$ || exit 1;
cat | formail -f -I "X-subsystem-sent: \"$CHROOT\"" >$TEMP/trapmail.$$

exec <$TEMP/trapmail.$$ || exit 1
rm -f $TEMP/trapmail.$$ # safe, we hold the file descriptor

exec /usr/sbin/sendmail -t -i 
exit 1
share|improve this answer
    
Thank you for your answer, it really helped me a lot. I've gone through and started to tighten up the application and i did find a problem where the validation for file types in the file manager tool were not being used properly. This led to the app allowing php uploads and script execution ( very dangerous ). Thanks again for your answer! Now to make sure there are no other problems. Thanks again. –  user13425 Jul 21 '09 at 0:05

There is an exploit in one of the files/libraries that the website is using. The exploit allows for files to be uploaded to the server and, it sounds like, placed in arbitrary locations. Since PHP runs as the same user apache is running as, all uploaded files will be owned by that user. Secondly because the Document Root was chmoded to 777, it allows any system user to write files/folders into that path.

Changing the permissions level, chmod 755 like you did, will help in resolving that, but I would recommend looking through your logs/code and eliminate the exploit, or possible exploit.

share|improve this answer
2  
Looking into your (virtual) server logs might tell you what exploit was used, especially if you have a timestamp on all those file creations. –  Liudvikas Bukys Jul 17 '09 at 20:48

I had a similar situation with one of my sites. I used the server logs and PHP based CMS logs to identify the IP address.

Using the .htaccess file I added the following line (which blocks access point blank)

#Blacklist
RewriteCond %{REMOTE_ADDR} (?:123.123.123.123) [NC]

Replacing the number above with the IP (or block the entire range if its from a dodgy country) which is what I did. Did the job. This is only one possible solution though. Hope it helps!

share|improve this answer
2  
Blacklisting instead of fixing the problem is utterly useless. –  ceejayoz Jul 18 '09 at 4:43
    
Its hardly "utterly useless" ceejayoz its just "one option" which may help. Dont be so narrow minded. –  JamesM Jul 20 '09 at 13:28
    
Let me just expand a little further to help you see my reasoning. I myself run a popular local club site which uses Post-nuke. I dabble with PHP but by no means a PHP dev. Our site got hacked and as I mentioned above I narrowed the IP. I couldn't find a fix nor support but we needed to be up ASAP. Now the proper solution to move to a CMS with current support and fixes, OK agree - but we needed to be up! So my solution above was the easiest to implement and worked while were looking at moving to another CMS. So I hope you see. I agree its not a solution but in reality its just not that easy. –  JamesM Jul 20 '09 at 15:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.