Full Disclosure mailing list archives
Re: Getting Off the Patch
From: Pete Herzog <lists () isecom org>
Date: Mon, 17 Jan 2011 16:12:42 +0100
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 () isecom org 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/
Current thread:
- Re: Getting Off the Patch, (continued)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 19)
- Re: Getting Off the Patch Cor Rosielle (Jan 19)
- Re: Getting Off the Patch Pete Smith (Jan 19)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 19)
- Re: Getting Off the Patch Cal Leeming [Simplicity Media Ltd] (Jan 19)
- Re: Getting Off the Patch Phil (Jan 19)
- Re: Getting Off the Patch Tracy Reed (Jan 19)
- Re: Getting Off the Patch Pete Smith (Jan 19)
- Re: Getting Off the Patch Valdis . Kletnieks (Jan 20)
- Re: Getting Off the Patch Procmail (Jan 18)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Григорий Братислава (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Thor (Hammer of God) (Jan 17)
- Re: Getting Off the Patch Pete Herzog (Jan 17)
- Re: Getting Off the Patch Roger Casteele (Jan 16)
- Re: Getting Off the Patch Christian Sciberras (Jan 17)
- Re: Getting Off the Patch Cor Rosielle (Jan 13)