[PEN-TEST] E-Commerce Merchant Penetration Observations

[Ben Lull <blull () VALLEYLOCAL COM>]

Heya,

    Well I'm sitting here trying to meet my deadline of 10 am (heh
coding for 32 hours straight makes your brain hurt)...  Anyhow I'm
creating an E-Commerce engine for one of our clients using php (ver. 4
patch release 2).  One of the techniques I'm using of course is sessions
(see www.php.net's manual on sessions for a detailed description).
Anyway, I was in the middle of creating a gawk/bash script to do a
search/replace on a bunch of files and copied the files temporarily into
/tmp.  Well while doing this I saw allot of files called sess_* (ex..
sess_a0s9821098b098109s8019830129).

     I realized these were all of my sessions generated when calling the
session_start() function.  When I looked in them to my surprise I saw
all the variables which I had made available in the session as well as
the values!  I had been storing the username/des encrypted password to
the administration interface in two different variables.  I also saw
that these files were mode 0600 owned by nobody.nobody (which apache
runs as on the server I'm coding on).

    Now considering that these files are mode 0600/nobody.nobody no one
can read these but apache... but since php is installed as a DSO all
files it handles are done with the uid/gid of nobody.nobody (see what
I'm getting at yet? *note I'm not sure if suexec works with DSO's or
just cgi's*).  Well I decided to play around with this a bit and simply
created the following php script:


<--- begin sess.php --->
<?php
  // Prove who we are
  system("/usr/bin/id");
  printf("<br>\n");
  system("/usr/bin/whoami");
  printf("<br><br>\n");

  // Proof of concept
  system("/bin/cat /tmp/sess_*");

?>
<--- end sess.php --->


    As you are suspecting I was able to read everything in the session
files.  This is definitely not a good thing.  Now do realize, these
files are only left on the system due to bad programming techniques (I
unfortunately had to learn php in a very short time frame for this
project which is why I implemented such nasty coding techniques so no
flames bout that please =p).  If you correctly called session_destroy()
when you are done with your session, the /tmp/sess_* file will be
removed.

    This then led me to believe that I would be able to alter the data
in a sess_* for a session which is currently still in use.  To
(unfortunantly/fortunatly, depending how you look at it) disprove my
theory I created the following script:


<--- begin sess2.php --->
<?php
  // Create a New Session and give it a global variable
  session_start();
  session_register("foo");
  $foo = "bar";

  // Get Our Session ID
  $sessid = session_id();

  // Check the file to make sure it exists
  $systr = "/bin/ls -al /tmp/sess_";
  $systr .= $sessid;
  printf("$systr output during session:<br>\n");
  system($systr);
  printf("<br><br>\n");

  // Kill our session
  session_destroy();

  // Verify the file still exists
  printf("$systr output after session:<br>\n");
  system($systr);
?>
<--- end sess2.php --->


The script generated the following output:


<--- Begin sess2.php Output --->
/bin/ls -al /tmp/sess_88971e11e44756ad653a50b1001935b4 output during
session:
-rw------- 1 nobody nobody 0 Aug 24 02:45
/tmp/sess_88971e11e44756ad653a50b1001935b4

/bin/ls -al /tmp/sess_88971e11e44756ad653a50b1001935b4 output after
session:

<--- end sess2.php output--->



    What I was hoping to see was a way to somehow alter the values for
the registered session variables during a session which is still in
progress.  If you were able to, depending on the data stored in the
session you could anything from obtain junk information to (hopefully
not though) hijack a session in progress (although this would require
extremely poor programming techniques, and I'm not even that bad), or
even gain root access (if someone actually stores root's password in a
session registered variable).

    This is still useful.  Now we know, that if a session isn't properly
destroyed with session_destroy() the sess_<session id> file is left in
/tmp with all the variables registered to the session.  By simply
examining the data you could potentially gain unauthorized access via
web based applications using sessions.

    In a nut shell... PHP programmers seem to not be aware of the
security aspects of their coding allot of the time (note I didn't say
all the time or even most, just allot (although you could argue that
isn't much different)).  Just another way which penetration via web
based applications can occur.  Since PHP, by default, can be used by any
normal user with an account on the system (or remotely via web bulletin
board, etc..), this type of attack could pose useful to the ISEC type of
person.


Thanks for putting up with the babble,
Ben Lull

***
* Ben Lull
* Valley Local Internet, Inc.
* Systems Administrator
***


P.S. This really isn't a bug (although I believe php session handling
should clean up the mess it leaves behind).  Its more a case of poor
programming techniques and how they can be used and abused.