[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT
From: silvio@big.net.au
Date: 09/16/02
- Next message: silvio@big.net.au: "[Full-Disclosure] (no subject)"
- Previous message: silvio@big.net.au: "[Full-Disclosure] Re: C initialization of static objects (was: ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)"
- In reply to: Mikhail Iakovlev: "Re[2]: [Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Next in thread: Michal Zalewski: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Reply: Michal Zalewski: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: silvio@big.net.au (silvio@big.net.au) Date: Sun, 15 Sep 2002 15:23:11 -0700
On Sun, Sep 15, 2002 at 07:30:23PM +0200, Mikhail Iakovlev wrote:
> The whole /proc file system is virtual. In short it provides information about your computer configuration.
> Don't worry, it does not actually occupy your computer's resources, except some memory.
> And removing this file...hah, I'd love to see how you do it, since
> file is sort of linked to actual memory.
A "thing" I've seen in the past with bad attempts to disabling /dev/*mem
style things (for crappy honeypots presumeablely - dont worry, this was one
on one of of our own _development_ boxes for a while) -->
have the lseek file operation "not do anything" for those devices ;-)
/bin/cat works, but you try to do anything with lseek, and it doesnt work..
just seeks back to 0.
of course.. u can emulate an lseek with reading etc, since this also
updates the fpos..
-- ok.. so for the security enhanced Linux etc.. and for those chkrootkit programs (shell scripts?) --> a nice method to find "hidden" processes is to recognize that a process is a process id can be considered an exclusive resource that is available on request by anyone on the system. so the idea is to cycle through all the pid's, and see which ones you can't obtain. if at the same time you can view such a process in the regular listings.. something is interesting. in any case, it would appear that the task slot cannot be allocated for "some" reason(s). take it with a grain of salt.. but interesting none the less. note that on linux recycling the pid's goes back to 300.. a sysctl would be nice here to set this figure. -- bad forensics 404 --> sometimes a kernel rootkit will hijack the stat syscall.. maybe when doing an exec redirection, and it wants to keep the original stat's correct etc. i've seen use on occasion to compare the timestamps via stat syscall and through something like debugfs for example on the inode directly. looking for inconsistancies here are important to detect interesting oddities. yes, it does depend when the incore inode gets written back to disk, but this is useful anyway.. forensics ain't what I do a profession.. hey, i don't even work here! -- Silvio
- Next message: silvio@big.net.au: "[Full-Disclosure] (no subject)"
- Previous message: silvio@big.net.au: "[Full-Disclosure] Re: C initialization of static objects (was: ALERT ALERT ALERT! google under attack ALERT ALERT ALERT!)"
- In reply to: Mikhail Iakovlev: "Re[2]: [Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Next in thread: Michal Zalewski: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Reply: Michal Zalewski: "[Full-Disclosure] ALERT ALERT plaintext passwords in linux ALERT ALERT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
