Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

Re: Suspicious files in /tmp

Subject: Re: Suspicious files in /tmp
Date: Tue, 19 Jun 2007 02:17:38 +0200

Am 18.06.2007 um 18:47 schrieb Matt D. Harris:

They're being executed despite filesystem mount options because the script isn't being executed, the perl interpretter is. The script is being read and interpretted by the perl interpretter. Interesting - I hadn't thought of this before. Some logic to check the underlying filesystem of a script before reading it would be a very cool addition to perl from a security standpoint. Wouldn't be a big performance hit at all just to check once every require, etc as well. It'd need to be somewhat platform specific. Anyways, it would be neat for someone to bring this up within the Perl community as a possible idea, and maybe consider python, ruby, and others as well. Then there're various shells... I tested bash and FreeBSD's /bin/sh, and neither of them respect the noexec mount flag on FreeBSD either. It seems like this should be a relatively easy problem to correct, at least for the most common platforms. It's a thought that I'm going to bring up with the FreeBSD guys and see what their reaction is. Thanks for bringing this up here. Take care, Matt



A quick google search turned up the hint to disallow access to perl (chmod 700 /usr/local/bin/perl, probably) and/or to write a wrapper for it.

If you don't need CGI-scripts, you can chmod 700 it.
If cronjobs etc. (not running as root) still need it, maybe use sudo.

It's really a nuisance, all in all.
If you've got a big installation, there might be literally hundrets of old pre-joomla mambos, old coppermines, galleries, phpBBs etc. waiting for exploitation.
Not to forget the BCC-injection susceptible mail-forms and the "index.php?page=bla.html"-allow-furl-open=yes morons...





cheers, Rainer -- Rainer Duffner CISSP, LPI, MCSE rainer@ultra-secure.de



-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper It's as simple as placing additional SQL commands into a Web Form input box giving hackers complete access to all your backend systems! Firewalls and IDS will not stop such attacks because SQL Injections are NOT seen as intruders. Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>