Call: +44 (0)1904 557620 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Can You Say That An Oracle Database is nn% secure?"] [Next entry: "How to Perform a Security Audit of an Oracle Database Training in Athens, Greece"]

Is SQL Injection A WebSite Problem?



I saw a post on https://www.facebook.com/rob.lockard.12 - (broken link) RobLockards Facebook page this week where he said some people have suggested that his SQL Injection talk only shows calling a procedure from SQLCl and not a web page and he suggests that he may make a web page to satisfy those that want to see SQL Injection via a web-page.

I am not sure that you will be able to see Robs post on his Facebook; I am connected to him so I see it but its unclear if its findable without a connection but connect to Rob if you want to see it. The list is what i have said above anyway. Rob also has his site http://oraclewizard.com/Oraclewizard/ - (broken link) Oracle Wizard.

It is a good point; should SQL Injection in Oracle demos be made in SQLCl or SQL*Plus or from a webpage? - I have been at both ends of this spectrum for many years. I wrote what i think were the some of the first Oracle SQL Injection papers 15 years ago in 2002 for Security Focus (Now Symantec). These are:

SQL Injection and Oracle Part 1
Sql Injection and Oracle Part 2
Detecting SQL Injection in Oracle

These papers were written a long time ago - 14 - 15 years ago in fact but they are still mostly relevant in the principles. The formatting on the Symantec website is not good for some of the content but they are readable.

I also wrote the first big paper by anyone on Oracle Security in 2001 - which is available on the Pentest Website to read still. This is old but some of the thought patterns are still good and I mention SQL Injection against Oracle in that paper as well.

Whats the point of these references; well back in 2001 not many people were doing SQL Injection or most likely had even heard of it. Certainly the Oracle community (DBA, Devs, etc) most likely did not consider the risk of SQL Injection in Oracle databases. The DBMS_ASSERT package did not exist until 2004 but probably not in wide use until 2005/2006. The large slew of PL/SQL injections in built in packages had not started in 2001 / 2002. The alerts program was only just getting going in 2001 and these were the only security patches released on an "as-when" basis. The CPU security patch regime did not start until 2005 (If i remember correctly). The large onslaught of built in packages with Sql injection or PL/SQL injection came in the middle of this period.

If anyone had heard of SQL Injection back in 2001 / 2002 they mostly associated it with websites and MySQL as that was what Rain Forrest Puppy (the person credited with coming up with this technique) talked about in the first posts on SQL Injection I the late 90s. When I first started to think about SQL Injection in Oracle back in 2001 and then wrote the papers for Security Focus I wanted to make one very big point; That is SQL Injection is not a web thing; it is a script engine thing where the input can be manipulated by an outsider or end user beyond what was intended by the writer of the code. i.e. the script engine (SQL, PL/SQL, PHP, Javascript....) executes dynamic code; actually the code may not be intended to be dynamic in nature its just ended up being written in pieces and stuck together with + signs or || signs or concat or whatever the host language likes to use. This is the problem; a piece of code can be modified by injecting additional code instead of data.

At the time in 2001 I wanted to write my papers and make a point to the reader that this is a code problem not a web problem. Hence I used SQL*Plus as the vehicle to deliver the injection examples to the database and to show how SQL Injection works. I wanted people to realise that they still have a problem if some code is vulnerable to injection even if there is no website to access the code from.

I teach about SQL Injection still in my OracleSecurity classes ; in fact I cover SQL Injection in depth in the secure coding in PL/SQL class and also in the secure and lock down Oracle class and its covered also in the Audit trail design class and also the 2 days class on how to perform a security audit of an Oracle database. SQL Injection has not gone away.

Nowadays I do what Rob is talking about; I have two web applications; one is Worpress 2.0 ported to use Oracle as its database and not MySQL and the other is my own web based application written in PHP (actually its written in PL/SQL as the PL/SQL packages I have written generate PHP for me). This application I call BOF - "Back OfFice" and it was described in a blog post called BOF: A Sample Application For Testing Oracle Security about a year ago. I demonstrate quite a lot of hacking against the PHP websites and show SQL injection, injecting PL/SQL into SQL and also DDL injection. In fact I cover all sorts of stuff from adding users, showing code, adding back-doors, changing passwords, removing audit settings and much more. This is always great for the participants, they love it, they get mesmerised, sit on the edges off their seats and get really excited - Its fun to do BUT does it get across the message that this is a scripting language issue (PL/SQL in this case) in the database and not a website issue. In fact in some of my demos I go 5 layers deep; I inject DDL into dynamic PL/SQL that is itself injected into dynamic PL/SQL that is injected into a SQL in a PL/SQL function that was injected into the SQL statement in the PHP layer. Why so many layers well this was necessary to inject DDL into this particular application (Wordpress). Also i injected IDS evasion techniques to get around the security protections in the PHP in Wordpress as well. This is exciting and fun BUT people don't get this complexity to achieve something. Also the statements I inject are pre-designed. If i walked up to this Wordpress application blind (which I actually did when i wrote the samples) then it takes literally thousands of requests to get something that works - you cannot demonstrate that part and some people question - How did you know how to send such a complex attack string? - then i have to explain and the magic wears off a little.

This is why I also demonstrate attacks using SQL*Plus and this fits nicely. I show four levels of attack;

1) Attacking the website logon form and also search form as a non-authenticated user (no logon on the site, no logon on the database)
2) Attacking the website as an authenticated (website authenticated) user by exploiting the wordpress post, page, comment,...etc pages (no database password)
3) Attacking the database via SQL*Plus as a low level user - CREATE SESSION only
4) Attacking the database via SQL*Plus as a powerful user - CREATE SESSION and DBA roles.

This covers both worlds, it shows the excitement of hacking a website and shows how to avoid security layers in the application and also how to do various injections, SQL into SQL, PL/SQL into SQL, PL/SQL into PL/SQL and DDL into PL/SQL into SQL BUT it also shows the problem at the most simplistic layer; i.e. as close to the problem as possible; executing a PL/SQL procedure and exploiting it.

My view, do both but focus on the SQL*Plus examples as its easier to see whats happening and it illustrates that its not a web problem but a code problem.