Hi all, had an attack attempt a few days ago via the kstatd, but it seemed to me it wasn't successfull. I did an netstat -p to check and got the following: (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) But I was root! My question now is, is this a standard comment of netstat or is there a "hidden" program running, which even root can't see (e.g. some trojan horse)? Thanks in Advance Martin -- ------------------------------------- Martin Geigl Universitaet Greifswald Institut fuer Physik Domstr. 10a 17489 Greifswald Tel.: +49-3834-864756 Fax: +49-3834-864701 -------------------------------------
Hi On Tue, Dec 05, 2000 at 12:38:20PM +0100, Martin Geigl wrote:
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
But I was root! My question now is, is this a standard comment of netstat or is there a "hidden" program running, which even root can't see (e.g. some trojan horse)? alex@joker:~# strings $(which netstat ) | egrep "(processes|shown)" (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
So, this string is definitely included in the netstat binary. However you cannot be sure whether you weren't compromised. What you could is to compile a new (best case is static) binary of netstat (better is lsof :)), to copy it to the system and execute it (like lsof -i) to check if the system has been trojaned. However this behaviour is not normal, if you have an idea why this is spit out though you are root, mail it to the list. MfG/Regards, Alexander -- Alexander Reelsen http://joker.rhwd.de ref@linux.com GnuPG: pub 1024D/F0D7313C sub 2048g/6AA2EDDB ar@rhwd.net 7D44 F4E3 1993 FDDF 552E 7C88 EE9C CBD1 F0D7 313C Securing Debian: http://joker.rhwd.de/doc/Securing-Debian-HOWTO
On Tue, 5 Dec 2000, Martin Geigl wrote:
Hi all,
had an attack attempt a few days ago via the kstatd, but it seemed to me it wasn't successfull. I did an netstat -p to check and got the following:
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
But I was root! My question now is, is this a standard comment of netstat or is there a "hidden" program running, which even root can't see (e.g. some trojan horse)?
AFAIK it just means what it says: netstat can't identify all running processes. Maybe not the best choice of words, but no trojan causing it. If you're afraid you've been hacked, check out CERT's checklist (www.cert.org). It has a number of steps you can check. For instance checking the md5sum of ps, ls etc.
Thanks in Advance Martin --
Stefan
The message just indicates that netstat can't determine the name of the process - you are probably fine. Try cross checking the output of "ps axfu" as root with the output of "netstat -ap", also as root netstat will (or should) give you the PIDs even when it can't identify the process by name. "ps axfu" will give you a list of running processes (by name and PID). You can then check the PIDs that netstat can't identify with the list that ps prints out. To verify an installed package against a RPM, use: rpm -Vp packagename.rpm execute this from the directory the rpm package is in (i.e. from /cdrom/suse/a1 or whatever). If nothing is printed out, this indicates that everything is ok. 5 indicates that the MD5 checksum does not check S indicates that the file size does not check if either (or both) is returned, suspect a problem. Use "man rpm" for more information, and try http://www.rpm.org for even more information. To determine what package a particular file came from, use: rpm -qf /path/to/file for netstat, it would be rpm -qf /bin/netstat for example. Burning updated packages onto CD-R discs is a Really Good Idea. If you do this, you have some assurance that the rpm package you are using to verify the installed files has not been altered. John
The message just indicates that netstat can't determine the name of the process - you are probably fine.
Try cross checking the output of "ps axfu" as root with the output of "netstat -ap", also as root
Or just run lsof and look for the connections =).
netstat will (or should) give you the PIDs even when it can't identify the process by name. "ps axfu" will give you a list of running processes (by name and PID). You can then check the PIDs that netstat can't identify with the list that ps prints out.
To verify an installed package against a RPM, use:
rpm -Vp packagename.rpm
This of course is trivial for an attacker to circumvent, the RPM database is not really protected at all.
execute this from the directory the rpm package is in (i.e. from /cdrom/suse/a1 or whatever). If nothing is printed out, this indicates that everything is ok.
Ok that's a little better but still an attacker can beat it (replace the rpm binary for example).
Burning updated packages onto CD-R discs is a Really Good Idea. If you do this, you have some assurance that the rpm package you are using to verify the installed files has not been altered.
This is why the packages should all by GnuPG signed. Then as long as no-one tampers with the rpm binary or root's keyring you can keep the binaries at ftp.badcrackerz.org and still easily verify that they haven't been modified.
John
-Kurt
Well, I actually enjoyed the original response from John. He is taking the effort to explain instead of complain. He also goes back to the core of matters (ps and netstat are just that, lsof is not). He advises to use a CD as a hash-key-reference and as such is making perfect sense. You rather failed to explain the shortcoming of that approach. If you still feel this is unsatisfactorily we would very much appreciate the rationale and the real-life, practical (command-line-options-and-all) alternative to the one proposed. Kurt Seifried wrote:
The message just indicates that netstat can't determine the name of the process - you are probably fine.
Try cross checking the output of "ps axfu" as root with the output of "netstat -ap", also as root
Or just run lsof and look for the connections =).
netstat will (or should) give you the PIDs even when it can't identify the process by name. "ps axfu" will give you a list of running processes (by name and PID). You can then check the PIDs that netstat can't identify with the list that ps prints out.
To verify an installed package against a RPM, use:
rpm -Vp packagename.rpm
This of course is trivial for an attacker to circumvent, the RPM database is not really protected at all.
execute this from the directory the rpm package is in (i.e. from /cdrom/suse/a1 or whatever). If nothing is printed out, this indicates that everything is ok.
Ok that's a little better but still an attacker can beat it (replace the rpm binary for example).
Burning updated packages onto CD-R discs is a Really Good Idea. If you do this, you have some assurance that the rpm package you are using to verify the installed files has not been altered.
This is why the packages should all by GnuPG signed. Then as long as no-one tampers with the rpm binary or root's keyring you can keep the binaries at ftp.badcrackerz.org and still easily verify that they haven't been modified.
To verify an installed package against a RPM, use:
rpm -Vp packagename.rpm
This of course is trivial for an attacker to circumvent, the RPM database is not really protected at all.
Burn it on a CD-R along with your tripwire database as soon as you have installed and configured your system, but before you bring up the network connections or allow anyone to log in on the console. And make sure no hacker can swap the CD-R around for one of his own making after compromising your system... :o) Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
This of course is trivial for an attacker to circumvent, the RPM database is not really protected at all.
Burn it on a CD-R along with your tripwire database as soon as you have installed and configured your system, but before you bring up the network connections or allow anyone to log in on the console. And make sure no hacker can swap the CD-R around for one of his own making after compromising your system... :o)
Cheers! Yuri.
I used to have the plaintext file databases lying around in the system,
hidden a bit so that it isn't obvious that it's a bait. The encrypted file
was somewhere else on the system. A simple diff over the two files
revealed what could have been tempered around with. Came very handy at
times...
Roman.
--
- -
| Roman Drahtmüller
Burn it on a CD-R along with your tripwire database as soon as you have installed and configured your system, but before you bring up the network Well you could also use fcheck personally I find it much better than tripwire I then run fcheck -a from my cron and voila everyday I get a report of changes to my system.
*grin* Don't you just love admins who do this!!!!! When we do penetration tests, often we just disable fcheck or tripwire entirely, and run a script from cron that mails a random "good" report every day to the admin, it is rarely if ever noticed. At least it's never noticed b4 we deliver the report, and I've heard of systems in the "wild" who have had this done to them indefinitely. At a minimum it gives you a chance to trojanise the backups for an extended period of time. As for the statement that someone made about using a non modular kernel, it is not necessary to have a modular capable kernel to load a trojan "module" Nix At 11:46 AM 6/12/2000 +0300, you wrote:
Burn it on a CD-R along with your tripwire database as soon as you have installed and configured your system, but before you bring up the network Well you could also use fcheck personally I find it much better than tripwire I then run fcheck -a from my cron and voila everyday I get a report of changes to my system.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
From http://securityportal.com/topnews/weekly/linux20001120.html crom - The version of Vixie Cron shipped with Debian GNU/Linux 2.2 is vulnerable to a local attack, discovered by Michal Zalewski. Several problems, including insecure permissions on temporary files and race conditions in their deletion, allowed attacks from a denial of service (preventing the editing of crontabs) to an escalation of priviledge (when another user edited their crontab). As a temporary fix, "chmod go-rx /var/spool/cron/crontabs" prevents the only available exploit; however, it does not address the problem. We recommend upgrading to version 3.0pl1-57.1, for Debian 2.2, or 3.0pl1-61, for Debian unstable. Also, in the new cron packages, it is no longer possible to specify special files (devices, named pipes, etc.) by name to crontab. Note that this is not so much a security fix as a sanity check. This is the most recent one that pops to mind (about 2 weeks old). Kurt Seifried, seifried@securityportal.com SecurityPortal - your focal point for security on the 'net
netstat cannot identify rpc services presented by the kernel. Check rpcinfo -p. This should account for the unidentified ports. &:-) 'Twas 12:38 Yesterday when Martin Geigl spake thus:
Hi all,
had an attack attempt a few days ago via the kstatd, but it seemed to me it wasn't successfull. I did an netstat -p to check and got the following:
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
But I was root! My question now is, is this a standard comment of netstat or is there a "hidden" program running, which even root can't see (e.g. some trojan horse)?
Thanks in Advance Martin
-- Deadbat Dustbian LuSE Hackware Also-randrake Line Ucks Lean Ucks Loon Icks Lynne Nicks free, dim (two chews)
netstat cannot identify rpc services presented by the kernel. Check rpcinfo -p. This should account for the unidentified ports.
Yeah, RPC is especially annoying since the ports have a tendancy to change sometimes. RPC is evil and should be turned off anyways (unless you absolutely must have it).
&:-)
Kurt Seifried, seifried@securityportal.com SecurityPortal - your focal point for security on the 'net
participants (11)
-
Alexander Reelsen -
andrew＠ledge.co.za -
John Pinder -
Kurt Seifried -
Martin Geigl -
Nix -
Peter van den Heuvel -
Roman Drahtmueller -
semat -
Stefan Suurmeijer -
Yuri Robbers