Re: [SECURITY] [DSA 2945-1] chkrootkit security update
Thanks a lot, Grazie di cuore, ormai sono pensionato ma debian mi aiuta a vivere :D On Wed, Jun 4, 2014 at 6:53 AM, Salvatore Bonaccorso wrote: > Hi, > > On Wed, Jun 04, 2014 at 01:08:44AM +0200, Luigi Bianca wrote: > > what's about oldstable ? Mi system says 0.49-4 but apt-get doesn't find > > anything to update. Thanks in advance. > > Security support for oldstable has ended at the end of the month, but > there is squeeze-lts available. > > See > > https://lists.debian.org/debian-security-announce/2014/msg00119.html > > Updates for squeeze-lts for chkrootkit are also beeing prepared, > AFAIK. > > Hope that helps, > > Regards, > Salvatore >
Re: [SECURITY] [DSA 2945-1] chkrootkit security update
Hi, On Wed, Jun 04, 2014 at 01:08:44AM +0200, Luigi Bianca wrote: > what's about oldstable ? Mi system says 0.49-4 but apt-get doesn't find > anything to update. Thanks in advance. Security support for oldstable has ended at the end of the month, but there is squeeze-lts available. See https://lists.debian.org/debian-security-announce/2014/msg00119.html Updates for squeeze-lts for chkrootkit are also beeing prepared, AFAIK. Hope that helps, Regards, Salvatore -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140604045351.gb...@lorien.valinor.li
Re: [SECURITY] [DSA 2945-1] chkrootkit security update
what's about oldstable ? Mi system says 0.49-4 but apt-get doesn't find anything to update. Thanks in advance. On Tue, Jun 3, 2014 at 11:37 PM, Giuseppe Iuculano wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - - > Debian Security Advisory DSA-2945-1 secur...@debian.org > http://www.debian.org/security/ Giuseppe Iuculano > June 03, 2014 http://www.debian.org/security/faq > - ----- > > Package: chkrootkit > CVE ID : CVE-2014-0476 > > Thomas Stangner discovered a vulnerability in chkrootkit, a rootkit > detector, which may allow local attackers to gain root access when /tmp > is mounted without the noexec option. > > For the stable distribution (wheezy), this problem has been fixed in > version 0.49-4.1+deb7u2. > > For the unstable distribution (sid), this problem has been fixed in > version 0.49-5. > > We recommend that you upgrade your chkrootkit packages. > > Further information about Debian Security Advisories, how to apply > these updates to your system and frequently asked questions can be > found at: http://www.debian.org/security/ > > Mailing list: debian-security-annou...@lists.debian.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.15 (GNU/Linux) > > iEYEARECAAYFAlOOQAoACgkQNxpp46476aq/JACeNpks0kYF513Xhiyja4koDYD2 > HbYAnjdAg+kWejYvmzOIMN4F6g08RLJZ > =BL4j > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/20140603213714.ga4...@sd6-casa.iuculano.it > >
Re: chkrootkit sniffers
On Mon, Aug 14, 2006 at 11:09:54AM +0300, Henri Salo wrote: > Lothar Ketterer wrote: > >and chkrootkit (version 0.46a) gives me > > > >eth0: PF_PACKET(/sbin/dhclient, /usr/sbin/arpwatch) > > > >lo is not mentioned. I just checked with chkrootkit version 44-2 (sarge package): Checking `sniffer'... lo: not promisc and no packet sniffer sockets > With ifup in unstable machine: Didn't you write "stable" in your original post? Regards, Lothar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
Lothar Ketterer wrote: Hi, It remains strange because normally, lo is a non-broadcast interface. Maybe it would help to know how Henri has his network configured. Mine is configured with ifupdown, /etc/network/interfaces looks like this: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp and chkrootkit (version 0.46a) gives me eth0: PF_PACKET(/sbin/dhclient, /usr/sbin/arpwatch) lo is not mentioned. Regards, Lothar With ifup in unstable machine: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp -- Henri Salo [EMAIL PROTECTED] 0407705733 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
Hi, > It remains strange because normally, lo is a non-broadcast interface. Maybe it would help to know how Henri has his network configured. Mine is configured with ifupdown, /etc/network/interfaces looks like this: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp and chkrootkit (version 0.46a) gives me eth0: PF_PACKET(/sbin/dhclient, /usr/sbin/arpwatch) lo is not mentioned. Regards, Lothar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
On Sunday 13 August 2006 23:38, Nicolas Haller wrote: > It remains strange because normally, lo is a non-broadcast interface. With version 0.46 it get this result: Checking `sniffer'... lo: not promisc and no packet sniffer sockets lan: PACKET SNIFFER(/sbin/dhclient3[6515]) Maybe it's just because of a different dhcp-client? Or the higher version of chkrootkit? Greetings, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
On Fri, Aug 11, 2006 at 11:40:24AM +0200, Izak Burger wrote: > On 8/11/06, Christian Schuerer <[EMAIL PROTECTED]> wrote: > >Isn't it strange that there is an DHCP client running on lo? I don't get > >the > >point of doing that. > The pid is the same for all three (29184), so it is obviously a > process that binds to 0.0.0.0, and as a result, ends up listening on > lo as well. The man page actually states it best: > --- snip --- > The names of the network interfaces that dhclient should attempt to > configure may be specified on the command line. If no interface > names are specified on the command line dhclient will normally > identify all network interfaces, eliminating non-broadcast interfaces > if possible, and attempt to configure each interface. > --- snip --- It remains strange because normally, lo is a non-broadcast interface. bye, -- Nicolas Haller signature.asc Description: Digital signature
Re: chkrootkit sniffers
On 8/11/06, Christian Schuerer <[EMAIL PROTECTED]> wrote: Isn't it strange that there is an DHCP client running on lo? I don't get the point of doing that. The pid is the same for all three (29184), so it is obviously a process that binds to 0.0.0.0, and as a result, ends up listening on lo as well. The man page actually states it best: --- snip --- The names of the network interfaces that dhclient should attempt to configure may be specified on the command line. If no interface names are specified on the command line dhclient will normally identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to configure each interface. --- snip --- Cheers, Izak -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
On Thursday 10 August 2006 23:23, Sven Hartge wrote: > Um 22:48 Uhr am 10.08.06 schrieb Henri Salo: > > I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with > > command chkrootkit and it gives me: > > > > Checking `sniffer'... lo: PACKET SNIFFER(/sbin/dhclient[29148]) > > eth0: PACKET SNIFFER(/sbin/dhclient[29148], /sbin/dhclient[29307]) > > eth1: PACKET SNIFFER(/sbin/dhclient[29148]) > > > > is that serious? > > No. Both dhclient and dhcpd are known false positives. > > You should of course check, if those processes are _really_ a dhclient. Isn't it strange that there is an DHCP client running on lo? I don't get the point of doing that. Regards, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit sniffers
Um 22:48 Uhr am 10.08.06 schrieb Henri Salo: > I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with > command chkrootkit and it gives me: > > Checking `sniffer'... lo: PACKET SNIFFER(/sbin/dhclient[29148]) > eth0: PACKET SNIFFER(/sbin/dhclient[29148], /sbin/dhclient[29307]) > eth1: PACKET SNIFFER(/sbin/dhclient[29148]) > > is that serious? No. Both dhclient and dhcpd are known false positives. You should of course check, if those processes are _really_ a dhclient. Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ Achtung, neue Mail-Adresse: [EMAIL PROTECTED]
chkrootkit sniffers
I am running Debian stable (kernel 2.6.8-2) chkrootkit version 0.44 with command chkrootkit and it gives me: Checking `sniffer'... lo: PACKET SNIFFER(/sbin/dhclient[29148]) eth0: PACKET SNIFFER(/sbin/dhclient[29148], /sbin/dhclient[29307]) eth1: PACKET SNIFFER(/sbin/dhclient[29148]) is that serious? -- Henri Salo [EMAIL PROTECTED] 0407705733 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
> > (I hope you don't mind if I publish our correspondence in Linux Gazette, > http://linuxgazette.net/ .) > No problem at all. Kevin Bailey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
hi ya thomas On Wed, 30 Nov 2005, Thomas Hochstein wrote: > Alvin Oga schrieb: > > > - fresh installs means you have to configure everything > > again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week > > No, you don't; you can just review the configuration file(s) manually > or check them against a known good backup. manually checking thousands of files is prone to error i run scripts to compare old vs new files, especially when looking for critical info - but one does assume that the script is "puurrfect" vs buggy > > always push backups, since remote machines should NEVER have access to > > root-read-only files > > That is not a good idea in a typical hosting environment; if you push > your backup and the machine to be backupped is compromised, the > attacker has access to your backups too because the automatic backup > process has to have the necessary credentials (unless you want to type > in the credentials every hour/day/week by hand, which is not very > feasible). it's "feasable" to me, and i do backups daily vs the risk of loss of data.. it's what's important to you and how you want to protect your data i always assume the main server is rooted and i try to protect data within those contraints reason ( ie .. i do NOT trust other machines .. ) - you can crack one box.. but hopefully you can't go anywhere else - i also assume that cracked box will run " rm -rf / " ( so don't even think about automounting backups :-) ) - i assume the cracker is in the primary box or any random box ... - they may NOT be able to run the backup scripts since they'd also need to type something ( pass phrase or password or voodoo ) - passwdless login and process for backup is a bad idea > Your backup host can and should be quite locked down so it > should be much harder to attack - I would prefer to allow remote > access to root-read-only files from a backup machine that is > presumably safe to giving an attacker from the "front-end" machine > access to the backups. if you pull files ... the primary system is allow a remote machine to read and backup root owned (protected) files which is an obvious secruity violation to allow non-root or root on other machines to remotely read root protected files - any random machine can also pretend to be the credentialed backup machine wanting to backup say /etc/shadow which probably requires special care ( encrypting backups ) if you push files ... you assume your backup is secure and you should encrypt and santize the backup .. - you have to trust your backup machines if it claims to be who it is or have a way to verify it too ( unique host info that is NOT copyable or fakable ) - when pushing, the remote backup machine CANNOT read and does NOT need access to read the primary machine's root protected files - whether backup is pushed or pulled, you can always read root owned files on the backups ... thus backup should be encrypted - secure backup methodology doesn't care if you are a colo user or all inhouse or all outsourced - everybody backup strategy will be different, ask 10 folks how they do backup and you will get 10 different ways - which is better will depend on what you're trying to protect and your paranoia level of trust (who and which machines) c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
Quoting Thomas Hochstein ([EMAIL PROTECTED]): > That is not a good idea in a typical hosting environment; if you push > your backup and the machine to be backupped is compromised, the > attacker has access to your backups too because the automatic backup > process has to have the necessary credentials (unless you want to type > in the credentials every hour/day/week by hand, which is not very > feasible). Remedy: If backups are set up cleverly using SSH public keypairs, all the intruder can do is re-run the backup job. (You would therefore want to have backups land on a dedicated filesystem, on the backup target host.) Details: "SSH Public-key Process" on http://linuxmafia.com/kb/Security/ -- Cheers, Rick Moen "Anger makes dull men witty, but it keeps them poor." [EMAIL PROTECTED] -- Elizabeth Tudor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
Alvin Oga schrieb: > - fresh installs means you have to configure everything > again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week No, you don't; you can just review the configuration file(s) manually or check them against a known good backup. > always push backups, since remote machines should NEVER have access to > root-read-only files That is not a good idea in a typical hosting environment; if you push your backup and the machine to be backupped is compromised, the attacker has access to your backups too because the automatic backup process has to have the necessary credentials (unless you want to type in the credentials every hour/day/week by hand, which is not very feasible). Your backup host can and should be quite locked down so it should be much harder to attack - I would prefer to allow remote access to root-read-only files from a backup machine that is presumably safe to giving an attacker from the "front-end" machine access to the backups. If you'vo got enough spare space on the server to be backupped, you could backup everything to the local harddisk first and then pull it from there - so you don't have the credentials for the backup space on the compromised machine, but also don't need to allow a root login from outside. Or you can push the backup out and then secure it on the backup server, i.e. write protect it or copy it to another location where the "front-end" host to be backupped has no access. -thh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
hi ya kevin On Tue, 29 Nov 2005, kevin bailey wrote: > i have tried out lots of different things on this server and have made the > mistake of leaving unnecessary services running. everybody does that, one forgets to "undo the experiment environment" and restore back to secure mode > in this case i think that webmin was running the miniserv.pl server and this > had a security warning issued for the version i had. any cgi is a bad idea unless you can do sanity checking of what users can feed it to get unauthorized access > also - very luckily - no data on the server has been damaged. - how do you "know" that ?? - can you compare the files against backups on cdrom that shows no modified changes ?? - one doesn't need to check binaries unless you want to check it vs fresh installs - using existing binaries is fine if you have a way to verify its md5 of the binary and libs and directory tree ( i prefer to check everything.. automatically with scripts ) - fresh installs means you have to configure everything again from nothing .. maybe 1hr ..maybe 1 day .. maybe 1 week ( i somtimes spend a week to fix up distros from net/cd installs ) > it seems to > spawn lots of hidden processes and has had to be rebooted to get it under > control again. it is typical for the reboot process ( scripts ) to be modified with trojans and backdoors and other hidden goodies > main points learnt. > > make sure you have snapshot backups going back months. and saved on say dvd or disks on backup servers that is powered off never overwrite backups unless you're willing to forgo checking against that data history dating back that far - it might be hours, days, weeks, months before you find that you've been had .. > regularly run chkrootkit and get the server to email the results to you. i wouldn't place too much confidence on binaries running on suspect hacked boxes, even if its for sanity checking, and first pass notifications of something whacky going on rebooting and running off standalone cd is better, but it means your server/services will be offline for the duration any of these IDS is sorta too late .. telling you're [cr|h]acked i'd tend to spend the time upfront to harden the server as best as possible for the time/budget that they or you/we provide for so we can sleep at nights > if backing up to another server get that server to pull backups out. on my > new machines i was pushing out the backups from the primary server - this > would mean a cracker would then have an easy way in to the backup machine > because i was using authorized_keys so the backup would run in a script. i say never use keys to do backups ... - keys can be stolen ... and if you dont require additional authentication, you're shot - if you can do it, play with backups, the [cr|h]acker and do it too - if you lock things down to one ip# ... its less likely the [cr|h]acker can get that ip# assigned to themself to play with your boxes always push backups, since remote machines should NEVER have access to root-read-only files - push with secure NFS and ssh ... pc1# mount backup_pc:/Backup/PC1 pc1# scp " copy all new files to remote backup_pc " requiring manual authenticaion if you're paranoid pc1# pgp encrypt that new backup data pc1# chmod 400 "backup data" pc1# umount backup_pc:/Backup/PC1 > but mainly only run required services - and check them closely - and don't > rely on your distro to incorporate every single security patch required for > your server. bingo and there's gazillion different solutions .. most works equally well for each user .. untill they outgrow it for any numberof reasons, where being cracked will usually result in some new changes c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
Rick Moen wrote: > > Unsafe data passed to eval(). Sheesh! And awstats is so large, that it would require a lot of effort to do a proper audit of it. Are their any automated tools for auditing perl code? Or I wonder what would happen if you just switced on taint mode? > >>I would agree with that idea. In fact, I've just lodged a bug report >>along those lines. Bug #341308. > > > Thank you, Geoff! No worries. Jonas has already responded to the bug, he sounds in favour of it. I'm sure he'd appreciate patch suggestions on implementing it. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
Quoting Geoff Crompton ([EMAIL PROTECTED]):
> The most recent vulnerability that I was aware of in Awstats can still
> work even in static mode. http://www.securityfocus.com/bid/14525. The
> referrer in the log file is not sanity checked.
Hmm. I note: "It should be noted this vulnerability is only possible
if the affected application has at least one URLPlugin enabled."
The iDefense advisory casts light on the problem Perl snippet:
the $url parameter contains unfiltered user-supplied
data that is used in a call to the Perl routine eval() on lines 4841
and 4842 of awstats.pl (version 6.4):
my $function="ShowInfoURL_$pluginname('$url')";
eval("$function");
The malicious referrer value will be included in the referrer
statistics portion of the AWStats report after AWStats has been run
to generate a new report including the tainted data. Once a user
visits the referrer statistics page, the injected perl code will
execute with permissions of the web service.
Unsafe data passed to eval(). Sheesh!
> I would agree with that idea. In fact, I've just lodged a bug report
> along those lines. Bug #341308.
Thank you, Geoff!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
> So, here's my favourite example of the "bad implementation" problem: > AWstats. It's had a long history of: > > o Someone finds yet another way its stats-generating CGI can be subverted by >sending it aberrant URL information from the public. > o The upstream maintainer issues an update. > o Debian issues a new package. > o An exploit emerges and gets rolled into automated attack tools. > o Lather, rinse, repeat. > > If you look more closely at AWstats, you might start to wonder: "I > guess the author never quite got input validation right. But why > does it have to run as a CGI (awstats.pl) in the first place? Can't it > run as a cronjob, instead, generating the same stats page as static HTML > every hour, instead?" The most recent vulnerability that I was aware of in Awstats can still work even in static mode. http://www.securityfocus.com/bid/14525. The referrer in the log file is not sanity checked. Unfortunately awstats seems to have organically grown as a single perl script. This one script is upto almost 5 lines of code. I've looked a little at the code, and I can't say it is easy to follow. But it does seem to do a good job of generating stats. I just don't feel comfortable trusting it on my servers. > > And you'd be right to wonder. That's a solved problem, thanks to Steve > Kemp over at debian-administration.org: > http://www.debian-administration.org/articles/85 > > I keep meaning to file a very polite bug with Debian maintainer Jonas > Smedegaard, suggesting that static-page mode be the default since > upstream's CGI default is (in my opinion) too risky, but I haven't done > that yet. > I would agree with that idea. In fact, I've just lodged a bug report along those lines. Bug #341308. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
On Tuesday 29 November 2005 14.04, kevin bailey wrote: > if backing up to another server get that server to pull backups out. on > my new machines i was pushing out the backups from the primary server - > this would mean a cracker would then have an easy way in to the backup > machine because i was using authorized_keys so the backup would run in a > script. Note that its not a question of push vs. pull but a question of where the authentication happens. In both cases you'll have some means (ssh key, hardcoded password etc.) to access the other machine - the decision should thus not be push vs. pull but to store the authentication information on the side where a compromise is less likely. Then, use tools like rssh to lock down the account used to transfer the back up data. Also allow log in on this account only from a fixed IP address. (Obviously not always possible in the hobbyist scenario when you're backing up your server to your home machine on DSL or so.) cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgp0p59XJGkXF.pgp Description: PGP signature
Re: chkrootkit has me worried!
Quoting kevin bailey ([EMAIL PROTECTED]): > what with it being several different symptoms i tend to think this is not a > false positive. Concur. > cause: > > this is an old server which has been running for 4 years. If such an old server is maintained and administered properly, and if you doesn't get unlucky and suffer compromise because a remote user's login credentials were stolen elsewhere, then host age alone is not a problem. > i have tried out lots of different things on this server and have made the > mistake of leaving unnecessary services running. Whoops. That is a risk factor. > in this case i think that webmin was running the miniserv.pl server and this > had a security warning issued for the version i had. Yes. Be aware that many CGI-based services are just plain risky on account of bad implementation (e.g., failure to validate input), and that the security team can't save you from this. Only alert and cautious system administration can. > it doesn't seem to have been fixed in the debian security fixes - i'll > contact debian RE this. So, here's my favourite example of the "bad implementation" problem: AWstats. It's had a long history of: o Someone finds yet another way its stats-generating CGI can be subverted by sending it aberrant URL information from the public. o The upstream maintainer issues an update. o Debian issues a new package. o An exploit emerges and gets rolled into automated attack tools. o Lather, rinse, repeat. If you look more closely at AWstats, you might start to wonder: "I guess the author never quite got input validation right. But why does it have to run as a CGI (awstats.pl) in the first place? Can't it run as a cronjob, instead, generating the same stats page as static HTML every hour, instead?" And you'd be right to wonder. That's a solved problem, thanks to Steve Kemp over at debian-administration.org: http://www.debian-administration.org/articles/85 I keep meaning to file a very polite bug with Debian maintainer Jonas Smedegaard, suggesting that static-page mode be the default since upstream's CGI default is (in my opinion) too risky, but I haven't done that yet. > also - very luckily - no data on the server has been damaged. it seems to > spawn lots of hidden processes and has had to be rebooted to get it under > control again. With respect, you have rather little reason to believe that you yet have control. Since it is highly likely that your site was root-compromised, your best course of action is to rebuild with the same data files but entirely fresh software from trusted media, avoiding direct reuse of any of your existing configuration files or user dotfiles. http://www.cert.org/tech_tips/win-UNIX-system_compromise.html > main points learnt. > > make sure you have snapshot backups going back months. > > regularly run chkrootkit and get the server to email the results to you. chkrootkit is useful (as is rkhunter) as a last-gasp doublecheck to increase your confidence that your other security precautions have worked. It's a "canary". However, it had better not be used in place of those precautions, or you're already in trouble. Let's use an analogy from public health: chkrootkit is the blood test that informs you that you have a case of amoebic dysentary. Your suggestion amounts to "Well, then I mostly need bloodwork done every few months. Never mind that bit about being careful about eating raw shellfish caught near sewage outfalls and eating in restaurants with questionable sanitary practices." The Debian security team is your county's restaurant inspectors. AWstats's default CGI-generated mode is that bucket of raw oysters. > but mainly only run required services - and check them closely - and don't > rely on your distro to incorporate every single security patch required for > your server. Right, and remember that the health inspectors can't guarantee every oyster -- and that fugu from a reputable restaurant can still kill you. (I hope you don't mind if I publish our correspondence in Linux Gazette, http://linuxgazette.net/ .) -- Cheers, Rick Moen "Anger makes dull men witty, but it keeps them poor." [EMAIL PROTECTED] -- Elizabeth Tudor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
thanks for the replies. what with it being several different symptoms i tend to think this is not a false positive. cause: this is an old server which has been running for 4 years. i have tried out lots of different things on this server and have made the mistake of leaving unnecessary services running. in this case i think that webmin was running the miniserv.pl server and this had a security warning issued for the version i had. it doesn't seem to have been fixed in the debian security fixes - i'll contact debian RE this. or it might have been a weakness in zope. luckily i was halfway through moving everything off this server to a new pair of servers and have been able to move the changeover forwards. also - very luckily - no data on the server has been damaged. it seems to spawn lots of hidden processes and has had to be rebooted to get it under control again. main points learnt. make sure you have snapshot backups going back months. regularly run chkrootkit and get the server to email the results to you. if backing up to another server get that server to pull backups out. on my new machines i was pushing out the backups from the primary server - this would mean a cracker would then have an easy way in to the backup machine because i was using authorized_keys so the backup would run in a script. but mainly only run required services - and check them closely - and don't rely on your distro to incorporate every single security patch required for your server. kev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit has me worried!
On Tue, Nov 29, 2005 at 04:34:11AM +, kevin bailey wrote: > hi, > > the following output looks like i've been rooted. Yes, it doesn't look like a false positive: > Checking `ls'... INFECTED > Checking `netstat'... INFECTED > Checking `ps'... INFECTED > Checking `top'... INFECTED Nasty. > Searching for suspicious files and dirs, it may take a while... > /usr/lib/zope/lib/python/Products/DCWorkflow/.Xserver-lcd > /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swo > /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swp > /usr/lib/zope/lib/python/SearchIndex/.testinfo Those might be FP. > /usr/lib/nmh/include/lib/.sniffer This one looks nasty. > Searching for anomalies in shell history files... Warning: > `//root/.bash_history' file size is zero Nasty. > Checking `lkm'... You have 107 process hidden for readdir command > You have 113 process hidden for ps command Nasty. > Checking `sniffer'... eth0 is PROMISC You have several processes hidden and what looks like sniffer logs so be careful. Your passwords might be compromised either through a trojaned ssh client if you are using ssh or through the sniffer if you are using clear-text passwords. Sorry, Javierthrough the sniffer if you are using clear-text passwords. signature.asc Description: Digital signature
Re: chkrootkit has me worried!
and.. :/usr/local/sbin# /usr/lib/chkrootkit/chkproc -v PID 4: not in ps output PID 1769: not in ps output PID 15688: not in ps output PID 15690: not in ps output PID 17760: not in ps output PID 17762: not in ps output PID 21583: not in ps output PID 21585: not in ps output PID 21919: not in ps output PID 21921: not in ps output PID 23002: not in readdir output PID 23002: not in ps output PID 23085: not in readdir output PID 23085: not in ps output PID 23105: not in readdir output PID 23105: not in ps output You have 3 process hidden for readdir command You have13 process hidden for ps command and freeway:~# cd /proc/1769/fd freeway:/proc/1769/fd# ls -l total 0 lrwx-- 1 root root 64 Nov 29 05:11 0 -> /dev/null lrwx-- 1 root root 64 Nov 29 05:11 1 -> /dev/null lrwx-- 1 root root 64 Nov 29 05:11 2 -> /dev/null lrwx-- 1 root root 64 Nov 29 05:11 3 -> socket:[300] freeway:/proc/1769/fd# grep 300 /proc/net/udp freeway:/proc/1769/fd# grep 300 /proc/net/tcp 26: :0016 : 0A : 00: 00 300 freeway:/proc/1769/fd :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chkrootkit has me worried!
hi, the following output looks like i've been rooted. i'm in the process of moving all services to another machine and restoring from backups etc. could anyone provide any analysis of what attack caused the problem - i would guess that it's possibly something o do with zope. thanks, kev :/usr/local/sbin# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not infected Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... INFECTED Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... INFECTED Checking `named'... not found Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... INFECTED Checking `pstree'... not infected Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... INFECTED Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/ttyop /dev/ttyoa Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... /usr/lib/zope/lib/python/Products/DCWorkflow/.Xserver-lcd /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swo /usr/lib/zope/lib/python/Products/ZnolkSQLWizard/.selectColumns.dtml.swp /usr/lib/zope/lib/python/SearchIndex/.testinfo /usr/lib/nmh/include/lib/.sniffer Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... Warning: `//root/.bash_history' file size is zero nothing found Checking `asp'... not infected Checking `bindshell'... not infected Checking `lkm'... You have 107 process hidden for readdir command You have 113 process hidden for ps command Warning: Possible LKM Trojan installed Checking `rexedcs'... not found Checking `sniffer'... eth0 is PROMISC Checking `wted'... nothing deleted Checking `z2'... nothing deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter / chkrootkit
Hi Rick, > Why don't you make a copy of one or more of those binaries, then > re-retrieve and install the Woody package of the same release, and > compare md5sums of the resulting binaries? (Note that you should make > very sure it's the same release, or you'll get a different md5sum for > entirely innocent reasons.) indeed, I could do it. After an established contact to one of the maintainer the previous advice to --update the md5sum from the rkhunter server solved the problem and it was not an irregularity within the debian server. So they've updated now which was required. > > Checking /dev for suspicious files... [ Warning! > > (unusual files found) ] > Well? What files? The fact that rkhunter has an opinion is not, by > itself, particularly interesting. You either have to know rkhunter > very, very well, such that you have a high degree of faith in its > opinions, or need to investigate for yourself what it claims is > suspicious. Preferably both. Don't know what files as there was no output and by the way it was the first time I used rkhunter. > > - ProFTPd 1.2.5rc1 [Vulnerable ] > > - OpenSSH 3.4p1[Vulnerable ] > > - GnuPG 1.0.6 [Vulnerable ] > Well? _Are_ those actually vulnerable, or is rkhunter making bad > assumptions? If you are running a conventional woody system, then > you're receiving backported security fixes -- which does not change the > package version number. Ergo, if rkhunter is stating the foregoing > strictly on the basis of version numbers, then it is making a common > elementary error. Hm, to be honest I wasn't able to read the source code but I don't think that my ProFTP is not vulnerable and I've to agree rkhunter is not able to detect the correct version so you're right. > > Incorrect MD5 checksums: 6 > Which ones? And on what basis is it saying they're incorrect? You > don't say. The binaries mentioned above. -- Best Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter / chkrootkit
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > Rootkit Hunter found some bad or unknown hashes. This can be happen due > replaced binaries or updated packages (which give other hashes). Be sure > your hashes are fully updated (rkhunter --update). If you're in doubt > about these hashes, contact the author ... Why don't you make a copy of one or more of those binaries, then re-retrieve and install the Woody package of the same release, and compare md5sums of the resulting binaries? (Note that you should make very sure it's the same release, or you'll get a different md5sum for entirely innocent reasons.) > And another alert was this: > > Checking /dev for suspicious files... [ Warning! > (unusual files found) ] Well? What files? The fact that rkhunter has an opinion is not, by itself, particularly interesting. You either have to know rkhunter very, very well, such that you have a high degree of faith in its opinions, or need to investigate for yourself what it claims is suspicious. Preferably both. > What's up now I would expect someone has replaced my /bin/login > binary which makes me feel unhappy or is there nothing to > worry about ? > > - ProFTPd 1.2.5rc1 [Vulnerable ] > - OpenSSH 3.4p1[Vulnerable ] > - GnuPG 1.0.6 [Vulnerable ] Well? _Are_ those actually vulnerable, or is rkhunter making bad assumptions? If you are running a conventional woody system, then you're receiving backported security fixes -- which does not change the package version number. Ergo, if rkhunter is stating the foregoing strictly on the basis of version numbers, then it is making a common elementary error. > At last there was this error messages: > > Incorrect MD5 checksums: 6 Which ones? And on what basis is it saying they're incorrect? You don't say. -- Cheers, There are 10 kinds of people in the world, those who Rick Moen know ternary, those who don't, and those who are now [EMAIL PROTECTED] looking for their dictionaries. -- Ron Fabre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rkhunter / chkrootkit
Incoming from [EMAIL PROTECTED]: > > chkrootkit found nothing but rkhunter found quite a lot: > > /bin/login /bin/su /usr/bin/locate /usr/sbin/useradd /usr/sbin/usermod > /usr/sbin/vip > > All these binaries have been alerted within rkhunter. > > I got a message like this [ and there was indeed an debian > update of passwd(login) but to get sure I need reilly competent > advices]: > > Rootkit Hunter found some bad or unknown hashes. This can be happen due > replaced binaries or updated packages (which give other hashes). Be sure > your hashes are fully updated (rkhunter --update). If you're in doubt > about these hashes, contact the author ... > > And another alert was this: > > Checking /dev for suspicious files... [ Warning! > (unusual files found) ] > > What's up now I would expect someone has replaced my /bin/login - what version of chkrootkit are you running? Latest is 0.44. - rkhunter appears to only be showing a "tripwire" sort of alert. Its recognition of what's on the system apparently wasn't updated when you installed new software, and that would be the mistake you made that's causing this confusion. So, I'd say the prudent things to do are: - install and run the latest chkrootkit. - rkhunter --update However, I don't run rkhunter. Is there an rkhunter-users mailing list anywhere? Perhaps you can check their archive? -- Any technology distinguishable from magic is insufficiently advanced. (*)http://www.spots.ab.ca/~keeling Please don't Cc: me. - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rkhunter / chkrootkit
Hello, it now it was a couple of days ago but I've to concern another time to in this case a compromised woody system. chkrootkit found nothing but rkhunter found quite a lot: /bin/login /bin/su /usr/bin/locate /usr/sbin/useradd /usr/sbin/usermod /usr/sbin/vip All these binaries have been alerted within rkhunter. I got a message like this [ and there was indeed an debian update of passwd(login) but to get sure I need reilly competent advices]: Rootkit Hunter found some bad or unknown hashes. This can be happen due replaced binaries or updated packages (which give other hashes). Be sure your hashes are fully updated (rkhunter --update). If you're in doubt about these hashes, contact the author ... And another alert was this: Checking /dev for suspicious files... [ Warning! (unusual files found) ] What's up now I would expect someone has replaced my /bin/login binary which makes me feel unhappy or is there nothing to worry about ? - ProFTPd 1.2.5rc1 [Vulnerable ] - OpenSSH 3.4p1[Vulnerable ] - GnuPG 1.0.6 [Vulnerable ] Ok, this could be solved by compiling from sources and indeed I've to do it. At last there was this error messages: Incorrect MD5 checksums: 6 Would this solve my problem and I've to update the hash within mkhunter as describe avove ? -- Best Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
* Quoting Bas ([EMAIL PROTECTED]): > If you do not run Portsentry you have a problem.. I disagree. There could be another process listening at that. - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
I presume you run Portsentry on the same machine if you do than the blindshell INFECTED is nothing to worry about ITs normal behavior if you run Portsentry and chkrootkit on the same machine. If you do not run Portsentry you have a problem.. Bas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Feb 2004 14:32:26 +0100, Greg <[EMAIL PROTECTED]> wrote: > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > > I am not sure how no interpret this. I have checked logs, as well as binary > checks and everything "seems" fine. Can someone help me interpret the logs. > I will attach them at the tail of the email in case the may be helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. Are you running portsentry? if you are, shut it off, and rerun chkrootkit. If not, nmap the box from outside, and see if there is something listening on those ports, if there is, but netstat shows nothing there, then you've probably been cracked, and you know what to do. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO6aUd90bcYOAWPYRAquCAKDfxWteagmgU8Qi4qDoY7TrMsPvPwCfQ8oA vfluFUl7UE5kvbbeT6XCVYU= =lM19 -END PGP SIGNATURE- -- Jim Richardson http://www.eskimo.com/~warlock Life imitates art, but does it have to imitate satire?
Re: chkrootkit - possible bad news`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Feb 2004 14:32:26 +0100, Greg <[EMAIL PROTECTED]> wrote: > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > > I am not sure how no interpret this. I have checked logs, as well as binary > checks and everything "seems" fine. Can someone help me interpret the logs. > I will attach them at the tail of the email in case the may be helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. Are you running portsentry? if you are, shut it off, and rerun chkrootkit. If not, nmap the box from outside, and see if there is something listening on those ports, if there is, but netstat shows nothing there, then you've probably been cracked, and you know what to do. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO6aUd90bcYOAWPYRAquCAKDfxWteagmgU8Qi4qDoY7TrMsPvPwCfQ8oA vfluFUl7UE5kvbbeT6XCVYU= =lM19 -END PGP SIGNATURE- -- Jim Richardson http://www.eskimo.com/~warlock Life imitates art, but does it have to imitate satire? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
On Tue, Feb 24, 2004 at 10:37:44AM -0500, Noah Meyerhans wrote: > On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > > > > Looks like there are a lot of false positives on it. > > > > It looks like there are a lot of false positives with chkrootkit in > general. Seriously, has anybody here ever had chkrootkit detect an > actual rootkit? [...snip...] > Well, I've had it confirm suspicions that a rootkit was installed, but no correct automated detection. I'm considering killing teh crontab entry, because it's getting too annoying having to verify that the entries it produces are false. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5 pgp8qftTDZ0fF.pgp Description: PGP signature
Re: chkrootkit - possible bad news`
Alohá! Noah Meyerhans wrote: > On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > >> Looks like there are a lot of false positives on it. >> > > > It looks like there are a lot of false positives with chkrootkit in > general. Seriously, has anybody here ever had chkrootkit detect an > actual rootkit? [...] Had about half a dozen public machines with old SuSe 6.4 default installations half-way in my area of responsibility that were 'uprooted'. Diagnosing them with chkrootkit when they started creating unusual network traffic let me make for a reinstall pretty quickly A friends small dyndns-server was hacked within two weeks after installation. Maybe chkrootkit is not that needed for 'big' server installations with somebody keeping an eye full-time on security related stuff and fs monitors reporting every change that might be suspicious to well kept logs, but for lazy admins that weight the cost of keeping things tight and secure higher than an occasional reinstallation (don't count me in there) chkrootkit is a welcome diagnosis tool. IMHO the biggest problem creating false positives are hidden processes that are actually supposed to be there for whatever conceptual reasons. best regards Martin
Re: chkrootkit - possible bad news`
On Tue, Feb 24, 2004 at 10:37:44AM -0500, Noah Meyerhans wrote: > On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > > > > Looks like there are a lot of false positives on it. > > > > It looks like there are a lot of false positives with chkrootkit in > general. Seriously, has anybody here ever had chkrootkit detect an > actual rootkit? [...snip...] > Well, I've had it confirm suspicions that a rootkit was installed, but no correct automated detection. I'm considering killing teh crontab entry, because it's getting too annoying having to verify that the entries it produces are false. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5 pgp0.pgp Description: PGP signature
Re: chkrootkit - possible bad news`
On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > > Looks like there are a lot of false positives on it. > It looks like there are a lot of false positives with chkrootkit in general. Seriously, has anybody here ever had chkrootkit detect an actual rootkit? Questions about its output have become relatively common on this list in the past few months, and I honestly don't remember any that didn't turn out to be false positives. noah pgpsDe9NDZC6c.pgp Description: PGP signature
Re: chkrootkit - possible bad news`
Alohá! Noah Meyerhans wrote: > On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > >> Looks like there are a lot of false positives on it. >> > > > It looks like there are a lot of false positives with chkrootkit in > general. Seriously, has anybody here ever had chkrootkit detect an > actual rootkit? [...] Had about half a dozen public machines with old SuSe 6.4 default installations half-way in my area of responsibility that were 'uprooted'. Diagnosing them with chkrootkit when they started creating unusual network traffic let me make for a reinstall pretty quickly A friends small dyndns-server was hacked within two weeks after installation. Maybe chkrootkit is not that needed for 'big' server installations with somebody keeping an eye full-time on security related stuff and fs monitors reporting every change that might be suspicious to well kept logs, but for lazy admins that weight the cost of keeping things tight and secure higher than an occasional reinstallation (don't count me in there) chkrootkit is a welcome diagnosis tool. IMHO the biggest problem creating false positives are hidden processes that are actually supposed to be there for whatever conceptual reasons. best regards Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
On Tue, Feb 24, 2004 at 09:14:05AM +0200, Sneferu wrote: > > Looks like there are a lot of false positives on it. > It looks like there are a lot of false positives with chkrootkit in general. Seriously, has anybody here ever had chkrootkit detect an actual rootkit? Questions about its output have become relatively common on this list in the past few months, and I honestly don't remember any that didn't turn out to be false positives. noah pgp0.pgp Description: PGP signature
Re: chkrootkit - possible bad news`
31337 - are your runing portsentry on that machine ? Quote from the www.chkrootkit.org site: I'm running PortSentry/klaxon. What's wrong with the bindshell test? If you're running PortSentry/klaxon or another program that binds itself to unused ports probably chkrootkit will give you a false positive on the bindshell test (ports 114/tcp, 465/tcp, 511/tcp, 1008/tcp, 1524/tcp, 1999/tcp, 3879/tcp, 5665/tcp, 10008/tcp, 12321/tcp, 23132/tcp, 27374/tcp, 29364/tcp, 31336/tcp, 31337/tcp, 45454/tcp, 47017/tcp, 47889/tcp, 60001/tcp). - Original Message - From: "Greg" <[EMAIL PROTECTED]> To: Sent: Tuesday, February 24, 2004 8:53 AM Subject: chkrootkit - possible bad news` > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > > I am not sure how no interpret this. I have checked logs, as well as binary > checks and everything "seems" fine. Can someone help me interpret the logs. > I will attach them at the tail of the email in case the may be helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. > > Thanks in advance. > > Greg MEATPLOW > > # > #chkrootkit > > alpha:~# chkrootkit > ROOTDIR is `/' > Checking `amd'... not found > Checking `basename'... not infected > Checking `biff'... not found > Checking `chfn'... not infected > Checking `chsh'... not infected > Checking `cron'... not infected > Checking `date'... not infected > Checking `du'... not infected > Checking `dirname'... not infected > Checking `echo'... not infected > Checking `egrep'... not infected > Checking `env'... not infected > Checking `find'... not infected > Checking `fingerd'... not found > Checking `gpm'... not found > Checking `grep'... not infected > Checking `hdparm'... not found > Checking `su'... not infected > Checking `ifconfig'... not infected > Checking `inetd'... not infected > Checking `inetdconf'... not infected > Checking `identd'... not found > Checking `killall'... not found > Checking `ldsopreload'... not infected > Checking `login'... not infected > Checking `ls'... not infected > Checking `lsof'... not found > Checking `mail'... not infected > Checking `mingetty'... not found > Checking `netstat'... not infected > Checking `named'... not infected > Checking `passwd'... not infected > Checking `pidof'... not infected > Checking `pop2'... not found > Checking `pop3'... not found > Checking `ps'... not infected > Checking `pstree'... not found > Checking `rpcinfo'... not infected > Checking `rlogind'... not found > Checking `rshd'... not found > Checking `slogin'... not infected > Checking `sendmail'... not infected > Checking `sshd'... not infected > Checking `syslogd'... not infected > Checking `tar'... not infected > Checking `tcpd'... not infected > Checking `top'... not infected > Checking `telnetd'... not found > Checking `timed'... not found > Checking `traceroute'... not infected > Checking `write'... not infected > Checking `aliens'... > /dev/st- /dev/sto > Searching for sniffer's logs, it may take a while... nothing found > Searching for HiDrootkit's default dir... nothing found > Searching for t0rn's default files and dirs... nothing found > Searching for t0rn's v8 defaults... nothing found > Searching for Lion Worm default files and dirs... nothing found > Searching for RSHA's default files and dir... nothing found > Searching for RH-Sharpe's default files... nothing found > Searching for Ambient's rootkit (ark) default files and dirs... nothing > found > Searching for suspicious files and dirs, it may take a while... nothing > found > Searching for LPD Worm files and dirs... nothing found > Searching for Ramen Worm files and dirs... nothing found > Searching for Maniac files and dirs... nothing found > Searching for RK17 files and dirs... nothing found > Searching for Ducoci rootkit... nothing found > Searching for Adore Worm... nothing found > Searching for ShitC Worm... nothing found > Searching for Omega Worm... nothing found > Searching for Sadmind/IIS Worm... nothing found > Searching for MonKit... nothing found > Searching for anomalies in shell history files... nothing found > Checking `asp'... not infected > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > Checking `lkm'... nothing detected > Checking `rexedcs'... not found > Checking `sniffer'... eth0 is not promisc > Checking `wted'... nothing deleted > Checking `z2'... > nothing deleted > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: chkrootkit - possible bad news`
May be you have installed "fakebo"? Billy
Re: chkrootkit - possible bad news`
You might not be hacked after all. Read this: http://www.webhostgear.com/25.html Also some googling might help ;-) http://www.google.ro/search?q=%27bindshell%27...+INFECTED+%28PORTS%3A++1524+31337&ie=UTF-8&oe=UTF-8&hl=ro&btnG=Caut%C4%83&meta= Looks like there are a lot of false positives on it. Still, you should do a tripwire (or any other file checking) test if you have a previous record to match against. Nmap should give you a good idea about opened ports. Logs? Probably there are some other things you can do...but this is what crosses my mind now. Regards, S At 08:53 AM 2/24/2004, Greg wrote: I am running Debian on a Dec Alpha PC164. I decided to run chkrootkit and was surprised by the following line. Checking `bindshell'... INFECTED (PORTS: 1524 31337) I am not sure how no interpret this. I have checked logs, as well as binary checks and everything "seems" fine. Can someone help me interpret the logs. I will attach them at the tail of the email in case the may be helpful. I don't know what my next step would be. If in deed I have been 'rooted' then I should obviously format and rebuild the server. Thanks in advance. Greg MEATPLOW # #chkrootkit alpha:~# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not found Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not found Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/st- /dev/sto Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... nothing found Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... INFECTED (PORTS: 1524 31337) Checking `lkm'... nothing detected Checking `rexedcs'... not found Checking `sniffer'... eth0 is not promisc Checking `wted'... nothing deleted Checking `z2'... nothing deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- Cauta-ti perechea pe http://dating.acasa.ro --- Cauta-ti perechea pe http://dating.acasa.ro
Re: chkrootkit - possible bad news`
On Tuesday 24 February 2004 07:53, Greg wrote: > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) Try a nmap port scan from the outside to your ip address. If those ports are open but netstat doesn't show them as LISTENING chances are your netstat is modified to hide the connections. You may also want to run chkrootkit when booted from single user mode. Regards, Ricardo. > > I am not sure how no interpret this. I have checked logs, as well as > binary checks and everything "seems" fine. Can someone help me interpret > the logs. I will attach them at the tail of the email in case the may be > helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. > > Thanks in advance. > > Greg MEATPLOW > > # > #chkrootkit > > alpha:~# chkrootkit > ROOTDIR is `/' > Checking `amd'... not found > Checking `basename'... not infected > Checking `biff'... not found > Checking `chfn'... not infected > Checking `chsh'... not infected > Checking `cron'... not infected > Checking `date'... not infected > Checking `du'... not infected > Checking `dirname'... not infected > Checking `echo'... not infected > Checking `egrep'... not infected > Checking `env'... not infected > Checking `find'... not infected > Checking `fingerd'... not found > Checking `gpm'... not found > Checking `grep'... not infected > Checking `hdparm'... not found > Checking `su'... not infected > Checking `ifconfig'... not infected > Checking `inetd'... not infected > Checking `inetdconf'... not infected > Checking `identd'... not found > Checking `killall'... not found > Checking `ldsopreload'... not infected > Checking `login'... not infected > Checking `ls'... not infected > Checking `lsof'... not found > Checking `mail'... not infected > Checking `mingetty'... not found > Checking `netstat'... not infected > Checking `named'... not infected > Checking `passwd'... not infected > Checking `pidof'... not infected > Checking `pop2'... not found > Checking `pop3'... not found > Checking `ps'... not infected > Checking `pstree'... not found > Checking `rpcinfo'... not infected > Checking `rlogind'... not found > Checking `rshd'... not found > Checking `slogin'... not infected > Checking `sendmail'... not infected > Checking `sshd'... not infected > Checking `syslogd'... not infected > Checking `tar'... not infected > Checking `tcpd'... not infected > Checking `top'... not infected > Checking `telnetd'... not found > Checking `timed'... not found > Checking `traceroute'... not infected > Checking `write'... not infected > Checking `aliens'... > /dev/st- /dev/sto > Searching for sniffer's logs, it may take a while... nothing found > Searching for HiDrootkit's default dir... nothing found > Searching for t0rn's default files and dirs... nothing found > Searching for t0rn's v8 defaults... nothing found > Searching for Lion Worm default files and dirs... nothing found > Searching for RSHA's default files and dir... nothing found > Searching for RH-Sharpe's default files... nothing found > Searching for Ambient's rootkit (ark) default files and dirs... nothing > found > Searching for suspicious files and dirs, it may take a while... nothing > found > Searching for LPD Worm files and dirs... nothing found > Searching for Ramen Worm files and dirs... nothing found > Searching for Maniac files and dirs... nothing found > Searching for RK17 files and dirs... nothing found > Searching for Ducoci rootkit... nothing found > Searching for Adore Worm... nothing found > Searching for ShitC Worm... nothing found > Searching for Omega Worm... nothing found > Searching for Sadmind/IIS Worm... nothing found > Searching for MonKit... nothing found > Searching for anomalies in shell history files... nothing found > Checking `asp'... not infected > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > Checking `lkm'... nothing detected > Checking `rexedcs'... not found > Checking `sniffer'... eth0 is not promisc > Checking `wted'... nothing deleted > Checking `z2'... > nothing deleted --
chkrootkit - possible bad news`
I am running Debian on a Dec Alpha PC164. I decided to run chkrootkit and was surprised by the following line. Checking `bindshell'... INFECTED (PORTS: 1524 31337) I am not sure how no interpret this. I have checked logs, as well as binary checks and everything "seems" fine. Can someone help me interpret the logs. I will attach them at the tail of the email in case the may be helpful. I don't know what my next step would be. If in deed I have been 'rooted' then I should obviously format and rebuild the server. Thanks in advance. Greg MEATPLOW ##### #chkrootkit alpha:~# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not found Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not found Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/st- /dev/sto Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... nothing found Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... INFECTED (PORTS: 1524 31337) Checking `lkm'... nothing detected Checking `rexedcs'... not found Checking `sniffer'... eth0 is not promisc Checking `wted'... nothing deleted Checking `z2'... nothing deleted
Re: chkrootkit - possible bad news`
31337 - are your runing portsentry on that machine ? Quote from the www.chkrootkit.org site: I'm running PortSentry/klaxon. What's wrong with the bindshell test? If you're running PortSentry/klaxon or another program that binds itself to unused ports probably chkrootkit will give you a false positive on the bindshell test (ports 114/tcp, 465/tcp, 511/tcp, 1008/tcp, 1524/tcp, 1999/tcp, 3879/tcp, 5665/tcp, 10008/tcp, 12321/tcp, 23132/tcp, 27374/tcp, 29364/tcp, 31336/tcp, 31337/tcp, 45454/tcp, 47017/tcp, 47889/tcp, 60001/tcp). - Original Message - From: "Greg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 24, 2004 8:53 AM Subject: chkrootkit - possible bad news` > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > > I am not sure how no interpret this. I have checked logs, as well as binary > checks and everything "seems" fine. Can someone help me interpret the logs. > I will attach them at the tail of the email in case the may be helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. > > Thanks in advance. > > Greg MEATPLOW > > # > #chkrootkit > > alpha:~# chkrootkit > ROOTDIR is `/' > Checking `amd'... not found > Checking `basename'... not infected > Checking `biff'... not found > Checking `chfn'... not infected > Checking `chsh'... not infected > Checking `cron'... not infected > Checking `date'... not infected > Checking `du'... not infected > Checking `dirname'... not infected > Checking `echo'... not infected > Checking `egrep'... not infected > Checking `env'... not infected > Checking `find'... not infected > Checking `fingerd'... not found > Checking `gpm'... not found > Checking `grep'... not infected > Checking `hdparm'... not found > Checking `su'... not infected > Checking `ifconfig'... not infected > Checking `inetd'... not infected > Checking `inetdconf'... not infected > Checking `identd'... not found > Checking `killall'... not found > Checking `ldsopreload'... not infected > Checking `login'... not infected > Checking `ls'... not infected > Checking `lsof'... not found > Checking `mail'... not infected > Checking `mingetty'... not found > Checking `netstat'... not infected > Checking `named'... not infected > Checking `passwd'... not infected > Checking `pidof'... not infected > Checking `pop2'... not found > Checking `pop3'... not found > Checking `ps'... not infected > Checking `pstree'... not found > Checking `rpcinfo'... not infected > Checking `rlogind'... not found > Checking `rshd'... not found > Checking `slogin'... not infected > Checking `sendmail'... not infected > Checking `sshd'... not infected > Checking `syslogd'... not infected > Checking `tar'... not infected > Checking `tcpd'... not infected > Checking `top'... not infected > Checking `telnetd'... not found > Checking `timed'... not found > Checking `traceroute'... not infected > Checking `write'... not infected > Checking `aliens'... > /dev/st- /dev/sto > Searching for sniffer's logs, it may take a while... nothing found > Searching for HiDrootkit's default dir... nothing found > Searching for t0rn's default files and dirs... nothing found > Searching for t0rn's v8 defaults... nothing found > Searching for Lion Worm default files and dirs... nothing found > Searching for RSHA's default files and dir... nothing found > Searching for RH-Sharpe's default files... nothing found > Searching for Ambient's rootkit (ark) default files and dirs... nothing > found > Searching for suspicious files and dirs, it may take a while... nothing > found > Searching for LPD Worm files and dirs... nothing found > Searching for Ramen Worm files and dirs... nothing found > Searching for Maniac files and dirs... nothing found > Searching for RK17 files and dirs... nothing found > Searching for Ducoci rootkit... nothing found > Searching for Adore Worm... nothing found > Searching for ShitC Worm... nothing found > Searching for Omega Worm... nothing found > Searching for Sadmind/IIS Worm... nothing found > Searching for MonKit... nothing found > Searching for anomalies in shell history files... nothing found > Checking `asp'... not infected > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > Checking `lkm'... nothing detected > Checking `rexedcs'... not found > Checking `sniffer'... eth0 is not promisc > Checking `wted'... nothing deleted > Checking `z2'... > nothing deleted > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
May be you have installed "fakebo"? Billy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
You might not be hacked after all. Read this: http://www.webhostgear.com/25.html Also some googling might help ;-) http://www.google.ro/search?q=%27bindshell%27...+INFECTED+%28PORTS%3A++1524+31337&ie=UTF-8&oe=UTF-8&hl=ro&btnG=Caut%C4%83&meta= Looks like there are a lot of false positives on it. Still, you should do a tripwire (or any other file checking) test if you have a previous record to match against. Nmap should give you a good idea about opened ports. Logs? Probably there are some other things you can do...but this is what crosses my mind now. Regards, S At 08:53 AM 2/24/2004, Greg wrote: I am running Debian on a Dec Alpha PC164. I decided to run chkrootkit and was surprised by the following line. Checking `bindshell'... INFECTED (PORTS: 1524 31337) I am not sure how no interpret this. I have checked logs, as well as binary checks and everything "seems" fine. Can someone help me interpret the logs. I will attach them at the tail of the email in case the may be helpful. I don't know what my next step would be. If in deed I have been 'rooted' then I should obviously format and rebuild the server. Thanks in advance. Greg MEATPLOW # #chkrootkit alpha:~# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not found Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not found Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/st- /dev/sto Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... nothing found Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... INFECTED (PORTS: 1524 31337) Checking `lkm'... nothing detected Checking `rexedcs'... not found Checking `sniffer'... eth0 is not promisc Checking `wted'... nothing deleted Checking `z2'... nothing deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- Cauta-ti perechea pe http://dating.acasa.ro --- Cauta-ti perechea pe http://dating.acasa.ro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit - possible bad news`
On Tuesday 24 February 2004 07:53, Greg wrote: > I am running Debian on a Dec Alpha PC164. > > I decided to run chkrootkit and was surprised by the following line. > > Checking `bindshell'... INFECTED (PORTS: 1524 31337) Try a nmap port scan from the outside to your ip address. If those ports are open but netstat doesn't show them as LISTENING chances are your netstat is modified to hide the connections. You may also want to run chkrootkit when booted from single user mode. Regards, Ricardo. > > I am not sure how no interpret this. I have checked logs, as well as > binary checks and everything "seems" fine. Can someone help me interpret > the logs. I will attach them at the tail of the email in case the may be > helpful. > > > I don't know what my next step would be. If in deed I have been 'rooted' > then I should obviously format and rebuild the server. > > Thanks in advance. > > Greg MEATPLOW > > # > #chkrootkit > > alpha:~# chkrootkit > ROOTDIR is `/' > Checking `amd'... not found > Checking `basename'... not infected > Checking `biff'... not found > Checking `chfn'... not infected > Checking `chsh'... not infected > Checking `cron'... not infected > Checking `date'... not infected > Checking `du'... not infected > Checking `dirname'... not infected > Checking `echo'... not infected > Checking `egrep'... not infected > Checking `env'... not infected > Checking `find'... not infected > Checking `fingerd'... not found > Checking `gpm'... not found > Checking `grep'... not infected > Checking `hdparm'... not found > Checking `su'... not infected > Checking `ifconfig'... not infected > Checking `inetd'... not infected > Checking `inetdconf'... not infected > Checking `identd'... not found > Checking `killall'... not found > Checking `ldsopreload'... not infected > Checking `login'... not infected > Checking `ls'... not infected > Checking `lsof'... not found > Checking `mail'... not infected > Checking `mingetty'... not found > Checking `netstat'... not infected > Checking `named'... not infected > Checking `passwd'... not infected > Checking `pidof'... not infected > Checking `pop2'... not found > Checking `pop3'... not found > Checking `ps'... not infected > Checking `pstree'... not found > Checking `rpcinfo'... not infected > Checking `rlogind'... not found > Checking `rshd'... not found > Checking `slogin'... not infected > Checking `sendmail'... not infected > Checking `sshd'... not infected > Checking `syslogd'... not infected > Checking `tar'... not infected > Checking `tcpd'... not infected > Checking `top'... not infected > Checking `telnetd'... not found > Checking `timed'... not found > Checking `traceroute'... not infected > Checking `write'... not infected > Checking `aliens'... > /dev/st- /dev/sto > Searching for sniffer's logs, it may take a while... nothing found > Searching for HiDrootkit's default dir... nothing found > Searching for t0rn's default files and dirs... nothing found > Searching for t0rn's v8 defaults... nothing found > Searching for Lion Worm default files and dirs... nothing found > Searching for RSHA's default files and dir... nothing found > Searching for RH-Sharpe's default files... nothing found > Searching for Ambient's rootkit (ark) default files and dirs... nothing > found > Searching for suspicious files and dirs, it may take a while... nothing > found > Searching for LPD Worm files and dirs... nothing found > Searching for Ramen Worm files and dirs... nothing found > Searching for Maniac files and dirs... nothing found > Searching for RK17 files and dirs... nothing found > Searching for Ducoci rootkit... nothing found > Searching for Adore Worm... nothing found > Searching for ShitC Worm... nothing found > Searching for Omega Worm... nothing found > Searching for Sadmind/IIS Worm... nothing found > Searching for MonKit... nothing found > Searching for anomalies in shell history files... nothing found > Checking `asp'... not infected > Checking `bindshell'... INFECTED (PORTS: 1524 31337) > Checking `lkm'... nothing detected > Checking `rexedcs'... not found > Checking `sniffer'... eth0 is not promisc > Checking `wted'... nothing deleted > Checking `z2'... > nothing deleted -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chkrootkit - possible bad news`
I am running Debian on a Dec Alpha PC164. I decided to run chkrootkit and was surprised by the following line. Checking `bindshell'... INFECTED (PORTS: 1524 31337) I am not sure how no interpret this. I have checked logs, as well as binary checks and everything "seems" fine. Can someone help me interpret the logs. I will attach them at the tail of the email in case the may be helpful. I don't know what my next step would be. If in deed I have been 'rooted' then I should obviously format and rebuild the server. Thanks in advance. Greg MEATPLOW ##### #chkrootkit alpha:~# chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected Checking `fingerd'... not found Checking `gpm'... not found Checking `grep'... not infected Checking `hdparm'... not found Checking `su'... not infected Checking `ifconfig'... not infected Checking `inetd'... not infected Checking `inetdconf'... not infected Checking `identd'... not found Checking `killall'... not found Checking `ldsopreload'... not infected Checking `login'... not infected Checking `ls'... not infected Checking `lsof'... not found Checking `mail'... not infected Checking `mingetty'... not found Checking `netstat'... not infected Checking `named'... not infected Checking `passwd'... not infected Checking `pidof'... not infected Checking `pop2'... not found Checking `pop3'... not found Checking `ps'... not infected Checking `pstree'... not found Checking `rpcinfo'... not infected Checking `rlogind'... not found Checking `rshd'... not found Checking `slogin'... not infected Checking `sendmail'... not infected Checking `sshd'... not infected Checking `syslogd'... not infected Checking `tar'... not infected Checking `tcpd'... not infected Checking `top'... not infected Checking `telnetd'... not found Checking `timed'... not found Checking `traceroute'... not infected Checking `write'... not infected Checking `aliens'... /dev/st- /dev/sto Searching for sniffer's logs, it may take a while... nothing found Searching for HiDrootkit's default dir... nothing found Searching for t0rn's default files and dirs... nothing found Searching for t0rn's v8 defaults... nothing found Searching for Lion Worm default files and dirs... nothing found Searching for RSHA's default files and dir... nothing found Searching for RH-Sharpe's default files... nothing found Searching for Ambient's rootkit (ark) default files and dirs... nothing found Searching for suspicious files and dirs, it may take a while... nothing found Searching for LPD Worm files and dirs... nothing found Searching for Ramen Worm files and dirs... nothing found Searching for Maniac files and dirs... nothing found Searching for RK17 files and dirs... nothing found Searching for Ducoci rootkit... nothing found Searching for Adore Worm... nothing found Searching for ShitC Worm... nothing found Searching for Omega Worm... nothing found Searching for Sadmind/IIS Worm... nothing found Searching for MonKit... nothing found Searching for anomalies in shell history files... nothing found Checking `asp'... not infected Checking `bindshell'... INFECTED (PORTS: 1524 31337) Checking `lkm'... nothing detected Checking `rexedcs'... not found Checking `sniffer'... eth0 is not promisc Checking `wted'... nothing deleted Checking `z2'... nothing deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: does chkrootkit properly detect a promisc interface?
Incoming from Jordan Lederman: > > While doing some normal system maintenance on a box of mine that primarily > runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing > out of the ordinary. Normally this is a good thing, but then I got to > thinking that if I am running snort, than I am in promiscuous mode and > chkrootkit should report so. So, what I've found is: There was a great hullabaloo on chkrootkit-users about two weeks ago regarding this. You should sheck the mailing list archives: http://marc.theaimsgroup.com/?l=chkrootkit-users -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: does chkrootkit properly detect a promisc interface?
Incoming from Jordan Lederman: > > While doing some normal system maintenance on a box of mine that primarily > runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing > out of the ordinary. Normally this is a good thing, but then I got to > thinking that if I am running snort, than I am in promiscuous mode and > chkrootkit should report so. So, what I've found is: There was a great hullabaloo on chkrootkit-users about two weeks ago regarding this. You should sheck the mailing list archives: http://marc.theaimsgroup.com/?l=chkrootkit-users -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
does chkrootkit properly detect a promisc interface?
While doing some normal system maintenance on a box of mine that primarily
runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
out of the ordinary. Normally this is a good thing, but then I got to
thinking that if I am running snort, than I am in promiscuous mode and
chkrootkit should report so. So, what I've found is:
chkrootkit runs /usr/lib/chkrootkit/ifpromisc to determine if an
interface is
in promisc mode.
If I run snort or tcpdump, i receive a message in my kernel log stating
that
the interface become promisc (device eth0 entered promiscuous mode)
however, /usr/lib/chkrootkit/ifpromisc does not report this.
If I 'ifconfig eth0 promisc' then /usr/lib/chkrootkit/ifpromisc does
report
that the interface is in promiscuous mode.
So, either I'm misunderstanding promiscuous mode, or
/usr/lib/chkrootkit/
ifpromisc isn't doing it's job. Can anyone shed light on this?
--jordan
does chkrootkit properly detect a promisc interface?
While doing some normal system maintenance on a box of mine that primarily
runs snort as an ids, I ran chkrootkit which ran cleanly, reporting nothing
out of the ordinary. Normally this is a good thing, but then I got to
thinking that if I am running snort, than I am in promiscuous mode and
chkrootkit should report so. So, what I've found is:
chkrootkit runs /usr/lib/chkrootkit/ifpromisc to determine if an interface is
in promisc mode.
If I run snort or tcpdump, i receive a message in my kernel log stating that
the interface become promisc (device eth0 entered promiscuous mode)
however, /usr/lib/chkrootkit/ifpromisc does not report this.
If I 'ifconfig eth0 promisc' then /usr/lib/chkrootkit/ifpromisc does report
that the interface is in promiscuous mode.
So, either I'm misunderstanding promiscuous mode, or /usr/lib/chkrootkit/
ifpromisc isn't doing it's job. Can anyone shed light on this?
--jordan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
[On 04 Dec, @07:24, Paul wrote in "Re: chkrootkit and linux 2.6 ..."] >I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 >processes possibly caused by LKM rootkit. I would have 69 processes >running with 42 of them owned by root. When I boot back to 2.4.23, it >comes up with the 4 mentioned in the bug. I'm no Linux master by any >means, but I'm just guessing that being owned by root is the kicker in >this instance. Either that, or I'm screwed ;) a 'chkrootkit -x lkm' was helpfull for me in this case - looks like the lkm test is fooled by threaded applications: xmms, named, etc... On my laptop killing X was enough the shut chkrootkit up: with X: 2 hidden processes without: none grtz Miek
Re: chkrootkit and linux 2.6
I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 processes possibly caused by LKM rootkit. I would have 69 processes running with 42 of them owned by root. When I boot back to 2.4.23, it comes up with the 4 mentioned in the bug. I'm no Linux master by any means, but I'm just guessing that being owned by root is the kicker in this instance. Either that, or I'm screwed ;) -Paul Norris
Re: chkrootkit and linux 2.6
[On 04 Dec, @07:24, Paul wrote in "Re: chkrootkit and linux 2.6 ..."] >I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 >processes possibly caused by LKM rootkit. I would have 69 processes >running with 42 of them owned by root. When I boot back to 2.4.23, it >comes up with the 4 mentioned in the bug. I'm no Linux master by any >means, but I'm just guessing that being owned by root is the kicker in >this instance. Either that, or I'm screwed ;) a 'chkrootkit -x lkm' was helpfull for me in this case - looks like the lkm test is fooled by threaded applications: xmms, named, etc... On my laptop killing X was enough the shut chkrootkit up: with X: 2 hidden processes without: none grtz Miek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
I see this same behavior with 2.6.0-test8. Chkrookit comes up with 42 processes possibly caused by LKM rootkit. I would have 69 processes running with 42 of them owned by root. When I boot back to 2.4.23, it comes up with the 4 mentioned in the bug. I'm no Linux master by any means, but I'm just guessing that being owned by root is the kicker in this instance. Either that, or I'm screwed ;) -Paul Norris
Re: chkrootkit and linux 2.6
[On 02 Dec, @20:56, David wrote in "Re: chkrootkit and linux 2.6 ..."] > > Right now chkrootkit gets lots of false positives regarding LKMs. There > was a pretty thorough discussion just a couple days ago so look through > the archive for the details: > http://lists.debian.org/debian-security/ ah, that explains it. (I hope) > So, its _probably_ a false alarm, but Using chkrootkit on RedHat (2.6.0-test9) didn't show anything wrong. Well, I really can not believe i'm rootedany it is really sucky that chkrootkit has a bug in this respect. thanks, grtz Miek
Re: chkrootkit and linux 2.6
On Wed, Dec 03, 2003 at 10:05:10AM +0100, Miek Gieben wrote: > I more and more start to think this is a bug in chkrootkit - on > busier systems more processes are hidded than on quiet systems. Sounds to me as a race condition: number of processes changes between the two checks. Indeed, in chkproc.c from chrootkit you can see that the checks are executed one after the other, and it's possible processes die or get forked between those checks. > I'll try it on 2.4 and see what happens, I get always 4 hidden processes on one 2.4.20 box, because: $ ps aux|head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1484 416 ?SApr10 0:09 init [2] root 2 0.0 0.0 00 ?SW Apr10 1:00 [keventd] root 3 0.0 0.0 00 ?SW Apr10 0:04 [kapmd] root 0 0.0 0.0 00 ?SWN Apr10 0:48 [ksoftirqd_CPU0] root 0 0.0 0.0 00 ?SW Apr10 69:16 [kswapd] root 0 0.0 0.0 00 ?SW Apr10 0:00 [bdflush] root 0 0.0 0.0 00 ?SW Apr10 0:12 [kupdated] root 9 0.0 0.0 00 ?SW Apr10 0:00 [khubd] root12 0.0 0.0 00 ?SW Apr10 56:49 [kjournald] $ Actually, these four processes are kernel processes... PID's are 4-7. and /proc/$PID do exist (only even root has no permission to read the cmd and exe symlinks, and cmdline is empty, fd inaccessable, etc) Possibly bug in ps (running testing/sarge)... But didn't research it further yet. --Jeroen -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl
Re: chkrootkit and linux 2.6
[On 03 Dec, @07:28, Hideki wrote in "Re: chkrootkit and linux 2.6 ..."] > Hi, > > Miek, if you are using kernel 2.6-test6 or newer, maybe not > worry about brk() bug. this kernel vulnerability effects under > 2.4.22 and 2.6-test5. I know, thanks. I'm running test11 right now and I closely followed the test releases starting from test6. I more and more start to think this is a bug in chkrootkit - on busier systems more processes are hidded than on quiet systems. I'll try it on 2.4 and see what happens, grtz Miek
Re: chkrootkit and linux 2.6
[On 02 Dec, @20:56, David wrote in "Re: chkrootkit and linux 2.6 ..."] > > Right now chkrootkit gets lots of false positives regarding LKMs. There > was a pretty thorough discussion just a couple days ago so look through > the archive for the details: > http://lists.debian.org/debian-security/ ah, that explains it. (I hope) > So, its _probably_ a false alarm, but Using chkrootkit on RedHat (2.6.0-test9) didn't show anything wrong. Well, I really can not believe i'm rootedany it is really sucky that chkrootkit has a bug in this respect. thanks, grtz Miek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
On Wed, Dec 03, 2003 at 10:05:10AM +0100, Miek Gieben wrote: > I more and more start to think this is a bug in chkrootkit - on > busier systems more processes are hidded than on quiet systems. Sounds to me as a race condition: number of processes changes between the two checks. Indeed, in chkproc.c from chrootkit you can see that the checks are executed one after the other, and it's possible processes die or get forked between those checks. > I'll try it on 2.4 and see what happens, I get always 4 hidden processes on one 2.4.20 box, because: $ ps aux|head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1484 416 ?SApr10 0:09 init [2] root 2 0.0 0.0 00 ?SW Apr10 1:00 [keventd] root 3 0.0 0.0 00 ?SW Apr10 0:04 [kapmd] root 0 0.0 0.0 00 ?SWN Apr10 0:48 [ksoftirqd_CPU0] root 0 0.0 0.0 00 ?SW Apr10 69:16 [kswapd] root 0 0.0 0.0 00 ?SW Apr10 0:00 [bdflush] root 0 0.0 0.0 00 ?SW Apr10 0:12 [kupdated] root 9 0.0 0.0 00 ?SW Apr10 0:00 [khubd] root12 0.0 0.0 00 ?SW Apr10 56:49 [kjournald] $ Actually, these four processes are kernel processes... PID's are 4-7. and /proc/$PID do exist (only even root has no permission to read the cmd and exe symlinks, and cmdline is empty, fd inaccessable, etc) Possibly bug in ps (running testing/sarge)... But didn't research it further yet. --Jeroen -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
[On 03 Dec, @07:28, Hideki wrote in "Re: chkrootkit and linux 2.6 ..."] > Hi, > > Miek, if you are using kernel 2.6-test6 or newer, maybe not > worry about brk() bug. this kernel vulnerability effects under > 2.4.22 and 2.6-test5. I know, thanks. I'm running test11 right now and I closely followed the test releases starting from test6. I more and more start to think this is a bug in chkrootkit - on busier systems more processes are hidded than on quiet systems. I'll try it on 2.4 and see what happens, grtz Miek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
Hi, Miek, if you are using kernel 2.6-test6 or newer, maybe not worry about brk() bug. this kernel vulnerability effects under 2.4.22 and 2.6-test5. in DSA-403, >This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and >2.6.0-test6 kernel tree. For Debian it has been fixed in version >2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 >kernel images and version 2.4.18-11 of the alpha kernel images. -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp
Re: chkrootkit and linux 2.6
Hi, Miek, if you are using kernel 2.6-test6 or newer, maybe not worry about brk() bug. this kernel vulnerability effects under 2.4.22 and 2.6-test5. in DSA-403, >This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and >2.6.0-test6 kernel tree. For Debian it has been fixed in version >2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 >kernel images and version 2.4.18-11 of the alpha kernel images. -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and linux 2.6
Right now chkrootkit gets lots of false positives regarding LKMs. There was a pretty thorough discussion just a couple days ago so look through the archive for the details: http://lists.debian.org/debian-security/ So, its _probably_ a false alarm, but -- David Ehle Computing Systems Manager CAPP CSRRI rm 077 LS Bld. IIT Main Campus Chicago IL 60616 [EMAIL PROTECTED] 312-567-3751 On Tue, 2 Dec 2003, Miek Gieben wrote: > Hello, > > When reading again about the (Debian) breakin, it said you should run > chkrootkit > to see if you have a rootkit installed. Well I did. But now it is complaining > about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then? > > I've checked the md5sums of some commands (ps, kill, ...) and they are equal > to the ones I just downloaded from a debian archive. > > I'm not subscribe to the list - so please cc me, > > thanks, > > grtz > Miek > -- > Serenity now! > -- Frank Costanza (Seinfeld) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: chkrootkit and linux 2.6
Right now chkrootkit gets lots of false positives regarding LKMs. There was a pretty thorough discussion just a couple days ago so look through the archive for the details: http://lists.debian.org/debian-security/ So, its _probably_ a false alarm, but -- David Ehle Computing Systems Manager CAPP CSRRI rm 077 LS Bld. IIT Main Campus Chicago IL 60616 [EMAIL PROTECTED] 312-567-3751 On Tue, 2 Dec 2003, Miek Gieben wrote: > Hello, > > When reading again about the (Debian) breakin, it said you should run chkrootkit > to see if you have a rootkit installed. Well I did. But now it is complaining > about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then? > > I've checked the md5sums of some commands (ps, kill, ...) and they are equal > to the ones I just downloaded from a debian archive. > > I'm not subscribe to the list - so please cc me, > > thanks, > > grtz > Miek > -- > Serenity now! > -- Frank Costanza (Seinfeld) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chkrootkit and linux 2.6
Hello, When reading again about the (Debian) breakin, it said you should run chkrootkit to see if you have a rootkit installed. Well I did. But now it is complaining about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then? I've checked the md5sums of some commands (ps, kill, ...) and they are equal to the ones I just downloaded from a debian archive. I'm not subscribe to the list - so please cc me, thanks, grtz Miek -- Serenity now! -- Frank Costanza (Seinfeld) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chkrootkit and linux 2.6
Hello, When reading again about the (Debian) breakin, it said you should run chkrootkit to see if you have a rootkit installed. Well I did. But now it is complaining about a LKM rootkit. But i'm running a 2.6 kernel, is this still valid then? I've checked the md5sums of some commands (ps, kill, ...) and they are equal to the ones I just downloaded from a debian archive. I'm not subscribe to the list - so please cc me, thanks, grtz Miek -- Serenity now! -- Frank Costanza (Seinfeld)
Re: chkrootkit and lkm
This one time, at band camp, Michael Parkinson said: > > Umm, I have the same problem. > > If I kill Exim and Spamassassin no hidden processes reported. > > Under normal load sometimes get 1-7 hidden processes. Was is a state of > panic but it does appear that Exim and Spamassassin combined do create false > positives. This is a known bug in chkrootkit - there is a race condition in the code such that on a relatively busy system (or a sluggish one), there is a difference in the ouput because of time lag - first it checks ps, then it checks /proc, and if they disagree, it reports. > Can this be fixed? Hopefully. It is irksome, but not the end of the world. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpdD7XzO6rNq.pgp Description: PGP signature
Re: chkrootkit and lkm
This one time, at band camp, Michael Parkinson said: > > Umm, I have the same problem. > > If I kill Exim and Spamassassin no hidden processes reported. > > Under normal load sometimes get 1-7 hidden processes. Was is a state of > panic but it does appear that Exim and Spamassassin combined do create false > positives. This is a known bug in chkrootkit - there is a race condition in the code such that on a relatively busy system (or a sluggish one), there is a difference in the ouput because of time lag - first it checks ps, then it checks /proc, and if they disagree, it reports. > Can this be fixed? Hopefully. It is irksome, but not the end of the world. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: chkrootkit and lkm
I'm not quite sure if i'm right .. but isn't there a kernel bug displaying some processes with PID 0 in ps or top. maybe lkm is using this.. just a thought greets Werner > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed I signature.asc Description: This is a digitally signed message part
Re: chkrootkit and lkm
I'm not quite sure if i'm right .. but isn't there a kernel bug displaying some processes with PID 0 in ps or top. maybe lkm is using this.. just a thought greets Werner > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed I signature.asc Description: This is a digitally signed message part
Re: chkrootkit and lkm
In article <[EMAIL PROTECTED]> you wrote: > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? it is a ps/kernel bug, try top. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: chkrootkit and lkm
Am Di, den 25.11.2003 schrieb Johannes Graumann um 21:18: > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed The same here (debian_sid): [EMAIL PROTECTED]:~# chkrootkit lkm ROOTDIR is `/' Checking `lkm'... You have 5 process hidden for ps command Warning: Possible LKM Trojan installed [EMAIL PROTECTED]:~# > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe related > to the server break ins? I do not think that it is a problem due to the compromised servers, because I noticed this on machines, which had been not updated since these serverhacks. I think this is a bug in the chkrootkit-package, although it has not been reported on the buglist. But please be carefull, it is only my opinion, I will not guarantee that the hack is not the cause of the problem ;) Greetz, Andre -- BOFH-excuse of the day: Traceroute says that there is a routing problem in the backbone. It's not our problem.
Re: chkrootkit and lkm
In article <[EMAIL PROTECTED]> you wrote: > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? it is a ps/kernel bug, try top. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and lkm
Am Di, den 25.11.2003 schrieb Johannes Graumann um 21:18: > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed The same here (debian_sid): [EMAIL PROTECTED]:~# chkrootkit lkm ROOTDIR is `/' Checking `lkm'... You have 5 process hidden for ps command Warning: Possible LKM Trojan installed [EMAIL PROTECTED]:~# > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe related > to the server break ins? I do not think that it is a problem due to the compromised servers, because I noticed this on machines, which had been not updated since these serverhacks. I think this is a bug in the chkrootkit-package, although it has not been reported on the buglist. But please be carefull, it is only my opinion, I will not guarantee that the hack is not the cause of the problem ;) Greetz, Andre -- BOFH-excuse of the day: Traceroute says that there is a routing problem in the backbone. It's not our problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: chkrootkit and lkm
Umm, I have the same problem. If I kill Exim and Spamassassin no hidden processes reported. Under normal load sometimes get 1-7 hidden processes. Was is a state of panic but it does appear that Exim and Spamassassin combined do create false positives. Can this be fixed? Mike Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit : > > I was just running 'chkrootkit' and came across this warning: > > > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed > > I have the same problem.. I believe it's a bug in chkrootkit > Do you stop the services before running chkrootkit? It can append that chkrootkit report false positive on machine still running services. I had the experience with exim. When I stop it I had no false positive... > > Michael > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: chkrootkit and lkm
Umm, I have the same problem. If I kill Exim and Spamassassin no hidden processes reported. Under normal load sometimes get 1-7 hidden processes. Was is a state of panic but it does appear that Exim and Spamassassin combined do create false positives. Can this be fixed? Mike Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit : > > I was just running 'chkrootkit' and came across this warning: > > > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed > > I have the same problem.. I believe it's a bug in chkrootkit > Do you stop the services before running chkrootkit? It can append that chkrootkit report false positive on machine still running services. I had the experience with exim. When I stop it I had no false positive... > > Michael > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: chkrootkit and lkm
Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit : > > I was just running 'chkrootkit' and came across this warning: > > > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed > > I have the same problem.. I believe it's a bug in chkrootkit > Do you stop the services before running chkrootkit? It can append that chkrootkit report false positive on machine still running services. I had the experience with exim. When I stop it I had no false positive... > > Michael >
RE: chkrootkit and lkm
Le mer 26/11/2003 à 01:17, Michael Bordignon a écrit : > > I was just running 'chkrootkit' and came across this warning: > > > > > Checking `lkm'... You have 4 process hidden for ps command > > > Warning: Possible LKM Trojan installed > > I have the same problem.. I believe it's a bug in chkrootkit > Do you stop the services before running chkrootkit? It can append that chkrootkit report false positive on machine still running services. I had the experience with exim. When I stop it I had no false positive... > > Michael > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and lkm
On Tue, Nov 25, 2003 at 06:42:21PM -0600, Adam Heath scribbled: [snip] > > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > > in existence that show a PID of 0. > > Am I right to assume that this is not the lkm kit, but rather some > > weiredness in PID assignment? > > > > The same PID thing is happening on my testing/unstable laptop - > > compromised as well or something else amiss in the distro, maybe related > > to the server break ins? > > Are you running 2.6, or the backported TLS patches on 2.4? it seems it's not only there. I think it's also the -aa kernels which show this behavior (that would include 2.4.23rcX). marek signature.asc Description: Digital signature
Re: chkrootkit and lkm
On Tue, Nov 25, 2003 at 06:42:21PM -0600, Adam Heath scribbled: [snip] > > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > > in existence that show a PID of 0. > > Am I right to assume that this is not the lkm kit, but rather some > > weiredness in PID assignment? > > > > The same PID thing is happening on my testing/unstable laptop - > > compromised as well or something else amiss in the distro, maybe related > > to the server break ins? > > Are you running 2.6, or the backported TLS patches on 2.4? it seems it's not only there. I think it's also the -aa kernels which show this behavior (that would include 2.4.23rcX). marek signature.asc Description: Digital signature
Re: chkrootkit and lkm
Thanks to everybody who was taking the time to sooth the novice ... ;0) Joh On Tue, 25 Nov 2003 12:18:35 -0800 Johannes Graumann <[EMAIL PROTECTED]> wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > > I did some reading and made sure the number is not changing (due to > running 'chkrootkit' while new processes are started and /proc and > 'ps' are not syncronized) - it remains 4. > I then went ahead and manually checked the output of 'ls -a /proc' > against that of 'ps -A' and found out, that there are 4 processes in > /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > in existence that show a PID of 0. > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe > related to the server break ins? > > Any comment is highly appreciated. > > Joh > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
Re: chkrootkit and lkm
Thanks to everybody who was taking the time to sooth the novice ... ;0) Joh On Tue, 25 Nov 2003 12:18:35 -0800 Johannes Graumann <[EMAIL PROTECTED]> wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > > I did some reading and made sure the number is not changing (due to > running 'chkrootkit' while new processes are started and /proc and > 'ps' are not syncronized) - it remains 4. > I then went ahead and manually checked the output of 'ls -a /proc' > against that of 'ps -A' and found out, that there are 4 processes in > /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > in existence that show a PID of 0. > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe > related to the server break ins? > > Any comment is highly appreciated. > > Joh > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and lkm
On Tue, 25 Nov 2003, Johannes Graumann wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > > I did some reading and made sure the number is not changing (due to > running 'chkrootkit' while new processes are started and /proc and 'ps' > are not syncronized) - it remains 4. > I then went ahead and manually checked the output of 'ls -a /proc' > against that of 'ps -A' and found out, that there are 4 processes in > /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > in existence that show a PID of 0. > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe related > to the server break ins? Are you running 2.6, or the backported TLS patches on 2.4? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and lkm
On Tue, 25 Nov 2003, Johannes Graumann wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > > I did some reading and made sure the number is not changing (due to > running 'chkrootkit' while new processes are started and /proc and 'ps' > are not syncronized) - it remains 4. > I then went ahead and manually checked the output of 'ls -a /proc' > against that of 'ps -A' and found out, that there are 4 processes in > /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There > are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) > in existence that show a PID of 0. > Am I right to assume that this is not the lkm kit, but rather some > weiredness in PID assignment? > > The same PID thing is happening on my testing/unstable laptop - > compromised as well or something else amiss in the distro, maybe related > to the server break ins? Are you running 2.6, or the backported TLS patches on 2.4?
RE: chkrootkit and lkm
> I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed I have the same problem.. I believe it's a bug in chkrootkit Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: chkrootkit and lkm
> I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed I have the same problem.. I believe it's a bug in chkrootkit Michael
Re: chkrootkit and lkm
On Tue, 2003-11-25 at 20:18, Johannes Graumann wrote:
[...]
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
[...]
> I then went ahead and manually checked the output of 'ls -a /proc'
> against that of 'ps -A' and found out, that there are 4 processes in
> /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There
> are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated)
> in existence that show a PID of 0.
> Am I right to assume that this is not the lkm kit, but rather some
> weiredness in PID assignment?
Yes. Well, rather to do with how `ps' handles the processes in question.
> The same PID thing is happening on my testing/unstable laptop -
> compromised as well or something else amiss in the distro, maybe related
> to the server break ins?
It's nothing at all to do with the compromise, and everything to do with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525> (`ps shows
incorrect pid value') and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278>
(`chkrootkit: doesn't work too well with kernel threads').
(FWIW, the bugs were filed 31 and 33 days ago, against procps and
chkrootkit respectively, and
http://bugs.debian.org/{procps,chkrootkit}> is currently
operational, although lacking a record of activity since late last
week.)
Your machine is behaving no more strangely than thousands of other
sarge/sid boxes. :-)
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and lkm
On Tue, Nov 25, 2003 at 12:18:35PM -0800, Johannes Graumann wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > (...) > > Any comment is highly appreciated. This is known bug in chkrootkit, it does not understand processes with pid '0' (kernel threads) which are not listed under /proc and emits this "alert". As a matter of fact it was reported previous to the compromise. Please check the following bugs for more information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 HTH Javi signature.asc Description: Digital signature
Re: chkrootkit and lkm
On Tue, 2003-11-25 at 20:18, Johannes Graumann wrote:
[...]
> I was just running 'chkrootkit' and came across this warning:
>
> > Checking `lkm'... You have 4 process hidden for ps command
> > Warning: Possible LKM Trojan installed
[...]
> I then went ahead and manually checked the output of 'ls -a /proc'
> against that of 'ps -A' and found out, that there are 4 processes in
> /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There
> are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated)
> in existence that show a PID of 0.
> Am I right to assume that this is not the lkm kit, but rather some
> weiredness in PID assignment?
Yes. Well, rather to do with how `ps' handles the processes in question.
> The same PID thing is happening on my testing/unstable laptop -
> compromised as well or something else amiss in the distro, maybe related
> to the server break ins?
It's nothing at all to do with the compromise, and everything to do with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525> (`ps shows
incorrect pid value') and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278>
(`chkrootkit: doesn't work too well with kernel threads').
(FWIW, the bugs were filed 31 and 33 days ago, against procps and
chkrootkit respectively, and
http://bugs.debian.org/{procps,chkrootkit}> is currently
operational, although lacking a record of activity since late last
week.)
Your machine is behaving no more strangely than thousands of other
sarge/sid boxes. :-)
Adam
Re: chkrootkit and lkm
On Tue, Nov 25, 2003 at 12:18:35PM -0800, Johannes Graumann wrote: > Hello, > > This is a testing/unstable system. > > I was just running 'chkrootkit' and came across this warning: > > > Checking `lkm'... You have 4 process hidden for ps command > > Warning: Possible LKM Trojan installed > (...) > > Any comment is highly appreciated. This is known bug in chkrootkit, it does not understand processes with pid '0' (kernel threads) which are not listed under /proc and emits this "alert". As a matter of fact it was reported previous to the compromise. Please check the following bugs for more information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 HTH Javi signature.asc Description: Digital signature
chkrootkit and lkm
Hello, This is a testing/unstable system. I was just running 'chkrootkit' and came across this warning: > Checking `lkm'... You have 4 process hidden for ps command > Warning: Possible LKM Trojan installed I did some reading and made sure the number is not changing (due to running 'chkrootkit' while new processes are started and /proc and 'ps' are not syncronized) - it remains 4. I then went ahead and manually checked the output of 'ls -a /proc' against that of 'ps -A' and found out, that there are 4 processes in /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) in existence that show a PID of 0. Am I right to assume that this is not the lkm kit, but rather some weiredness in PID assignment? The same PID thing is happening on my testing/unstable laptop - compromised as well or something else amiss in the distro, maybe related to the server break ins? Any comment is highly appreciated. Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chkrootkit and lkm
Hello, This is a testing/unstable system. I was just running 'chkrootkit' and came across this warning: > Checking `lkm'... You have 4 process hidden for ps command > Warning: Possible LKM Trojan installed I did some reading and made sure the number is not changing (due to running 'chkrootkit' while new processes are started and /proc and 'ps' are not syncronized) - it remains 4. I then went ahead and manually checked the output of 'ls -a /proc' against that of 'ps -A' and found out, that there are 4 processes in /proc (3-6) which don't show up as PIDs in the 'ps -A' output. There are however four processes (ksoftirqd_CPU0, kswapd, bdflush, kupdated) in existence that show a PID of 0. Am I right to assume that this is not the lkm kit, but rather some weiredness in PID assignment? The same PID thing is happening on my testing/unstable laptop - compromised as well or something else amiss in the distro, maybe related to the server break ins? Any comment is highly appreciated. Joh
Re: Another call for help regarding chkrootkit
Hello! Thanks to all for answering! Kind regards Matthias
Re: Another call for help regarding chkrootkit
Hi Matthias, >A reboot does not solve the problem. >I use an actual sid with kernel 2.4.22 from package >kernel-source- 2.4.22-3. Before PID 3 are starting >PID 1 init (of course) >and >PID 2 keventd > > >Does this look like a rootkit and what is to do? Did you see this post? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217278 -- Regards, Hideki Yamanemailto:henrich @ iijmio-mail.jp
Re: Another call for help regarding chkrootkit
> Does this look like a rootkit and what is to do? It's a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217525 top should display the processes correctly nico.
Another call for help regarding chkrootkit
Hello! I have got a problem with chkrootkit, too (refering to http:// lists.debian.org/debian-security/2003/debian-security-200310/msg00204.html): ai1:# chkrootkit -x lkm ROOTDIR is `/' ### ### Output of: ./chkproc -v -v ### PID 3: not in ps output CWD 3: / EXE 3: / PID 4: not in ps output CWD 4: / EXE 4: / PID 5: not in ps output CWD 5: / EXE 5: / PID 6: not in ps output CWD 6: / EXE 6: / You have 4 process hidden for ps command A reboot does not solve the problem. I use an actual sid with kernel 2.4.22 from package kernel-source- 2.4.22-3. Before PID 3 are starting PID 1 init (of course) and PID 2 keventd Does this look like a rootkit and what is to do? Thanks! - Matthias P.S.: /proc/X/status have following contents: Name: ksoftirqd_CPU0 State: S (sleeping) Tgid: 0 Pid:3 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: SigPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: CapEff: feff Name: kswapd State: S (sleeping) Tgid: 0 Pid:4 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: SigPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: CapEff: feff Name: bdflush State: S (sleeping) Tgid: 0 Pid:5 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: SigPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: CapEff: feff Name: kupdated State: S (sleeping) Tgid: 0 Pid:6 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: SigPnd: SigBlk: fff9 SigIgn: SigCgt: CapInh: CapPrm: CapEff: feff
