Most Common Internal Vulnerabilities Found
You can patch OSes all you want and scan your network with just about any general vulnerability scanner but you've left out one very important step - password policy enforcement beyond just domain accounts.I thought that I take a quick moment to answer an ongoing comment/question that always seems to come up at the various client’s that I assess, “We have a solid vulnerability management program that includes an automated system patching process and a top rated vulnerability scanner, how in the hell are you still breaking into our boxes?” Well the answer is really easy; you can patch OSes all you want and scan your network with just about any general vulnerability scanner but you’ve left out one very important step - password policy enforcement beyond just domain accounts. Yes sometimes it’s insecure builds and 3rd party application patching that gives up the information that is helpful to exploit the box, but when I step back and think about it, it always comes back to the passwords.
Below is an overview of the top most common ways I generally find to get in:
- Blank/Weak MS SQL “sa” Account Passwords - Yep, number one way still I typically get in. What’s funny is that lately it’s either a security database that houses proximity card access rights or the companies Blackberry Enterprise Server. Believe it or not, most of your commercial and open source general vulnerability scanners only check for a couple of passwords for this account - typically only a blank password, but I’ve seen some that actually will also check for “sa” and “password” as the account password. As you all may or may not know, give me “sa” access to your MS SQL database and I own the box. Using the same administrator password on all of your servers? Well, I now own them as well! So what do I use to find this common hole, SQLLHF (thanks Matt Wagenknecht!!) with a dictionary file of about only 10 common passwords - does the trick almost every time.
- No Password Assigned on the Oracle TNS Listener Service - When I see an Oracle service running in an environment I start foaming at the mouth. Why you ask? Because 9 times out of 10, if no password is assigned to the listener service, I know I’ll find a default Oracle account. Also I know that if I can’t take over the host OS with that account I’m bound to find some really juicy data being stored in the database that makes taking over the host OS look like peanuts.
- Cached Credentials - By default, Windows stores the last 10 accounts that logged into a system in cache. While cracking these passwords can take some time, it’s generally worth the extra time and effort as typically they are domain admin accounts that will give me the keys to the kingdom. So you might be saying, “OK, well in order to get cached credentials you’d have to be an admin on the box. That means a weak password for an admin account exists and we should have seen that during our scanning and addressed it.” Well, yes and no. How often are you scanning your workstations and mobile devices? It’s funny how when you give users local admin rights to their workstations, or most commonly laptops, how the local accounts (or the local Admin account) have a blank or the username same as the password. All it takes is one bad apple to bring down the entire tree:-)
- Weak/Default Password on Networked Appliances and/or Networking Devices - While this doesn’t directly lead to a compromise of the environment it can be just as damaging. I can’t tell you how many times I’ve run across things like default accounts on an HVAC control system for a datacenter or a central console device to manage networking gear (Often companies don’t put passwords on console access to networking devices because you have to physically be at the console – right?). Wrong! Nowadays administrators try to stay out of the datacenter as much as possible and do everything remotely. Who wants to sit in a freezing room for hours on end when you can remote into the device from the comforts of your office.
To enhance your vulnerability management program, I recommend the following tools be added to your arsenal. Without them you could be leaving a door open for an attacker.
- Oscanner – Oracle scanner that tests for default Oracle accounts and passwords
- SQLLHF – MS SQL scanner that allows for dictionary attacks against the “sa” account
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrent VersionWinlogon CachedLogonsCount
Finally, investigate all web services identified by your scanners – especially those running in the 8000 range as some of these remote web management services can either be disruptive to the system/device or lead to a direct compromise of the system/device itself. Disable them, or at a bare minimum, change the default password and ensure that they are up to date (of the current release). By making these simple enhancements/changes, the next time I come in for an assessment, you’ll stop me dead in my tracks…Or at least make me work a little harder.