Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

One of my server's web accounts got hacked a couple of times. Each time someone downloaded a Perl script via some phpBB forum and used the Perl script to do whatever they wanted to do (mostly connect to IRC and start DDoS attacks according to the script's code).

I would like to disable Perl for most (not all as some processes I use are using Perl) or some specific users.

How can I do it properly? I am using Debian.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user).

However as an aside, the straightforward way if you have an application in linux that you want to restrict to certain users, you first, create a group, then add users to that group. The following commands accomplish this in ubuntu (creating the perl group and adding user1, user2, user3 to it:

sudo addgroup perl
sudo adduser user1 perl
sudo adduser user2 perl   
sudo adduser user3 perl

Now find where perl currently is (which perl which on my system was /usr/bin/perl) find what it's perl's ownership and permissions currently are (ls -l /usr/bin/perl on ubuntu by default set to owned by user root and in group root) with everyone having read/execute permissions, which you should disable for other users unless they are in the perl group:

sudo chgrp perl /usr/bin/perl
sudo chmod o-rx /usr/bin/perl

Note that an attacker on your system who isn't a member of the perl group, if they can get to a terminal could upload their own version of the perl executable (or if you didn't remove read access to other users; they could have just copied it) to some local/tmp directory, set the executable bit on it (if they can run chmod), and then use that run perl script's off their own executable.

share|improve this answer

Disabling perl is useless. The exploit that can be written in Perl can also be written in another language. Say, PHP, which you obviously aren't going to disable.

If you take a system that's already very secure (as in: vulnerabilities are rare and tend to affect only a small part of the system with no direct way of enabling the execution of arbitrary code), then it can be worthwhile to disable all methods of scripting. This can limit the extent to which some vulnerabilities can be exploited. For example, if you can only inject a small number of ASCII characters, writing a machine executable might be a major challenge whereas writing a script would be trivial.

Against the kind of vulnerability you encountered, disabling interpreters wouldn't help. The attacker could upload PHP, or machine code. You're shooting the messenger.

share|improve this answer
1  
+1 i agree. disabling perl is a joke. –  Rook Jun 18 '12 at 23:22
2  
@Rook In isolation, yes. But as part of a wider hardening/minimisation process? I disagree. –  lew Jun 19 '12 at 3:53
    
@lew In this case, I don't see how removing perl has a nontrivial impact on the ease of writing an exploit. It means that this particular exploit wouldn't work (assuming you managed to get your system working without perl, which is a tall order), but that's bolting one of many barn doors after the horses have left through it. –  Gilles Jun 19 '12 at 15:21
1  
OK thanks for the detailed answer I get it. Since I have been hacked twice and each time I found perl scripts in the temp directory of my server (under the one account's username) my idea was that it might make it a bit harder if the hacker only uses PERL kiddy scripts. As I said below I deleted everything from the user's directory and installed a backup that I believe is clean. Recent Apache logs did not show anything suspicious, but my server keeps logs within the user's own directory. –  Guillaume Jun 19 '12 at 16:27

The attack you are experiencing is called a Remote File Inclusion (RFI) technique. It's basically the outcome of a vulnerable web application which is being taken advantage of to upload malicious code to spawn a remote shell.

You do not need to specifically disable Perl. You can start identifying the vulnerable application like for example phpBB that the attacker uses, then patch or completely remove that application and replace it with an upgraded version.

Since the box is compromised, it is mostly unsafe to just rely with the method above given that they might have already installed a backdoor running on your host. If you have a physical access to the server, try to bring it down on the network. If you do have remote access, then just work around with the firewall rules first ensuring access only to your location of origin (IP address).

One thing you can do is to explicitly DENY all incoming traffic from the network layer and SPECIFY only traffic for a given or used port: TCP/22,80 to ensure that even though they might have installed a backdoor running on a port different from the two, it won't bind and spawn a remote shell.

Removing Perl will break all the Perl dependent applications running on your host.

share|improve this answer
    
-1 RFI is disabled by default on most systems, and by default for PHP for the past couple of years. What proof do you have that this was the attack used? –  Rook Jun 18 '12 at 23:21
1  
Yes RFI is disabled by default in PHP>=5.2, but why would you jump and assume a box using such version? And even if it was using non-vulnerable version, does PHP alone is vulnerable to this? The post said "One of my server's web accounts got hacked a couple times." I am making an analysis based on the details of what has been posted, not with forensics infront of my terminal. Considering your argument and creating doubt, then what proof do you have that file inclusion was not the attack. –  John Santos Jun 19 '12 at 7:32
    
RFI exploits dried up years ago and no one posts them to the exploit boards (exploit-db, full disclosure... ). Even if this was the problem you should suggest disabling remote file inclusion... Its still possible to obtain RCE with an LFI, but that wasn't mentioned. Maybe you should suggest UPDATING PHPBB, but the op is too stupid to even post the version number or even understand the basics of why he was hacked. –  Rook Jun 19 '12 at 8:06
    
Are you sure that file inclusion is not in effect for today's environment and no one posts them in exploit boards lately? EDB-ID: 18308. Not because a vulnerability dried up few years back means no box is connected in the wild susceptible to an attack OR the "possibility" of a newly provisioned unhardened box today does not exist. A stupid misconfiguration by an admin as what you are trying to say can lead to a remote code execution whether it is remote/local. –  John Santos Jun 19 '12 at 12:46
1  
Thanks Rook, I really appreciate being called "stupid", to be honest that's not the kind of help I was hoping for. PhpBB has been deleted from the hosting account after the first attack, I installed it some time ago to check it out really and kind of forgot about it - mistake I know. I am not an expert is security I won't lie about it, or I wouldn't be here posting basic questions - nonetheless I don't think I deserve being insulted for asking a question. The perl scripts were uploaded to the system's temp directory and executed from there. They were chrooted to the web account's user ... –  Guillaume Jun 19 '12 at 16:15

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.