Hacking Challenges: A Training Tool
I'm a big fan of security challenges, mainly because they help to improve your security skills without the risk and presure of being involved in a real incident. They are a marvelous training tool!
At the begining of the 2006 summer, Ethical Hacker started to promote a series of bi-monthly security challenges, called the Skillz H@ck1ng Challenge. The second one, developed by Mike Poor, was called "Hack Bill!". This challenge was focused on Unix, specifically, on how to use sudo properly, common file hidding and sniffing techniques in Linux, and introduced an evil usage of Bill Stearns' apptrace tool to capture SSH and GnuPG credentials on Linux.
You can find my submission in this veeeerrryy loooong post. Before reading it, I encourage you to read the challenge and try to solve it. Having participated and judged several security challenges, I'm aware that the scores are subjective and directly conditioned by the jury preferences... so, I didn't win this time, and sincerely, I don't know why
P.S. Judge it by yourself and contact Mike to change his mind and, specially, properly evaluate the countermeasures section! Perhaps, he got fascinated about the winner mentioning Sebek in his answer
BTW, the September challenge, Netcat in the hat, has been published. Unfortunately, I won't be able to participate this time.
Security Challenge: "Hack Bill" (July 2006) by Raul Siles (www.raulsiles.com)
ACKS: Thanks to Eric and Monica for being as you are! Life is terrific with you!
1. How can you restrict sudo to specific commands for specific users?
Sudo (superuser do) [1] allows a system administrator to give specific users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments. Sudo restrictions to specific commands for specific users can be applied through the "/etc/sudoers" configuration file. Each line specifies:
Where "Username" can run the list of "Commands" as the users in "Run_as" in all these "Hostnames". For example, the following Sudo specification only allows "cottonmouth" to run the "/usr/bin/passwd" command as "operator" in the "snakepit" host.
Sudo management and setup tasks can be simplified defining aliases to group multiple users (User_Alias), run as users (Runas_Alias), hosts (Host_Alias) and commands (Cmnd_Alias). The file also can contain default settings and the specifications reflecting the system Sudo policy. More details are available at [2].
The Squad's shell server has a very permisive configuration, allowing 7 different users to run anything on any machine as any user, "ALL=(ALL) ALL".
2. What does O-ren do immediately after starting her sniffer? Why? How can a sysadmin find that file on the box? How can O-ren recover her sniffer file?
After running the sniffer with the "tcpdump -nnw " " &" command (PID 4371), O-ren executed:
This command lists the inode number of the " " sniffer output file. The inode is the unique numeric representation of any object (file, directory...) in a Unix filesystem, in this case 97314.
This command deletes the " " file *name* (directory entry) from the filesystem. Due to the fact the " " name was the last link to the "tcpdump" PCAP output file but, the "tcpdump" process is still running and have the file open, the file (including the disk space it is using) will remain in existence. It will be available until the last file descriptor referring to it is closed, that is, once the "tcpdump" process finishes.
NOTE: Please, see "Appendix A" for additional comments on the challenge output.
O-ren run the 2nd command in order to delete the file from the standard Unix tools perspective, such as "ls, find...", so that the administrator cannot find this potentially suspicious file used to save all the network traffic captured. The 1st command will let him to recover the file contents through the inode number.
A sysadmin can find the file on the box using the Unix "lsof" tool [3]. The command "lsof +L1" lists all the system unlinked files, that is files with a link count less than 1 (+L1) or "NLINK" equal to zero. This would be the output obtained by the administrator when running this tool on "snakepit":
O-ren can recover the sniffer file using Unix standard commands:
First, O-ren needs to stop the "tcpdump" process from writting more data to the " " output file, trying to avoid recovering a corrupted PCAP file.
Second, O-ren needs to know what is the file descriptor (fd) pointing to the file from the "tcpdump" process perspective. This information is available through the Unix "/proc" pseudo-filesystem. In this case, the process is using fd 4 to point to the " " file.
Finally, O-ren simply copies the file contents indicating the file descriptor (fd) used by the "tcpdump" process to reference the file, to a new file, called "/tmp/snakepit.pcap".
3. How did O-ren get Bill’s passwords for ssh and gpg? What can Bill do to safeguard his gpg-protected information from such attacks?
First, O-ren transferred Bill Stearn's "apptrace" [4] Unix script to the system using "netcat" [5]. It set the execution permission bits on the transferred file and run the tool to get details (see bellow) associated to any SSH client invocation, "/usr/sbin/ssh":
The "apptrace" tool records the last time the application specified as the first argument ran ("$APPNAME-last-run" file), the command-line switches involved ("$APPNAME-parameters" file) and it uses the "strace" Unix tool to monitor the kernel system calls invoked by the running application. The information is stored in the output directory, called "$HOME/apptrace" (or "/tmp/apptrace" if there is no $HOME variable defined).
NOTE: $APPNAME (in the output filenames) is the name of the application used in the first argument, in this case, "ssh".
When the "apptrace" script is executed it replaces the binary file of the command specified as the first argument by the "apptrace" script itself, and saves a copy of the original binary as ".orig", in this case "/usr/sbin/ssh.orig".
The new "binary" file ("/usr/sbin/ssh", now the "apptrace" script) simply calls "strace" with the "-f -o" options (follow process forks and output to a file) and traces the original binary, now called "ssh.orig":
The next time the "binary" (ssh) runs, "strace" collects all the system calls performed by it, including the reads syscalls associated to the password input, called after showing the SSH "Password:" prompt.
The same kind of attack was used to gather Bill's GPG passphrase. O-ren run a command like:
When Bill invoked "gpg", all the system calls used by this binary were collected, including the reads syscalls associated to the passphrase input, called after showing the GPG "Enter passphrase:" prompt.
Bill can safeguard his gpg-protected information from such attacks following the following countermeasures:
First of all, not allowing any other user (local or remote) to obtain root privileges. The passwords were obtained through the "strace" tool, and in order to run it you need to be root. In this scenario O-ren got root access due to the unsecure configuration of the Sudo tool in both systems (that specifically allowed him to run the "su -" command):
Therefore, it is recommended to restrict Sudo usage following the details of question 1. However, this is not the only way to become root in a Unix system, so it is recommended to harden the box as much as possible so that it's not possible to take advantage of any other exploit (local or remote) to scalate privileges.
In the second place, O-ren got access to the second system by gathering Bill's SSH password. If Bill would have used digital certificates to authenticate via SSH to the second system (instead of the username and password authentication mechanism), the attack would have been more difficult to achieve (although still feasible capturing the kernel system calls).
Additionally, the "apptrace" tool works by replacing critical system binary files. Having some kind of host or file integrity checker, such as Tripwire [6] or AIDE [7], would have help to detect the forgery prior to invoking the replaced commands, "ssh" and "gpg". Besides, having some kind of host-based intrusion detection capabilities, even a home-made one running the "lsof" command of question 2 periodically, would have helped to detect anomalous behaviours, such as unlinked files, that could have alerted Bill about O-ren's actions and the compromise.
In order to decrypt the PGP armored "okunote" file, the user private key is required (together with the passphrase protecting this key). If Bill would have kept this file out of the box, such as in a USB stick, O-ren wouldn't had be able to get the file contents. This method is known as two-factor authentication, something you know (the passphrase) and something you have, the USB thumbdrive containing the private key. The only vulnerable timeframe is when the USB drive is plugged into the system, but this drastically reduce the time of exposure to the attack presented. The same idea applies if digital certificates are used to authenticate via SSH.
Lastly, the "gpg: Warning: using insecure memory!" warning message displayed by the "gpg" program [8] means that the binary is running without setuid, therefore, it is not locking memory pages. In this scenario, the OS can write the "gpg" memory pages containing the secret keys to disk during its memory management tasks. This secret information on disk could be potentially accessed by an intruder (this method was not used by O-ren).
4. For extra credit: what is the meaning behind snakecharmer’s passwords?
Snakecharmer’s passwords are the hexadecimal ASCII representation [9] of the letters of two different words:
ASCII translation: "otaku".
Otaku refers to a variety of geek obsessed with anime and manga. In Japanese this term has negative connotations, although in English can have positive or negative connotations (specially in Internet forums) [10].
ASCII translation: "Bill".
"Hack Bill!" ;-)
- REFERENCES:
[1] Sudo:
http://www.courtesan.com/sudo/ (Unix)
http://sudowin.sourceforge.net (Windows)
[2] Sudo manual page:
# man sudoers
[3] Lsof:
http://freshmeat.net/projects/lsof/
[4] Apptrace:
http://www.stearns.org/apptrace/
http://www.stearns.org/doc/apptrace.v0.1.html
[5] Netcat:
http://www.vulnwatch.org/netcat/
[6] Tripwire:
http://www.tripwire.com
http://sourceforge.net/projects/tripwire/
[7] AIDE:
http://sourceforge.net/projects/aide
[8] GPG memory warning message:
http://www.gnupg.org/documentation/faqs.html#q6.1
[9] ASCII table:
http://www.lookuptables.com
[10] Wikipedia:
http://en.wikipedia.org/wiki/Otaku
- Appendix A:
The challenge output shows how O-ren run the sniffer:
O-ren created a " " directory and inside it a " " file (inode: 97314) where the sniffer output was saved. However, after running the "tcpdump" command he didn't change the directory location although the command prompt seems to indicate that he did, because he is at "/home/cottonmouth" instead of at "/home/cottonmouth/ ".
If I'm not wrong, the command prompt should contain a final "/ " for the last 2 commands, or a "cd .." should have been executed after the "tcpdump" command:
For the challenge answers I have considered that the "/ " was missing and only the PCAP file was unlinked.
At the begining of the 2006 summer, Ethical Hacker started to promote a series of bi-monthly security challenges, called the Skillz H@ck1ng Challenge. The second one, developed by Mike Poor, was called "Hack Bill!". This challenge was focused on Unix, specifically, on how to use sudo properly, common file hidding and sniffing techniques in Linux, and introduced an evil usage of Bill Stearns' apptrace tool to capture SSH and GnuPG credentials on Linux.
You can find my submission in this veeeerrryy loooong post. Before reading it, I encourage you to read the challenge and try to solve it. Having participated and judged several security challenges, I'm aware that the scores are subjective and directly conditioned by the jury preferences... so, I didn't win this time, and sincerely, I don't know why
P.S. Judge it by yourself and contact Mike to change his mind and, specially, properly evaluate the countermeasures section! Perhaps, he got fascinated about the winner mentioning Sebek in his answer
BTW, the September challenge, Netcat in the hat, has been published. Unfortunately, I won't be able to participate this time.
Security Challenge: "Hack Bill" (July 2006) by Raul Siles (www.raulsiles.com)
ACKS: Thanks to Eric and Monica for being as you are! Life is terrific with you!
1. How can you restrict sudo to specific commands for specific users?
Sudo (superuser do) [1] allows a system administrator to give specific users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments. Sudo restrictions to specific commands for specific users can be applied through the "/etc/sudoers" configuration file. Each line specifies:
Username Hostname = (Run_as) Commands
Where "Username" can run the list of "Commands" as the users in "Run_as" in all these "Hostnames". For example, the following Sudo specification only allows "cottonmouth" to run the "/usr/bin/passwd" command as "operator" in the "snakepit" host.
cottonmouth snakepit = (operator) /usr/bin/passwd
Sudo management and setup tasks can be simplified defining aliases to group multiple users (User_Alias), run as users (Runas_Alias), hosts (Host_Alias) and commands (Cmnd_Alias). The file also can contain default settings and the specifications reflecting the system Sudo policy. More details are available at [2].
The Squad's shell server has a very permisive configuration, allowing 7 different users to run anything on any machine as any user, "ALL=(ALL) ALL".
2. What does O-ren do immediately after starting her sniffer? Why? How can a sysadmin find that file on the box? How can O-ren recover her sniffer file?
After running the sniffer with the "tcpdump -nnw " " &" command (PID 4371), O-ren executed:
root@snakepit:/home/cottonmouth # ls -i “ “
97314
This command lists the inode number of the " " sniffer output file. The inode is the unique numeric representation of any object (file, directory...) in a Unix filesystem, in this case 97314.
root@snakepit:/home/cottonmouth # unlink “ “
This command deletes the " " file *name* (directory entry) from the filesystem. Due to the fact the " " name was the last link to the "tcpdump" PCAP output file but, the "tcpdump" process is still running and have the file open, the file (including the disk space it is using) will remain in existence. It will be available until the last file descriptor referring to it is closed, that is, once the "tcpdump" process finishes.
NOTE: Please, see "Appendix A" for additional comments on the challenge output.
O-ren run the 2nd command in order to delete the file from the standard Unix tools perspective, such as "ls, find...", so that the administrator cannot find this potentially suspicious file used to save all the network traffic captured. The 1st command will let him to recover the file contents through the inode number.
A sysadmin can find the file on the box using the Unix "lsof" tool [3]. The command "lsof +L1" lists all the system unlinked files, that is files with a link count less than 1 (+L1) or "NLINK" equal to zero. This would be the output obtained by the administrator when running this tool on "snakepit":
# lsof +L1
COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME
tcpdump 4371 root 4w REG 0,12 0 0 97314 /home/cottomouth/ / (deleted)
O-ren can recover the sniffer file using Unix standard commands:
# kill -STOP 4371
First, O-ren needs to stop the "tcpdump" process from writting more data to the " " output file, trying to avoid recovering a corrupted PCAP file.
# ll /proc/4371/fd
total 5
lrwx------ 1 root root 64 Jul 25 13:20 0 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 25 13:20 1 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 25 13:20 2 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 25 13:20 3 -> socket:[19747]
l-wx------ 1 root root 64 Jul 25 13:20 4 -> /home/cottomouth/ / (deleted)
Second, O-ren needs to know what is the file descriptor (fd) pointing to the file from the "tcpdump" process perspective. This information is available through the Unix "/proc" pseudo-filesystem. In this case, the process is using fd 4 to point to the " " file.
# cp /proc/4371/fd/4 /tmp/snakepit.pcap
Finally, O-ren simply copies the file contents indicating the file descriptor (fd) used by the "tcpdump" process to reference the file, to a new file, called "/tmp/snakepit.pcap".
3. How did O-ren get Bill’s passwords for ssh and gpg? What can Bill do to safeguard his gpg-protected information from such attacks?
First, O-ren transferred Bill Stearn's "apptrace" [4] Unix script to the system using "netcat" [5]. It set the execution permission bits on the transferred file and run the tool to get details (see bellow) associated to any SSH client invocation, "/usr/sbin/ssh":
root@snakepit:~/ # nc -lp 5050 > apptrace
root@snakepit:~/ # chmod +x apptrace
root@snakepit:~/ # ./apptrace /usr/sbin/ssh
The "apptrace" tool records the last time the application specified as the first argument ran ("$APPNAME-last-run" file), the command-line switches involved ("$APPNAME-parameters" file) and it uses the "strace" Unix tool to monitor the kernel system calls invoked by the running application. The information is stored in the output directory, called "$HOME/apptrace" (or "/tmp/apptrace" if there is no $HOME variable defined).
NOTE: $APPNAME (in the output filenames) is the name of the application used in the first argument, in this case, "ssh".
When the "apptrace" script is executed it replaces the binary file of the command specified as the first argument by the "apptrace" script itself, and saves a copy of the original binary as "
The new "binary" file ("/usr/sbin/ssh", now the "apptrace" script) simply calls "strace" with the "-f -o" options (follow process forks and output to a file) and traces the original binary, now called "ssh.orig":
strace -f -o/usr/sbin/ssh.orig $*
The next time the "binary" (ssh) runs, "strace" collects all the system calls performed by it, including the reads syscalls associated to the password input, called after showing the SSH "Password:" prompt.
The same kind of attack was used to gather Bill's GPG passphrase. O-ren run a command like:
[root@localhost snakechamer]# ./apptrace /usr/sbin/gpg
When Bill invoked "gpg", all the system calls used by this binary were collected, including the reads syscalls associated to the passphrase input, called after showing the GPG "Enter passphrase:" prompt.
Bill can safeguard his gpg-protected information from such attacks following the following countermeasures:
First of all, not allowing any other user (local or remote) to obtain root privileges. The passwords were obtained through the "strace" tool, and in order to run it you need to be root. In this scenario O-ren got root access due to the unsecure configuration of the Sudo tool in both systems (that specifically allowed him to run the "su -" command):
- In snakepit this let him to run "strace" to get the SSH password to access the 192.168.159.133 box.
- In the 192.168.159.133 system this let him to run "strace" to get the GPG passphrase required to read the "okunote" secret file.
Therefore, it is recommended to restrict Sudo usage following the details of question 1. However, this is not the only way to become root in a Unix system, so it is recommended to harden the box as much as possible so that it's not possible to take advantage of any other exploit (local or remote) to scalate privileges.
In the second place, O-ren got access to the second system by gathering Bill's SSH password. If Bill would have used digital certificates to authenticate via SSH to the second system (instead of the username and password authentication mechanism), the attack would have been more difficult to achieve (although still feasible capturing the kernel system calls).
Additionally, the "apptrace" tool works by replacing critical system binary files. Having some kind of host or file integrity checker, such as Tripwire [6] or AIDE [7], would have help to detect the forgery prior to invoking the replaced commands, "ssh" and "gpg". Besides, having some kind of host-based intrusion detection capabilities, even a home-made one running the "lsof" command of question 2 periodically, would have helped to detect anomalous behaviours, such as unlinked files, that could have alerted Bill about O-ren's actions and the compromise.
In order to decrypt the PGP armored "okunote" file, the user private key is required (together with the passphrase protecting this key). If Bill would have kept this file out of the box, such as in a USB stick, O-ren wouldn't had be able to get the file contents. This method is known as two-factor authentication, something you know (the passphrase) and something you have, the USB thumbdrive containing the private key. The only vulnerable timeframe is when the USB drive is plugged into the system, but this drastically reduce the time of exposure to the attack presented. The same idea applies if digital certificates are used to authenticate via SSH.
Lastly, the "gpg: Warning: using insecure memory!" warning message displayed by the "gpg" program [8] means that the binary is running without setuid, therefore, it is not locking memory pages. In this scenario, the OS can write the "gpg" memory pages containing the secret keys to disk during its memory management tasks. This secret information on disk could be potentially accessed by an intruder (this method was not used by O-ren).
4. For extra credit: what is the meaning behind snakecharmer’s passwords?
Snakecharmer’s passwords are the hexadecimal ASCII representation [9] of the letters of two different words:
- Password to 192.168.159.133 is: "6f74616b75".
ASCII translation: "otaku".
Otaku refers to a variety of geek obsessed with anime and manga. In Japanese this term has negative connotations, although in English can have positive or negative connotations (specially in Internet forums) [10].
- GPG passphrase in clear text: “42696c6c”.
ASCII translation: "Bill".
"Hack Bill!" ;-)
- REFERENCES:
[1] Sudo:
http://www.courtesan.com/sudo/ (Unix)
http://sudowin.sourceforge.net (Windows)
[2] Sudo manual page:
# man sudoers
[3] Lsof:
http://freshmeat.net/projects/lsof/
[4] Apptrace:
http://www.stearns.org/apptrace/
http://www.stearns.org/doc/apptrace.v0.1.html
[5] Netcat:
http://www.vulnwatch.org/netcat/
[6] Tripwire:
http://www.tripwire.com
http://sourceforge.net/projects/tripwire/
[7] AIDE:
http://sourceforge.net/projects/aide
[8] GPG memory warning message:
http://www.gnupg.org/documentation/faqs.html#q6.1
[9] ASCII table:
http://www.lookuptables.com
[10] Wikipedia:
http://en.wikipedia.org/wiki/Otaku
- Appendix A:
The challenge output shows how O-ren run the sniffer:
root@snakepit: # cd /home/cottonmouth/
root@snakepit:/home/cottonmouth # mkdir " "
root@snakepit:/home/cottonmouth # cd
root@snakepit:/home/cottonmouth/ # tcpdump -nnw " " &
[1] 4371
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
root@snakepit:/home/cottonmouth # ls -i “ “
97314
root@snakepit:/home/cottonmouth # unlink “ “
O-ren created a " " directory and inside it a " " file (inode: 97314) where the sniffer output was saved. However, after running the "tcpdump" command he didn't change the directory location although the command prompt seems to indicate that he did, because he is at "/home/cottonmouth" instead of at "/home/cottonmouth/ ".
If I'm not wrong, the command prompt should contain a final "/ " for the last 2 commands, or a "cd .." should have been executed after the "tcpdump" command:
root@snakepit: # cd /home/cottonmouth/
root@snakepit:/home/cottonmouth # mkdir " "
root@snakepit:/home/cottonmouth # cd
root@snakepit:/home/cottonmouth/ # tcpdump -nnw " " &
[1] 4371
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
root@snakepit:/home/cottonmouth/ # ls -i “ “
97314
root@snakepit:/home/cottonmouth/ # unlink “ “
For the challenge answers I have considered that the "/ " was missing and only the PCAP file was unlinked.
posted by Raul Siles at 12:53 PM
2 Comments:
Hey Raul,
Thanks for the reply on my blog. Yours was definitly the more techincal entry.
Thanks again.
PS: a great paper on wireless driver exploits for your website: http://www.uninformed.org/?v=6&a=2&t=sumry
;-), Thanks Dean!
Dean won Mike's challenge, and posted in his Blog about it and my comments! :-)
Great wireless security reference! It has been added to my wireless security Web page.
Post a Comment
<< Home