Detecting Database Attacks

 < Day Day Up > 

Database attacks, as already discussed, often occur as a result of poor coding. Compromising the contents of a database or even the server on which it resides can, on the surface, be passed off as perfectly legitimate SQL traffic. It is only when the environment is secured against the casual attacker that a more determined attempt can be detected.

Auditing

Auditing is often the first step for a DBA in identifying unauthorized access, or attempted access, to a database server.

Access auditing is simple to enable. You can configure and interrogate it either at the server or database level. SQL Server maintains its own error logging system in addition to the Windows Event Log. When access auditing is configured in SQL Server, audit events are written to both logs. SQL Server has four audit levels, shown previously in Figure 8-7:

  • None Login attempts are not recorded.

  • Success Only successful logins are written to the log.

  • Failure Only failed logins are written to the log.

  • All Every attempt to log in to the database is recorded.

As a further level of protection, an intrusion detection system (IDS) provides functionality to protect against unauthorized access. Figure 8-10 shows the default Cisco IDS signature that detects all attempts to log in as the sa account.

Figure 8-10. Cisco IDS Signature 3702


From this, you can see the results produced by the IDS when the sa account attempts to log in (successfully or otherwise) in Figure 8-11.

Figure 8-11. Cisco IDS Event Viewer Detecting 3702 Events


Failed Logins

As with any application, SQL Server passwords can be brute forced. As previously discussed, several tools exist for just such a purpose. You can spot a clumsy attempt to brute force access to the SQL Server if you enable monitoring of failed logins. Figure 8-12 shows an extract from the SQL Server log with full auditing configured.

Figure 8-12. SQL Server Error Log Extract


System Stored Procedures

Among the many system stored procedures that SQL Server boasts, sp_password is used to add or change a password for a SQL Server login. The useful thing about this stored procedure is that every time it is called, the name sp_password is recognized, and the entire statement is hidden from view. The syntax of sp_password is this:

sp_password 'old password', 'new password', 'login name';

Figure 8-13 shows the results in SQL Profiler of executing this statement:

sp_password '123', '123', 'SQLlogin'

Figure 8-13. SQL Profiler Showing sp_password Being Executed


This feature prevents usernames and passwords from being presented in log files in clear text, and as such, it increases security on one level. However, had you executed the following SQL statement instead:

select 'sp_password', * from orders

the result in SQL Profiler would have been the same as in Figure 8-13. Just embedding the string 'sp_password' anywhere within the SQL statement is enough for the whole statement to be obscured and the message (as shown in Figure 8-13) to be displayed instead. Armed with this knowledge, a hacker can easily disguise his activities. However, it would be unusual for numerous password changes to occur at the same time. Also, although the actual SQL statements cannot be interrogated, the presence of more than two or three password changes in quick succession should alert a DBA to a potential attack.

SQL Injection

The nature of SQL injection makes it almost impossible to detect attacks either in real-time or via any type of auditing process. Only when damage has been done (data altered, perhaps) or Trojans have been entered into code does it become apparent that the system has been compromised. Even IDS can rarely detect SQL injection attacks, largely because no signature can be traced.

The only safeguard against SQL injection attacks is to implement a full code review and maintain tight controls on coding standards of production systems. Ensure that input validation is maintained throughout your applications and that input data is "scrubbed" to remove any potentially dangerous characters such as the single quote (') or the semicolon (;).

     < Day Day Up > 


    Penetration Testing and Network Defense
    Penetration Testing and Network Defense
    ISBN: 1587052083
    EAN: 2147483647
    Year: 2005
    Pages: 209

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net