Re: [Full-disclosure] Getting Off the Patch

[Pete Herzog <lists@xxxxxxxxxx>]

Zach,

On 1/14/2011 9:31 PM, Zach C wrote:
> Pete, let's say one of the assets I want to protect is the code for my site 
> running on the web server. Now, let's say my web server has a serious bug 
> that allows a given attacker to read the raw contents (i.e. code) of *any* 
> file the web server has access to. In this circumstance, the web server still 
> must be able to interact with these assets by reading and subsequently 
> executing them for continued operations, but it is this very same vector that 
> is being exploited by the attacker. Are there any controls, besides patching, 
> that can be applied here without inhibiting current operations in any way? 
> (Switching web servers not being an option for various reasons, even though 
> that's where I would go first).

I think the question calls for some more information for which I have 
to make many assumptions. The OSSTMM 3 categorized 10 op controls and 
they should be applied to each interactive point for each vector in 
places where thee is no trust. This is especially true of an 
Internet-based service where connections can come from anywhere.

One of the main reasons we published the research we did in the OSSTMM 
is because it makes very clear there is a gap in solutions to cover 
various op controls in elegant and meaningful ways. We do hope that 
the markets can fill these gaps for various systems and especially 
make them easy to apply and configure for the general public.

Your question is a good one and it's a direction we're looking to 
cover with the Applied OSSTMM for Web Apps project. Hopefully, now 
that we have the basis of our research, we can expand it into 
specific, practical scenarios.

Now without writing a how-to manual as an answer, one I don't have 
time for, I will cover these points:

There are 3 main vectors here that require controls to protect against 
your proposed scenario. The op controls that we would put in place 
will not just exist to protect against this one bug but against many 
bugs known and unknown. Mostly, when creating a web service, these are 
the types of controls you want applied from the start and not just 
when the problem appears. I also want to make clear that these 
controls are just for solving this problem and in no way institutes a 
complete array of controls for any web service environment. You would 
not do all this for one problem. However if this was done in advance, 
this bug would not be a problem and you would not need to race to 
patch it before bad things happen.

Also, before any detractors care to take this apart piece by piece, 
please remember I'm clearly saying these solutions may not work for 
all cases and in this short time, I'm not being thorough. However, I 
hope that it's enough to get you to understand how the OSSTMM breaks 
these operations down so you can think along these lines too and help 
find other and better solutions for the same problem.

Internet to Server: here we want to control the possibility and 
severity of an attack

+ Authentication: a white-list ingress and egress filtering on packet 
types and web service requests. In this case, NOT from the web service 
itself.

+ Confidentiality: SSL over HTTP will prevent cache poisoning and some 
attacks against communication in transit.

+ Privacy: the white-list authentication mechanism will have the 
benefit of allowing you to keep information about your service from 
being fingerprinted.

+ Subjugation: once again, provided by the white-list to force users 
to use these controls upon connection.


Server OS: here we want to limit the damage that can be done should 
the attack be applied.

+ Authentication: where possible create proper discretion between the 
privileges of the web service and the files it may access. Remove 
files and code you would not want seen or executed if possible. 
Specifically allow only certain files to be executed by the web 
service and assure they are designated as execute only by the web 
service.

+ Privacy: remove or change default directories and file names where 
possible.

+ Integrity: a means for maintaining the static files remain static. 
Changes will be refused or undone immediately from a read-only source.

+ Alarm: immediate notification from the web service should any 
request outside the white-list be requested on the server itself.

+ Subjugation: least privileges designation.


Server to DMZ: here we want to prevent the attack from affecting other 
servers

+ Authentication: Make sure that servers are configured not to be able 
to directly be accessed by other servers in the network. White-list 
administrative access if needed. Also a white-list egress filtering on 
packet types. In this case, NOT from the server itself.

+ Subjugation: once again, provided by the white-list to force users 
to use these controls upon connection.


Again, while this is not the most exhaustive or creative list, it's a 
way that controls can be considered and applied to a web service to 
prevent certain bugs from being exploitable. My goal here is to help 
you think in this type of structured, methodical approach to improve 
security.

Sincerely,
-pete.

-- 
Pete Herzog - Managing Director - pete@xxxxxxxxxx
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/