<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Virtualization on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/tags/virtualization/</link>
    <description>Recent content in Virtualization on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 24 Oct 2018 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/tags/virtualization/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Hack.lu 2018: ARM IoT Firmware Emulation Workshop by Saumil Udayan Shah</title>
      <link>https://insinuator.net/2018/10/hack.lu-2018-arm-iot-firmware-emulation-workshop-by-saumil-udayan-shah/</link>
      <pubDate>Wed, 24 Oct 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/10/hack.lu-2018-arm-iot-firmware-emulation-workshop-by-saumil-udayan-shah/</guid>
      <description>&lt;p&gt;First day at &lt;a href=&#34;https://2018.hack.lu/&#34;&gt;hack.lu&lt;/a&gt;. Three of us kicked the conference off with the ARM IoT Firmware Emulation workshop by &lt;a href=&#34;https://twitter.com/therealsaumil&#34;&gt;Saumil&lt;/a&gt;. The goal of this workshop was not so much to write exploits or to pwn boxes but to learn how to build a beneficial research environment by emulating the hardware of a Linux based IoT device to run its firmware in order to run analysis and tests.&lt;/p&gt;&#xA;&lt;p&gt;First step is to obtain the firmware. This could be done by dumping it directly from the device or by downloading firmware images from the vendor. In order to dump the firmware from the device one has to obtain access to the underlying system which is usually done by finding the serial console on the hardware since this one often exposes an unauthenticated root shell. I think there is enough documentation online on how to identify and connect to a serial console so I won’t cover the details here. It’s also covered in Saumil’s &lt;a href=&#34;https://www.slideshare.net/saumilshah/hacklu-2018-make-arm-shellcode-great-again&#34;&gt;slides&lt;/a&gt; in detail. Having the bootup logs from this console will be helpful later though. While talking about baud rates for the serial console Saumil made a great pun I don’t want to withhold: “Most common is baud rate 115200. If you find a console with baud rate 9600 you are in fact talking to an acoustic coupler. That’s not an IoT device, it rather belongs to a museum.”&lt;/p&gt;</description>
    </item>
    <item>
      <title>Virtualized Training Environment with Ansible</title>
      <link>https://insinuator.net/2018/02/virtualized-training-environment-with-ansible/</link>
      <pubDate>Fri, 02 Feb 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/02/virtualized-training-environment-with-ansible/</guid>
      <description>&lt;p&gt;As Kai and I will be holding a &lt;a href=&#34;https://troopers.de/troopers18/trainings/tr18-automation-with-ansible/&#34;&gt;TROOPERS workshop on automation with ansible&lt;/a&gt;, we needed a setup for the attendees to use &lt;a href=&#34;https://www.ansible.com/&#34;&gt;ansible&lt;/a&gt; against virtual machines we set up with the necessary environment. The idea was, that every attendee has their own VMs to run ansible against, ideally including one to run ansible from, as we want to avoid setup or version incompatibilities if they set up their own ansible environment on their laptop.  Also they should only be able to talk to their own machines, thus avoiding conflicts because of accidental usage of wrong IPs or host names but also simplify the setup for the users.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Docker, DevOps &amp; Security</title>
      <link>https://insinuator.net/2016/03/docker-devops-security/</link>
      <pubDate>Thu, 10 Mar 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/03/docker-devops-security/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;this week I gave a presentation together with &lt;a href=&#34;https://twitter.com/der_Cthulhu&#34;&gt;Florian Barth&lt;/a&gt; from &lt;a href=&#34;http://stocardapp.com/&#34;&gt;Stocard&lt;/a&gt; on Docker, DevOps/Microservices, and Security — a topic and collaboration that I will definitely cover in even more detail in the future!&lt;/p&gt;&#xA;&lt;p&gt;The slides can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_Stocard_Docker-Devops-Security_fbarth-mluft.pdf&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;so long,&lt;/p&gt;&#xA;&lt;p&gt;Matthias&lt;/p&gt;</description>
    </item>
    <item>
      <title>Revisiting Xen’s x86 Emulation: Xen XSA 123</title>
      <link>https://insinuator.net/2015/03/revisiting-xens-x86-emulation-xen-xsa-123/</link>
      <pubDate>Tue, 10 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/revisiting-xens-x86-emulation-xen-xsa-123/</guid>
      <description>&lt;p&gt;In my &lt;a href=&#34;http://www.insinuator.net/2015/02/the-dangers-of-x86-emulation-xen-xsa-110-and-105/&#34; title=&#34;The Dangers of x86 Emulation: Xen XSA 110 and 105&#34;&gt;last blog post&lt;/a&gt;, I gave an overview about recent vulnerabilities discovered in the x86 emulation layer of Xen. While both of the discussed vulnerabilities only allow for guest privilege escalation, the complexity of the involved code seemed to indicate that even more interesting bugs could be discovered. So I spent some time searching for memory corruption issues and discovered a very interesting bug that resulted in &lt;a href=&#34;http://xenbits.xen.org/xsa/advisory-123.html&#34;&gt;XSA 123&lt;/a&gt; . This post gives an overview about the root cause of the bug and a short description of exploitation challenges. A follow-up post will describe possible exploitation strategies in more detail.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Dangers of x86 Emulation: Xen XSA 110 and 105</title>
      <link>https://insinuator.net/2015/02/the-dangers-of-x86-emulation-xen-xsa-110-and-105/</link>
      <pubDate>Mon, 23 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/the-dangers-of-x86-emulation-xen-xsa-110-and-105/</guid>
      <description>&lt;p&gt;&lt;img src=&#34;http://www.insinuator.net/wp-content/uploads/2015/02/xen-300x81.png&#34; alt=&#34;Xen Logo&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;Developing a secure and feature rich hypervisor is no easy task. Recently, the open source Xen hypervisor was affected by two interesting vulnerabilities involving its x86 emulation code: &lt;a href=&#34;http://xenbits.xen.org/xsa/advisory-110.html&#34;&gt;XSA 110&lt;/a&gt; and &lt;a href=&#34;http://xenbits.xen.org/xsa/advisory-105.html&#34;&gt;XSA 105&lt;/a&gt;. Both bugs show that the attack surface of hypervisors is often larger than expected. XSA 105 was &lt;a href=&#34;//labs.bitdefender.com/wp-content/uploads/downloads/2014/10/Gaining-kernel-privileges-using-the-Xen-emulator.pdf&#34;&gt;originally reported&lt;/a&gt;) by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the emulation routines of several critical system instructions including LGDT and LIDT. The vulnerable code can be reached from unprivileged user code running inside hardware virtual machine (HVM) guests and can be used to escalate guest privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns insufficient checks when emulating long jumps, calls or returns.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cisco Cloud Services Router 1000V and the Virtual Matryoshka</title>
      <link>https://insinuator.net/2014/07/cisco-cloud-services-router-1000v-and-the-virtual-matryoshka/</link>
      <pubDate>Mon, 28 Jul 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/07/cisco-cloud-services-router-1000v-and-the-virtual-matryoshka/</guid>
      <description>&lt;p&gt;Recently we started playing around with Cisco’s virtual router, the CSR 1000V, while doing some protocol analysis. We found Cisco offering an BIN file for download (alternatively there is an ISO file which contains a GRUB boot loader and the BIN file, or an OVA file which contains a virtual machine description and the ISO file) and file(1) identifies it as DOS executable:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ file csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin &#xA;    csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin: DOS executable (COM)&lt;/code&gt;&lt;/pre&gt;&#xA;&lt;p&gt;We didn’t manage to get the file running, neither in a (Free-)DOS environment, nor in a wine virtual DOS environment, except using the boot loader from the ISO file. So we became curious as for the structure and ingredients of the file.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Serial Port Debugging Between two Virtual Machines in VMware Fusion</title>
      <link>https://insinuator.net/2014/01/serial-port-debugging-between-two-virtual-machines-in-vmware-fusion/</link>
      <pubDate>Thu, 16 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/serial-port-debugging-between-two-virtual-machines-in-vmware-fusion/</guid>
      <description>&lt;p&gt;In the course of our virtualization research, we came across a certain technical issue we couldn’t find an easy solution on knowledge bases and the like. However, as we found the question several times on the web, the following post gives just a short hint on a technical detail.&lt;/p&gt;&#xA;&lt;p&gt;If you want to connect two virtual machines in VMware Fusion using a serial port (e.g. for debugging purposes), Fusion doesn’t provide you an GUI option to configure that. However, if you just add the following config to the debugger system’s VMX file:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Exploiting Hyper-V: How We Discovered MS13-092</title>
      <link>https://insinuator.net/2014/01/exploiting-hyper-v-how-we-discovered-ms13-092/</link>
      <pubDate>Tue, 14 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/exploiting-hyper-v-how-we-discovered-ms13-092/</guid>
      <description>&lt;p&gt;During a recent research project we performed an in-depth security assessment of Microsoft’s virtualization technologies, including Hyper-V and Azure. While we already had experience in discovering security vulnerabilities in other virtual environments (e.g. &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building/&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2011/07/the-key-to-your-datacenter/&#34;&gt;here&lt;/a&gt;), this was our first research project on the Microsoft virtualization stack and we took care to use a &lt;a href=&#34;http://www.insinuator.net/2013/05/analysis-of-hypervisor-breakouts/&#34;&gt;structured evaluation strategy&lt;/a&gt; to cover all potential attack vectors.&lt;br&gt;&#xA;Part of our research concentrated on the Hyper-V hypervisor itself and we discovered a critical vulnerability which can be exploited by an unprivileged virtual machine to crash the hypervisor and potentially compromise other virtual machines on the same physical host. This bug was recently patched, see &lt;a href=&#34;https://technet.microsoft.com/en-us/security/bulletin/ms13-092&#34;&gt;MS13-092&lt;/a&gt; and our &lt;a href=&#34;http://www.insinuator.net/2014/01/state-of-virtualization-security-14/&#34;&gt;corresponding post&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>State of Virtualization Security ‘14</title>
      <link>https://insinuator.net/2014/01/state-of-virtualization-security-14/</link>
      <pubDate>Sun, 05 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/state-of-virtualization-security-14/</guid>
      <description>&lt;p&gt;First of all, I hope you all had a good start to 2014. Having some time off “between the years” (which is a German saying for the time between Christmas and NYE), I caught up on several virtualization security topics.&lt;/p&gt;&#xA;&lt;p&gt;While virtualization is widely accepted as a sufficiently secure technology in many areas of IT operations (also for sensitive applications or exposed systems, like &lt;a href=&#34;http://www.insinuator.net/2009/12/some-reflections-on-virtualization-security-part-1/&#34;&gt;DMZs&lt;/a&gt;) by 2014, there are several recent vulnerabilities and incidents that are worth mentioning.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Analysis of Hypervisor Breakouts</title>
      <link>https://insinuator.net/2013/05/analysis-of-hypervisor-breakouts/</link>
      <pubDate>Mon, 20 May 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/05/analysis-of-hypervisor-breakouts/</guid>
      <description>&lt;p&gt;In the course of a current virtualization research project, I was reviewing a lot of documentation on hypervisor security. While “hypervisor security” is a very wide field, hypervisor breakouts are usually one of the most (intensely) discussed topics. I don’t want to go down the road of rating the risk of hypervisor breakouts and giving appropriate recommendations (even though we do this on a regular base which, surprisingly often, leads to almost religious debates. I know I say this way too often:I’ll cover this topic in a future post ;)), but share a few observations of analyzing well-known examples of vulnerabilities that led to guest-to-host-escape scenarios. The following table provides an overview of the vulnerabilities in question:&lt;/p&gt;</description>
    </item>
    <item>
      <title>BPDU Guard in Virtualized Environments (2)</title>
      <link>https://insinuator.net/2013/04/bpdu-guard-in-virtualized-environments-2/</link>
      <pubDate>Wed, 17 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/04/bpdu-guard-in-virtualized-environments-2/</guid>
      <description>&lt;p&gt;Just a quick update here: Ivan (who gave the magnificent &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-presentations/index.html#virtual_firewalls&#34;&gt;Virtual Firewalls&lt;/a&gt; talk at &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; recently) blogged about this and some guy added some feedback from an environment with Cisco FEX and “one of the server guys start[ing] a Citrix Netscaler” ;-). See the second comment to his &lt;a href=&#34;http://blog.ioshints.info/2013/04/vm-bpdu-spoofing-attack-works-quite.html&#34;&gt;post&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This shows, once more, that the dependencies of various technologies (and what they are used for) must be well understood in cloud/virtualized environments. Complexity … but who do we tell. Y’ all know that, right?&lt;/p&gt;</description>
    </item>
    <item>
      <title>VMDK Has Left the Building – Write Access</title>
      <link>https://insinuator.net/2012/09/vmdk-has-left-the-building-write-access/</link>
      <pubDate>Wed, 05 Sep 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/09/vmdk-has-left-the-building-write-access/</guid>
      <description>&lt;p&gt;In our last series of posts regarding the VMDK file inclusion attack, we focused on &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building/&#34;&gt;read access&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building-follow-up/&#34;&gt;prerequisites&lt;/a&gt; for the attack, but avoided stating too much about potential write access. But as we promised to cover write access in the course of our future research, the following post will describe our latest research results.&lt;/p&gt;&#xA;&lt;p&gt;First of all, the same &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building-follow-up/&#34;&gt;prerequisites&lt;/a&gt; (which will be refined a little bit more later on) as for read access must be fulfilled and the same &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building/&#34;&gt;steps&lt;/a&gt; have to be performed in order to carry out the attack successfully. If that is the case, there are several POIs (Partitions Of Interest) on a ESXi hypervisor that are interesting to include:&lt;/p&gt;</description>
    </item>
    <item>
      <title>VMDK Has Left the Building — FAQ</title>
      <link>https://insinuator.net/2012/06/vmdk-has-left-the-building-faq/</link>
      <pubDate>Sun, 17 Jun 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/06/vmdk-has-left-the-building-faq/</guid>
      <description>&lt;p&gt;As we are receiving a lot of questions about our &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building/&#34;&gt;VMDK has left the building post&lt;/a&gt;, we’re compiling this FAQ post — which will be updated as our research goes on.&lt;/p&gt;&#xA;&lt;p&gt;** **&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;How does the attack essentially work?&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;em&gt;By bringing a specially crafted VMDK file into a VMware ESXi based virtualization environment. The specific attack path is described &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building-follow-up/&#34;&gt;here&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;* *&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;What is a VMDK file?&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;em&gt;A combination of two different types of VMDK files, the plain-text descriptor file containing meta data and the actual binary disk file, describes a VMware virtual hard disk. A detailed description can be found &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building/&#34;&gt;here&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>VMDK Has Left the Building — Some Nasty Attacks Against VMware vSphere 5 Based Cloud Infrastructures</title>
      <link>https://insinuator.net/2012/05/vmdk-has-left-the-building-some-nasty-attacks-against-vmware-vsphere-5-based-cloud-infrastructures/</link>
      <pubDate>Thu, 24 May 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/05/vmdk-has-left-the-building-some-nasty-attacks-against-vmware-vsphere-5-based-cloud-infrastructures/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Update #1:&lt;/strong&gt; Slides are available for download &lt;a href=&#34;http://www.insinuator.net/2012/05/vmdk-has-left-the-building-slides-available/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;In the course of our ongoing &lt;a href=&#34;http://www.troopers.de/archives/troopers12/agenda/auditing-the-cloud-workshop/&#34;&gt;cloud security research&lt;/a&gt;, we’re continuously thinking about potential attack vectors against public cloud infrastructures. Approaching this enumeration from an external customer’s (speak: attacker’s 😉 ) perspective, there are the following possibilities to communicate with and thus send malicious input to typical cloud infrastructures:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Management interfaces&lt;/li&gt;&#xA;&lt;li&gt;Guest/hypervisor interaction&lt;/li&gt;&#xA;&lt;li&gt;Network communication&lt;/li&gt;&#xA;&lt;li&gt;File uploads&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;As there are already several successful exploits against management interfaces (e.g. &lt;a href=&#34;http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/AmazonSignatureWrapping.pdf&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2011/07/the-key-to-your-datacenter/&#34;&gt;here&lt;/a&gt;) and guest/hypervisor interaction (see for example &lt;a href=&#34;http://www.vmware.com/security/advisories/VMSA-2012-0009.html&#34;&gt;this one&lt;/a&gt;; yes, this is the funny one with that ridiculous recommendation “Do not allow untrusted users access to your virtual machines.” ;-)), we’re focusing on the upload of files to cloud infrastructures in this post. According to our experience with major &lt;em&gt;Infrastructure-as-a-Service&lt;/em&gt; (IaaS) cloud providers, the most relevant file upload possibility is the deployment of already existing virtual machines to the provided cloud infrastructure. However, since a quick additional research shows that most of those allow the upload of VMware-based virtual machines and, to the best of our knowledge, the VMware virtualization file format was not analyzed as for potential vulnerabilities yet, we want to provide an analysis of the relevant file types and present resulting attack vectors.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Trust &amp; Control in the Age of Virtualization and the Cloud</title>
      <link>https://insinuator.net/2010/11/trust-control-in-the-age-of-virtualization-and-the-cloud/</link>
      <pubDate>Wed, 17 Nov 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/11/trust-control-in-the-age-of-virtualization-and-the-cloud/</guid>
      <description>&lt;p&gt;Two days ago I gave the keynote at an industry event, reflecting on the changing role of traditional security controls in the age of virtualization and the cloud. As this was an updated version of the stuff distributed in the conference proceedings, some people have asked for it. Voilà, &lt;a href=&#34;http://www.ernw.de/content/e7/e181/e1612/download1614/ERNW_LANline_VirtCloudSec_Keynote_ger.pdf&#34;&gt;here we go&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;have a good one,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>Research on “Application Virtualization” – Results online now</title>
      <link>https://insinuator.net/2010/08/research-on-application-virtualization-results-online-now/</link>
      <pubDate>Mon, 16 Aug 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/08/research-on-application-virtualization-results-online-now/</guid>
      <description>&lt;p&gt;Just wanted to let you know that we sent out &lt;a href=&#34;http://ernw.de/content/e15/e28/e1575/download1577/ERNW_Newsletter_32_ThinApp_signed_en_ger.pdf&#34;&gt;ERNW Newsletter 32&lt;/a&gt; end of last week. As we &lt;a href=&#34;http://www.insinuator.net/2010/08/application-virtualization-as-browser-security-control/&#34;&gt;promised&lt;/a&gt; it includes the results of  research regarding the question “Is browser virtualization a valid security control in order to mitigate browser based security risks?”.&lt;/p&gt;&#xA;&lt;p&gt;Simon did a great job with writing the latest newsletter. It’s a 30-page document which should help you to have a basis for well-informed decisions when it comes to the deployment of an application virtualization technology.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Application Virtualization as Browser Security Control?</title>
      <link>https://insinuator.net/2010/08/application-virtualization-as-browser-security-control/</link>
      <pubDate>Mon, 09 Aug 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/08/application-virtualization-as-browser-security-control/</guid>
      <description>&lt;p&gt;One of the biggest pains in the ass of most ISOs – and subsequently subject of fierce debates between business and infosec – is the topic of “Browser Security”, i.e. essentially the question “How to protect the organization from malicious code  brought into the environment by users surfing the Internet?”.&lt;/p&gt;&#xA;&lt;p&gt;Commonly the chain of events (of a typical malware infection act) can be broken down to the following steps:&lt;/p&gt;&#xA;&lt;p&gt;1.) Some code – no matter if binary or script code – gets transferred (mostly: downloaded) to some system “from the Internet”, that means “over the network”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some reflections on virtualization security, part 1</title>
      <link>https://insinuator.net/2009/12/some-reflections-on-virtualization-security-part-1/</link>
      <pubDate>Mon, 07 Dec 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/12/some-reflections-on-virtualization-security-part-1/</guid>
      <description>&lt;p&gt;Today was an interesting day, for a number of reasons. Amongst those it stuck out that we were approached by two very large environments (both &amp;gt; 50K employees) to provide security review/advise, as they want to “virtualize their DMZs, by means of VMware ESX”.&lt;br&gt;&#xA;[yes, more correctly I could/should have written: “virtualize some of their DMZ segments”. but this essentially means: “mostly all of their DMZs” in 6-12 months. and “their DMZ backend systems together with some internal servers” in 12-24 months. and “all of this” in 24-36 months. so it’s the same discussion anyway, just on a shifted timescale ;-)]&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
