Network Layer Attacks

Application Layer Attacks

There are two categories of attack in the application level. The first involves simply exploiting exposed functionality in order to run operating system commands, and the second involves the exploitation of buffer overflow issues within the functionality. Either way, the exploit is written in SQL (or T-SQL or PL/SQL) and can be launched from a standard SQL client tool. Due to the fact that SQL and extensions to SQL are equivalent to a programming language, you can hide the attack by coding it in any number of ways. This technique makes it extremely difficult for the target program to defend itself against or even notice attacks if examination takes place only at the application layer. In my experience, Intrusion Detection Systems (IDSs) and even Intrusion Prevention Systems (IPSs) miserably fail to notice anything untoward taking place. As a simple example, consider this: Before the actual attack is launched, the exploit, which could be encoded, is inserted into a table. Then a second query is made, perhaps weeks later, that selects the exploit into a variable and then exec s it.

 Query 1: INSERT INTO TABLE1 (foo) VALUES ('EXPLOIT')     Query 2:     DECLARE @bar varchar(500) SELECT @bar = foo FROM TABLE1  EXEC (@bar) 

You might say that this could be recognized as an attack by the dynamic exec . Certainly it could, but if this kind of query is not outside the bounds of normal use, then this attack could not be differentiated from a normal query. By far, the best approach to securing database servers is not to rely on IPS/IDS but to spend time seriously locking down the server.