Обнаружение SQL инъекций в ORACLE, часть вторая

Внутренние трассировочные файлы Oracle.

Oracle может также генерировать файлы трассировки из ядра Oracle, когда запущен SQL. Это может быть включено на уровне RDBMS, при установке параметра SQL_TRACE=true в файле init.ora. Это может также быть включено в случае следующего действия:

ALTER SYSTEM SET SQL_TRACE=TRUE;

Трассировка также может быть включена для текущего сеанса:

ALTER SESSION SET SQL_TRACE=TRUE;

Прежде, чем будет включена трассировка, параметр timed_statistics, в файле инициализации, должен быть установлен в значение TRUE. Трассировочные файлы будут записаны в файл, определенный, в файле инициализации, параметром  user_dump_dest.

Давайте создадим файл трассировки для нашего простого примера SQL инъекции и проанализируем его следующим образом:

SQL> alter session set sql_trace=true;

Session altered.

SQL> exec get_cust('x'' union select username from all_users where ''x''=''x');

PL/SQL procedure successfully completed.

SQL>

Файл трассировки создается с форматом имени: {SID}_ora_{PID).trc. Формат определяется платформой. В случае трассировочных файлов SQL*Net,  PID является OS PID, и снова это может быть определено с помощью запроса к представлениям v$session и v$process. Необработанный файл трассировки может быть прочитан, а рассматриваемый SQL может быть замечен следующим образом:

*** 2003-06-16 16:54:01.429

*** SESSION ID:(8.29) 2003-06-16 16:54:01.408

APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240

=====================

PARSING IN CURSOR #3 len=33 dep=0 uid=17 oct=42 lid=17 tim=1055782441429190 hv=3

732290820 ad='846c85c0'

alter session set sql_trace=true

END OF STMT

EXEC #3:c=0,e=1,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1055782441407935

*** 2003-06-16 16:54:34.876

=====================

PARSING IN CURSOR #3 len=82 dep=0 uid=17 oct=47 lid=17 tim=1055782474876639 hv=3

204430447 ad='8482555c'

BEGIN get_cust('x'' union select username from all_users where ''x''=''x'); END;

END OF STMT

PARSE #3:c=0,e=6430,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1055782474876611

Лучшим путем является запись файла трассировки с утилитой, называемой tkprof:

oracle:jupiter> tkprof emil_ora_616.trc output.trc sys=yes

TKPROF: Release 9.0.1.0.0 - Production on Mon Jun 16 16:59:50 2003

(c) Copyright 2001 Oracle Corporation. All rights reserved.

Сгенерированный файл содержит весьма много информации, включая синхронизацию и идентификаторы пользователей. Синхронизация должна читаться в необработанном файле трассировки, но пользовательский идентификатор может быть найден в выходных данных tkprof. Преобразованные выходные данные показывают пакеты PL/SQL, называемые также динамическими SQL строками:

BEGIN get_cust('x'' union select username from all_users where ''x''=''x');

END;

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.00 0.00 0 0 0 1

Fetch 0 0.00 0.00 0 0 0 0

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 2 0.00 0.01 0 0 0 1

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: 17

<output snipped>

select customer_phone

from

customers where customer_surname='x' union select username from all_users

where 'x'='x'

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.01 0.02 0 0 0 0

Execute 1 0.01 0.00 0 0 1 0

Fetch 37 0.01 0.00 0 184 5 36

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 39 0.03 0.03 0 184 6 36

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: 17 (recursive depth: 1)

Rows Row Source Operation

------- ---------------------------------------------------

36 SORT UNIQUE

36 UNION-ALL
<output snipped>

Пользовательский идентификатор можно прочесть в базе данных следующим образом:

<output snipped>
SQL> select username,user_id

2 from dba_users

3 where user_id=17;

USERNAME USER_ID

------------------------------ ----------

DBSNMP 17

SQL>

У трассировочных файлов, несомненно, есть перспектива в осуществлении системы обнаружения SQL инъекций, но у них также существуют некоторые серьезные проблемы:

·         Поскольку файлы трассировки тоже генерируются основанными на OS PID, то их обслуживание в реальном времени, для гарантирования от злоупотребления ресурсами, является очень трудным. Любые долго запущенные сеансы очень легко переполняют диск.

Информация в трассировочных файлах хороша и пригодна к использованию, но производительные проблемы с генерацией трассировки постоянно наводят на мысль о том, чтобы не использовать этот метод. Как и в случае с SQL*NET эти файлы могут использоваться более расчетливо.

Чтение SQL из System Global Area (SGA)

Это может быть наиболее перспективным методом выделения и анализа SQL, в случае если была сделана попытка SQL инъекции. Причины этого исключительно из-за того, что - основной элемент Oracle RDBMS, весь SQL и запущенный PL/SQL, проводит некоторое время в SQL области в SGA. Однако существует несколько проблем, чтобы быть уверенным в этом. Во-первых - то, что запрос к SQL области может интенсивно использовать ресурсы и заставить работать систему на критическом уровне, а во-вторых, может отсутствовать уже выполненный SQL. Если база данных запускает тысячи различных SQL, а память, выделенная для SQL области - не большая, то нечасто используемый SQL (однажды или дважды) может очень быстро покинуть SQL область.

Постоянные SQL запросы - являются ключевыми в контролировании нападений. Слишком часто это может приносить вред производительности, и не достаточно часто вы могли бы что-нибудь пропустить. Если организация использует этот метод для проверки нападений, то запускать проверки нужно два или три раза в день, а контролировать и исправлять необходимо как можно чаще.

Снова, как с другими источниками информации, фильтр или синтаксический анализатор  действительно необходимы для анализа SQL, извлеченного для показа некоторых признаков того, что является легальным, а что нет. Для начала можно использовать сценарий, проверяющий только существование union в SQL, фильтрующий некоторых возможных пользователей и сохраняющий результаты в итоговой таблице, используя команду create table as select, а далее фильтрующий определенные связанные таблицы. Хорошее первое приближение было бы должно выдвинуть на первый план любой SQL, произведенный не sys пользователем с предложением union, обращающимся к таблице или представлению, принадлежащему sys. Наш пример делает запрос к представлению all_users, принадлежащему sys.

Ниже простой пример запроса, извлекающего из SGA, SQL, содержащий в себе предложение union. Это должно дать читателю идеи о том, как могут быть прочитаны данные. Далее мы проводим фильтрацию, как описано выше.

select  a.address address,
        s.hash_value hash_value,
        s.piece piece,
        s.sql_text sql_text,
        u.username parsing_user_id,
        c.username parsing_schema_id
from    v$sqlarea a,
        v$sqltext_with_newlines s,
        dba_users u,
        dba_users c
where a.address=s.address
and a.hash_value=s.hash_value
and a.parsing_user_id=u.user_id
and a.parsing_schema_id=c.user_id
and exists (select 'x'
        from v$sqltext_with_newlines x
        where x.address=a.address
        and x.hash_value=a.hash_value
        and upper(x.sql_text) like '%UNION%')
order by 1,2,3
/

Running this gives: 


<output snipped>
QL_TEXT                            PARSING_USER_ID PARSING_SCHEMA_
----------------------------------- --------------- ---------------
and a.parsing_schema_id=c.user_id
and upper(s
.sql_text) like '%UNION%'           SYSTEM          SYSTEM
order by 1,2,3

BEGIN dbsnmp.get_cust('x'' union    SYS             SYS
select username from all_users
where ''x''=''x'); END;             SYS             SYS

select customer_phone from          SYS             SYS
customers where
customer_surname='x'
union select username from          SYS             SYS
all_users where 'x'='x'

BEGIN get_cust('x'' union select    DBSNMP          DBSNMP
username from all_users where '
'x''=''x'); END;                    DBSNMP          DBSNMP

select                              SYS             SYS
tc.type#,tc.intcol#,tc.position#,c.
type#, c.length,c.scal
<output snipped>

Пример был выполнен, как SYS пользователь и как DBSNMP пользователь, пока эта база данных неоднократно была в выводе(output). Этот метод пока, кажется, самый простой в использовании и вероятно самый легкий способ реализации полного средства/сценария для анализа SQL инъекций. Также он имеет наименьшее количество плохих сторон!

Использование аудита Oracle.

Возможности, доступные в стандартном Oracle аудите - богаты и различны, но существует множество проблем с его использованием, для обнаружения SQL инъекций.

Аудит должен использоваться независимо от использования любого из других методов. Это - устойчивая и полезная система может быть полезной для обнаружения нападений.

Не так легко обнаружить SQL инъекцию с помощью аудита, скорее можно отследить явные улики. Например, если аудит был включен для select access в таблицах DBSNMP.customers и SYS.all_users, тогда контрольный след должен показать проникновение, в случае использования, такой как описано в нашем примере, попытки SQL инъекции. Мы не можем определенно говорить, что использовался union, но доступ с помощью DBSNMP к ALL_USERS должен быть видим.

Когда хакер пытается предположить, как добавить union, подзапрос или  усекающий комментарий, к существующей SQL строке, то могут быть сгенерированы SQL ошибки, если он делает это неправильно. И снова это является явной уликой, а детальный анализ ошибок в контрольном следе и другие действия тем же самым пользователем в том же самом сеансе могут указывать на то, что случилось.

Ниже находиться пример использования аудита, для выполняющейся SQL инъекции. Сначала включите аудит в представлении ALL_USERS и таблице CUSTOMERS.

SQL> audit select on sys.all_users by access;

Audit succeeded.

SQL> audit select on dbsnmp.customers by access;

Audit succeeded.

Проверьте контрольный след со следующим SQL:

 SQL> audit select on sys.all_users by access;

Audit succeeded.

SQL> audit select on dbsnmp.customers by access;

Audit succeeded.

Все это показывает доступ к представлению ALL_USERS и таблице CUSTOMERS пользователями DBSNMP в одном и том же сеансе. Это также является простым в написании части SQL, для анализа ошибок в контрольном следе.

Аудит, несомненно, может использоваться, для обнаружения SQL инъекций, но он требует значительных усилий при определении "хороших" SQL запросов и параметров настройки аудита для надежного "предположения" при попытках SQL инъекций.

Триггеры базы данных.

Триггеры базы данных обычно являются следующей линией защиты, когда используется внутренний аудит Oracle. Нормальные средства аудита работают на уровне object, или привилегированном уровне, и не могут быть полезны при определения случившегося на уровне строки. Для этого могут использоваться триггеры. Их использование влечет за собой программирование триггеров для каждой таблицы и для каждого действия типа insert, update или delete. Главный недостаток триггеров это - то, что они не могут быть написаны для запуска, если команда select используется против таблицы или представления.

Выделение фактического SQL, используемого для update, delete , или insert - не возможно. Возможно, создать SQL, который будет использоваться при запуске триггера изменения таблицы, читая прежде и после значения для каждой строки и создать триггер запускающийся для каждой строки.

Ввиду этих ограничений, триггеры базы данных, не всегда полезны в поисках попыток SQL инъекций.

Высокоточный аудит

С версии 9i, в Oracle представлен высокоточный аудит (FGA). Эта функция основана на внутренних триггерах, запускающихся при каждом анализе SQL выражений. Как и высокоточный контроль доступа, (FGA) основывается на определении предикатов, для ограничения SQL, который будет ревизоваться. Используя аудитную политику, аудит может быть сфокусирован на небольшом поднаборе действий, выполненных против определенного набора данных.

Единственное преимущество, которое дает нам эта функция это способность контролировать команды select на уровне строк. Стандартная обрабатывающая функция, также фиксирует SQL, так что она может быть хорошим средством, для проверки SQL инъекций. Действительно, Oracle заявляет в своей on-line документации этого пакета, что он - идеальный инструмент для осуществления IDS системы.

Давайте установим простую политику и посмотрим, можем ли мы отловить инъекцию в нашем примере. Первое требование - то, что таблицы, с установленным против них FGA, должны генерировать аналитическую статистику. Также должен использоваться cost-based оптимизатор. Существует множество проблем с FGA, которые являются факторами неправильного запуска триггеров, например, если в SQL используется правило проверки RULE.

Сначала проверьте оптимизатор и проанализируйте пример таблицы:

SQL> analyze table dbsnmp.customers compute statistics;

Table analyzed.

SQL> select name,value from v$parameter
  2  where name='optimizer_mode';

NAME
----------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
optimizer_mode
CHOOSE

Затем, создайте политику, которая будет каждый раз выполнять выражение, запущенное против таблицы (в этом случае DBSNMP.CUSTOMERS).

SQL> set serveroutput on size 100000
SQL> exec get_cust('x'' union select username from all_users where ''x''=''x');
debug:select customer_phone from customers where customer_surname='x' union
select username from all_users where 'x'='x'
::AURORA$JIS$UTILITY$
::AURORA$ORB$UNAUTHENTICATED
::CTXSYS
::DBSNMP
::EMIL
<records snipped>
::SYS
::SYSTEM
::WKSYS
::ZULIA

Затем, выполните пример SQL инъекции, и проверьте контрольный след для любых входов:

SQL> col db_user for a15
SQL> col object_name for a20
SQL> col sql_text for a30 word_wrapped
SQL> select db_user,timestamp,object_name,sql_text
  2  from dba_fga_audit_trail
  3  order by timestamp;

DB_USER         TIMESTAMP OBJECT_NAME          SQL_TEXT
--------------- --------- -------------------- ------------------------------
DBSNMP          16-JUN-03 CUSTOMERS            select customer_phone from
                                               customers where
                                               customer_surname='x' union
                                               select username from all_users
                                               where 'x'='x'

SQL>

Отлично, успех! Динамический SQL показывается, включая предложение union, присоединенное к системной таблице ALL_USERS. Использование FGA должно быть расширено к каждой таблице в прикладном проекте. Тогда должны записываться сообщения, это возвращало бы только те входы, которые нарушают некоторые из основных правил, определенных вначале, типа SQL с предложением union, или SQL со строкой типа 'x' = 'x'.

Вся политика может быть легко сгенерирована, используя следующий SQL:

 select 'exec dbms_fga.add_policy(object_schema=>'''||owner||''',object_name=>'''
||table_name||''',policy_name=>'''||table_name||''',audit_condition=>''1=1'',aud
it_column=>null,handler_schema=>null,handler_module=>null,enable=>true);'
from dba_tables
where owner not in ('SYS','SYSTEM')
/
 

Защита лучше чем обнаружение

Некоторые решения по защите от SQL инъекций, можно узнать из  предыдущих статей, но для совершенства, несколько главных идей снова здесь включены:

Выводы