September 19, 2006

Mounting CD/DVD ISO images in Windows XP

Have you ever wished there was a (free) Windows equivalent to the linux "mount -o loop" command to mount CD/DVD ISO images?

Well, I just found out there is a tiny free tool from Microsoft (though unsupported) that does just that: it is called "Virtual CD-ROM Control Panel for Windows XP" and it allows you to browse a CD/DVD iso image (.iso file) as if it was a real CD/DVD connected to your Windows XP system. The tool will assign a drive letter to the virtual CD (e.g. Z:) and from that moment on you will be able to access it, read-only, using all the normal utilities like Windows Explorer and from any program (e.g. File->Open).

Direct link the tool:

This is where I found the reference to the tool:

Go to:
Click on:
What are ISO image files and how do I use them?
Click on:
Mounting ISO files virtually:
See the text:
The following tool for Windows XP allows image files to be mounted
virtually as CD-ROM/DVD-ROM devices. This tool is provided here for
your convenience, and is unsupported by Microsoft Product Support
* Virtual CD-ROM Control Panel for Windows XP
The last line of the text above (Virtual CD-ROM Control Panel for Windows XP) contains the link mentioned before.


September 15, 2006

Do you Pen-Test? (Updated: 20060926)

I have always thought that penetration testing is a very important part of the continous improvement of security and also an effective way to make clear that the risk of being hacked isn't theoretical.

We have been doing penetration testing for some time, now. Every time we get the right combination of fun and challenge, creativity and technical knowledge. However, not every company has its basic security needs covered and for such companies isn't worth to have to have their systems tested periodically or even ocasionally.

Fortunately security awareness is improving and companies like Microsoft, that did not have security as one of its strengths, has now its own internal penetration testing team, has formalized and systematized the process and is even conducting internal confences about hacking (named Bluehat sessions as a reminder of the blackhat sessions).

Other companies have their own penetration testing teams for their own use or to deliver that service for others. Many of those teams use different sets of programs that gather pieces of information or test specific vulnerabilities (both home developed and downloaded from the Internet). Some others are using free tools, like Metasploit, that only cover the exploitation of vulnerabilities, or comercial tools that integrate most of the required functionality, like the wonderful Core Impact. What I haven't found yet is a FREE tool (GPL) that integrates all the functionalities that are required for the different stages of a penetration test (maybe using existing tools as modules) and that can also be extended if needed.

Is it posible to find such utility? Do you know of any such wonder? Is the free software business model appliable in this case? Can the source be available and still have people/companies interested in paying for support/update? I would love to read your opinions and learn from your experience on this subject.

Begin UPDATE by Raul on 20060926

During our penetration testing activities over the last years we have always dreamt with the free tool that would integrate all the open-source pen-testing tools mentioned by Jorge. Even we started a prototype of the mentioned framework to complement our customized pen-testing Linux-based Live CD, but it never saw the light...

Prior to Jorge publishing this post, I didn't have the chance to talk about this with Jorge and David and let them know that, perhaps, in a near future, such a tool will be released...

The Security Tools Integration Framework (STIF), developed by Fyodor and Meder, promises to automate the pen-testing process (specially the most basic and boring tasks) by integrating commonly used tools and sharing data between them using STIF messages (XML-based).

The framework consists of two components:
  • Unified output format for security tools (unified language)
  • Inference engine based on the STIF format (real time data analysis, data proccessing and data exchange)
You can get the latest README file, tool version and source code from the official Web page (the project Web page has being recently updated). The tool was initially presented during the HackIntheBox 2004 conference and the video for the presentation is available from a big Bit Torrent pack of 1.9GB.

End UPDATE by Raul on 20060926

September 10, 2006

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 (

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 “ “

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
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 ".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":
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 box.
  • In the 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 is: "6f74616b75".
Hex equivalence: 6f=o, 74=t, 61=a, 6b=k, 75=u.
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”.
Hex equivalence: 42=B, 69=i, 6c=l, 6c=l.
ASCII translation: "Bill".

"Hack Bill!" ;-)


[1] Sudo: (Unix) (Windows)

[2] Sudo manual page:
# man sudoers

[3] Lsof:

[4] Apptrace:

[5] Netcat:

[6] Tripwire:

[7] AIDE:

[8] GPG memory warning message:

[9] ASCII table:

[10] Wikipedia:

- 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 “ “
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 “ “
root@snakepit:/home/cottonmouth/ # unlink “ “

For the challenge answers I have considered that the "/ " was missing and only the PCAP file was unlinked.

September 01, 2006

Malicious web pages are all around

I bet everybody knows somebody who thinks you are kidding when you tell them that a malicious web page could take full control of their computers just by browsing to it if they don't take some precautions. I thought I'd rather share a small example from a real-world incident I investigated recently hoping someone finds it useful to show the risk to the non-believers.

The PC of the victim had been completely taken over by the attacker(s). Among other things, a trojan program had been installed that would monitor all web connections established by the victim and report to a certain web site all kinds of information. Bad.

The forensic analysis of the system revealed the infection vector: the user had browsed to a particular web page and the active content of that page had managed to download and install a program into the system. This program, in turn, was a downloader itself that downloaded and installed other programs, but that's beyond our current interest.

So, what did this active content looked like? Well, you can see for yourself. Inside the ZIP file that accompanies this article (see below) you will find an HTML file containing a slightly modified version of that code. Actually, you will find two versions: demo.html and demo_verbose.html. They are basically the same, but the verbose version incorporates pop-up messages so you can follow its execution step by step.

You can download the zip file from:

(ZIP password: "radajo")

In summary, the page instantiates an object (RDS.DataSpace) and then, using javascript to manipulate that object, it tries to download a file from a particular URL (, copy it to the hard drive (c:\tempfile.exe) and then execute it.

The good news is that this particular attack will not work if you have a security level of "Medium" or higher, which, of course, is the recommendation for your Internet Zone. Nor will it work if you click "No" at the popup warning messages, which of course, is another good thing to do.

Sadly, however, most users don't follow the recommendations, just like the victim in this case. :-(

If you want to see it running, do the following: copy both html files to a directory served by your favourite web server (e.g. wwwroot in IIS). Also, copy some inocuous executable file (e.g. calc.exe) to the same directory so that it is also served by the web server. Then, edit the html files using your favourite text editor to reflect the IP of your web server and the correct URL to access the executable file. Finally, launch Internet Explorer (it might work with other web browsers, but I have only tested IE and only in XP SP1 and SP2) in a different system and type in the URL to access the demo.hml or demo_verbose.html files. You will probably get the following warning message from IE three times:

Click "Yes" every time and you should get your downloaded program running (e.g. calc.exe).

Please note that this may not work depending on the security settings of your IE (Tools-> Internet Options -> Security). If you definitely want it to work you can include the url of your web server in the "Trusted Sites". Effectively, you are enabling every feature for the site. Alternatively, you can set a security level of "Medium" for you Internet Zone and then customize it to enable the following two options:
  • Access data sources across domains
  • Initialize and script ActiveX controls not marked as safe
That is: "Medium" security level plus those two settings will enable all this malicious web page needs.

If this example helps in opening the eyes of even just one person, I'll be happy. :-)