phpinfo() Recon
Today I was doing a little research and I happened across a site that displayed it’s phpinfo() function. I wasn’t even sure what I was looking at at first because it was just such an insane wealth of reconnaissance information on the server in question that I just couldn’t believe my eyes. It’s my new favorite amusing Google Dork: intitle:phpinfo() inurl:com
Let’s take an example, like ns7.webmasters.com. What can we derive out of looking at their phpinfo? Where should we start?
- Compile time configuration information. So if I wanted to know configuration options for PHP, I’ve pretty much got that at my disposal, not to mention path information. Bummer.
- Register_globals is apparently turned on - lucky for us.
- libcurl/7.15.1 OpenSSL 0.9.8a 11 Oct 2005 zlib/1.2.2 libidn/0.5.18 - lots of outdated software.
- Hashing engines - at least we don’t have to muddle around and guess how data is hashed too much once we do break in
- ImageMagick 5.5.7 - another outdated version, love it.
- pfpro.defaulthost test-payflow.verisign.com - could be interesting if we can compromise the DNS, but it’s only a test. This could be more interesting on a production machine.
- libTidy Release 1 September 2005 - more outdated software.
- Apache/1.3.34 Ben-SSL/1.57 (Unix) mod_gzip/1.3.26.1a mod_fastcgi/2.4.2 mod_throttle/3.1.2 Chili!Soft-ASP/3.6.2 FrontPage/5.0.2.2635 mod_perl/1.29 PHP/4.4.2 - hmmm… vulnerable to the expect XSS issue among other issues.
Why would you ever put something like this on your server, and more importantly why would you ever allow a search engine to spider it? These sorts of information disclosure issues can really hurt companies, and unfortunately it’s trivial to find them (less so on targeted servers, but for un-targeted worms this is great recon). Scary.
January 30th, 2007 at 4:26 pm
I am surprised that you have found this so late
Some of the nameservers display phpinfo() functions, some of the well configured servers have phpinfo() on the special page…
Otherwise I have to agree with you, phpinfo is great source of information on the server, you don’t even have to use nmap
January 30th, 2007 at 5:05 pm
I am too… where was I sleeping?
January 30th, 2007 at 5:23 pm
You could even use the phpinfo() page to execute XSS for PHP version 5.1.2 and prior or PHP version 4.4.2 and prior.
Example using the google dork [”PHP 4.4.1″ intitle:phpinfo() inurl:com]:
http://st100.startlogic.com/phpinfo.php?cx[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]=%3Cscript%3Ealert(String.fromCharCode(88,83,83));%3C/script%3E
January 30th, 2007 at 8:10 pm
DanielG, I’ve found that the above exploit actually works on some 4.4.4 servers also.
Witness:
https://secure.dorado.lunarpages.com/php.php?cx[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]=%3Cscript%3Ealert(String.fromCharCode(104,105));%3C/script%3E
January 30th, 2007 at 11:05 pm
Haha RSnake. Even I knew this! But it is really useful and as DanielG and Andrew pointed out, has more uses than just recon.
January 31st, 2007 at 2:42 am
RSnake: XSS bug found by me ath website of the largest daily newspaper in Slovakia: www.sme.sk
Attacker could gain access to logged users’ data in the discussions - it was possible to inject HTML/JS code into the discussion comment easily (no checking for or encoding it whatsoever). Attacker could gain access to the username, user’s email, IP address of user, session ID and of course full access to any property of document object model.
More reading in Slovak language only ;-):
http://www.ambience.sk/bezpecnostna-chyba-sme-sk
January 31st, 2007 at 4:19 am
Rsnake,
this is indeed quite old news. However the Suhosin extension (since 0.9.15) transparently adds META tags into the phpinfo() output that tells search engines to NOT index them.
Similiar stuff is also in the PHP CVS, and will be part of default PHP as soon new versions are released.
January 31st, 2007 at 6:11 am
It was very easy to find several .gov sites with remotely exploitable vulnerabilities in just a few minutes time that allow remote code execution (of course they may be relying on an IPS crutch to stop some of it). Seems like this would have been used more effectively. Of course it would also be real easy to seed Google with fake PHPInfo pages on a honeypot. Great for meeting a monthly bust a script kiddie quota.
Not knowing a lot about this but I would think having PHPInfo open would not be the default installation. If that is true wouldn’t it be likely that these sites would other permissions set incorrectly?
btw Rsnake, I think someone from Slovakia is trying hard to get your attention.
January 31st, 2007 at 6:59 am
Yeah it’s something I was barking to fellow developers for many years, but they just don’t see the risk, for them it’s handy.
But there is something far more dangerous, sometmies a developer needs to know the globals stored in PHP, this can be accessed with: var_dump($GLOBALS)
Now, the cool thing about it is, that it also dumps the database login unto the screen if that file is present before the place where you call the globals.
January 31st, 2007 at 9:52 am
John @ NIST: please, read discussion under older articles - I was referring to the larges Czech e-zine Zive.cz XSS vulnerability which I have mentioned under the older article.
January 31st, 2007 at 11:08 am
Hey folks,
try that google dork, much less spam
“intitle:phpinfo() inurl:com System Build Date”
Greetings dexcs
January 31st, 2007 at 11:14 am
Sry, Mod for another Post, but check this one out:
http://tools.wikimedia.de/~dab/test.php
February 1st, 2007 at 4:49 pm
Andrew Says:
January 30th, 2007 at 8:10 pm
DanielG, I’ve found that the above exploit actually works on some 4.4.4 servers also.
So….Andrew, RSnake, what kind of info can be gained thru an XSS vulnerability in phpinfo() just for my information? -trying to build my security knowledge as a junior developer
February 18th, 2007 at 3:02 pm
[…] О том, чем может помочь злоумышленику страница созданная функцией phpinfo() можно почитать например в записи phpinfo() Recon. […]