It was just a simple database. It hadn't been used in over a year. It was behind the firewall and it didn't really contain anything that anyone would care about. That is, until someone on the inside with malicious intent got hold of it.
I see this scenario quite often. It's almost always a case of the focus being on the "important" database systems – while the seemingly "little" database systems that no one really uses are ignored. Ending up on the Privacy Rights Clearinghouse list of data breaches is as simple as a trusted insider using a few free tools to exploit database weaknesses that almost certainly exist on the network. Sure, we can talk about database patching and passwords until we're purple in the face, but those two things are still the essence of most database security problems I see. Let me walk you through a real-world scenario.
Step 1: A bored employee (or contractor, or consultant, or auditor – you name it) decides one day that he wants to see what he can get into on the network. He knows that most of the good stuff is stored in company databases. The employee then combs the Internet for a couple of minutes and stumbles across the free (and very handy) SQLPing tool. This tool, like most network and security tools, is intended for legitimate and legal use, but the employee knows that good things can be used in bad ways. So, he simply plugs his local network address range into the tool and finds all of the SQL Server systems he can "play" with as shown in Figure 1.
[IMAGE]
Figure 1 – Using the SQLPing scanner to find live SQL Server systems. (Click on image for enlarged view.)
Step 2: The employee then starts to poke around on the database systems during his adventure to hack SQL Server databases. He's not sure how to actually connect to the database, so he does a little more research on the Internet. He learns that Microsoft has a couple of tools he can use to connect to SQ
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
L Server databases. He hopes he won't need a password. Ha! He's in luck. It just so happens that the database he's interested in does not have a password on the sa account. Good for him – bad for business. Figure 2 shows how the employee simply connects to the database using Microsoft Web Data Administrator.
[IMAGE]
Figure 2 – Using Web Data Administrator to export a database. (Click on image for enlarged view.)
The ability to export databases, create backdoor users, delete databases is all in his control.
Step 3: The employee then stumbles across another interesting database system – and a new tool. With Microsoft's SQL Server Management Studio Express, he can connect and execute queries to databases as he sees fit. Sure, SELECT statements, table names and the like aren't for the faint of heart. But everything he needs is at his beck and call on the Internet. Having gone out on a limb and gained access to the database by using "password" as the password, he gets right in. He's able to execute a basic query that shows how many other accounts on the system have no password at all, as shown in Figure 3.
[IMAGE]
Figure 3 – Using SQL Server Management Studio Express to execute queries. (Click on image for enlarged view.)
The system is thick with sloppy misconfigurations. The database is his.
Step 4: The employee has read recently that unstructured data scattered about the network is becoming a big problem for businesses. He does a little research and decides to poke around for Microsoft Access files on unsecured shares where they shouldn't be. He knows data contained in them may be stale, but they may still have some juicy content. After all, they were the company's mission-critical, relied-upon databases not that long ago. Any files he comes across are his. It's just a matter of loading them into Access. If they're password protected as a means of SQL Server database security, he can simply crack the passwords using a good commercial password cracking tool. It's a lot of valuable information for such a small investment.
Step 5: The employee goes on to abuse the database content for ill-gotten gains and the network administrator is none the wiser.
Think about these vulnerabilities. Then look at the descriptions of known breaches happening every week. It's all so free and easy, and it's reality -- no fancy commercial hacking tools are required.
Network flaws need your attention right now. It's okay to focus on the most urgent vulnerabilities on your enterprise's most critical systems, but don't overlook the "little guys." Your greatest SQL Server database security issues may very well be on some harmless database deep inside the network that no one ever uses. Leave no stone unturned and never, ever assume that network insiders cannot or will not do bad things, that is hack your SQL Server databases.
[TABLE]
