Home > Archive > PHP Programming > February 2008 > Hacker attack. What do they want?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Hacker attack. What do they want?
|
|
|
| Hi,
my site allows to upload images. For that reasons I have created a
directory which have "drwxrwxrwx"-permission. I.e. everybody can write
in that directory. I understand that it is not save, because everybody
can upload to this directory some scripts which would destroy my file
system or store some information. To make things a little bit better I
put there the following .htaccess file:
php_flag engine off
IndexIgnore *
So it means that php-scripts cannot be executed in this directory. But
what about the shell scripts? How could I prevent an execution of the
shell script in this directory?
My php script which upload files to the directory takes only files
which have *.jpg extension. Today I found out that in the directory I
have a file (called 854.jpg) which is an sub-directory! How did they
did it? Well I understand, that jpg extension does not guarantee the
file is an jpg-image, but I did not know that this file can be a
directory!
The problem is that subdirectory "854.jpg" does not have the above
mentioned .htaccess file. So the owner of the directory can make there
whatever it wants. How can I solve this problem?
| |
| Dikkie Dik 2008-02-23, 7:02 pm |
| > my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write
> in that directory.
Nice, but who else writes in that directory than the web server user?
> I understand that it is not safe, because everybody
> can upload to this directory some scripts which would destroy my file
> system or store some information. To make things a little bit better I
> put there the following .htaccess file:
> php_flag engine off
> IndexIgnore *
When you move the temp file to the final location, YOU (the webserver)
can give it any name YOU want. The fact that the directory is
world-writeable AND has an .htaccess file should ring a bell: If you
keep the file names, anyone can upload an .htaccess file...
> So it means that php-scripts cannot be executed in this directory.
Given the above, are you sure?
> But
> what about the shell scripts? How could I prevent an execution of the
> shell script in this directory?
By not making them executable. You can chmod the file if it is executable.
> My php script which upload files to the directory takes only files
> which have *.jpg extension. Today I found out that in the directory I
> have a file (called 854.jpg) which is an sub-directory! How did they
> did it? Well I understand, that jpg extension does not guarantee the
> file is an jpg-image, but I did not know that this file can be a
> directory!
>
> The problem is that subdirectory "854.jpg" does not have the above
> mentioned .htaccess file. So the owner of the directory can make there
> whatever it wants. How can I solve this problem?
>
By putting the things that appear in the .htaccess file in the normal
config. There is really no reason for .htaccess files, other than lack
of access to system maintainers.
Furthermore, you can check if it is a directory upon upload.
Good luck!
| |
| Betikci Boris 2008-02-24, 8:07 am |
| On Feb 23, 11:21 pm, Fro <showandbesh...@gmail.com> wrote:
> Hi,
>
> my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write
> in that directory. I understand that it is not save, because everybody
> can upload to this directory some scripts which would destroy my file
> system or store some information. To make things a little bit better I
> put there the following .htaccess file:
> php_flag engine off
> IndexIgnore *
>
> So it means that php-scripts cannot be executed in this directory. But
> what about the shell scripts? How could I prevent an execution of the
> shell script in this directory?
>
> My php script which upload files to the directory takes only files
> which have *.jpg extension. Today I found out that in the directory I
> have a file (called 854.jpg) which is an sub-directory! How did they
> did it? Well I understand, that jpg extension does not guarantee the
> file is an jpg-image, but I did not know that this file can be a
> directory!
>
> The problem is that subdirectory "854.jpg" does not have the above
> mentioned .htaccess file. So the owner of the directory can make there
> whatever it wants. How can I solve this problem?
You have to give write and execute privilages to users just before the
upload and change chmod to 644 or 744 or whatever immediately after
upload. If you able to logged these attackers ip addresses you should
ban these ip's to connect. Furthermore for security reasons disable
some php functions such as exec(), ftp, etc.
| |
|
| Fro wrote:
> Hi,
>
> my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write
> in that directory.
I do believe you could use drw-rw-rw- permissions. Leaving off
the execute permission would prevent creating a subdirectory.
| |
| Toby A Inkster 2008-02-25, 4:15 am |
| bill wrote:
> I do believe you could use drw-rw-rw- permissions. Leaving off the
> execute permission would prevent creating a subdirectory.
It would prevent everyone from reading the directory listing.
--
Toby A Inkster BSc (Hons) ARCS
[G of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 15:54.]
Bottled Water
http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/
| |
|
| Toby A Inkster wrote:
> bill wrote:
>
>
> It would prevent everyone from reading the directory listing.
>
Thanks Toby, you are correct, of course.
bill
| |
| Gordon 2008-02-25, 8:06 am |
| On Feb 23, 9:21 pm, Fro <showandbesh...@gmail.com> wrote:
> Hi,
>
> my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write
> in that directory. I understand that it is not save, because everybody
> can upload to this directory some scripts which would destroy my file
> system or store some information. To make things a little bit better I
> put there the following .htaccess file:
> php_flag engine off
> IndexIgnore *
>
> So it means that php-scripts cannot be executed in this directory. But
> what about the shell scripts? How could I prevent an execution of the
> shell script in this directory?
>
> My php script which upload files to the directory takes only files
> which have *.jpg extension. Today I found out that in the directory I
> have a file (called 854.jpg) which is an sub-directory! How did they
> did it? Well I understand, that jpg extension does not guarantee the
> file is an jpg-image, but I did not know that this file can be a
> directory!
>
> The problem is that subdirectory "854.jpg" does not have the above
> mentioned .htaccess file. So the owner of the directory can make there
> whatever it wants. How can I solve this problem?
* Do you use is_file and is_uploaded_file to verify that the script is
dealing with an actual file and not some kind of other filesystem
object, and that it is a file that's been uploaded and not inserted
some other way?
* Does your script check the MIME type of the uploaded file? The
$_FILES superglobal contains a mime element you can check. If this
isn't 'image/jped' or 'image/pjpeg' then reject the upload and delete
it from your temp directory.
* Is your .htaccess file set read only? If not it can be overwritten
by the script.
* Does your script check the name of the uploaded file and makes sure
it's not something dangerous? If the filename is .htaccess or some
other potentially dangerous name then you should reject the upload.
| |
|
| Fro pisze:
> Hi,
>
> (CUT)
Mabe You should just use ftp functions to put files in some other dir
(not accesible directly through web server)?
You can then still use php to access them when needed (move, display or
whatever...) ? It would make unnecessary to keep world-writable
directory and keep You safe.
| |
| The Natural Philosopher 2008-02-25, 7:03 pm |
| Dape wrote:
> Fro pisze:
>
> Mabe You should just use ftp functions to put files in some other dir
> (not accesible directly through web server)?
> You can then still use php to access them when needed (move, display or
> whatever...) ? It would make unnecessary to keep world-writable
> directory and keep You safe.
Or simply put them in a databe.
Its almost impossible to execute them from there.;-).
| |
| Toby A Inkster 2008-02-25, 7:03 pm |
| Gordon wrote:
> * Does your script check the MIME type of the uploaded file? The
> $_FILES superglobal contains a mime element you can check. If this
> isn't 'image/jped' or 'image/pjpeg' then reject the upload and delete it
> from your temp directory.
This is virtually worthless from a security point of view. The MIME type
is reported by the client's browser, so cannot be relied upon.
A better test would be to check that the the file's contents seemed to be
a valid JPEG. One way of doing this would be to read the file into a
string (or to save memory, just the first few bytes) and check that bytes
7 to 10 match the string "JFIF".
Better still, use GD or similar to open the file and check it's a valid
image.
--
Toby A Inkster BSc (Hons) ARCS
[G of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 20:32.]
Bottled Water
http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/
| |
| Gordon 2008-02-25, 7:03 pm |
| On Feb 25, 2:19 pm, Toby A Inkster <usenet200...@tobyinkster.co.uk>
wrote:
> Gordon wrote:
>
> This is virtually worthless from a security point of view. The MIME type
> is reported by the client's browser, so cannot be relied upon.
>
> A better test would be to check that the the file's contents seemed to be
> a valid JPEG. One way of doing this would be to read the file into a
> string (or to save memory, just the first few bytes) and check that bytes
> 7 to 10 match the string "JFIF".
>
> Better still, use GD or similar to open the file and check it's a valid
> image.
>
> --
> Toby A Inkster BSc (Hons) ARCS
> [G of HTML/SQL/Perl/PHP/Python/Apache/Linux]
> [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 20:32.]
>
> Bottled Water
> http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/
You're right, but I think if you're going to do that then GD is the
way to do it. There's nothing stopping somebody from making the first
line of a malicious file a comment that contains the JPEG magic
string.
| |
| Toby A Inkster 2008-02-26, 8:07 am |
| Gordon wrote:
> You're right, but I think if you're going to do that then GD is the way
> to do it. There's nothing stopping somebody from making the first line
> of a malicious file a comment that contains the JPEG magic string.
True, but if they don't know *how* you're checking that the file is a JPEG
(i.e. /^.{6}JFIF/) then they might not think to forge those bytes. You
could be doubly-sure by checking for:
if ( preg_match('/^.{6}JFIF/', $firstfewbytes)
&& (!preg_match('/^(.ELF|\#\!)/', $firstfewbytes))
{
// file is safe
}
--
Toby A Inkster BSc (Hons) ARCS
[G of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 27 days, 17:47.]
Bottled Water
http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/
| |
|
| Fro a écrit :
> Hi,
>
> my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write
> in that directory. .......
>
For such use,you have to give 222 permission: everybody can write,
without read, without exec!!!
| |
| MichaelD 2008-02-26, 7:06 pm |
| I would suggest building a more robust interface - use something like
http://www.digitalgemstones.com/script/ImgUploader.php to make
uploading files easy and secure, then build your own interface - it
doesn't have to be much more complex than the natural one Apache
servers up - but if you built it, you can control it.
The problem with opening up security holes like that is, you're going
to be very hard pressed to ensure that you've covered all your bases
as far as only allowing valid access - much better, even if it's more
work in the short term, to build it yourself.
|
|
|
|
|