Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:Number 5? (Score 5, Informative) 268

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.

Comment Re:Big problem, but addressable (Score 5, Informative) 179

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.
Security

Submission + - Entropy Problems for Linux in "The Cloud" (forbes.com)

CalTrumpet writes: "Our research group recently spoke at Black Hat USA on the topic of Cloud Computing Security. One of the interesting outcomes of our research was the discovery that the combination of virtualization technologies and public system images results in a problem for random number generation on guest operating systems. This is especially true for Linux, since it's PRNG uses only a small set of entropy gathering events and virtual Linux images often generate SSH host keys within seconds of their initial boot. The slides themselves are available here"

Slashdot Top Deals

"The trouble with doing something right the first time is that nobody appreciates how difficult it was." -- Walt West

Working...