Penetration Testing mailing list archives
[PEN-TEST] E-Commerce Merchant Penetration Observations
From: Ben Lull <blull () VALLEYLOCAL COM>
Date: Thu, 24 Aug 2000 03:07:51 -0700
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.
Current thread:
- [PEN-TEST] E-Commerce Merchant Penetration Observations Ben Lull (Aug 24)
- Re: [PEN-TEST] E-Commerce Merchant Penetration Observations Shaun Clowes (Aug 26)