По материалам SecurityFocus.com Введение В прошлом году были написаны две статьи о SQL инъекциях в Oracle. В них были описаны различные методы SQL инъекций, используемые в Oracle, даны простые примеры об их работе и некоторые предложения по защите от нападений злоумышленников, использующих эти методы. Статьи можно найти здесь: SQL инъекция и Oracle, часть 1 SQL инъекция и Oracle, часть 2 Данная статья более подробно развивает данную тему и исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. Возможно ли вообще обнаружение SQL инъекции? Если да, то какие средства и методы должны использоваться? В этой статье мы сфокусируем внимание на исследовании некоторых методов трассировки данных и анализе лог файлов. Наша цель - показать читателю доступные решения. В этой статье не упоминаются коммерческие решения. Так как настоящие инструменты обнаружения SQL инъекций включают в себя написание синтаксических анализаторов или фильтров для анализа SQL выражений, то полный показ таких методов, к сожалению, выходит за рамки короткой статьи. Можно ли обнаружить SQL инъекцию? Ответ короткий - определенно да... вероятно... То есть да, возможно обнаружить SQL инъекцию, но вероятно, что не всегда и не во всех случаях, и не всегда в реальном времени. Причины этого сложны и их много: Существует много различных форм атак с помощью SQL инъекций - они ограничены только воображением хакера и предвидением DBA (или его нехваткой) в защите базы данных и обеспечении наименьшего количества необходимых привилегий. Идентификация нелегальных SQL выражений является непростой задачей. Причиной возможности SQL инъекций является использование в приложениях динамического SQL запроса. Это означает, что очень тяжело, а в некоторых случаях даже невозможно определить все легальные SQL выражения. Если легальные выражения невозможно определить, тогда мы будем считать их нелегальными. Также не всегда просто отличить нормальное администрирование от нападения, т.к. нападающий может захватить и использовать учетную запись администратора. При обнаружении SQL инъекций, неизбежны всевозможные дополнения или сокращения SQL выражений при их синтаксическом анализе. Имена таблиц и представлений должны быть извлечены и проверены, для того чтобы увидеть, были ли они изменены. Для полезности методики, мы не должны слишком сильно затрагивать производительность базы данных. Также необходимы подтверждения данных, таких как имена пользователей и временных меток данных. И многое другое... Обнаружение попыток SQL инъекций вообще и конкретно против Oracle возможно. Как возможно этого добиться, и какие данные являются доступным? В данной статье мы попытаемся исследовать эти вопросы. Сначала необходимо определить граничные условия, или какие действия должны быть обнаружены. Затем нужно выбрать возможные бесплатные решения в рамках Oracle и как можно их использовать для достижения хорошего эффекта. Некоторые возможные коммерческие решения Нет никаких коммерческих решений, обнаруживающих попытки SQL инъекций, конкретно в базах данных Oracle. Существует определенное количество программ межсетевой защиты, которые объединяют Oracle proxy и несколько средств IDS, поддерживающих Oracle. В настоящее время множеством компаний серьезно разрабатываются проекты IDS приложений под Oracle, и возможно эти средства смогут обнаруживать SQL инъекции. Для должной работы большинства существующих коммерческих программ, необходимо использование правил и сигнатур, определенных для специфических случаев Oracle. Некоторые бесплатные решения Невозможно определить полный список всех типов и сигнатур SQL инъекций, но в качестве отправной точки можно выделить следующее: SQL, в котором предложение UNION, вызывает обращение к другой таблице или представлению. SQL, в котором добавлен необоснованный SUB-SELECT. SQL, в котором предложение WHERE было зациклено, путем дополнения строки типа '' = '' или 1=1. SQL, в котором происходит необоснованный вызов встроенных или сохраненных процедур. SQL, в котором выполнен доступ к системным таблицам и/или пользовательским приложениям и идентификационным таблицам. SQL, в котором, предложение WHERE было сокращено с помощью комментария - -- Анализ некоторых классов ошибок, указывающих на то, что выбранные классы имеют неправильное количество аргументов или неправильный тип данных. Это может указать на то, что кто-то пытается создать дополнительный запрос, используя предложение UNION. Главное, сначала сделать все как можно проще; попытка делать что-то слишком сложное с помощью встроенных средств, в данном случае не принесет никакого эффекта. Важно не “перегнуть палку” с предположениями о том, что действительно является легальным SQL, а что создано хакером. Остерегайтесь ложных плюсов. Делайте это просто и действенно - используйте, если возможно, более одного метода, расширяйтесь и учитесь. Любое средство или система, используемые для обнаружения SQL инъекций, могут идентифицировать большинство возможностей из вышеупомянутого списка. В попытке определить, откуда приходят данные для анализа SQL, следующие шаги должны быть полезными для одного и нескольких методов: Необходим как можно более быстрый захват SQL, отправленного базе данных. Необходимо выполнение анализа SQL, для проверки некоторых или всех вышесказанных случаев, указывающих на SQL инъекцию. Необходимо получение пользовательских и timestamp данных. Фокусирование внимания на захвате SQL, а если возможно, то на получении timestamp и пользовательской информации, также как и возможный дальнейший анализ, приводят нас к следующему списку возможностей: Сетевые снифферы/IDS средства, типа snort (не используются в дальнейших экспериментах) Бесплатные анализаторы сетевых пакетов, типа snoop Файлы сетевой трассировки ORACLE Файлы трассировки Oracle сервера Извлечение SQL из памяти Oracle сервера (SGA) Использование инструментов типа Oracle Log Miner (Сборщик логов) и возможно анализ повторных логов Oracle аудит Триггеры базы данных Высокоточный аудит (Fine grained audit, FGA) Из-за некоторых проблем нельзя находиться в полной уверенности. Средства аудита используются исключительно для более явных случаев. Если при шифровании сетевого трафика используются дополнительные параметры 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 :BSNMP ::EMIL ::FRED Теперь мы проанализируем, какие из трассировок, пакетов, контрольной и внутренней информации, смогли записать любое из доказательств выполнения этого запроса. Сборщик логов Oracle поддерживает две хранимые процедуры базы данных DBMS_LOGMNR и DBMS_LOGMNR_D, позволяющие архивировать и интерактивно восстанавливать лог файлы, которые будут проанализированы. Восстановленные лог файлы содержат всю информацию, для воспроизведения любого действия в базе данных. Они используются для моментального восстановления, для транзакций и совместимости данных. Однако существуют некоторые, перечисленные ниже, проблемы с функциональными возможностями Сборщика логов. Если используется база данных MTS (Multi Threaded Server), то Сборщик логов не может использоваться из-за внутреннего распределения памяти этой программы. Сборщик логов использует PGA память, невидимую потокам, используемым в MTS. Программа не поддерживает должным образом цепные и перемещаемые строки, а также не полностью поддерживаются объекты. Анализ индексных таблиц и кластеров также не поддержан. SQL, сгенерированный Сборщиком логов, не такой как SQL, выполненный пользователем. Это происходит, из-за того, что восстановленные лог файлы сохраняют достаточно данных для изменения значений на уровнях строк и столбцов, так что невозможно воспроизвести первоначальные составные выражения. Некоторые преимущества Сборщика логов: Анализ не могут выполнять в исходной базе данных, поэтому архивные лог файлы могут быть перемещены в специализированную базу данных и проанализированы автономно. Существует инструмент с графическим интерфейсом, доступный через Oracle Enterprise Manager (OEM) Для того чтобы сделать практичным использование этого инструмента, база данных должна быть в режиме 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 :BSNMP ::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-текста из шины. Существуют как преимущества, так и недостатки этого метода: Преимущества: Система может быть реализована на отдельном сервере, позволяющем проводить анализ в реальном масштабе без влияния на исходную базу данных. Недостатки: Этот метод использует много ресурсов. Пакеты должны проанализированы близко к источнику и в той же самой подсети, для гарантирования проходов всех пакетов через анализатор. Если используются дополнительные защитные параметры Oracle применяемые для шифрования сетевых пакетов или любые другие решения, используемые для шифрования, то анализатор сетевых пакетов не будет работать. Если, как в нашем примере, пробную попытка SQL инъекции передают как запрос к хранимой процедуре, то не будет виден настоящий внутренний динамический SQL. Вместо этого вы будете просто видеть напечатанный в команде. Анализ каждого пакета приводит к генерации огромного количества данных. Конвейеризация пакетов через программу-фильтр смягчает эту проблему. Для демонстрации, мы будем использовать 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 [email protected]...... 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 инъекцией. Как и в других методах описанных в этой статье, должно быть выполнено следующее: Должна быть запущена программа - фильтр, это необходимо для синтаксического анализа SQL выражений и определения потенциальных попыток SQL инъекций. Для реального использования, программа-фильтр также должна извлекать информацию о времени создания файла и IP адрес источника из заголовков сетевых пакетов. Выделение пользователя базы данных может быть чрезвычайно трудным, поскольку, для выделения информации об учетных записях входа в систему, должны быть проверены все предыдущие сетевые пакеты. Все это дает потребность в сохранении предыдущих пакетов или информации о них и их последовательностях. В качестве простого решения, анализ сетевых пакетов, может выступать в роли альтернативного решения, обеспечивающего достаточно простые фильтры/синтаксические анализаторы, написанные в 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 инъекций: Трассировочные файлы очень быстро увеличиваются в размерах, используя при этом огромное количество дискового пространства. При неправильном управлении существует опасность переполнения диска, и как следствие отказ в обслуживании. Существует предел в записи трассировочных файлов. Хотя и возможно определить уникальное имя и расположение трассировочного файла, но Oracle добавляет идентификатор процесса (PID) в конец имени файла трассировки. PID можно увидеть в следующих 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 текста из дампов пакета и определения были ли SQL инструкции попыткой SQL инъекции. PID, используемый как часть имени файла трассировки не известен, до тех пор, пока не подсоединится пользователь, и не запустится фоновый процесс. Если бы имена файлов не были уникальны подобно snoop, то трассировка могла бы быть пропущена через фильтр, и проблема использования дискового пространства была бы решена. Трассировочные файлы могут регулярно проверяться простым сценарием, который проверяет трассировочные файлы, в которых больше не запущен фоновый процесс. В этом случае они могут быть обработаны и удалены. Длительные сеансы генерировали бы огромные трассировки и таким образом не могли бы идеально контролироваться. Проще всего определить пользователей операционной системы и пользователей базы данных, включающих в себя трассировку SQL*NET, поскольку эта информация может быть найдена в представлениях v$process и v$session со сведениями об OS PID. Этот метод не удобен, для выполнения простой утилиты обнаружения SQL инъекций. Ресурсные проблемы только затрудняют управление и работу. Можно использовать это более расчетливо, когда подозреваемый инцидент произошел и где использование трассировки может контролироваться на ограниченном отрезке времени или числе пользователей. продолжение следует....
