Got an email rejection message from Gmail… the alerting thing were the recipient of the message (ktdhih****@gmail.com) and the sender(www-data). Emails were sent to a dubious address through the webserver!

Correlating the timestamp of the email with the /var/log/mail.log and then with the webserver’s log, I could identify that some strange named PHP file was being called: "POST /yjhgdoemyf.php HTTP/2.0"

Looking at the webroot of the domain, I found many more of these files, and even some new subdirectories:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

cuwcdeccvu.php
cymafuoiiv.php
dcyohvtlvx.php
dwplmlvpvg.php
eavkuvizkd.php
epcdptvkdj.php
euuxiicowx.php
fgnevjbemu.php
findcp-spamtools.be.php
findwhmhash-spamtools.be.php
fipqzcwhrt.php
fnkrhdyetu.php
Fox-C                  <--- directory
gjcjcbiyiy.php
gqvtwpheni.php

What happened ?

CVE-2017-9841 is the keyword :-( Respectively its new variant as of 2020

Actually there is a vulnerability in one of the files contained in the PHPUnit framework, which is auto-installed by composer, a packet-manager for PHP. The bad thing: actually PHPUnit is only used for unit-testing the package, not for productive use! So this is actually dead code, introducing security holes.

As far as I could find out on the internet and by looking at the server, only PHP files were created, but nothing else was carried out.

Another domain was also targeted, but there, the webserver had no write permissions in the webroot (only read acess), therefore no code could be uploaded (but I assume code could still be executed directly using a POST request). Removing write acvcess to the webroot for the webserver seems to be a good guideline…

Immediate mitigation

Remove PHPUnit

• either though composer : composer --working-dir=${HOME}/www remove phpunit/phpunit
• or manually : rm -rf ${HOME}/www/vendor/phpunit

Long-term mitigation

Actually there’s no need that the composer-installed packages are accessible by the webserver. In fact, they are always included by the PHP processor, never directly called. Thus the access to the /vendor directory can be blocked by the webserver itself.

For Nginx:

1
2
3
4
5
6
7

server {
    location ^~ /vendor/ {
        deny all;
        return 403;
    }
    ...
}

and for Apache

1
2
3

$ cat << EOF > ${HOME}/www/vendor/.htaccess
Require all denied
EOF