From: Igor Escobar on
Hi Folks!

The portal for which I work is suffering constant attacks that I feel that
is PHP Injection. Somehow the hacker is getting to change the cache files
that our system generates. Concatenating the HTML file with another that
have an iframe to a malicious JAR file. Do you have any suggestions to
prevent this action? The hacker has no access to our file system, he is
imputing the code through some security hole. The problem is that the portal
is very big and has lots and lots partners hosted on our estructure
structure. We are failing to identify the focus of this attacks.

Any ideas?


Regards,
Igor Escobar
Systems Analyst & Interface Designer

+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)
From: Ashley Sheridan on
On Mon, 2010-06-07 at 09:54 -0300, Igor Escobar wrote:

> Hi Folks!
>
> The portal for which I work is suffering constant attacks that I feel that
> is PHP Injection. Somehow the hacker is getting to change the cache files
> that our system generates. Concatenating the HTML file with another that
> have an iframe to a malicious JAR file. Do you have any suggestions to
> prevent this action? The hacker has no access to our file system, he is
> imputing the code through some security hole. The problem is that the portal
> is very big and has lots and lots partners hosted on our estructure
> structure. We are failing to identify the focus of this attacks.
>
> Any ideas?
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)


OK, first thing, check all the file access logs, i.e. FTP logs, etc,
just to make sure that it's not a case of a compromised password.
There's a well-known issue with people who use FileZilla on Windows
systems that allows passwords to be easily stolen.

Next, see if you can isolate the IP address(s) that might be making
these changes, and then go back over the HTTP access logs to determine
what URLs they are visiting on the site. This should give you an idea
about where the attack is coming in from.

Make sure that any pre-built systems (i.e. shopping carts, blog or forum
software) is patched and up-to-date. A lot of attacks are targeted at
sites en-mass because they are found to have the same flaw which, left
unpatched, is like an open door to your server.

It's also not a bad idea to change the passwords used to access the
server, both for FTP and SSH. You might also need to scan the server
with antivirus software (this is mainly for Windows servers really) to
make sure that a rootkit hasn't been installed.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: Peter Lind on
On 7 June 2010 14:54, Igor Escobar <titiolinkin(a)gmail.com> wrote:
> Hi Folks!
>
> The portal for which I work is suffering constant attacks that I feel that
> is PHP Injection. Somehow the hacker is getting to change the cache files
> that our system generates. Concatenating the HTML file with another that
> have an iframe to a malicious JAR file. Do you have any suggestions to
> prevent this action? The hacker has no access to our file system, he is
> imputing the code through some security hole. The problem is that the portal
> is very big and has lots and lots partners hosted on our estructure
> structure. We are failing to identify the focus of this attacks.
>
> Any ideas?
>

Check all user input + upload: make sure that whatever comes from the
user is validated. Then check all output: make sure that everythin
output is escaped properly. Yes, it's an enormous task, but there's no
way around it.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
From: Phpster on

On Jun 7, 2010, at 8:54 AM, Igor Escobar <titiolinkin(a)gmail.com> wrote:

> Hi Folks!
>
> The portal for which I work is suffering constant attacks that I
> feel that
> is PHP Injection. Somehow the hacker is getting to change the cache
> files
> that our system generates. Concatenating the HTML file with another
> that
> have an iframe to a malicious JAR file. Do you have any suggestions to
> prevent this action? The hacker has no access to our file system, he
> is
> imputing the code through some security hole. The problem is that
> the portal
> is very big and has lots and lots partners hosted on our estructure
> structure. We are failing to identify the focus of this attacks.
>
> Any ideas?
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)

Can you implement a simple form dump process that would catch the form
name an the data being entered and save that? That would allow you to
at least see what script has the hole as you trap it.

Bastien

Sent from my iPod

From: Igor Escobar on
Hi Ashley!

Thanks for helping us!

OK, first thing, check all the file access logs, i.e. FTP logs, etc, just to
make sure that it's not a case of a compromised password. There's a
well-known issue with people who use FileZilla on Windows systems that
allows passwords to be easily stolen.
*
*
*We've done this before. FTP logs are clean. We limit access to FTP only
authorized machines.
*
*
*
Next, see if you can isolate the IP address(s) that might be making these
changes, and then go back over the HTTP access logs to determine what URLs
they are visiting on the site. This should give you an idea about where the
attack is coming in from.

*I'll see if I can find a way to identify the IP of the person who changed
the file last time. As he is injecting a PHP script within our server, the
script itself is changing the file so it is assumed as the default user
apache as who made the change.*

Make sure that any pre-built systems (i.e. shopping carts, blog or forum
software) is patched and up-to-date. A lot of attacks are targeted at sites
en-mass because they are found to have the same flaw which, left unpatched,
is like an open door to your server.

*We always encourage our partners to keep their system current. They are
usually blogs (wordpress) and plugins
*
It's also not a bad idea to change the passwords used to access the server,
both for FTP and SSH. You might also need to scan the server with antivirus
software (this is mainly for Windows servers really) to make sure that a
rootkit hasn't been installed.

*All access via username and password are clean, if we identify unauthorized
access, we will certainly do that!*
*
*
*Thank you for your help! Let's try to identify the IP address of the person
who changed the file and then we try to trace your browsing history!*
*
*Regards,
Igor Escobar
Systems Analyst & Interface Designer

+ http://blog.igorescobar.com
+ http://www.igorescobar.com
+ @igorescobar (twitter)





On Mon, Jun 7, 2010 at 10:03 AM, Ashley Sheridan
<ash(a)ashleysheridan.co.uk>wrote:

> On Mon, 2010-06-07 at 09:54 -0300, Igor Escobar wrote:
>
> Hi Folks!
>
> The portal for which I work is suffering constant attacks that I feel that
> is PHP Injection. Somehow the hacker is getting to change the cache files
> that our system generates. Concatenating the HTML file with another that
> have an iframe to a malicious JAR file. Do you have any suggestions to
> prevent this action? The hacker has no access to our file system, he is
> imputing the code through some security hole. The problem is that the portal
> is very big and has lots and lots partners hosted on our estructure
> structure. We are failing to identify the focus of this attacks.
>
> Any ideas?
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)
>
>
> OK, first thing, check all the file access logs, i.e. FTP logs, etc, just
> to make sure that it's not a case of a compromised password. There's a
> well-known issue with people who use FileZilla on Windows systems that
> allows passwords to be easily stolen.
>
> Next, see if you can isolate the IP address(s) that might be making these
> changes, and then go back over the HTTP access logs to determine what URLs
> they are visiting on the site. This should give you an idea about where the
> attack is coming in from.
>
> Make sure that any pre-built systems (i.e. shopping carts, blog or forum
> software) is patched and up-to-date. A lot of attacks are targeted at sites
> en-mass because they are found to have the same flaw which, left unpatched,
> is like an open door to your server.
>
> It's also not a bad idea to change the passwords used to access the server,
> both for FTP and SSH. You might also need to scan the server with antivirus
> software (this is mainly for Windows servers really) to make sure that a
> rootkit hasn't been installed.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>