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

По материалам SecurityFocus.com

Введение

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

Данная статья более подробно развивает данную тему и исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. Возможно ли вообще обнаружение SQL инъекции? Если да, то какие средства и методы должны использоваться?

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

Можно ли обнаружить SQL инъекцию?

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

Существует много различных форм атак с помощью SQL инъекций - они ограничены только воображением хакера и предвидением DBA (или его нехваткой) в защите базы данных и обеспечении наименьшего количества необходимых привилегий.

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

Сначала необходимо определить граничные условия, или какие действия должны быть обнаружены. Затем нужно выбрать возможные бесплатные решения в рамках Oracle и как можно их использовать для достижения хорошего эффекта.

Некоторые возможные коммерческие решения

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

Некоторые бесплатные решения 

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

Главное, сначала сделать все как можно проще; попытка делать что-то слишком сложное с помощью встроенных средств, в данном случае не принесет никакого эффекта. Важно не “перегнуть палку” с предположениями о том, что действительно является легальным SQL, а что создано хакером. Остерегайтесь ложных плюсов. Делайте это просто и действенно - используйте, если возможно, более одного метода, расширяйтесь и учитесь.

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

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

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

Если невозможно обнаружить SQL инъекцию в реальном времени, то лучше узнать позже, чем вообще не знать, что это произошло.

Примеры с решениями

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

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

  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
::FRED

Теперь мы проанализируем, какие из трассировок, пакетов, контрольной и внутренней информации, смогли записать любое из доказательств выполнения этого запроса.

Сборщик логов

Oracle поддерживает две хранимые процедуры базы данных DBMS_LOGMNR и DBMS_LOGMNR_D, позволяющие архивировать и интерактивно восстанавливать лог файлы, которые будут проанализированы. Восстановленные лог файлы содержат всю информацию, для воспроизведения любого действия в базе данных. Они используются для моментального восстановления, для транзакций и совместимости данных. Однако существуют некоторые, перечисленные ниже, проблемы с функциональными возможностями Сборщика логов.

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

Некоторые преимущества Сборщика логов:

Для того чтобы сделать практичным использование этого инструмента,  база данных должна быть в режиме ARCHIVELOGMODE, а для размещения пользовательской информации значение transaction_auditing в файле инициализации должно быть true.

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

Восстановленные лог файлы, также могут быть проанализированы вручную. Хорошая статья, демонстрирующая это, может быть найдена здесь.

Теперь мы можем просмотреть пример и исследовать содержание архивных лог файлов. Сначала проверьте, находится ли база данных в ARCHIVELOGMODE, определите, где записаны архивные лог файлы и, наконец, что включен аудит имен пользователей.

SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG
SQL> select name,value from v$parameter
2 where name in('log_archive_start','log_archive_dest');
NAME
------------------------------------------------------
VALUE
------------------------------------------------------
log_archive_start
TRUE
log_archive_dest
/export/home/u01/app/oracle/admin/emil/archive

Обнаружение, какой именно пользователь выполнил команду:

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

NAME
----------------------------------------------------------------
VALUE
----------------------------------------------------transaction_auditing
TRUE
  

Теперь запустите пробную SQL инъекцию, а затем используйте Сборщик логов, для просмотра того, что было зарегистрировано. Для облегчения анализа этого примера, архивный лог файл сохраняется только до, и после выполнения этой команды находящейся в лог файле:

  SQL> connect sys as sysdba 
Enter password:
Connected. 
SQL> alter system archive log current;
System altered. 
SQL> 
SQL> connect dbsnmp/dbsnmp@emil 
Connected.
SQL> 
set serveroutput on size 100000 
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

PL/SQL procedure successfully completed. 
SQL> connect sys as sysdba 
Enter password:
Connected. 
SQL> alter system archive log current; 
System altered. 
SQL> 
  

Сначала создайте словарь Сборщика логов:

SQL> set serveroutput on size 1000000
SQL> exec dbms_logmnr_d.build('logmnr.dat','/tmp');
LogMnr Dictionary Procedure started
LogMnr Dictionary File Opened
TABLE: OBJ$ recorded in LogMnr Dictionary File
TABLE: TAB$ recorded in LogMnr Dictionary File
TABLE: COL$ recorded in LogMnr Dictionary File
TABLE: TS$ recorded in LogMnr Dictionary File
<output snipped>
Procedure executed successfully - LogMnr Dictionary Created
PL/SQL procedure successfully completed.
SQL>

Найдите правильный архивный лог файл:

SQL> select name
  2  from v$archived_log
  3  where completion_time=(select max(completion_time) from v$archived_log);

NAME
--------------------------------------------------------------

/export/home/u01/app/oracle/admin/emil/archive/1_7.dbf

SQL>

Теперь загрузите архивный лог файл в Сборщик логов:

SQL> exec dbms_logmnr.add_logfile
('/export/home/u01/app/oracle/admin/emil/archive/1_7.dbf',sys.dbms_logmnr.NEW);

PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.start_logmnr(dictFileName => '/tmp/logmnr.dat');

PL/SQL procedure successfully completed.

SQL>

Наконец необходимо найти результаты:

SQL> select scn,username,timestamp,sql_redo
  2      from v$logmnr_contents
SQL>
<snipped>
       

       SCN USERNAME        TIMESTAMP SQL_REDO
---------- --------------- --------- ------------------------------
    253533 DBSNMP          16-JUN-03 set transaction read write;
    253533 DBSNMP          16-JUN-03 update "SYS"."AUD$" set
                                     "ACTION#" = '101',
                                     "RETURNCODE" = '0',
                                     "LOGOFF$LREAD" = '228',
                                     "LOGOFF$PREAD" = '0',
                                     "LOGOFF$LWRITE" = '10',
                                     "LOGOFF$DEAD" = '0',
                                     "LOGOFF$TIME" =
                                     TO_DATE('16-JUN-2003
                                     12:16:12', 'DD-MON-YYYY

       SCN USERNAME        TIMESTAMP SQL_REDO
---------- --------------- --------- ------------------------------
                                     HH24:MI:SS'), "SESSIONCPU" =
                                     '5' where "ACTION#" = '100'
                                     and "RETURNCODE" = '0' and
                                     "LOGOFF$LREAD" IS NULL and
                                     "LOGOFF$PREAD" IS NULL and
                                     "LOGOFF$LWRITE" IS NULL and
                                     "LOGOFF$DEAD" IS NULL and
                                     "LOGOFF$TIME" IS NULL and
                                     "SESSIONCPU" IS NULL and ROWID
                                     = 'AAAABiAABAAAAEWAAX';


       SCN USERNAME        TIMESTAMP SQL_REDO
---------- --------------- --------- ------------------------------
    253534 DBSNMP          16-JUN-03 commit;
<snipped output>

Первое, что можно заметить это то, что Сборщик логов не обрабатывает команды select и отображает вывод в 9i. Модуль Сборщика логов не поддерживает выборки, поскольку они не сохраняются в восстановленных лог файлах. Возможно использование Сборщика логов, для онлайнового чтения восстановленных лог файлов, но я оставляю эти эксперименты читателям. Даже притом, что SQL инъекция может быть обнаружена в insert, delete и update выражениях, Сборщик логов не является подходящим средством для обнаружения SQL инъекций. Это, также как и некоторые другие проблемы, упомянутые выше, является недостатком в способности Сборщика логов обнаруживать команды select.

Анализатор сетевых пакетов

Главная проблема в анализаторе пакетов при подключении к базе данных Oracle это то, что сетевой протокол Oracle является собственным и не открытым. Это имеет ли значение при установлении, были ли попытки SQL инъекций? Вероятно да, поскольку доступ к протоколу был бы более эффективным инструментом для решения этой задачи. При отсутствии доступа к протоколу и желания это воспроизводить, задача ограничена только захватом строк ASCII-текста из шины. Существуют как преимущества, так и недостатки этого метода:

Преимущества:

  Система может быть реализована на отдельном сервере, позволяющем проводить анализ в реальном масштабе без влияния на исходную базу данных.

Недостатки:

Анализ каждого пакета приводит к генерации огромного количества данных. Конвейеризация пакетов через программу-фильтр смягчает эту проблему.

Для демонстрации, мы будем использовать snoop на Solaris, чтобы увидеть то, что видимо внутри сетевых пакетов. Запустите snoop, и SQL из сеанса SQL*PLUS:

root:jupiter> snoop -t a -x 0 jupiter and port 1521 | strings
Using device /dev/hme (promiscuous mode)
15:06:34.31348 172.16.240.3 -> jupiter TCP D=1521 S=1404  Ack=299902194 
\Seq=26460609 Len=174 Win=8413
   0: 0800 2092 9d88 00a0 ccd3 a550 0800 4500    .. ........P..E.
  16: 00d6 6884 4000 8006 596d ac10 f003 ac10    ..h.@...Ym......
  32: f00b 057c 05f1 0193 c1c1 11e0 24f2 5018    ...|........$.P.
  48: 20dd 0f36 0000 00ae 0000 0600 0000 0000     ..6............
  64: 1169 36a4 61de 0001 0101 0303 5e37 0304    .i6.a.......^7..
  80: 0021 0078 71de 0001 52bc 39de 0001 0a00    .!.xq...R.9.....
  96: 0000 00e0 39de 0000 0101 0000 0000 0000    ....9...........
 112: 0000 0000 0000 0000 0000 0000 0000 0000    ................
 128: e239 de00 4245 4749 4e20 6765 745f 6375    .9..BEGIN get_cu
 144: 7374 2827 7827 2720 756e 696f 6e20 7365    st('x'' union se
 160: 6c65 6374 2075 7365 726e 616d 6520 6672    lect username fr
 176: 6f6d 2061 6c6c 5f75 7365 7273 2077 6865    om all_users whe
 192: 7265 2027 2778 2727 3d27 2778 2729 3b20    re ''x''=''x');
 208: 454e 443b 0a00 0101 0101 0000 0000 0001    END;............
 224: 0800 0105                                  ....
15:06:34.33281      jupiter -> 172.16.240.3 TCP D=1404 S=1521     Ack=26460783 
Seq=299902194 Len=54 Win=24820
   0: 00a0 ccd3 a550 0800 2092 9d88 0800 4500    .....P.. .....E.
  16: 005e 094a 4000 4006 f91f ac10 f00b ac10    .^.J@.@.........
  32: f003 05f1 057c 11e0 24f2 0193 c26f 5018    .....|..$....oP.

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

В качестве простого решения, анализ сетевых пакетов, может выступать в роли альтернативного решения, обеспечивающего достаточно простые фильтры/синтаксические анализаторы, написанные в Perl или C. Нашей целью является вывод возможных преступлений, выделяя SQL, timestamp и src и dest IP из пакетного потока.

Анализ внутренних сетевых пакетов Oracle (sqlnet trace)

Извлечение сетевой информации из Oracle возможно, используя средство трассировки SQL*NET, Net*8 или Oracle networking (смотря какое из названий подходит к версии вашей базы данных).

Средства трассировки доступны для большинства сетевых сервисов Oracle, таких как: listener, Oracle names, connection manager, names control utility, и конечно Oracle networking client and server. В этом примере мы сконцентрируем внимание на трассировке сервера.

Существуют некоторые недостатки в использовании сетевых трассировочных файлов, как средства поиска SQL инъекций:

SQL> select p.spid,s.username
  2  from v$session s,v$process p
  3  where s.paddr=p.addr;
SPID      USERNAME
--------- ------------------------------
<records snipped>
616       DBSNMP
556       SYSTEM
9 rows selected.
SQL>

Для включения трассировки необходимо в файле $ORACLE_HOME/network/admin/sqlnet.ora добавить следующие строки:

TRACE_FILE_SERVER=pf_trace.trc
TRACE_DIRECTORY_SERVER=/tmp
TRACE_LEVEL_SERVER=SUPPORT

Параметры определяют, где должен быть записан файл трассировки, как он должен называться, а также его уровень. Существует четыре используемых уровня трассировки: OFF, USER, ADMIN и SUPPORT. Они повышают детализацию трассировки от OFF до SUPPORT; уровень SUPPORT учитывает содержание сетевых пакетов.

Давайте снова запустим наш пример из SQL*PLUS на Windows-клиенте и посмотрим, что было сгенерировано в a файле трассировки. Трассировочный файл, как и ожидалось, называется pf_trace_616.trc. Ничего себе! Этот файл содержит в себе 4005 строк, и это только из-за соединения и запуска следующей команды:

SQL> exec get_cust('x'' union select username from all_users where ''x''=''x');
PL/SQL procedure successfully completed.

Выполнив поиск дампа пакета, в файле трассировке, мы можем найти попытку SQL инъекции, посланной базе данных:

nsprecv: 165 bytes from transport
nsprecv: tlen=165, plen=165, type=6
nsprecv: packet dump
nsprecv: 00 A5 00 00 06 00 00 00  |........|
nsprecv: 00 00 03 5E 35 03 04 00  |...^5...|
nsprecv: 21 00 78 71 DE 00 01 52  |!.xq...R|
nsprecv: BC 39 DE 00 01 0A 00 00  |.9......|
nsprecv: 00 00 E0 39 DE 00 00 01  |...9....|
nsprecv: 01 00 00 00 00 00 00 00  |........|
nsprecv: 00 00 00 00 00 00 00 00  |........|
nsprecv: 00 00 00 00 00 00 00 E2  |........|
nsprecv: 39 DE 00 42 45 47 49 4E  |9..BEGIN|
nsprecv: 20 67 65 74 5F 63 75 73  | get_cus|
nsprecv: 74 28 27 78 27 27 20 75  |t('x'' u|
nsprecv: 6E 69 6F 6E 20 73 65 6C  |nion sel|
nsprecv: 65 63 74 20 75 73 65 72  |ect user|

nsprecv: 6E 61 6D 65 20 66 72 6F  |name fro|
nsprecv: 6D 20 61 6C 6C 5F 75 73  |m all_us|
nsprecv: 65 72 73 20 77 68 65 72  |ers wher|
nsprecv: 65 20 27 27 78 27 27 3D  |e ''x''=|
nsprecv: 27 27 78 27 29 3B 20 45  |''x'); E|
nsprecv: 4E 44 3B 0A 00 01 01 01  |ND;.....|

При использовании файлов трассировки SQL*Net, существует еще ряд проблем, помимо перечисленных выше:

Этот метод не удобен, для выполнения простой утилиты обнаружения SQL инъекций. Ресурсные проблемы только затрудняют управление и работу. Можно использовать это более расчетливо, когда подозреваемый инцидент произошел и где использование трассировки может контролироваться на ограниченном отрезке времени или числе пользователей.

продолжение следует....