full-disclosure - ALERT ALERT plaintext passwords in linux ALERT ALERT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20020915152311.B813@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: ALERT ALERT plaintext passwords in linux ALERT ALERT

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