Wednesday, July 4, 2007

Why is it still so easy to hack Windows networks?

The other day, a few of us at work were discussing how internal Windows penetration tests have remained ridiculously easy, irrespective of the client, since we first started in this field. Between the four of us, we've done at least twenty or thirty Windows internal pen-tests in the last few years, against both gigantic and small networks. Regardless of the target's size and complexity, we can usually get domain administrator control of the environment within one day, or even a few hours, and it's not through any fancy attack techniques either. The progression is almost always the same:
  1. Compromise standalone servers/workstations through a handful of common attacks.
  2. Run LSAdump to obtain LSA secrets, run PWdump to crack local account hashes.
  3. Use recovered credentials to gain access to domain accounts.
Step #1 usually is accomplished by finding SQL servers with blank or weak 'SA' passwords and gaining local admin through xp_cmdshell. Yes, this is still a problem, even in highly sensitive environments where you'd never expect it. We also often find old IIS servers permitting anonymous FrontPage authoring, load up hostile ASP to pass-through commands, and pop the server that way. A third approach is to enumerate users on Windows hosts via anonymous NetBIOS, and test them for blank passwords & password=username. Local accounts are almost always neglected on at least a few hosts. These are the "low-hanging-fruit" for which we'll immediately scan, before attempting more involved attacks. They are incredibly old issues (MS SQL 2005 won't let you give SA a blank password, and anonymous authoring hasn't been enabled by default in FrontPage for years) but in a big environment you'll always find some susceptible systems that were "missed" for some reason or other.

Once we've got Local Admin on a box (one way or another), PWdump gives us the local user password hashes and LSAdump gives us the LSA secrets. It's especially fun to crack the Local Admin account password with PWdump and then realize they're using the same password for Local Admin on every other Windows box. Typical excuse: "It's too hard to manage the Local Admin accounts on so many machines, so we just use the same password on all of them."

But I usually have the best luck with passwords in the LSA secrets - there's almost always some service account running as a domain administrator with the same credentials. It's absolutely ridiculous how liberally some organizations assign AD privileges - "Oh, XXX service didn't run right, so we had to make the account a domain admin." Horrible reasoning. And sometimes you just get a local user account that has the same password for his or her equivalent domain account.

In some cases, we'll get a domain admin account but it won't be allowed to establish Terminal Services connections. That's really not much of a security control when you can still shuttle files on and off the machine with NetBIOS and execute commands with psexec (or schedule commands on the remote host with "at", or remotely start/stop services and edit the registry, etc.).

The bottom line is that although these attack techniques and vulnerabilities are old and easy to fix, they persist year after year, client after client. I think there are a few contributing factors:

  • It is difficult to create and maintain an accurate inventory of all systems active in an environment. If you don't know it's there, you can't make sure it's secure.
  • Many organizations already know about the vulnerabilities we find, but had assumed them to be acceptable risks. Sometimes it takes a penetration test to really drive home the "real-world" impact of an issue before management will understand and act on it. In other cases, risks are accepted because developers or sys-admins successfully argue that correcting the flaw would "break" key functionality - often because they didn't feel like going through the trouble of making it work.

  • Applying the principle of least-privilege to Windows domains and their user accounts is exponentially more difficult as an environment grows in size and complexity.

  • (potentially controversial point) The barrier to entry for Windows system administrators is lower than that for Unix or networking admins, simply because at a superficial level, it is easier to stand up and maintain a Windows environment. As a result, many are often less technically proficient than they need to be. This is based purely on my anecdotal observations, but other some of my other colleagues agree.
I certainly acknowledge that it must be hell to be on the other end of a pen-test, even if you are a diligent administrator - it's much easier to break down one door rather than defend hundreds of them. I just get frustrated when I see really basic security vulnerabilities that are obviously the product of poor controls, organization, and leadership. It shouldn't be That easy for any unprivileged user to own your environment.

Thoughts/comments are welcome.

Labels: ,

0 Comments:

Post a Comment

<< Home