Numerous technical articles emerge each day about the latestvulnerabilities, flaws, exploits, and whatnot. That's great and all (who hasn't simultaneously groaned and cheered whenthey find an MS08-067 exploitable machine on a pentest, 4+ years after thevulnerability was documented?), but why bother going to all the trouble whenusers often give you all the ammo you need to successfully compromise yourtargets?
In this post, I'd like to cover some of the terrible, awfulthings users do that help pentesters in their duties (and the bad guys aswell). They may not be the sole reasonfor compromises, but they can greatly accelerate them in an environment wherepure technical machismo would be left out in the cold. Let's begin, using some (terribly named)characters.
Reuse, Recycle, Regurgitate
Oh, how users hate to remember passwords, especially thosedarn nasty "complex" ones (which we've railed against in past GSRs). If JoeUser gets a great password scheme going, such as the name of his favorite Rushsong, merged with 2 random objects on his desk, etc, it's just so hardto be continuously creative! Therefore,in the instances where Joe must utilize not one but two separateaccounts (such juser and juser-a for his Domain Administrator functions), it's mucheasier for him to just use the same (or similar) passwords for both. After all, what's it going to hurt?
Enter our intrepid hero, Peter the Pentester. Peter is having an easy time getting userhashes through a variety of methods, but has been stonewalled thus far bytightly locked down servers and a strict least-privilege model. Peter has Joe's user password, but hasn'tbeen able to find an accessible machine where the admin login has been used,even in mscache.
"Aha!" says Peter. "Iwonder if Joe reuses passwords between his logins?" Sure enough, within seconds, our intrepidpentester has escalated an individual user compromise into the compromise ofthe entire domain – all through non-technical means.
In case you're curious what this looks like behind the scenes, here is what the NT hash representation of Joe's mistake would look like. The unsalted nature of NT hashes allows for a quick search of identical user passwords:
Something tells me Joe's going to call in sick for the nextstaff meeting…
Aside from the "split admin" scenario, we often see passwordreuse between service accounts, between service types, and even between ActiveDirectory Domains (think PCI/nonPCI) etc. As across the Internet at large, an individual password may be your mostamazing password "ever", but it sets you up for all your accounts to fall,should one of them be compromised.
Leaving your toys out, Part 1
We've already seen that leaving your textual toys out leads to disaster. However, it's amazingjust how often users do it. It's theequivalent of a sticky note under the keyboard, only it's a virtual sticky on avirtual keyboard. Worse yet, it's done in scenarios where it's not as obviousas you think. Did you just tell your fellow admin over your corporate messagingproduct what you changed the service password to? Guess what, anyone with access to thatproduct's logs knows it, too.
We understand – again, remembering passwords is hard. But instead of digitally writing them down,reusing, or hiring people with eidetic memories, consider a password vault orsimilar product.
Leaving your toys out, Part 2 (Electric Boogaloo?)
But wait, there's more! Do you allow your users freedom overtheir own machines? Of course you do,you'd have a riot on your hands (complete with pitchforks and torches) if youdidn't. However, guess what users do ifallowed to perform their own software installs – they install anything andeverything that looks like it might be useful. Joe User decided to play with aVNC server on his laptop so that he could use it from the kitchen at home. His gain is now Peter's gain, because Peterjust utilized a default password in that installation package to gain consoleaccess.
My personal favorite – how many products install their owncopy of the Microsoft SQL Server Engine along with the software itself? More than you'd be comfortable with. Well-written products do things such aslaunching the engine on localhost-only, using a randomly generated connectionstring, etc. Poorly-written softwarejust stands up an older SQL engine, listening on the public interface, andleaves in goodies such as default sa passwords.
Your pentester thanks you in advance for custom-installingadditional vulnerabilities for him/her, but suggests you should regularly audityour workstations for user mistakes such as these. Having trouble with usersbehaving on their own workstations? There's a NAC for that! Leverage some network admission control and shunmachines that are standing up services that are against corporate policies.
Too many cooks…
Even harder than remembering your passwords is figuring outproper permission levels. Many carelessIT admins employ a policy for privilege levels and troubleshooting called "JustGive it Domain Admin". In other words, rather than spend the time determiningwhat levels of permission a critical component needs, it's far easier to justgive the account the keys to the kingdom. This results in a "fix" of permissionerrors, but also greatly facilitates a pentest due to the speed with which onecompromised backup host gives a tester control over the domain. Worse yet, many software vendors don't appearto know the granular controls their own apps need and routinely tell theircustomers to "Just Give it Admin".
Does your DNS Admin really need admin to every singleserver? Do your Remote Desktop Usersreally need admin on the TS jump box? The more you think your access model through, the happier you'll be whenthe going gets tough.
The Rules Don't Apply to Me
I've been beating up on Joe User a lot here, but let'sconsider Adam Admin for a second. Adamadministrates Active Directory, and enjoys the fact that he makes his usersemploy a 15 character password, because it breaks Lan Manager password storageby default. However, Adam is a colossalhypocrite, because he takes advantage of his own control over the domain tochange passwords to values that break policy. It's a lot easier for him to remember "Password1" when his users allhave to remember "ThisLongCrazyPa$$WordIHateTypeingEveryTime"!
Lest you think these sins are restricted to administrators,let's revisit the glory days of SOX (were there any?). CFOs would routinely sign off on securitycontrol exceptions personally, because it was "inconvenient" for themotherwise. In other words, they werebetting the security of the company on their desire to shirk the rules.
Companies spend millions on security – shiny firewalls,crypto, IDS, IPS, grunka-lunkas and armed guards,but all this can fall down in the face of careless users with legitimateaccess. Since we can't just encase our systems in concrete and throw them inthe ocean, it's up to us (administrators and pentesters alike) to incorporatefacets of user education, awareness, and the role they play in the securityecosystem into our duties. Without it, security would be a hodge-podge ofstatic vulnerabilities and a false sense of safety.