vCenter has a flaw that provides network read access to arbitrary files. VMware has released an advisory with patch information (VMSA-2011-0008):

A directory traversal vulnerability allows an attacker to remotely retrieve files from vCenter Server without authentication. In order to exploit this vulnerability, the attacker will need to have access to the network on which the vCenter Server host resides.

If you have network access to vCenter and login as a user, the same advisory points out that session IDs are exposed.

The SOAP session ID can be retrieved by any user that is logged in to vCenter Server. This might allow a local unprivileged user on vCenter Server to elevate his or her privileges.

Scientists recently proposed that some spiders are able to spin silk from their legs (tarsi) to hang onto slippery surfaces. The claim was disputed, but now it has been proven.

Like all spiders, tarantulas (family Theraphosidae) synthesize silk in specialized glands and extrude it from spinnerets on their abdomen. In one species of large tarantula, Aphonopelma seemanni, it has been suggested that silk can also be secreted from the tarsi but this claim was later refuted. We provide evidence of silk secretion directly from spigots (nozzles) on the tarsi of three distantly related tarantula species: the Chilean rose, Grammostola rosea; the Indian ornamental, Poecilotheria regalis; and the Mexican flame knee, Brachypelma auratum, suggesting tarsal silk secretion is widespread among tarantulas. We demonstrate that multiple strands of silk are produced as a footprint when the spider begins to slip down a smooth vertical surface.

Slipping and falling would be fatal to a tarantula, so the silk from their legs is given as an example of a control developed for survival.

Verizon has publicly shared some perspective on how they approach PCI DSS compliance as a cloud service provider:

But what does PCI DSS compliance by a cloud services provider actually mean and what value does this provide to an enterprise?

Cloud services providers, such as Verizon, which have obtained PCI DSS Level 1 compliance, must undergo extensive preparation, testing and assessment of their cloud environment to verify that it is built and operated in a manner that meets the security standards that enterprises require. Cloud services providers must undergo a third-party audit and, due to the nature of a cloud services provider’s environment, there is also the responsibility for day-to-day governance required to maintain its security posture and provide the necessary transparency to customers. In addition, achievement of PCI DSS compliance by a cloud services provider for its cloud infrastructure offers customers verification that the following will occur:

• Annual penetration tests
• Quarterly vulnerability scanning using an Approved Scanning Vendor
• Architecture reviews validating environment isolation on a per customer basis
• Virtual environment configuration reviews of hypervisor and virtual switches
• Log collection and auditability
• Authentication
• Process and procedure definition and documentation

Heroku has been added to the list of cloud sites with availability issues. Their write-up makes me nostalgic for my Motorola pager and the IBM AIX systems that always used to wake me up at night.

The primary on-call engineer was paged and quickly escalated the problem to the on-call incident commander who began investigating. The situation very quickly worsened and some nodes became unresponsive, causing applications with DNS records pointing to those IP addresses to become unreachable.

Oh, but wait, this isn’t some old traditional IT environment. This is the cloud. Applications are unreachable? A traditional IT environment attack, a flood of SYN packets, is to blame.

These attacks affected any customers who had their DNS configured to direct a root domain name (i.e.: mydomain.com, but not www.mydomain.com) at the IP addresses we publish in our documentation. [2] Customers with applications directed via CNAME records at proxy.heroku.com were generally unaffected. Because Heroku.com was also directed at these IP addresses, deploys via git push heroku were similarly affected.

This outage comes just as cloud DDoS mitigation marketing is taking off and encouraging companies to trust their service providers.

VeriSign, which now sells a $35K/year DDoS mitigation service, has just published a scare-report that the chance of attack is higher than ever.

Examination of a global sample of websites revealed that when availability problems occur, sites hosting their own DNS (representative of most enterprises today) are much more impacted than those using third-party managed DNS providers

The CloudFlare blog explains how they would perform traffic analysis for you and then apply limits to reduce the impact duration of DoS attacks.

One of our user’s site was under a denial of service (ddos) attack earlier this week. You can see the surge in traffic (the green line). Then, soon after, you can see the CloudFlare system start to learn from the change in data and start identifying that the new traffic is indeed an attack (red line), rather than a surge in legitimate traffic. As CloudFlare starts to identify the new traffic as an attack, the system starts to block it at our edge nodes around the world.

I wonder if we should call this the Boa Constrictor defence to DDoS — it looks like a well-fed snake.

There are numerous theoretical advantages to having a service provider respond on your behalf to an incident. The reality, however, may be a very different story. One big question to ask a provider is whether they will “own” or personally accept the incident as their own if you transfer responsibility. And that begs the question of whether an incident is in any way a consequence of their architecture/environment.