Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: ESX Vmware Physically connected to different segments |
|---|---|
| Date: | Mon, 28 Jan 2008 22:04:46 +0100 |
David, look at the security advisories VMware issued in the last six months. Most of them had at least one "full compromise of host by attack from guest" (for ESX) in them. And there are quite some people out there who think this thing is long from being finished... For some more details and discussion you might look at http://www.ernw.de/content/e7/e181/e987/download989/erey_virtualization_v099r_ger.pdf thanks, Enno On Mon, Jan 28, 2008 at 03:32:41PM -0500, David M. Zendzian wrote:
Yes it does make you think twice when considering such a design, however I am not familiar with exploits at a guest domain that would effect the host specifically. While yes in 'theory' there could be some kernel hook that could allow a guest to access the host server, and I hate to be in a situation when one arrives; however, the same argument also applies to shared virtual web hosts, but only the largest companies have dedicated hosts for every domain, there will always be sharing happening which is why virtual environments are growing in popularity. Would it not be better to examine the hooks in systems that allow communication / buffers / etc in virtual environments and help ensure that they are done correctly? I know this is not really possible with VMWare, but with Xen & other systems where the code is available the issues can at least be investigated. Now if someone has code (links/docs/etc) available the detail attacks on guests effecting hosts (DOS not included, exploits taking control of services of a host from a guest, or accessing network or resources not setup for that guest), then please post them to the list so we can discuss the issues and how to address them. These same questions might also be applied to VLANs or other types of virtualization techniques that allow for greater use of the devices we have available. While there are fun ways to attack network vlans to access security domains outside of configured settings, it is the disclosure of these techniques that allowed for providers to secure the tools to a point where I know of no business I've ever worked with have dedicated network devices for every network. While I have seen different equipment on "DMZ vs Internal" networks, most still use VLAN security to segment those as well (it's a $ thing & usually a complexity thing, more parts means more people to manage, understand, change w/ out breaking, etc). I believe there are ways of deploying virtual technology that may not prevent the theoretical attack, at least provide protection against the common attacks and provide for a viable solution for the small business' I work with. The only way to be secure is to unplug, the rest of us have to work for a living :) David Kurt Buff wrote:Even if everything is configured properly, mixing security domains in a virtual hosting is a capital mistake. That's because the underlying host is also vulnerable, and attacks against a guest OS in an untrusted domain can be leveraged against the host, and from there *all* guest OSes are toast, or near to it. Don't do it, ever. Kurt On Jan 28, 2008 5:08 AM, Loupe, Jeffrey J <JLoupe@whitneybank.com> wrote:If everything is setup properly this configuration should be secure. The problem comes with misconfiguration. It's exceedingly easy for a careless admin to connect a vNic to the wrong vSwitch and allow traffic meant for the DMZ onto the trusted network. In general we disallow this practice unless only one or two trusted admins have control of the box. Even then, we audit the configuration frequently. -J ________________________________________________________________ Confidentiality Notice: This E-Mail transmission (and/or the documents accompanying it) may contain information belonging to the sender which is confidential, privileged and/or exempt from disclosure under applicable law. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this E-Mail transmission in error, please immediately notify us by return E-Mail or telephone to arrange for return of its contents including any documents.------------------------------------------------------------------------ This list is sponsored by: Cenzic Need to secure your web apps NOW? Cenzic finds more, "real" vulnerabilities fast. Click to try it, buy it or download a solution FREE today! http://www.cenzic.com/downloads ------------------------------------------------------------------------------------------------------------------------------------------------ This list is sponsored by: Cenzic Need to secure your web apps NOW? Cenzic finds more, "real" vulnerabilities fast. Click to try it, buy it or download a solution FREE today! http://www.cenzic.com/downloads ------------------------------------------------------------------------
-- Enno Rey Check out www.troopers08.org! ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Heidelberg: HRB 7135 Geschaeftsfuehrer: Roland Fiege, Enno Rey ------------------------------------------------------------------------ This list is sponsored by: Cenzic Need to secure your web apps NOW? Cenzic finds more, "real" vulnerabilities fast. Click to try it, buy it or download a solution FREE today! http://www.cenzic.com/downloads ------------------------------------------------------------------------
| Previous by Date: | Re: ESX Vmware Physically connected to different segments, David M. Zendzian |
|---|---|
| Next by Date: | Re: ESX Vmware Physically connected to different segments, Kurt Buff |
| Previous by Thread: | RE: ESX Vmware Physically connected to different segments, Loupe, Jeffrey J |
| Next by Thread: | Re: ESX Vmware Physically connected to different segments, Johnny Tsao |
| Indexes: | [Date] [Thread] [Top] [All Lists] |