Thursday, March 1, 2012

CIFS Null Session to Domain Admin

I am beginning to love CIFS Null Sessions (CNS). I have had incredible success on pen tests when this vulnerability is discovered and quite often Domain Admin was right around the corner... We've seen clients ignore it time and time again but I cannot stress how problematic it can be for your network.

This post will become a living document and I'll update is as I encounter CNS and subsequent actions that are useful.

Not all CNS are useful, but when you can enumerate things like user accounts and password policies, your CNS can become very valuable. My favorite tool for CNS enumeration is winfo.exe.

For example, looking at the output of winfo, what does this information tell us about the environment?

Key Observations:
  1. Except for the 60 day rotation, they have a terrible password policy. 3 character minimum?! Damn! This also indicates they probably have lots of other problems on their network if their password policy is so weak.
  2. The lockout duration is 10 minutes and then a locked out account is automatically reset. This is probably the most important piece of information. Why? Because locked out accounts don't require an human Administrator to unlock them. Their employees are probably trained on an account lockout to just wait it out and try again.
  3. The lockout threshold is 5 so we get about 3-4 brute force password tries on each account if we want to be "stealthy" and not lock them out. However, even if we do lock an account out, it likely wont raise any red flags since it will auto-reset in 10 minutes!
There are so many issues with that password policy, it's mind blowing.
In addition to that juicy information, if you're lucky enough to get a list of user accounts from winfo, you can begin to tailor a brute force attack based on your discovered insider information. The way I like to do this is to use the smb_login module against a domain controller, or some other file server with port 445 open.

When you're configuring the module try to pick a single password that you think will have the best chance of working. The module I configured below will try the the following combinations: username as the password, blank password and the word "password." That's a total of three tries for each user in our enumerated list which is less than the 5 that will lock out the account. I picked "password" because their password policy above was so bad, it just seemed like it had to work ;) If you wanted to squeeze one more password in, just create a text file with 2 passwords in it and set the PASS_FILE option and remove your SMBPass option instead.

Running the module in my situation against 2000 user accounts yielded 12 valid sets of credentials. But what the hell can we do with these accounts if they're just basic low level user accounts that may/may not have access to anything?

First place I look is the NETLOGON share on the domain controller. Since you have a valid domain account, you'll automatically have access to the NETLOGON share. In my case, I looked through all their logon scripts that are stored in this location and found a few that sounded "interesting." Opening them up revealed hard coded domain credentials in the scripts. They were even nice enough to make this account a Domain Admin. Game over.

Why do admins do this? As a former admin, I know exactly why. When you try to remove administrative privileges from all your employee computers as a best practice, you'll run into situations where you want to install printer, software or make changes to their systems that require admin access. You can either touch every machine manually, or script it, with credentials that have the rights to make the changes you want. Often these scripts will get left up there and forgotten forever.

I used to do this too but was diligent about disabling this "service account" when we were done using it and also removing the script from the NETLOGON share.

Here are some other ideas if you're not this lucky on what you can do with your newly discovered accounts:

  1. See if the accounts appear to be service related. For example, "faxingaccount" probably has to do with their fax server. Figure out the fax server and test these credentials. If it's a local admin account, you're probably in business.
  2. Try these accounts against file shares. It's possible they're a part of employee file access groups.
  3. Use an LDAP browser with these credentials to browse AD. You can get a feel for how the company is organized, how their organization AD units are structured and I have even seen passwords written in the comments fields of accounts. 
Chaining all these attacks together from one CIFS Null Session can really be devastating.

Happy pwnag3!

No comments: