Re: system breach
On Friday 29 December 2006 21:50, Brandon S. Allbery KF8NH wrote: > That looks like CPAN to me. pear is actually like CPAN - but for PHP. I didn't have the said download directory on my FreeBSD 6.1-STABLE machine, but going to /usr/ports/devel/pear and doing make all install clean sure does create the directory and the files inside. That directory is basically used when pear is downloading modules (hope that's what they're called). [EMAIL PROTECTED] ~ #> pear config-show | grep download_dir PEAR Installer downloaddownload_dir /tmp/download [EMAIL PROTECTED] ~ #> You can change the location of that directory at any time using pear config-set (works on a per user basis writing to their $HOME/.pearrc) or by editing the file /usr/local/etc/pear.conf. Try "pear help" for more details. -- patrick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth On Fri, Dec 29, 2006 at 10:54:36PM +0200, gareth wrote: > On Fri 2006-12-29 (10:16), Jeremy Chadwick wrote: with regards to you last post to me (personal) i had installed freebsd v6.1-release and setup xwindows (both kde & gnome) desktop environments, then left teh machine sit and settle. the machine is a compaq proliant 5500 with 2 PIII Xeon 550/100 L2 Cache off 1 mb . it has a 45 gb raid5 array (35 gb data/10 gb raid indexing etc) this is built ontop of a SMART-2/P array controller with a pair od symbiosis scsi3 host adapters. the machine is sitting idle on a shelf while i get several dozen dlt-IV tapes that i've ordered for the DLT-7000 scsi tape streamer so that i can save teh image/filesystems to tape then scour the disks clean and start again. its got a dorectory in teh root fs and several othe files pepered all over teh array and many endries in teh systems logs all started on or about 22 november about 11 pm i think .. sorry the machine is running something else at teh moment and its a bit too hard to get the relevent details but if itis of any valu e to you or anyone-else i'd be happy to run up freebsd v6.1-release and get teh details for you. the compromise seems to be a sshd couple to a X11 subsystem sned out pornography type of attack. as i told you earlier i've contacted aus-cert and give tehm teh open port numbers which they confirmed as a current local compromise thats been peretrated by several fellows in china (mainland) hongkong and from indonesia as well, it is apparent reasonably well know gang that is doing this, could be targeting anyone with freebsd v6.1-release or more likely the version of kde/gnome that installed with freebsd v6.1-release. one thing to note that is freebsd warns after installation (that is after teh first night time maintenance run) the security mail list 18 or so packages as being know to be compromiseable and or weak in that respect. i didn't think much of it as i wasn't going to be using teh machine, just let it run up as it was new (to me) its recycled from another life and is some 10 years old (pretty new in my meuseum, big grin) if anyone else is interested in details i'd be happy to furnish details off list most kind regards jonathan also, best wishes for the coming new year and hope that you christmas was happy holy safe and incident free. -- powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system === appropriate solution in an inappropriate world === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (10:16), Jeremy Chadwick wrote:
> Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
> temporary storage location for where things are stored. Taken from
> the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
>
> PKG_TMPDIR
> TMPDIR (In that order) Temporary directory where pkg_fetch down-
> loads files temporarily. If neither is not defined,
> ``/var/tmp'' is used.
>
> Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
> make.conf, their own dotfiles, root's dotfiles, or within their
> php.ini?
thanx for all the detective work, i grepped for TMPDIR and download
in the ports tree and didn't find anything worthwhile. however, found
this in the go-pear file in /usr/ports/distfiles/pear-1.4.11.tar.bz2:
putenv('PHP_PEAR_DOWNLOAD_DIR=' . $temp_dir . '/download')
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (19:48), Thomas Nystr?m wrote: > It looks like this: > > ture(root)# dir > total 50 > drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ > drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ > drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ > drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ > drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ > -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml > -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml snap ;) package*.xml are also "12 Jul 02:09" > Exactly which port that did this is hard to tell. I have around > 130 ports installed and most of them were updated 29:th Aug. > I have looked at the files that exists in these directories > and according to the +CONTENTS files in /var/db/pkg all is claimed > to belong to pear-1.4.11 so that might be a candidate. ah yes, well played, md5's match too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Dec 29, 2006, at 13:53 , Thomas Nyström wrote:
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/
download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
See my other mail about a suspicous port (pear-1.4.11)
PEAR would also make sense; it's a (apparently lamer, at least
security-wise; then again, it *is* PHP :> ) CPAN-alike for PHP.
--
brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Dec 29, 2006, at 13:48 , Thomas Nyström wrote: ture(root)# dir total 50 drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml That looks like CPAN to me. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
Jeremy Chadwick wrote:
>
I've been following this thread and trying to track down what's been
reported (by two people at this point); that is, temporary ports
"stuff" getting stored in /tmp/download.
A `grep -r '/download$' /usr/ports` returns some results, but not
very many. Ones which could raise suspicion, but probably are not
the cause, are:
/usr/ports/biology/garlic/pkg-plist:[EMAIL PROTECTED] %%DOCSDIR%%/download
/usr/ports/lang/diveintopython/Makefile:DIPDLDIR= ${DOCSDIR}/download
/usr/ports/lang/diveintopython/pkg-plist:@dirrm %%DOCSDIR%%/download
/usr/ports/sysutils/jailuser/pkg-plist:%%PORTDOCSDOCSDIR%%/download
Thus, I decided to go straight to the portupgrade source and look
through that. Nothing really shined through, but I did come across
something that may or may not help:
Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
temporary storage location for where things are stored. Taken from
the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
PKG_TMPDIR
TMPDIR (In that order) Temporary directory where pkg_fetch down-
loads files temporarily. If neither is not defined,
``/var/tmp'' is used.
Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
make.conf, their own dotfiles, root's dotfiles, or within their
php.ini?
Nope.
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
See my other mail about a suspicous port (pear-1.4.11)
/thn
--
---
Svensk Aktuell Elektronik AB Thomas Nyström
Box 10Phone: +46 8 35 92 85
S-191 21 SollentunaFax: +46 8 35 92 86
Sweden Email: [EMAIL PROTECTED]
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth wrote: On Fri 2006-12-29 (17:25), Thomas Nystr?m wrote: I just checked one of my servers and also found a /tmp/download directory with the same files that you had. I then compared the timestamp of /tmp/download with the timestamp of the directories in /var/db/pkg: Same. My conclusion is that during a portupgrade these files were written there, directly or indirectly by portupgrade or the port itself. oh. ok. well even though that's weird behaviour from a package it's more plausible since i haven't found anything else suspicious. are the timestamps exactly the same? i have 4 packages that're 20 minutes different. which of yours are the same? or was that for all files. (since i'd like to try an reproduce it). It looks like this: ture(root)# dir total 50 drwxrwxr-x 5 root wheel512 29 Aug 16:29 ./ drwxrwxrwt 11 root wheel 3072 29 Dec 19:35 ../ drwxrwxr-x 4 root wheel512 29 Aug 16:29 Archive_Tar-1.3.1/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 Console_Getopt-1.2/ drwxrwxr-x 3 root wheel512 29 Aug 16:29 XML_RPC-1.5.0/ -rw-rw-r-- 1 root wheel 15433 12 Jul 02:09 package.xml -rw-rw-r-- 1 root wheel 22193 12 Jul 02:09 package2.xml Exactly which port that did this is hard to tell. I have around 130 ports installed and most of them were updated 29:th Aug. I have looked at the files that exists in these directories and according to the +CONTENTS files in /var/db/pkg all is claimed to belong to pear-1.4.11 so that might be a candidate. /thn -- --- Svensk Aktuell Elektronik AB Thomas Nyström Box 10Phone: +46 8 35 92 85 S-191 21 SollentunaFax: +46 8 35 92 86 Sweden Email: [EMAIL PROTECTED] --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri, Dec 29, 2006 at 07:39:16PM +0200, gareth wrote:
> oh. ok. well even though that's weird behaviour from a package it's
> more plausible since i haven't found anything else suspicious. are
> the timestamps exactly the same? i have 4 packages that're 20 minutes
> different. which of yours are the same? or was that for all files.
> (since i'd like to try an reproduce it).
Preface: I am not a portupgrade user, as I'm one of those admins
who believes that if the FreeBSD base system ports management data-
base/dependancy structure is "flawed" or "ineffective" (which is
apparently the reason portupgrade maintains its own separate copy
of ports dependancies -- which continues to induce "why are my
dependancies not working" support mails to the ports mailing list)
then the problem should be fixed in the base system and not require
reliance on a third-party tool that induces more headaches. (OK, I
am off my soapbox now)
I've been following this thread and trying to track down what's been
reported (by two people at this point); that is, temporary ports
"stuff" getting stored in /tmp/download.
A `grep -r '/download$' /usr/ports` returns some results, but not
very many. Ones which could raise suspicion, but probably are not
the cause, are:
/usr/ports/biology/garlic/pkg-plist:[EMAIL PROTECTED] %%DOCSDIR%%/download
/usr/ports/lang/diveintopython/Makefile:DIPDLDIR= ${DOCSDIR}/download
/usr/ports/lang/diveintopython/pkg-plist:@dirrm %%DOCSDIR%%/download
/usr/ports/sysutils/jailuser/pkg-plist:%%PORTDOCSDOCSDIR%%/download
Thus, I decided to go straight to the portupgrade source and look
through that. Nothing really shined through, but I did come across
something that may or may not help:
Apparently pkg_fetch will use either $PKG_TMPDIR or $TMPDIR as a
temporary storage location for where things are stored. Taken from
the manpage in pkgtools-2.2.2/man/pkg_fetch.1:
PKG_TMPDIR
TMPDIR (In that order) Temporary directory where pkg_fetch down-
loads files temporarily. If neither is not defined,
``/var/tmp'' is used.
Do either of the reporters have PKG_TMPDIR or TMPDIR defined in
make.conf, their own dotfiles, root's dotfiles, or within their
php.ini?
I'm wondering if maybe a PHP script is trying to do something with
pkg_fetch, and does something like setenv("PKG_TMPDIR", "/tmp/download")
before calling system("pkg_fetch ..."). Why a PHP script would do
this, I don't know, but it wouldn't surprise me.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (17:25), Thomas Nystr?m wrote: > I just checked one of my servers and also found a /tmp/download > directory with the same files that you had. > > I then compared the timestamp of /tmp/download with the timestamp > of the directories in /var/db/pkg: Same. > > My conclusion is that during a portupgrade these files were written > there, directly or indirectly by portupgrade or the port itself. oh. ok. well even though that's weird behaviour from a package it's more plausible since i haven't found anything else suspicious. are the timestamps exactly the same? i have 4 packages that're 20 minutes different. which of yours are the same? or was that for all files. (since i'd like to try an reproduce it). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth wrote: On Thu 2006-12-28 (22:10), David Todd wrote: something's up, nothing in ports will write to a /tmp/download directory, so either you or someone with root access did it. I just checked one of my servers and also found a /tmp/download directory with the same files that you had. I then compared the timestamp of /tmp/download with the timestamp of the directories in /var/db/pkg: Same. My conclusion is that during a portupgrade these files were written there, directly or indirectly by portupgrade or the port itself. About two years ago I cleaned up a system that really had a system breach (through some php-based webapplication). I could then find a directory in /tmp owned by www that contains a complete distribution with configurescript and the result of the build. This /tmp/download doesn't look like that at all. /thn -- --- Svensk Aktuell Elektronik AB Thomas Nyström Box 10Phone: +46 8 35 92 85 S-191 21 SollentunaFax: +46 8 35 92 86 Sweden Email: [EMAIL PROTECTED] --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Fri 2006-12-29 (11:07), Matthew Seaman wrote: > > Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on > > signal 12 (core dumped) > > Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on > > signal 12 (core dumped) > > These are from autoconf testing various capabilities of the system to do > with signal handling -- nothing to be worried about. ok, ta. > Are you running a web server as root on this machine? This illustrates nope, as the www user. > why that is such a bad idea... If you aren't running a web server, > but only using PHP as a command line tool, then have you been doing any > work with such things as IDEs or other large toolsets? They often > have the capability to download and install extra bits at a mouseclick. no haven't used it from the command line, only webserver > The best defense against all of this sort of stuff is to be fully > patched and up to date with all your installed software. PHP is a i use portupgrade at least once a week ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
On Thu 2006-12-28 (22:10), David Todd wrote: > something's up, nothing in ports will write to a /tmp/download > directory, so either you or someone with root access did it. thought as much :/ > I suggest: > checking /var/log/auth.log for attempted breachings i had a rough skim and nothing suspicious, wanted to know when this happened so i could scrutinise the logs better. > run sockstat and look for processes with ports open that shouldn't > have ports open. thx, had a look at that and netstat etc, everything's normal. > conftest cores ususally mean a ./configure was issued and parts of > said configure failed, them being so far apart suggests that some work > was done to the configure script to fix it. > > If you didn't install anything from ports at or around those periods > of time, then someone was running a configure script to build > something on the machine. ah. it could very well have been me, was compiling a lot've stuff around those 2 days. doesn't seem like portupgrade etc keeps logs to check. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
something's up, nothing in ports will write to a /tmp/download directory, so either you or someone with root access did it. I suggest: checking /var/log/auth.log for attempted breachings run sockstat and look for processes with ports open that shouldn't have ports open. conftest cores ususally mean a ./configure was issued and parts of said configure failed, them being so far apart suggests that some work was done to the configure script to fix it. If you didn't install anything from ports at or around those periods of time, then someone was running a configure script to build something on the machine. I wouldn't be overly concerned that if you're dealing with a breach, you're dealing with anyone who is compitent, change your passwords, check auth.log for ssh connections and look at sockstat to see if any programs are running that are listening on ports (that shouldn't be) David On 12/28/06, gareth <[EMAIL PROTECTED]> wrote: hey guys, my server rebooted a few days ago, and while i was looking around for possible reasons (none came up, which's disconcerting in itself) i found this suspicious directory: $ ls -l /tmp/download total 44 drwxr-xr-x 4 root wheel512 Oct 23 16:28 Archive_Tar-1.3.1 drwxr-xr-x 3 root wheel512 Oct 23 16:28 Console_Getopt-1.2 drwxr-xr-x 3 root wheel512 Oct 23 16:28 XML_RPC-1.5.0 -rw-r--r-- 1 root wheel 15433 Jul 12 02:09 package.xml -rw-r--r-- 1 root wheel 22193 Jul 12 02:09 package2.xml the subdirs contain a bunch've .php files, and the xml files are info about version updates of PEAR'S "XML-RPC for PHP". they're owned by root (only i have the passwd) so it wasn't made by a local user, and i assume it wasn't made by portupgrade or something like that? so, i've got no idea how that dir got there, i'm guessing via some web exploit that i still need to look into, and /tmp is mounted 'exec' for some legit processes to function, can't remember which, so it's possible they were able to upload something and run it. chkrootkit which i've only just installed seems clear. anyway, i'm trying to figure out when this happened to have something to go on, and i don't understand the stat command, for example: $ stat /tmp/download/package2.xml 60 49356 -rw-r--r-- 1 root wheel 198776 22193 "Dec 28 04:03:50 2006" "Jul 12 02:09:14 2006" "Oct 23 16:28:28 2006" "Jul 12 02:09:14 2006" 4096 44 0 /tmp/download/package2.xml taking hints from 'stat -x' and 'stat -s' i gather this means: access time = Dec 28 04:03:50 2006 modify time = Jul 12 02:09:14 2006 change time = Oct 23 16:28:28 2006 birth time = Jul 12 02:09:14 2006 now how much of these dates are local or carried over from the source system, since my system was created at 08:00 on 21 Oct 2006 (ie. the Jul dates don't make sense)? (also what's the difference between modify and change time?) essentially is there a way i can tell when the files were put there? this's the directory's info too: $ stat /tmp/download 60 49346 drwxr-xr-x 5 root wheel 196642 512 "Dec 29 00:53:16 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" 4096 4 0 /tmp/download ps. out've interest: this's the only suspicious thing in the logs i could find: Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on signal 12 (core dumped) Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on signal 12 (core dumped) though from google it seems it could be an innocent apache thing. also around the 23rd or 24th of Oct i started taking md5sums of all the files in the bin and lib directories, and they haven't changed without my knowledge since then. course that doesn't help if the breach was in the 2 odd days before this and after the system was created. also, snort hasn't reported anything overly suspicious, and all packages are kept up to date. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system breach
gareth wrote: > Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on signal > 12 (core dumped) > Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on signal > 12 (core dumped) These are from autoconf testing various capabilities of the system to do with signal handling -- nothing to be worried about. > hey guys, my server rebooted a few days ago, and while i was > looking around for possible reasons (none came up, which's > disconcerting in itself) i found this suspicious directory: > > $ ls -l /tmp/download > total 44 > drwxr-xr-x 4 root wheel512 Oct 23 16:28 Archive_Tar-1.3.1 > drwxr-xr-x 3 root wheel512 Oct 23 16:28 Console_Getopt-1.2 > drwxr-xr-x 3 root wheel512 Oct 23 16:28 XML_RPC-1.5.0 > -rw-r--r-- 1 root wheel 15433 Jul 12 02:09 package.xml > -rw-r--r-- 1 root wheel 22193 Jul 12 02:09 package2.xml > > > the subdirs contain a bunch've .php files, and the xml files > are info about version updates of PEAR'S "XML-RPC for PHP". > they're owned by root (only i have the passwd) so it wasn't > made by a local user, and i assume it wasn't made by portupgrade > or something like that? Are you running a web server as root on this machine? This illustrates why that is such a bad idea... If you aren't running a web server, but only using PHP as a command line tool, then have you been doing any work with such things as IDEs or other large toolsets? They often have the capability to download and install extra bits at a mouseclick. Generally if you have a compromise in a PHP based webserver, you'll see the compromised machine used as a spam-bot or similar. Check the contents of your mail spool. Use tcpdump / wireshark to monitor the traffic to and from the machine to look for suspicious activity. If you've got the permissions right, then the attackers will not be able to write to the hard drive through compromising the webserver, which means that a stop and restart of Apache will thwart their nefarious plans, at least until they can recompromise your server. Generally that's about 5 -- 15 minutes, as all that sort of stuff is pretty automated nowadays. The best defense against all of this sort of stuff is to be fully patched and up to date with all your installed software. PHP is a nightmare security wise -- the whole language tends to steer developers into doing sloppy and insecure things by default. Well known, big projects like phpMyAdmin or Horde will generally code stuff pretty tightly, but the rest often need a severe beating with the clue stick. Even the well-managed projects will have their problems, and in fact one of the measures of a well-managed project is how promptly they deal with security problems and how open they are about revealing such things. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
system breach
hey guys, my server rebooted a few days ago, and while i was looking around for possible reasons (none came up, which's disconcerting in itself) i found this suspicious directory: $ ls -l /tmp/download total 44 drwxr-xr-x 4 root wheel512 Oct 23 16:28 Archive_Tar-1.3.1 drwxr-xr-x 3 root wheel512 Oct 23 16:28 Console_Getopt-1.2 drwxr-xr-x 3 root wheel512 Oct 23 16:28 XML_RPC-1.5.0 -rw-r--r-- 1 root wheel 15433 Jul 12 02:09 package.xml -rw-r--r-- 1 root wheel 22193 Jul 12 02:09 package2.xml the subdirs contain a bunch've .php files, and the xml files are info about version updates of PEAR'S "XML-RPC for PHP". they're owned by root (only i have the passwd) so it wasn't made by a local user, and i assume it wasn't made by portupgrade or something like that? so, i've got no idea how that dir got there, i'm guessing via some web exploit that i still need to look into, and /tmp is mounted 'exec' for some legit processes to function, can't remember which, so it's possible they were able to upload something and run it. chkrootkit which i've only just installed seems clear. anyway, i'm trying to figure out when this happened to have something to go on, and i don't understand the stat command, for example: $ stat /tmp/download/package2.xml 60 49356 -rw-r--r-- 1 root wheel 198776 22193 "Dec 28 04:03:50 2006" "Jul 12 02:09:14 2006" "Oct 23 16:28:28 2006" "Jul 12 02:09:14 2006" 4096 44 0 /tmp/download/package2.xml taking hints from 'stat -x' and 'stat -s' i gather this means: access time = Dec 28 04:03:50 2006 modify time = Jul 12 02:09:14 2006 change time = Oct 23 16:28:28 2006 birth time = Jul 12 02:09:14 2006 now how much of these dates are local or carried over from the source system, since my system was created at 08:00 on 21 Oct 2006 (ie. the Jul dates don't make sense)? (also what's the difference between modify and change time?) essentially is there a way i can tell when the files were put there? this's the directory's info too: $ stat /tmp/download 60 49346 drwxr-xr-x 5 root wheel 196642 512 "Dec 29 00:53:16 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" "Oct 23 16:28:28 2006" 4096 4 0 /tmp/download ps. out've interest: this's the only suspicious thing in the logs i could find: Oct 23 00:31:42 lordcow kernel: pid 48464 (conftest), uid 0: exited on signal 12 (core dumped) Oct 23 01:19:26 lordcow kernel: pid 17512 (conftest), uid 0: exited on signal 12 (core dumped) though from google it seems it could be an innocent apache thing. also around the 23rd or 24th of Oct i started taking md5sums of all the files in the bin and lib directories, and they haven't changed without my knowledge since then. course that doesn't help if the breach was in the 2 odd days before this and after the system was created. also, snort hasn't reported anything overly suspicious, and all packages are kept up to date. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
