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
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.
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
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
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 28th, 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.
Brian once again covered this worm for the SQLServerCentral.com community with
his article: SQLsnake
Worm Hits SQL Servers and Networks Hard.
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.
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
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.
is Latest Hack Victim,
- RealNames' Customer
Hack: 'Good' Sabotage,
Wired News (World Economic Forum article)
Say They Hack for Our Sake,
PCWorld (Deceptive Duo article)
Database Posted on Defacement, InternetNews.com (Midwest Express
- Analysis of the
Sapphire Worm, CAIDA (SQL Slammer)
settles with Guess on Web vulnerabilities,
- PetCo Plugs Credit
two years after 9/11, corporate security focus still lacking,