Hacker’s activities/Malicious user may try to hack

1. Direct connections via the Internet

These connections can be used to attach to SQL Servers sitting naked without firewall protection for the entire world to see (and access). I don't understand the logic behind making a critical server like this directly accessible from the Internet, but I still find this flaw in my assessments, and we all remember the effect the SQL Slammer worm had on so many vulnerable SQL Server systems. Nevertheless, these direct attacks can lead to denial of service, buffer overflows and more.

2. Vulnerability scanning
Vulnerability scanning often reveals weaknesses in the underlying OS, the Web application or the database system itself. Anything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses to SNMP exploits can be uncovered by attackers and lead to database server compromise. The bad guys may use open source, home-grown or commercial tools. Some are even savvy enough to carry out their hacks manually from a command prompt. In the interest of time (and minimal wheel spinning), I recommend using commercial vulnerability assessment tools like QualysGuard from Qualys Inc. (for general scanning), WebInspectfrom SPI Dynamics (for Web application scanning) and Next Generation Security Software Ltd.'s NGSSquirrel for SQL Server (for database-specific scanning). They're easy to use, offer the most comprehensive assessment and, in turn, provide the best results. Figure 1 shows some SQL injection vulnerabilities you may be able to uncover.

Figure 1: Common SQL injection vulnerabilities found using WebInspect.

3. Enumerating the SQL Server Resolution Service

Running on UDP port 1434, this allows you to find hidden database instances and probe deeper into the system. Chip Andrews' SQLPing v 2.5 is a great tool to use to look for SQL Server system(s) and determine version numbers (somewhat). This works even if your SQL Server instances aren't listening on the default ports. Also, a buffer overflow can occur when an overly long request for SQL Servers is sent to the broadcast address for UDP port 1434.

4. Direct-exploit attacks 

Direct attacks using tools (any), shown in Figure 2, and its commercial equivalents (CANVAS and CORE IMPACT) are used to exploit certain vulnerabilities found during normal vulnerability scanning. This is typically the silver-bullet hack for attackers penetrating a system and performing code injection or gaining unauthorized command-line access.

Figure 2: SQL Server vulnerability exploitable using Metasploit's MSFConsole.

5. SQL injection

SQL injection attacks are executed via front-end Web applications that don't properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually -- if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics' SQL Injector

.
Figure 3: SPI Dynamics' SQL Injector tool automates the SQL injection process.

6. Blind SQL injection

These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as a standard SQL injection. The big difference is that the attacker doesn't receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that's where Absinthe, shown in Figure 4, comes in handy.

Figure 4: Absinthe tool takes the pain out of blind SQL injection testing.

7. Reverse engineering the system

The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you'll find a discussion about reverse engineering ploys.

8. Google hacks

Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors -- such as "Incorrect syntax near" -- leaking from publicly accessible systems. Several Google queries are available at Johnny Long's Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth.

9. Perusing Web site source code

The source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.

10. Cracking SA passwords

You can use the following ways to secure the SA login.

a.           Use Windows Authentication Mode

One way of doing this is to use "Window Authentication mode" from the Server Properties dialog which will allow access to only Windows logins and not SQL logins. Microsoft also recommends Windows authentication mode only. One thing to note is that even though you are using Windows authentication, you must use a strong password for the SA account, because anyone can change the authentication mode by updating the registry value and restarting the SQL Services.

Replace the username and password with Integrated Security=SSPI;

So the connection string should be

<connectionStrings>

<add name="NorthwindContex"

   connectionString="data source=localhost;   initial catalog=northwind;persist security info=True;

   Integrated Security=SSPI;"

providerName="System.Data.SqlClient" />

</connectionStrings>

To change this setting in SQL Server Management Studio, right-click the server, click Properties and go to Security page as shown below.

b.           Disable the SA Login

Disabling the SA account is a good option to prevent its use. When it is disabled no one can use it in any circumstance until it is enabled. The only disadvantage is that we can't use the SA account in an emergency.

You can use the below T-SQL to disable SA account.

--Query to disable the SA account.

ALTER LOGIN sa DISABLE;

This query will check the status of the SA account. A value of 1 indicates the account is disabled and 0 indicates the account is enabled.

--Query to check account status

SELECT name,is_disabled from sys.server_principals where name='sa'

c.           Rename the SA Login

You can also rename the SA account which will prevent hackers/users to some extent. The one disadvantage is that it does not change the SID for the SA account which by default is 0x01, so someone could find the new name by looking up the SID.

--Query to check account status

ALTER LOGIN sa WITH NAME = [mssqltip];

This query could be used to lookup the name for the SA account based on the SID.

SELECT * FROM sys.syslogins WHERE sid = 0x01

11. Make the system administrator account's password complicated :

If you are using mixed-mode authentication in SQL Server, always set a complex password for the SA account. As a best practice, always avoid using the SA account to connect Web applications to SQL Server. One should always avoid using the system administrator account to perform day-to-day maintenance activities. For day-to-day stuff, use Windows accounts with appropriate permissions. As a best practice, don't forget to change SA account passwords once every few days.

12. Audit logins

As a SQL Server security best practice, you should always audit failed logins to SQL Server. Once you have enabled login auditing in SQL Server, the failed and successful login information will be written to the SQL Server error logs, which can be monitored regularly to look into suspicious activities from time to time.

13. Turn off the SQL Server browser service

As another SQL Server security best practice, a database admin should turn off the SQL Server browser service when running a default instance of SQL Server. Even if you are running a named instance, you can explicitly define the port and mention the port within the application connection strings to connect to a named instance of SQL Server.

14. Disable unused features in SQL Server

Disable features such as XP_CMDSHELL, OLE AUTOMATION, OPENROWSET and OPENDATASETwhen not in use to reduce surface area attacks. In SQL Server 2005 you can enable or disable these features using the SQL Server Configuration Manager. If you are using SQL Server 2008 or higher versions you can enable or disable the above-mentioned features using the policy-based management feature.

15. Decrease privileges for the SQL Server service account

A final best practice is that a database administrator should always run SQL Server services in a minimally privileged local domain account. Avoid running SQL Server services under the contexts of the local system, local administrator or domain administrator accounts. However, make sure that the SQL Server service account has "full control" permissions on data, log and backup directories for read and write activities.