Numerous technical articles emerge each day about the latest vulnerabilities, flaws, exploits, and whatnot. That's great and all (who hasn't simultaneously groaned and cheered when they find an MS08-067 exploitable machine on a pentest, 4+ years after the vulnerability was documented?), but why bother going to all the trouble when users often give you all the ammo you need to successfully compromise your targets?
In this post, I'd like to cover some of the terrible, awful things users do that help pentesters in their duties (and the bad guys as well). They may not be the sole reason for compromises, but they can greatly accelerate them in an environment where pure technical machismo would be left out in the cold. Let's begin, using some (terribly named)characters.
Oh, how users hate to remember passwords, especially those darn nasty "complex" ones (which we've railed against in past GSRs). If Joe User 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 hard to be continuously creative! Therefore, in the instances where Joe must utilize not one but two separate accounts (such juser and juser-a for his Domain Administrator functions), it's much easier 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 user hashes through a variety of methods, but has been stonewalled thus far by tightly locked down servers and a strict least-privilege model. Peter has Joe's user password, but hasn't been able to find an accessible machine where the admin login has been used, even in ms cache.
"Aha!" says Peter. "I wonder if Joe reuses passwords between his logins?" Sure enough, within seconds, our intrepid pentester has escalated an individual user compromise into the compromise of the 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:
juser1001:aad3b435b51404eeaad3b435b51404ee:2753ae3e4aa1cfd068504972c94576ca:::
juser-a:1002:aad3b435b51404eeaad3b435b51404ee:2753ae3e4aa1cfd068504972c94576ca:::
Something tells me Joe's going to call in sick for the next staff meeting…
Aside from the "split admin" scenario, we often see password reuse between service accounts, between service types, and even between Active Directory Domains (think PCI/non PCI) etc. As across the Internet at large, an individual password may be your most amazing password "ever", but it sets you up for all your accounts to fall, should one of them be compromised.
We've already seen that leaving your textual toys out leads to disaster. However, it's amazing just how often users do it. It's the equivalent of a sticky note under the keyboard, only it's a virtual sticky on a virtual keyboard. Worse yet, it's done in scenarios where it's not as obvious as you think. Did you just tell your fellow admin over your corporate messaging product what you changed the service password to? Guess what, anyone with access to that product'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 or similar product.
But wait, there's more! Do you allow your users freedom over their own machines? Of course you do, you'd have a riot on your hands (complete with pitchforks and torches) if you didn't. However, guess what users do if allowed to perform their own software installs – they install anything and everything 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 Peter just utilized a default password in that installation package to gain console access.
My personal favorite – how many products install their own copy of the Microsoft SQL Server Engine along with the software itself? More than you'd be comfortable with. Well-written products do things such as launching the engine on localhost-only, using a randomly generated connection string, etc. Poorly-written software just stands up an older SQL engine, listening on the public interface, and leaves in goodies such as default sa passwords.
Your pentester thanks you in advance for custom-installing additional vulnerabilities for him/her, but suggests you should regularly audit your workstations for user mistakes such as these. Having trouble with users behaving on their own workstations? There's a NAC for that! Leverage some network admission control and shun machines that are standing up services that are against corporate policies.
Even harder than remembering your passwords is figuring out proper permission levels. Many careless IT admins employ a policy for privilege levels and troubleshooting called "JustGive it Domain Admin". In other words, rather than spend the time determining what levels of permission a critical component needs, it's far easier to just give the account the keys to the kingdom. This results in a "fix" of permission errors, but also greatly facilitates a pentest due to the speed with which one compromised backup host gives a tester control over the domain. Worse yet, many software vendors don't appear to know the granular controls their own apps need and routinely tell their customers to "Just Give it Admin".
Does your DNS Admin really need admin to every single server? Do your Remote Desktop Users really need admin on the TS jump box? The more you think your access model through, the happier you'll be when the going gets tough.
I've been beating up on Joe User a lot here, but let's consider Adam Admin for a second. Adam administrates Active Directory, and enjoys the fact that he makes his users employ a 15 character password, because it breaks Lan Manager password storage by default. However, Adam is a colossal hypocrite, because he takes advantage of his own control over the domain to change passwords to values that break policy. It's a lot easier for him to remember "Password1" when his users all have 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 security control exceptions personally, because it was "inconvenient" for them otherwise. In other words, they were betting 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 legitimate access. Since we can't just encase our systems in concrete and throw them in the ocean, it's up to us (administrators and pentesters alike) to incorporate facets of user education, awareness, and the role they play in the security ecosystem into our duties. Without it, security would be a hodge-podge of static vulnerabilities and a false sense of safety.