.htacess and random files hacked

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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!