Windows file servers "hold the gold" on your network. They house sensitive files, databases, passwords and more. When file servers go down, the network is incapacitated, and when they're breached, all hell can break loose.
The following are examples of true Windows file server hacks I've discovered. I'll share with you what I came across and how the vulnerabilities were exploited -- all from a hacker's point of view. This will help put security vulnerabilities you hear about in the news and read in security bulletins into a new context -- one that can help you approach your server security testing with a fresh perspective and the realization that not all security exploits are high-tech.
Step 1: Exploiting a missing patch
Take all the Microsoft critical security updates you're expected to keep up with and combine those with some of my favorite vulnerability scanning and exploit tools. What you've got is a surefire security breach waiting to happen.
You'll often find that most Windows file server security vulnerabilities are facilitated by a missing patch and is directly exploitable from inside the network. This is due to the fact that so many networks don't use internal segmenting or intrusion prevention -- everything's trusted. This is not good when you've got a rogue employee looking to control your Windows servers.
Let's look at how a missing Windows patch vulnerability can be easily exploited from a rogue insider's point of view. All that's required is a connection on your network and a couple of freely-downloadable security tools: NeXpose Community edition and Metasploit.
The following steps seal the deal:
- The malicious user installs NeXpose and scans the network -- or a few key servers that he knows about -- looking for vulnerabilities.
- He comes across the MS08-067 issue on a file server that allows "arbitrary code" execution, which sounds like fun.
- The user goes to Metasploit's exploit listing page and sees that this exploit is supported.
- He downloads and installs Metasploit, plugs in a few variables, and magically creates a command prompt with full access to your server, as shown in the following figure.
This can be done time and time again with vulnerabilities affecting Windows and related applications without you ever knowing a thing about it. Imagine the damage that could be done with full server command prompt access: delete files, copy the backup SAM database and other sensitive files, add/remove users, and so on. The same type of exploit can be carried out via the Internet on one of your publicly-accessible servers if it's not adequately protected behind a firewall.
It's also important to remember that the network connection requirement mentioned above can be obtained via an improperly secured wireless network. An example would be having a couple of access points connected directly to your network that serve handheld scanners in your warehouse. There's hardly ever any WEP, WPA or other security controls for these scanners; anyone within range (which is usually your parking lot or in adjacent buildings) can jump right onto your network to carry out their exploits.
Step 2: Sniffing the network for juicy info
Speaking of unsecured wireless networks, all it takes for a malicious outsider to hop onto your network and glean sensitive information is to load up a wireless network analyzer such as CommView for WiFi or AirMagnet WiFi Analyzer. Furthermore, if the attacker is able to obtain a physical connection to your network (or is a trusted user), he can load a tool to perform ARP poisoning, which would allow him to bypass your Ethernet switch "security" and grab anything and everything from your network.
What does this have to do with hacking file servers? Easy -- the attacker can simply glean password information from SMB, POP3, Web, FTP, and Windows authentication sessions right off the wire (as shown below) and use that info as a direct link for unauthorized access into your file servers.
Step 3: Stumbling across sensitive files
I revisit this particular hack a lot because the problem only seems to be getting worse. It's the issue of sensitive information stored in an unprotected fashion on server shares accessible to anyone on the network -- typically in public folders. Why? My theory is that network administrators often have too much information to manage, coupled with the fact that users do too many careless things with their files. Still, that's no excuse in the regulators' eyes given what's at stake with personally-identifiable information (PII) these days.
Here's what can happen:
- A network user with standard domain rights (or a hacker who's obtained someone's authentication credentials) scans the network for shares. A great program for this is GFI LANguard, which has a share finder tool built right in.
- He finds shares and literally tries to connect to them one by one to see what he can see.
- He realizes that there are too many files to sift through and decides to use the Windows Explorer search function -- or better yet -- a faster and more powerful tool like Effective File Search (EFS) to root out sensitive information.
- The attacker runs a search for .doc, .xls, .txt, and similar files containing text strings such as "ssn", "dob", "confidential", and so forth. He'll undoubtedly find dozens if not hundreds of files containing the information he's looking for.
- He copies the information and then uses it against the victim via identity theft, selling intellectual property to competitors, etc.
Again, test this for yourself and you'll see what I'm talking about. It doesn't matter what tool you use as long as you search for the right type of documents and text strings. If your Windows file servers are publicly-accessible (heaven forbid, but I see it every now and then) there are various things an attacker can do with Google queries to root out sensitive server information. To test this, I recommend using Acunetix's Web Vulnerability Scanner, which has a Google hacking database (GHDB) scanning feature.
Step 4: Executing related hacks that indirectly affect file server security
Finally, it's easy to overlook other vulnerabilities in your network infrastructure that can indirectly lead to file server manipulation and exploitation. These mostly revolve around physical security.
One serious issue I came across was where the Web interface for a data center's physical security management system was accessible to all network users as well as anyone able to connect to an unsecured wireless network from outside the building. Even worse, the data center management application was running with the default username and password. This meant that once you logged in, door sensors could be disabled, security alerts could be rerouted, log files could be tampered with, and so on. What a great way for an attacker to cover his tracks after breaking into the data center!
I've also seen several situations where file servers were completely accessible to the public (notably at busy real estate offices, healthcare facilities, and "open house" networking events for local businesses). I'm talking about no doors, no locks -- not even the slightest physical security measure taken. These servers almost always have their screens unlocked, which can make an administrator backdoor easy as pie to setup.
The bad guys can also gain a leg up on how everything is interconnected and accessible to steal after hours or when no one is around. Think a stolen Windows file server is difficult to crack? As long as the hard disks are not encrypted, all it takes is a tool like Ophcrack Live CD or ElcomSoft System Recovery to crack or reset any passwords on the system, including the administrator password. This is certainly an incentive to use whole disk encryption on your servers as a last line of defense!
Finally -- don't sit idle
Always remember that if the bad guys can do it, then you need to be doing it as well. You've got to ethically hack your Windows file servers -- with a malicious mindset -- to see what can be done by both unruly insiders and outside attackers. Keep in mind that there's a method to all this madness, as this will ensure you're testing in the right way, at the right time, with the right tools, and so on.
ABOUT THE AUTHOR
Kevin Beaver (CISSP), is an information security consultant, expert witness, as well as a seminar leader and keynote speaker with Atlanta-based Principle Logic, LLC. Kevin can be reached at www.principlelogic.com.