From: Lachniet, Mark (mlachniet@sequoianet.com)
Date: Thu Jul 07 2005 - 08:36:33 EDT
It is far from convenient, but you can use the strace command to monitor
all of the keystrokes of any shell on a box where you have root.
For example 'strace /bin/sh' then you will see the program behavior,
including text like the following:
read(0, "a", 1) = 1
write(2, "a", 1a) = 1
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
read(0, "b", 1) = 1
write(2, "b", 1b) = 1
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
read(0, "c", 1) = 1
write(2, "c", 1c) = 1
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
You could then run a grep command on the output to filter only those
lines that contain "read", use some sed and column breaking, and write a
script to output the text as a log.
This is a handy way of tracking what hackers are doing on a box without
any previous setup of a logger. You can also use strace to trace an
existing process that you didn't spawn yourself using the -p <pid>
option
Mark Lachniet
> -----Original Message-----
> From: Chuck [mailto:chuck.lists@gmail.com]
> Sent: Wednesday, July 06, 2005 5:11 PM
> To: pen-test@securityfocus.com
> Subject: Re: Keystroke logging
>
> The approach that I use is to set my bash prompt to include
> the time and date and then run everything in a screen
> session. Screen has the ability to log everything typed on
> command lines and all output using it's -L command line
> option. I really like having the output along with the
> commands typed, the log is handy to refer to when writing up
> findings. You also get the added ability of being able to
> detach from a long running command without killing it.
>
> Screen won't record what happens within a vi session (or
> other interactive console program), but if I edit a file, I
> just cat it afterwards so that the edited version is included
> in the log. I do the same thing with any files full of IPs
> to scan, shell scripts, and the like.
>
> Chuck
>
> On 7/1/05, Aaron J. Bedra <abedra@westervillelibrary.org> wrote:
> > Something to think of,
> >
> > Yes, most shells have keylogging built in, but most
> pen-test reports
> > require you to not only provide keylogging, but also timestamps
> > (depending on where you are working, sometimes in UTC
> format), or they
> > are not accepted as real logs.
> >
> > Aaron J. Bedra
> >
> >
> > On Fri, 2005-07-01 at 11:41 +0200, Guillaume Vissian wrote:
> > > Be carefull the history logs only show the common
> commands input on
> > > the shell, this didn't show everything wrappen on it. Only
> > > keyloggers can do that. If history remember all it would
> be a major
> > > security failure... For example with shells history logs
> you can't
> > > see the vim editing sequences, and for sure the password entries.
> > > And the real, and only for me, utility of a keylogger is
> to log thoses pass entries.
> > > A good keylogger have to, in my mind, be directly
> implanted in the
> > > kernel, the shells let to much ways to escape from the logs...
> > > A way to search :
> > > http://linux.ittoolbox.com/documents/document.asp?i=2284
> > >
> > > Google is your friend
> > > G.
> > >
> > > 2005/7/1, Joshua Hamor <josh@cnemedia.com>:
> > > > Agreed. Most modern shells have history logs. You
> should be able
> > > > to save this text file for your tests.
> > > >
> > > > -J also
> > > >
> > > > Jeff Miller wrote:
> > > > > I've used bash shell logging before for similar situations.
> > > > > just grab the source and compile with the syslogging option.
> > > > >
> > > > >
> > > > > On Jun 30, 2005, at 2:36 PM, JB wrote:
> > > > >
> > > > >> I'm wondering if anyone has either a kernel level keystroke
> > > > >> logger for the Linux 2.6, or a userspace keystroke
> logger for
> > > > >> Linux. As part of our penetration testing, we are
> required to
> > > > >> give the client a log of all actions performed - so
> this would
> > > > >> be a good way of logging all linux commands. Also -
> if you know
> > > > >> of the same sort of tool for windows - that would also be
> > > > >> appreciated.
> > > > >>
> > > > >> -J
> > > > >>
> > > > >>
> > > > >
> > > >
> >
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:31 EDT