Updated: Sep 30, 2020
On June 3rd, the InfosecMatter blog published a post titled "Top #10 Vulnerabilities: Internal Infrastructure Pentest". This blog post detailed the top most common vulnerabilities in Windows servers and networks found during more than 60 internal infrastructure penetration tests around the world. After reading this article, I was prompted to actively look for similar resources on SQL Server penetration testing, and I got some interesting findings. See below my conclusions.
After reading up on a bunch of SQL Server penetration testing articles, I found that the steps of a common penetration test are as follows:
Attacking (Loot / Destruction)
Logically, these steps mimic the steps taken by a common would-be hacker (except, of course, they try not to actually damage anything).
I'll briefly describe each step from the point of view of a hacker or penetration tester, the common methodologies of each step, and offer recommendations that we can follow to protect our database systems at every level.
The first step a hacker or a "pentester" would do when introduced into a network, is to start looking for SQL Servers. This is done using IP and Port scanner tools that scan the network for common ports that may represent a vulnerable system.
Scan the network for open TCP/IP 1433 port (the SQL Server default)
Scan the network for open UDP 1434 port (the SQL Server Browser service)
Using SQL Injection (to discover the server address via an existing application)
How to Protect Ourselves
Shut down the SQL Server Browser service and disable it (use static ports instead)
Alternatively, if possible, disable the TCP/IP protocol entirely and rely on Named Pipes or Shared Memory instead.
2. Gaining Access
Now that we have our "targets", our next step is trying to break in. Basically this means guessing a working username and password combination or using an elevated Operating System account to create a new login.