14

Background

I have an issue on my server where some hole is allowing malicious PHP files to be written to any world-writable directories beneath the web root. It is not currently causing any harm, as I have all these directories blocked from serving php scripts (or anything else unless images/videos for some of them), and get an email notice as soon as anything is created in them, but I obviously want to get it fixed.

I have taken various measures, such as ensuring the Joomla and Wordpress installations on the server are up to date, but still it continues. There is a client site on the server running a fairly old version of an eCommerce system, which I suspect may be the culprit.

Question

So I have set up auditd to monitor all of these world-writable directories, and await the problem occurring again to gather some logs, but I already have some log entries to look at from normal activity that has occurred.

It is as I suspected, and of course when a PHP script writes to a file all auditd shows for the exe is /usr/sbin/httpd. See sample output below. It is potentially possible to get an idea of which site the problem is coming from based on the CWD, but that could be changed and is not reliable. Also knowing the specific script would be useful.

So I am wondering, is it possible to have auditd log the script name (edit: or perhaps the call stack) that is generating the action through /usr/sbin/httpd, or anything close to that information?

time->Wed Nov 30 14:36:30 2016

type=PATH msg=audit(1480516590.911:180239): item=1 name="/home/web/www.example.com/html/cache/example.php" inode=539842913 dev=08:05 mode=0100644 ouid=48 ogid=48 rdev=00:00 objtype=CREATE

type=PATH msg=audit(1480516590.911:180239): item=0 name="/home/web/www.example.com/html/cache/" inode=539833631 dev=08:05 mode=040777 ouid=634 ogid=634 rdev=00:00 objtype=PARENT

type=CWD msg=audit(1480516590.911:180239): cwd="/home/web/www.example.com/html"

type=SYSCALL msg=audit(1480516590.911:180239): arch=c000003e syscall=2 success=yes exit=36 a0=7f9baf272550 a1=241 a2=1b6 a3=9 items=2 ppid=26483 pid=30957 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" key="write_to_open_web_directories"

Community
  • 1
  • 12
    Why not use timestamps? You would check access.log of httpd and compare it with auditd and that should give clues. – Aria Nov 30 '16 at 18:23
  • 1
    Thanks, yes that did occur to me, and I will do that if it's the only way. But I'm wondering if there's a way to grab the call stack from httpd or something else more concrete. Saves me trawling through access logs for every site too! And gives more information than the access logs, like perhaps what library was used/broken in to. –  Nov 30 '16 at 18:25
  • 1
    No. Even if you had the time, skills and money to start re-writing SELinux (which is an absurd idea to begin with) this would require a call back into user-space from the kernel - technically possible but fraught with complications. While I would also recommend Aria's approach, I would go further and recommend amending your logging to capture the full request (requires additional capabilities e.g. mod_security) and (since you appear to be using mod_php on Apache) add %P – symcbean Dec 07 '16 at 14:31
  • Ah, great idea, thanks. Of course, extending the APACHE logging to capture the full request! Combined with Aria's idea, will do the job perfectly. Thanks. I'll look in to it. –  Dec 07 '16 at 14:35
  • Why don't share your solution using Apache logs for this @SuperDuperApps? – Jesús Franco Oct 31 '17 at 21:00
  • 1
    Could you make the directories immutable and then wait until a request fails when it tries to write to the directory, which should give you info on what is happening? – jrtapsell Jan 01 '18 at 20:05
  • Nice idea @jrtapsell. Unfortunately not, as these are (were) live directories in use by a web app. –  Jan 02 '18 at 21:19
  • If it's happening often and you can't find evidence of a targeted/functional attack you most likely have some well known vulnerability which is being attack by web scanners. – Allison Jan 13 '18 at 04:36

1 Answers1

1

auditd cannot perform a stack trace or gain other information because it's only invoked on system calls or file access. The stack trace is only accessible from userspace, and would require unwinding the stack, which would incur significant overhead.

As mentioned in the comments, you can add %P to the access log config to get PIDs for correlation with auditd, or log the full requests from mod_security.

You could also modify mod_php or use an LD_PRELOAD to add information to relevant requests on file open.

David
  • 15,814
  • 3
  • 48
  • 73