Hackers - SQL Injection

[sjethwa]

We may have experienced someone trying to hack our databse via an EBase form by entering a SQL statement into a text/textarea field repeatedly.

Luckily they didn't get anywhere since the sql syntax was incorrect, but below is the form-level error message we trapped:-

===============================================
An error occured within the Hertfordshire Archives and Local Studies online index application

System Time: 14:49
Form: HALS_INDEXES
Current page: SEARCH_SUMMARY
Current script:
User name: xyz_TEMP_99
Order ID:
Error message: SQL error on statement select * from sequences where sequence_id = ? - StandardXAConnectionHandle:prepareStatement getTransaction exception: javax.transaction.SystemException: Cannot send XA(StandardXAConnection:
commit on prepare =<false>
is closed =<false>
this autoCommit =<false>
listeners size =<1>
next timeOut =<0>
timeOut period =<60000>
timeOut secs =<0>
transaction manager=<org>
StandardXADataSource:
connection count=<2>
number of dead connection=<0>
dead lock max wait=<300000>
dead lock retry wait=<10000>
driver=<oracle>
driver name=<oracle>
number of *free* connections=<1>
max con=<0>
min con=<50>
prepared stmt cache size=<0>
transaction manager=<org>
xid connection size=<0>
StandardConnectionPoolDataSource:
master prepared stmt cache size=<0>
prepared stmt cache size =<0>
StandardDataSource:
driver=<oracle>
url=<jdbc>
user=<xxxx_xxxxxxt>
CoreDataSource :
debug =<false>
description =<null>
login time out =<60>
user =<ufs_hertsdirect>
verbose =<false>
StandardXADataSource:
connection count=<2>
number of dead connection=<0>
dead lock max wait=<300000>
dead lock retry wait=<10000>
driver=<oracle>
driver name=<oracle>
number of *free* connections=<1>
max con=<0>
min con=<50>
prepared stmt cache size=<0>
transaction manager=<org>
xid connection size=<0>
StandardConnectionPoolDataSource:
master prepared stmt cache size=<0>
prepared stmt cache size =<0>
StandardDataSource:
driver=<oracle>
url=<jdbc>
user=<xxx_xxxxxxxxx>
CoreDataSource :
debug =<false>
description =<null>
login time out =<60>
user =<xxx_xxxxxxxxxt>
verbose =<false>
StandardXAStatefulConnection:
commit on prepare =<false>
timed out =<false>
id =<1893>
state =<6>
time out =<0>
xid =<bb14>
StandardXAConnectionHandle:
global transaction =<true>
is really used =<false>
this autoCommit =<true>
in use size =<0>
master prepared stmt cache size =<0>
transaction =<bb14>
connection =<oracle>
oracle.jdbc.driver.T4CConnection@23627d) start:javax.transaction.xa.XAException: java.sql.SQLException: Closed Connection (error code = 0) --java.sql.SQLException: Closed Connection
===============================================


I was wondering if anyone else has seen this? More importantly, does anyone have any ideas on how to stop such randon sql statements being entered into fields and being executed via EBase scripts?

I guess we could inspect EACH field on EACH form to see if there are any special characters or sequence of words --- eg, prevent use of *, (, ), select, characters or words that may be used in SQL starements, but this would be overkill, especially retrospectively for our 100s of forms.

I am hoping there is a Tomcat level security patch available to stop this sort of hack? Or is it down to low level field validation.

Comments appreciated.

Thanks

Sanjay

[Joost]

We may have experienced someone trying to hack our databse via an Ebase form by entering a SQL statement into a text/textarea field repeatedly.
[...]
I was wondering if anyone else has seen this? More importantly, does anyone have any ideas on how to stop such randon sql statements being entered into fields and being executed via Ebase scripts?

I have not seen this on our installation. I guess Ebase at the least uses PreparedStatements for their database access and thus prevents SQL injection for the largest part. We are regularly checked by a security company and thusfar our webinstallations including Ebase are deemed safe. Because I was asked recently if Ebase is vulnerable to SQL Injection I would like some insight from Ebase on this as well though.

Could it be you only got hammered by some script trying various well known exploits for CMS's and other webbased software in general and only passed your site? I've seen this a lot at FTP sites as well. They try, but cannot get in.

I guess we could inspect EACH field on EACH form to see if there are any special characters or sequence of words

If you would do something like this I would go the other way around. I'd not try to think of all possible exploitable characters, but just allow only the bare minimum of characters. I've used a java method to sanitize web input this way before.

But this would mean amending various scripts. I'd first check if the attacking IP addresses are known in spam-blacklists like Project Honey Pot and use their API to ward off future attacks. I used it to protect a Smartsite CMS installation which was harassed a lot by form spammers.

[sjethwa]

Thanks Joost for your comments.

I agree we may have been hammered as you suggest, but it looks like the SQL statement WAS being executed (albeit it failed becuase of incorrect table+column name).

A comment from our friends at EBase on SQL Injection vulnerabilities would be useful ....

Sanjay

[Hovik]

There is nothing to suggest that this was an attempt at hacking into the system. Looking at the log message, it seems that the error was caused by the database connection being closed.

The sql statement: “select * from sequences where sequence_id = ?”

is a query issued by Ebase itself, when the sequence fpl command is used. In particular, the ? at the end of the statement is used by Ebase in a prepared statement – this is not something that would be used by a hacker as the ? only has meaning when substituted with a real value.


The following addresses the more general concern of Ebase vulnerability to attack by SQL Injection.

In the vast majority of cases, SQL Injection is not possible with Ebase because character data entered by the end user is automatically enclosed in quotes and this makes SQL Injection impossible.

However, there is one specific scenario where SQL Injection may be possible. If you need to know the detailed circumstances, please request this information by email.

A hacker normally gains information by trial and error. In a development system, Ebase displays detailed runtime error messages to the user. A hacker could potentially use such information in subsequent attempts.

It is imperative and good practice to prevent such messages in a production system, by setting Ufs.systemMode=Prod. Furthermore, we also recommend replacing the error message page by your own, user friendly, page.

A hacker will get no feedback to their attempts, and give up.

[sjethwa]

Many thanks Hovik for your analysis and response.

Please can you forward me the one scenario you mention via email.

I will consider setting the production system mode to PROD as you suggest.


Sanjay