Back

When Databases Attack: Entry Points

Secure database configurations are important. However, many database administrators fail to lock down accounts that are used by trusted services. As a result, trusted services can often be used as entry points into database servers. Over time attackers have become very efficient at identifying those entry points, gaining access to confidential information, and pretty much being evil. This blog covers MS SQL Server entry points that can potentially be used to execute arbitrary queries via trusted database accounts.

Threats

Never discount the insider threat. Even if the administrator isn’t the culprit, their account can be impersonated and their password can be stolen. Also, insider attacks typically don’t trigger alerts in the same way that brute force attacks do because all of the actions appear to be legitimate from the system’s perspective. That makes enforcing the least privilege on accounts and objects even more important. Below I’ve listed a few accounts types that usually have more privileges than they really should. You may want to keep an eye on them.

  1. Application Database Accounts
    Database accounts used by applications typically have more privileges than they need to perform their function. In my experience I’ve found that most database accounts used by applications are assigned sysadmin privileges or actually use the SA account. As a result, every developer with access to the account can execute arbitrary queries and system commands on the database server. Application accounts should really only be assigned the access they require on the associated application database.
  2. Database Administrator Accounts
    Of course it makes sense to give database administrators access to manage their own databases. However, nine times out of ten they are able to elevate their privileges and access other databases and systems through inherited SQL Server service account permissions. So only give DBA access when it’s needed, set strong passwords, and audit administrative account activity.
  3. Server Administrator Accounts
    Similar to database administrators, local server administrators usually have more power than they realize due to inherited permissions. In SQL Server versions prior to 2008, the local Windows administrators group is assigned the sysadmin role by default. As a result, every local administrator is inherently also a database administrator. The lesson here is: Don’t assign the local administrators group sysadmin database privileges.
  4. Database Service Accounts
    In most environments SQL Server service accounts are part of the local administrators group. As a result, service accounts usually have sysadmin database privileges just like any other local administrator account. Shared SQL Server service accounts are another very common problem/practice in large environments because they make managing accounts easier. However, the reality is that the shared service accounts compound the issue by opening unwanted lines of trust between all of the database servers. When using shared service accounts, anyone who can administer one database server can also access data on every other server using the shared service account. Local commands and queries can be executed as the SQL Server service account by executing the OSQL command with the “-E” switch via the xp_cmdshell extended stored procedure. Contrary to what your parents may have taught you, when it comes to SQL Server service accounts, it’s not nice to share.

Entry Points

Below is a list of potential entry points into MS SQL Servers. Generally speaking, a database entry point is anywhere a user or application interfaces with a database. The idea is simple enough, and I think that most IT professionals understand it. What they don’t always understand is what those entry points are, or they forget that any interface used legitimately can also potentially be used by an attacker. The list below is intended to shed a little light into both areas. Most of the entry points can also be used to access other data management systems like Oracle and MySQL. However, I haven’t supplied any details for those platforms.

  1. Database Listener
    By default, SQL Servers listen on port 1433. In most cases they are configured to allow connections from anywhere on the network. As a result attackers can attempt to use exploits and weak passwords to gain unauthorized access. Based on my experience, there is at least one SQL Server account configured with a weak password. There are a number of tools to help identify such accounts. I like to use the SQLPing3 scanner. It does a good job of identifying SQL Servers and weak account passwords with the right word list. It also does a good job of finding SQL Servers on non-default ports along with all of the associated instance information. If you’re not a fan of SQLPing3, pretty much any vulnerability scanner will find the default database credentials for a SQL Server on the default port. The general idea for this bullet is to patch regularly and set strong passwords for all database accounts. If you’re using SQL Server 2005 or later I suggest inheriting the local or domain account policies to help enforce strong passwords.
  2. ODBC
    Open Database Connectivity (ODBC) is a middle layer of software that helps facilitate communication between applications and database servers. If an ODBC connection is already configured, it can be used to execute arbitrary queries against the database server through applications that use it. Examples include but are not limited to, Access, Excel, and Word. Additionally, some configurations allow attackers to extract usernames and passwords from ODBC configuration files. For example, Cain & Able has a nice ODBC password extractor for SQL Server 2005. If the password is recovered, attackers can connect directly to the SQL Server using SQL Server Management Studio.
  3. Client-Server Applications
    I think a lot of developers are under the impression that if a client application’s GUI doesn’t give users the option to execute arbitrary database queries then it’s not possible. Unfortunately that is far from the truth. Many applications can be decompiled with tools like .NET Reflector and the Boomerang Decompiler. Once decompiled the connection strings are often accessible in clear text. In some case the connections strings can even be accessed with a hex editor prior to being decompiled. Also, tools like Echo Mirage can be used to intercept and modify network traffic between the application and the server. Users and attackers can actually conduct thick application SQL injection by modifying the database queries in the TCP payload. If you’re interested, Mike Anderson wrote a brief blog on the subject which is available at https://netspi.com/blog/2010/05/04/echo-mirage-piercing-the-veil-of-thick-application-security/. The take away here should be to obfuscate or encrypt your code, and encrypt all application communication with the server.
  4. Web Applications
    Web applications present a number potential entry points. My goal today is not to provide a comprehensive list, but I will include some examples. If an attacker can access clear text connection strings in source code or configuration files such as the web.config, then the attacker can user them to connect to the backend database. Vulnerabilities that provide read access to such files vary from application to application, but the result is the same. If you are using clear text connection strings, consider encrypting them or using integrated authentication. SQL injection is another big one, which I’m sure doesn’t come as a shock to anyone. In many cases SQL injection can be used to bypass firewalls and execute arbitrary queries on the backend database. For SQL injection use common sense and best practice coding methods. I would spend more time on solutions for SQL injection, but there are volumes on the subject available online. Finally, some web applications actually support the functionality to build SQL queries on the fly. Technically it doesn’t qualify as SQL injection, but it definitely has the same result. The fix? Don’t do that. 🙂
  5. Web Services
    There are surprising amounts of web services running applications behind the scenes out there. I’ve seen quite of few used by both web applications and client-server applications. SOAP, REST, and RPC web services all still seem to be pretty popular right now. Overall, SOAP web services seem to be used more by web applications, and REST/RPC web services seem to be used more by client-server applications. Regardless of the web service type, I’ve seen many of the same issues that affect traditional web applications causing security holes that provide attackers with arbitrary query access.

While assessing the security of your database servers make sure to consider more than the local database configuration. While the local database configuration needs to be secure, connections from trusted services can also be used as entry points by attackers. Make sure to lock down accounts from those trusted services or you may be unwittingly providing full database access to internal and external attackers.
– Boo evil

Reference Links

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X