Is my apache/php server being hacked?
August 27, 2012 7:30 PM Subscribe
I have a simple php script. A few times a day, some user has reported that he is seeing the php source code. I can't reproduce it. But I was able to see the source as it appeared on their screen, and there is a weird anomaly.
In the source on the page displayed to them, the <?php tag at the beginning of the file ended up on his computer with <!--?php put in there. So apache was thinking it should not be executed. The file doesn't do anything complicated. On the disk when I look at the php file in the live html directory it just looks normal: starts with <?php So somehow, something is adding in the !-- either by mistake or on purpose. This only has happened a few times out of maybe 200,000 pageviews as far as has been reported to me, but 2 of them were by different users in different continents. The only thing that I can tell you is the uncanny coincidence is that all 3 users who reported it are using the chrome browser. When they switch to any other browser, they could not reproduce it. When I got them to delete all cached files on their computer, they could not reproduce it again either. But I got the screenshots, and I know it happened. Am I being hacked or is this some kind of bug?
I also recently added all my files to git (within a day of this beginning to happen) but doing a bunch of diffs, I cannot find any significant difference at all, whatsoever.
Thanks for your insight.
In the source on the page displayed to them, the <?php tag at the beginning of the file ended up on his computer with <!--?php put in there. So apache was thinking it should not be executed. The file doesn't do anything complicated. On the disk when I look at the php file in the live html directory it just looks normal: starts with <?php So somehow, something is adding in the !-- either by mistake or on purpose. This only has happened a few times out of maybe 200,000 pageviews as far as has been reported to me, but 2 of them were by different users in different continents. The only thing that I can tell you is the uncanny coincidence is that all 3 users who reported it are using the chrome browser. When they switch to any other browser, they could not reproduce it. When I got them to delete all cached files on their computer, they could not reproduce it again either. But I got the screenshots, and I know it happened. Am I being hacked or is this some kind of bug?
I also recently added all my files to git (within a day of this beginning to happen) but doing a bunch of diffs, I cannot find any significant difference at all, whatsoever.
Thanks for your insight.
Response by poster: Hi, Thanks, just 1 webserver with 4 cpu 2 cores each, running centos 5 with apache 2.2.3 , php 5.3.3, APC version 3.1.9. Yesterday when 2 users simultaneously noticed it, I still had php 5.2 on it, but then I updated to 5.3 Then it happened today also extremely briefly, but now cannot be reproduced again.
posted by peter_meta_kbd at 8:05 PM on August 27, 2012
posted by peter_meta_kbd at 8:05 PM on August 27, 2012
Do you have any sort of caching on? mod_gzip? Anything special about your apache configuration at all? Any special settings you set in php.ini? A preamble or epilogue file?
It's especially odd because if the source is being sent as "text/html" then they'd just get a blank page (because of the comments). So it must be getting sent as "text/plain" sometimes.
posted by sbutler at 8:12 PM on August 27, 2012
It's especially odd because if the source is being sent as "text/html" then they'd just get a blank page (because of the comments). So it must be getting sent as "text/plain" sometimes.
posted by sbutler at 8:12 PM on August 27, 2012
Did you have nested PHP (like this person did) that could have gotten cached somewhere?
posted by erst at 8:14 PM on August 27, 2012
posted by erst at 8:14 PM on August 27, 2012
Where are these users in relation to the server, and where are you in relation to the server? Could these users be connecting through a HTTP proxy of some sort? Even unknowingly (transparent proxy) - do your server log files for these users indicate a proxied connection?
(Just trying to winnow down options here - if something is inserting things into the HTML, a HTTP proxy would be perfect for the job.)
posted by Jimbob at 8:42 PM on August 27, 2012
(Just trying to winnow down options here - if something is inserting things into the HTML, a HTTP proxy would be perfect for the job.)
posted by Jimbob at 8:42 PM on August 27, 2012
@Jimbob: but a proxy server outside your local setup should never see PHP source code.
posted by sbutler at 8:46 PM on August 27, 2012
posted by sbutler at 8:46 PM on August 27, 2012
Any htaccess or special directives running?
Check your php error logs for anything unusual. Also, check your Apache logs to see if the web server reported any requests where the response size matches the length of the php source instead of the correctly parsed output and what the actual request URI was.
posted by justkevin at 9:29 PM on August 27, 2012
Check your php error logs for anything unusual. Also, check your Apache logs to see if the web server reported any requests where the response size matches the length of the php source instead of the correctly parsed output and what the actual request URI was.
posted by justkevin at 9:29 PM on August 27, 2012
Response by poster: Thanks, 1 user in Australia, 1 in Florida, 1 in Michigan, server in LA, I'm in Hawaii. The users are all going directly to the site without any proxy inbetween. 1 time I was also able to get this to happen to me (in the same 5 minute interval as one of the users had this bug, right as he was calling in to report it, I was doing the test). In my case, I have a ssh tunnel that goes to a localhost IP going into a completely different directory that only has phpmyadmin in there, and I got served the phpmyadmin source right to my chrome browser. Then it stopped again. It's true that one of the 3 files where this problem is known to have occurred was called from javascript, and the results of the file were embedded into a HTML tag's content. However in 2 other cases this was not the case. In these latter 2 cases it was completely unrelated to js. Yes, deflate is on (has been for years). 2 of these php files I wrote (no recent changes), but they do completely different kinds of things. 1 of them is just the index.php file of phpmyadmin and I've never touched it before, it was installed in 2010 and has no timestamps since then.
I suppose it is possible that chrome is inserting the !-- secretly "just to help out", maybe the actual php files are being served as text files without that.
posted by peter_meta_kbd at 9:29 PM on August 27, 2012
I suppose it is possible that chrome is inserting the !-- secretly "just to help out", maybe the actual php files are being served as text files without that.
posted by peter_meta_kbd at 9:29 PM on August 27, 2012
What are the modification timestamps on your PHP files? Are they writable to the web server account (they shouldn't be)? Can you reproduce the behaviour by manually inserting the <--?
posted by themel at 11:55 PM on August 27, 2012
posted by themel at 11:55 PM on August 27, 2012
Response by poster: Hi, The timestamps are older than the problem (weeks, months, years. In the case of phpmyadmin, it was installed more than 1 year ago and no changes were ever written to that file). They are not writable by the apache user. Yes, I can reproduce the behavior by saving the file with a different name and inserting the !-- so it starts with <!--?php .
posted by peter_meta_kbd at 12:21 AM on August 28, 2012
posted by peter_meta_kbd at 12:21 AM on August 28, 2012
Response by poster: When I manually insert the !-- inside the initial php tag beginning, I see that it does not have identical behavior. The manually inserted (by me) leaves the whole file as a comment. But in the few cases where Ihave seen the source of the auto-inserted, the comment tags are also closed. It doesn't close on the final php tag, but rather the comment tag closes on the very next closing tag of any kind. For instance this is actually copied directly from chrome's inspect element the one time this happened on my browser, which I can do b/c the tab is still open:
<> [ ...... a bunch of lines deleted here... this is actually from phpmyadmin/sql.php ... ]
if ($do_confirm) {
$stripped_sql_query = $sql_query;
require_once './libraries/header.inc.php';
if ($is_drop_database) {
echo '
... then a bunch of html (not php) code and text ....
then
<> echo '
... a buch more html (not php) code and text
posted by peter_meta_kbd at 12:55 AM on August 28, 2012
<> [ ...... a bunch of lines deleted here... this is actually from phpmyadmin/sql.php ... ]
if ($do_confirm) {
$stripped_sql_query = $sql_query;
require_once './libraries/header.inc.php';
if ($is_drop_database) {
echo '
... then a bunch of html (not php) code and text ....
then
<> echo '
... a buch more html (not php) code and text
posted by peter_meta_kbd at 12:55 AM on August 28, 2012
When was the last time you restarted apache or the server? Not reloaded apache, but done a full stop, make sure all apache processes are dead, and then start it again.
Apache on Linux makes several copies of itself to service requests (called forking children). One of those children might have a bad or outdated configuration. A configuration that doesn't recognize .php files as a sever side script. That would explain the somewhat random appearance of the problem. You wouldn't hit this "problem" child every time.
Normally when you tell apache to reload it kills all of its children and forks new ones with the new configuration. But right now this is the only thing I can think of that would be causing your sporadic issue.
posted by sbutler at 12:59 AM on August 28, 2012
Apache on Linux makes several copies of itself to service requests (called forking children). One of those children might have a bad or outdated configuration. A configuration that doesn't recognize .php files as a sever side script. That would explain the somewhat random appearance of the problem. You wouldn't hit this "problem" child every time.
Normally when you tell apache to reload it kills all of its children and forks new ones with the new configuration. But right now this is the only thing I can think of that would be causing your sporadic issue.
posted by sbutler at 12:59 AM on August 28, 2012
Not to ask the obvious, but does anything show up in the apache error log at the times this has happened? What do the entries for php look like in your httpd.conf and .htaccess?
posted by jferg at 4:13 AM on August 28, 2012
posted by jferg at 4:13 AM on August 28, 2012
This sounds like they are seeing the source without trying to do something, but earlier this year a standing ~10 year old bug was found in that would expose the source code by adding a query string parameter. It only affected PHP run via CGI. This is a remote possibility but worth considering if you are running an older version of PHP.
posted by dgran at 6:17 AM on August 28, 2012
posted by dgran at 6:17 AM on August 28, 2012
This thread is closed to new comments.
posted by erst at 7:45 PM on August 27, 2012 [1 favorite]