NYCPHP Meetup

[Federico Ulfo]

Nice topic!

A cool exploit I used for some security test was an hidden upload form used
as backdoor to upload PHP files, in combination with this
phpinstaller<https://github.com/rainphp/phpinstaller>,
I was able to compress all files in a single auto-deflating PHP and upload
on the website.

If you want to check the security of an application you may want to keep an
eye also on file_get_contents, curl and "simple" input form.


On Wed, Nov 9, 2011 at 9:58 AM, Gary Mort <garyamort at gmail.com> wrote:

> On 10/20/2011 5:10 PM, Chris Snyder wrote:
>
>> It would be more interesting to find out that these attacks are happening
>> in VPSes or private servers, which would indicated a real exploit, rather
>> than on GoDaddy or Dreamhost or some other shared system.
>>
>
> I find there are 3 classifications of attacks to be concerned about, and
> each is problematic to address.
>
> One is known PHP exploits.  The problem with known PHP exploits is that
> there are a number of ways to secure a system against them, but quite often
> PHP programmers have this idealized view that basically shifts the
> responsibility for security to the underlying operating system.  There are
> quite a number of exploits based on writing or appending to an existing
> file where if the file was read only, even if still owned by the web server
> process and able to chmod it at will from within PHP, those exploits would
> be stopped cold.  Coders are lazy though and they claim "well, if you can
> WRITE to the file, then you can change the file permissions, so why should
> I do extra work whenever I want to write a file".
>
> The next is based on shared hosts and leaving files writable to other
> virtual hosts running on the system, so one compromise allows all to be
> compromised.  Instead of taking steps to minimize that, the solution
> proposed seems to be run your own VPS.
>
> Yet the VPS has it's own problem in that most of them don't bother to lock
> out users who repeatedly try to ftp/sftp to the system - thereby being open
> to dictionary attacks.
>
> The solution is to take security seriously and actually attempt to plug as
> many holes as possible, never just declare it as someone else's problem and
> that "all will be better if only you do..."
>
> Just MHO
>
> -Gary
>
> ______________________________**_________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/**mailman/listinfo/talk<http://lists.nyphp.org/mailman/listinfo/talk>
>
> http://www.nyphp.org/Show-**Participation<http://www.nyphp.org/Show-Participation>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20111109/17d1f895/attachment.html>