Most Common Internal Vulnerabilities Found

By Kirk Greene ·
0 Shares

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.
Side Note – The most common default Oracle account found is DBSNMP. Why is that? Because just changing the password for this account within the database breaks the Intelligent Agent service if you don’t also change the password in the snmp_rw.ora file. DBA’s will often change the account in the database, see that the Intelligent service stopped working, and then just change it back thinking that since the account isn’t a really privileged account so what’s the harm. Well reality is that this account has just the right amount of privileges to compromise not only the database but also sometimes the host OS itself. No account within an Oracle database is safe to leave with the default password assigned – even the SCOTT account!
  • 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.
Well those are the top things that I typically run across that ruin the day for the client but make it a successful engagement for me:-) The one finding that I stress in just about every report, and also to the client throughout the engagement, is you have to expand your password policy to anything that requires or can be assigned a password - anything! Then you have to educate users on the need for good password usage. If you don’t, then there will always be a way to get in. You can scan all you want and patch systems until you’re blue in the face, but if you don’t use good passwords, you’re just opening the door for an attacker to walk right in.

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
Aside from the tools listed above, I’d also recommend updating your system configuration policies and setting the following registry key to 0:

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.

0 Shares