SQL Server Security: Why Security Is Important

By Brian Kelley, 2003/07/31

Total article views: 6762 | Views in the last 30 days: 4

Rate this |

Join the discussion |

Briefcase

Typically I write about technical solutions to SQL Server problems. This is true whether I'm writing about performance, security, or disaster recovery. This article will be atypical in that respect because it'll consist of case studies that point out why security is critical. All of the case studies will be on security incidents that have made the news. These incidents also involve compromised databases. Not all of them involve SQL Server but point out a fundamental axiom: databases are primary targets because they are information stores.

As SQL Server DBAs, we have to realize that SQL Server is growing in market share. Microsoft’s SQL Server is an enterprise-class database platform more and more companies are using to store critical and sensitive data. SQL Server is an important cog in Microsoft’s .NET enterprise server architecture. It’s easy to use, takes fewer resources to maintain and performance tune than other comparable database platforms, and it’s reasonably priced. All these facts mean SQL Server has a big target painted on the side of your server that says, “I’m important. Come and get me.” If your SQL Servers aren’t secured, someone will. Others have found out the hard way. Here are some examples.

RealNames

In February 2000, C|Net, one of the more prominent tech news organizations, reported the company RealNames informed customers that its customer information database had been breached and the attackers had walked off with valuable information, to include credit card numbers.

RealNames was in the business of making complex web addresses accessible by the use of keywords. Anyone was capable of going to the RealNames’ site, registering and paying via credit card, and thus getting keywords associated with their website. It was this customer database the attackers broke into.

RealNames is no longer in business, and though the reason for RealNames closing its doors has nothing to do with this security breach, obviously the breach caused numerous issues for RealNames’ customers. Credit card numbers were valuable then and they are now. RealNames’ customers most certainly had to go through the process of canceling any and all credit cards they might have used on the RealNames site and acquiring new ones. At least RealNames acted in a respectable manner, sending an email to its customer base within 24 hours of discovering the breach.

RealNames then went and hired security firm Internet Security Systems (ISS) to conduct an audit and prevent against future security breaches. But the fact remains that up to 50,000 customers might have had their credit card information readily accessible by an attacker, one who had been on the system undetected for at least a few days.

World Economic Forum

About a year later (Feb 2001), crackers from the group Virtual Monkeywrench announced they had hacked into the registration database of the World Economic Forum (WEF). What did they get? The group captured credit card numbers, personal addresses and emails, home and cell phone numbers, and passport information for all who had attended the WEF in the previous three years.

Virtual Monkeywrench then passed this information on to a Zurich, Switzerland, newspaper that published some of it on the newspaper’s website. Among the information published: Bill Gates’ email address, Amazon.com head Jeff Bezo’s home phone number, and a credit card number for CEO of PepsiCo Beverages Peter Thompson. But the fun doesn’t stop there. The group was also able to grab participant passwords into the database for former US President Bill Clinton, Russian President Vladimir Putin, and Palestinian Leader Yasser Arafat. The newspaper that had received all the information, SonntagsZeitung, reported the crackers had turned over a CD-ROM with 800,000 pages of data!

Note: In the hacker community, hacker isn’t a negative word. Hacker is used to describe one who investigates out of curiosity. A hacker isn’t necessarily one who breaks into systems for personal gain, though that’s how the media uses the term. The community prefers the term crackers for those people who maliciously seek to break into or compromise systems.

Midwest Express and Others

The one thing I will say about the previous two examples is SQL Server wasn’t explicitly mentioned. The first example, RealNames, had an NT 4.0 server running SP 5 compromised, but this was the front-end or web server, according to the InternetNews.com article on the hack (see the Additional Resources section). None have specifically pointed a finger at SQL Server or I should say “Microsoft SQL,” which even if it isn’t SQL Server, users will read as Microsoft SQL Server.

Midwest Express, an airline, was hacked in April 2002 and their flight schedule and passenger manifest was stolen. The people, calling themselves the Deceptive Duo, who carried out the attack then hit another site, the US Space and Naval Warfare Systems Command, and posted Midwest Express’ passenger manifest, complete with names and emails.

But the Deceptive Duo didn’t stop there. They also hacked into several government agencies and banks. One of their methods of attack was to compromise SQL Servers with a “default” password. Since both SQL Server 7.0 and SQL Server 2000 allow for the sa account to have a blank password, this is probably what they meant since SQL Server 7.0’s install doesn’t even prompt for one (though to get a blank password in SQL Server 2000 I have to knowingly choose to leave the password blank during the install).

So far as the Deceptive Duo was concerned, targeting SQL Server was part of their plan. If we put ourselves in the minds of the hacker, that plan makes perfect sense. If the default install of SQL Server is ripe for the plucking, why bother with anything else? And that’s probably what the Deceptive Duo thought, too.

Note: SQL Server 7.0 isn’t alone in leaving the sa password blank, a frequent item of consternation for security experts. The open source database, MySQL, installed by default with no password for root, the super user account for the database. I haven't kept up with the most recent versions, so if this behavior has changed, please let me know in the comments section. The bottom-line, regardless of database platform, is this: secure all privileged accounts with strong passwords immediately.

Attack of the Worms

All three of these attacks were targeted. Attackers deliberately went after selected systems to try and break in. Could someone fashion an attack that goes after SQL Servers one-by-one? The answer to that question is a resounding and earth-shattering, “Yes!” In November 2001, the first of two worms targeted at SQL Server were released into the wild.

In November 2001, security researchers reported a new worm that attempted to log on to servers using the standard Microsoft SQL Server TCP port (1433), the sa account, and a blank password. Since the default port for a SQL Server 7 installation is 1433 and since the setup program doesn’t prompt for a sa password during installation, quite a few SQL Servers were vulnerable to this worm. The worm had successfully infected a small number of systems before it was detected. Because security researchers discovered the worm very quickly, most of the systems vulnerable to it were never attacked.

Note: Brian Knight alerted the SQLServerCentral.com community about what the worm did with his article Security Alert: SQL Server Worm Virus Attacking Systems.

The security community reaction was swift and security experts quickly asked the owner of the FTP server to remove the file that was downloaded by this worm. The owner did so. Then security experts send out announcements through sources such as CERT (http://www.cert.org), the SANS Institute (http://www.sans.org) and NTBugTraq (http://www.ntbugtraq.com). Because security teams responded so quickly, W32.Cblade.Worm was relatively minor in scope. It attacked in a predictable way and was easily defendable. This worm should have served to be a wake-up call for the SQL Server community. Instead, it ended up being a warning shot before the main firefight.

In early May 2002 security researchers starting reporting about increased port scanning for TCP port 1433. Chip Andrews put a notice on his SQLSecurity.com site on May 4, 2002. Then on May 28^th, security researchers discovered another worm in the wild. The community gave the new worm several different names; among them were SQLSnake and Digispid.B.Worm. I’ll stick with the latter.

The attack pattern for Digispid.B.Worm was the same as for W32.Cblade.Worm: make a connection to TCP port 1433 and attempt to login as sa with a blank password. However, this worm was more aggressive and it was able to infect more systems than W32.Cblade.Worm. Various sources report the number of systems infected range from a hundred to thousands. Cblade was a warning but many DBAs, system administrators and network engineers didn’t heed it. These personnel weren’t prepared and hadn’t locked down their SQL Servers. As a result, Digispid.B.Worm was able to get a foothold. This new worm was more intrusive than W32.Cblade.Worm because it was far more aggressive. It required some cleanup, but it pales in comparison to the next major worm attack.

Note: Brian once again covered this worm for the SQLServerCentral.com community with his article: SQLsnake Worm Hits SQL Servers and Networks Hard.

SQL Slammer

If you are a SQL Server DBA and you haven't heard about SQL Slammer, now's the time for a quick education. In January 2003, the hammer came down. A SQL Server worm hit on Friday, January 24th, and moved so fast that it effectively became a Denial of Service attack against any network where it got a foothold, including portions of the Internet. SQL Slammer has been to date the most aggressive worm the world has seen, bar none. I've included a link to a study detailing its propagation in the Additional Resources section.

SQL Slammer attacked UDP port 1434, the listener port for SQL Server 2000 (SQL Server 7.0 was not vulnerable). Clients use this port when they are trying to discover what SQL Servers are on the network, such as when you pull down the drop-down list in Query Analyzer. Clients also use this port to identify what TCP port to connect to for a named instance. Keep in mind the default instance typically listens on TCP 1433. If you have a named instance, it's not going to be able to use the same port. Since SQL Server 2000 will randomly assign a port number when you install the named instance, it could be anything. The way to deal with this issue is to have that listener service. The client contacts it and finds out what TCP port to use. It can then connect and all of this occurs seamlessly for the user. The problem is that this port is set for every single SQL Server 2000 installation. A target and it's not moving! If you are running a SQL Server that doesn't require network access (local use only), as of SP3a you can disable this listener port, but this wasn't the case when SQL Slammer hit.

SQL Slammer took advantage of a buffer overflow attack on this listener service. What really drove the security community nuts was a patch had been made available some six months before! NGSSoftware even had demonstration code that showed what the exploit could do (and the worm "writer" used it heavily). A lot of systems weren't patched. Some systems were patched but it was later found out that a certain Microsoft hotfix to repair an unrelated issue replaced critical files. The files changed to prevent the buffer overflow were overwritten with older versions that were vulnerable. In other words, the unrelated hotfix made systems vulnerable again. All in all, it was a very big mess that required a lot of people working a lot of long hours. Even for companies that weren't hit, every SQL Server in inventory had to be checked and verified. When you include MSDE builds, this was a very sizeable effort.

Note: Brian's write-up on this site is: Another SQL Server Virus Hits the Internet. He followed it up with Who's to Blame for the SQL Slammer Virus.

PetCo.Com

This one is my new favorite when I talk to developers within my organization about security. Though SQL Inection has gotten a lot of press in recent days, Guess (the clothing manufacturer) and PetCo.Com fell victim to this now classic vulnerability. In February 2002, Guess' website was compromised by a SQL Injection attack which netted attackers an unknown number of customer credit card numbers. So you'd figure by June 2003 every major player on the Internet would have learned their lesson, right? Not quite.

Not long after Guess settled with the FTC, Jeremiah Jacks discovered PetCo.com was vulnerable to the exact same SQL Injection attack he discovered on the Guess site. What would the payoff had been if he were a malicious cracker? The prize was a database with about 500,000 credit card entries complete with names, addresses, and order information. How did he do it? He used Google to search for pages that were likely to be vulnerable then tried to use an injection attack. He estimated it took less than a minute to be successful! Imagine finding a major vulnerability for one retailer and then almost a year and a half later finding the same type of vulnerability, one easily patched mind you, on another major retailer. It's enough to drive one insane. But that's what this security researcher found. Hopefully we've all received our wake-up call, but don't be surprised if another major target falls to SQL Injection in the near future.

Concluding Remarks

These six case studies represent a fraction of the literature available on cases where databases have been breached. All involve configurations that weren't secure. In most cases, simple security procedures would have stopped an attacker cold but for whatever reason these procedures weren't done. After several of these high profile cases, it would seem logical that security would receive a heavy focus from companies and organizations but the reality is things haven't changed a lot. A recent survey showed that even after the incidents on 9/11, when companies were forced to take a hard look at not only their disaster recovery but also their security procedures, very little change has occurred. This is somewhat disheartening, but not all together surprising.

Proper security takes time and effort. Often it's an afterthought on projects and seen as an impediment for delivery on-time and on- schedule. I've faced this issue myself when supporting recent projects. The difference between the ones that take security into account from the beginning as opposed to waiting until the last minute is like night and day. Somehow we have to effect a corporate culture change where security is of paramount concern. Hopefully these case studies start the discussions in your own circles that may bring about that change where you work.

Remember the mantra (double negative intended): Just because I'm paranoid doesn't mean someone is not out to get me.