There are several methods of escalating to domain admin once you have Local Administrator access on a member workstation. It is our experience that most large Enterprise AD networks are vulnerable to at least one of these issues:

1. Crack a common local user with a shared password, like "MACHINENAME\ITAdmin". Alternatively, you can use an NTLM hash as a password equivalent with custom tools, like my colleague Jesse Burns demonstrated in 2005.

2. Crack the cached hash of a domain admin from the SECURITY hive. This hash is created by an interactive login to the machine, i.e. via the local keyboard or RDP. These hashes are not stored after remote RPC, SMB, etc...

3. Install a keystroke logger and wait for an interactive login by an Administrator. A good technique is to open an IT ticket as the victim, which often triggers an admin to remotely access the machine via RDP.

4. Wait for an automated process to touch the box with domain admin credentials. Common tools that do this are patch management systems, vulnerability scanners, software licensing compliance tools and event log aggregation systems. When the handshake for the network service begins (say over DCE RPC), the attacker rejects the Kerberos ticket and requests a downgrade to LanMan or NTLMv1. Either one of those protocols will allow an attacker to use a pre-computed time-memory trade-off to quickly recover the password (aka Rainbow Tables).

5. Wait for an automated "touch" and perform a pass-the-hash attack. This is possible on services that do not enforce at least "Packet Integrity" security. The admin and the victim machine legitimately exchange credentials, but the resulting authenticated connection can now be modified by the attacker. Again, see Burns 2005.

While the origin of the issue is the virtualization layer, it is more specifically a cloud problem because most IaaS/VPS providers use standard images with a public random seed file, so everybody's machine initializes up to the same state (RTC + random seed + handful of interrupts).

Actually, /dev/random and /dev/urandom have their own, separate secondary pools that are fed off of a main pool when entropy is "depleted" in the second level pools. This is an area of research for us as well, since Linux's entropy estimation algorithm fails in situations where the timing deltas of entropy gathering events (IRQs and disk IOs) are actually predictable, so it's possible that the second level pools are not being refreshed at appropriate times.

If you write to /dev/urandom, it goes into the primary pool by tradition. This is what the rc scripts do on bootup with the random seed file on disk.

BTW, it's absolutely the wrong solution to get entropy from another source on the network (for many reasons, but one is that you can't do a secure HTTPS handshake without, you guessed it, unguessable random numbers). The whole point here is that we are looking for a way for 500 Linux instances on EC2 to have different entropy pools before the kernel completes boot. The only possible solution is for the hypervisor (Xen for Amazon) to provide a simulated HW RNG that pulls entropy from a real HW RNG or from an entropy daemon in the hypervisor.

The best way to learn about Linux RNG basics is Gutterman et. al. Analysis of the Linux Random Number Generator. Several of the issues they describe have been addressed, such as their PFS concerns, but their description of the entropy pools is still accurate.

Howdy... I'm actually one of the contributors to the book. We have been working with Adobe and CERT for a while on this issue, and we felt that as much time as is reasonable had elapsed since the initial reporting. The disclosure of security vulnerabilities is always a complicated ethical issue, and you have to weigh the public's right to know with the possibility that a speedy fix may reduce the overall damage from disclosure. Even with several months of work, "patching" the vulnerabilities is complicated, since the issues exist in the SWF files themselves and not in Flash player, so the only solution is for website owners to re-generate their Flash applets with the updated generators, which should be out shortly.

A more formal vulnerability report is being co-ordinated with CERT and should be out soon with the details of the issues.