[plug] Untraceable Process. Sys-Op Challenge
Timothy White
weirdo at tigris.org
Tue Feb 8 00:05:19 WST 2005
I have a small scenario for the system admin's out there (or any other
person that thinks they may be able to solve it.)
Please try and work out how to trace the untraceable process, it may hit
you one day soon.
Here it is:
You are a system admin of a small lab of Nix Boxes. They are all
connected via 100Mbit Ethernet and are also connected to the Campus
network. They authenticate over NIS and share home directorys over NFS.
As it is a programmers lab home directorys need to allow executables to
exists and run.
There are semi tight security restricts with the hope that most users
will follow rules. You suspect that one users is break the rules and
circumventing some security restrictions as well. As you walk past their
computer you notice a screen that confirms your suspicion that the user
is getting around some security restrictions.
You know that they are not going to reveal how they do it so you decided
to attempt to find out what they are doing before you confront them.
After walking past a few more times you get a glimpse of an address of a
local server that they are logged into. Due to the fact that all of the
programming can be done on the local computer and NFS is running, there
is no need for any user to log into the server so you know that this is
where they are getting past security.
You log into the server:
---
$ who
tim pts/2 Feb 7 23:21 (linmedia:S.0)
luser pts/4 Feb 7 23:32 (nix3.eng.lab.domain)
--- You see that they are logged in. (luser)
$ ps aux |grep luser
luser 5048 0.5 3.4 3176 2092 pts/4 Ss+ 23:32 0:00 -bash
luser 5078 0.4 5.0 4664 3132 pts/4 S 23:32 0:00 perl
server.pl
tim 5162 0.0 0.7 1496 448 pts/2 S+ 23:34 0:00 grep luser
--- You can see that the process you want is a perl script called server.pl
$ su
Password:
--- You change to root so you can get into his home dir
# cd /home/luser
# ls
...
--- You see a jumble of files. You can't immediately see the one you want.
# find /home/luser |grep server.pl
--- Shows nothing
# find / |grep server.pl
--- Also shows nothing
# vdir /proc/5078/
total 0
-r--r--r-- 1 luser luser 0 Feb 7 23:39 cmdline
lrwxrwxrwx 1 luser luser 0 Feb 7 23:39 cwd -> /tmp
-r-------- 1 luser luser 0 Feb 7 23:39 environ
lrwxrwxrwx 1 luser luser 0 Feb 7 23:39 exe -> /usr/bin/perl
dr-x------ 2 luser luser 0 Feb 7 23:39 fd
-r--r--r-- 1 luser luser 0 Feb 7 23:39 maps
-rw------- 1 luser luser 0 Feb 7 23:39 mem
lrwxrwxrwx 1 luser luser 0 Feb 7 23:39 root -> /
-r--r--r-- 1 luser luser 0 Feb 7 23:39 stat
-r--r--r-- 1 luser luser 0 Feb 7 23:39 statm
-r--r--r-- 1 luser luser 0 Feb 7 23:39 status
--- Shows that the file should be in /tmp. It's not.
To make things worse, after killing the process the luser can still
start it again.
Then, to make matters worse, you take it up a notch.
You check their crontab, empty. You read their mail, none their.
---
# crontab -u luser -l
no crontab for luser
# mail -u luser
No mail for luser
---
You set up a script to monitor logins and alert you when they login. For
the sake of it you also set up a script to monitor process and alert you
when they have running processes.
10 Minutes after you kill their process it starts again. No login.
You start checking the system again.
---
# ps aux |grep luser
luser 5620 0.1 4.9 4660 3044 ? S 23:44 0:00 perl
server.pl
root 5858 0.0 0.7 1496 448 pts/2 S+ 23:50 0:00 grep luser
--- You check their bash_history
#cat /home/luser/.bash_history
...
--- Nothing except for the class work that they are doing (remember that
it is home over NFS)
Well. That should leave most of you stumped. I could have stopped after
checking /proc but decided that someone out there would think of looking
in .bash_history. Oh, and if you think this is impossible then think
again; I had a good 6 hours to think about this while I was cooking KFC
today.
If you can find a flaw then please tell me, I have this system working
and can test it as much as needed.
/Nothing/ in the above has been modified, it is all real commands and
real output. Server.pl is a simple perl script that daemonises it's self
and waits for connections on port 9000.
The actual scenario hasn't happened although a similar one has happened
before to me. Basically though the sys-op knew lab students were getting
past the firewall and took control of my computer when he saw me
browsing the unreachable web. Back then though I worked as a team so my
other team member logged into the server and I was saved by quick typing
rather than untraceable processes. (It took the sys-op a while to
actually work out we were using a remote server to do the work rather
than local machines as it made it easier for us to work as a team.)
Being the good boy I am, I fully explain the security hole and how we
managed to exploit it to the sys-op when we left, I also ensured that no
damage was done.
Oh, one last clue. /home didn't need to be allowed to execute programs
in this instance as the process was a perl script. I believe that unless
the user has access to a partition that allows the execute bit on
programs as well as allowing the user to write to a directory on the
partition then they can't use a normal executable/s. So basically there
is nothing happening here that the user can't do normally except they
are hiding the program and covering all steps thoroughly without
stopping them quickly and easily restarting the program.
Tim
--
Tim White - Use the Fox, Luke!
PGP/GPG id: 602E944D, Pub Key Serv: subkeys.pgp.net
Fingerprint: 04C2 9682 B7B2 3006 009D A9F3 067E EDCD 602E 944D
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20050208/99e75b15/attachment.pgp>
More information about the plug
mailing list