| Издательский дом ООО "Гейм Лэнд" | ЖУРНАЛ ХАКЕР #113, МАЙ 2008 г. |
Запароленная власть
sh2kerr
Хакер, номер #113, стр. 113-052-1
Щелкаем пароли от Oracle, как орешки
Если ты читал наши предыдущие статьи, ты уже имеешь представление, как удаленно порутать Oracle. Считай, что доступ к базе мы получили, но что дальше? Как поднять свои права? И что можно получить, имея доступ к системным таблицам? Слушай сюда, сейчас расскажу.
Не всегда доступ к базе данных мы получаем с правами администратора (DBA). Бывают ситуации, когда локальных эксплоитов, повышающих привилегии до роли DBA, нет, а удаленно пароль к системному пользователю не спешит подбираться. Или, предположим, ты получил права администратора в СУБД, но не знаешь его пароль, а узнать очень хочется, так как он, вероятно, может подойти на ssh-доступ к серверу или к другим СУБД в компании. Что делать в таких случаях? Первое, что приходит на ум – получить доступ к хэшам паролей и попытаться их расшифровать. Рассмотрим, в каких ситуациях нам могут помочь хэши паролей.
- Один из самых распространенных вариантов – получение доступа к базе данных через SQL-инъекцию в WEB-приложение, которое использует эту СУБД. Есть вероятность, что пользователь, от имени которого идут запросы к СУБД, имеет доступ на чтение таблицы с паролями.
- Возможен случай удаленного получения доступа к консоли СУБД пользователем, у которого по умолчанию есть доступ на чтение таблицы с хэшами паролей (права SELECT ANY DICTIONARY), но нет роли DBA. Тем самым, расшифровав пароль, мы получим права DBA в базе данных, а также сможем попытаться использовать подобранный пароль на другие сервисы.
- Доступ к хэшам паролей можно получить, найдя уязвимость класса PL/SQL Injection в функции или процедуре, которая исполняется от имени пользователя с правами SELECT ANY DICTIONARY, позволяющими читать системные таблицы. Одна из таких уязвимостей была найдена мной, и эксплоит к ней можно отыскать по адресу http://milw0rm.com/exploits/4995.
Как известно, многие админы зачастую имеют одинаковые пароли на доступ к различным серверам и приложениям. Тогда что же мешает расшифровать пароль администратора СУБД Oracle, тем более, что это бывает намного проще, чем расшифровывать пароль на операционную систему?
Хранение паролей
Сегодня мы изучим алгоритм хранения паролей в СУБД Oracle и научимся ломать эти пароли. Сначала рассмотрим старый алгоритм. В СУБД Oracle до 11 версии пароли пользователей хранятся в таблице dba_users. На деле они хранятся в системной таблице SYS.USER$, а таблица DBA_USERS – лишь представление (VIEW) для вышеуказанной системной таблицы, но эти особенности не критичны. Итак, у нас есть доступ к таблице DBA_USERS. Чтобы достать из нее пароли, можно воспользоваться несложным запросом:
SQL> select username, password from DBA_USERS;
Как мы видим, поле Password содержит хэш пароля, состоящий из 8 байт. Что же за алгоритм используется для хранения паролей?
Алгоритм шифрования паролей
Алгоритм шифрования паролей в СУБД Oracle был до поры до времени неизвестен, пока в публичных источниках не появилась работа «Assessment of the Oracle Password Hashing Algorithm» авторов Joshua Wright и Carlos Ci. В ней был подробно описан алгоритм шифрования паролей в Oracle. Детальная информация предоставлена в статье по адресу: http://www.isg.rhul.ac.uk/~ccid/publications/oracle_passwd.pdf.
Алгоритм шифрования паролей в СУБД Oracle был задействован чуть ли не с первых версий и не менялся вплоть до недавней версии 11G. Сам алгоритм оказался не таким уж и сложным. Вот как работает генерация хэша:
- происходит конкатенация имени пользователя и пароля – если у нас есть пользователь с именем SYS и паролем test1, то мы получаем строку SYStest1;
- далее вся строка преобразовывается к верхнему регистру, и мы получаем SYSTEST1;
- если в ОС используется однобайтовая кодировка, то каждый символ преобразовывается в двухбайтовый, заполнив старший байт нулями (0x00);
- получившаяся строка (дополненная нулями до длины блока) шифруется алгоритмом DES в режиме CBC с фиксированным ключом, значение которого есть 0x0123456789ABCDEF;
- полученная строка шифруется еще раз с помощью DES-CBC, но используя последний блок предыдущего шага как ключ шифрования.
Теперь перечислим недостатки алгоритма, которые помогут нам при взломе.
1. В качестве соли (salt) используется предсказуемое значение, а именно – имя пользователя. Это дает нам возможность использовать предварительно сгенерированные таблицы для расчета пароля (rainbow tables), тем самым увеличив скорость перебора паролей в разы.
2. Исходный словарь символов, используемых для генерации пароля, первоначально составляет 256 символов. Так как введенный пароль преобразовывается к верхнему регистру, то алфавит сужается до 256-26=230 символов. На самом деле символов еще меньше, так как операция UPPER() действует не только для символов латинского алфавита. В итоге мы получаем алфавит из 164 символов, каждый из которых можно использовать при генерации пароля (более подробно, откуда появилась эта цифра можно прочитать на форуме http://www.petefinnigan.com/forum/yabb/YaBB.cgi?board=ora_sec;action=display;num=1131556773). Но это все в теории, а на практике при создании нового пользователя в командной строке СУБД Oracle оказывается, что мы можем использовать далеко не все символы. Рассмотрим на примере.
SQL> create user test01 identified by abc123_$#;
User created.
SQL> create user test02 identified by 123abc#_$;
create user test02 identified by 123abc#_$
*
ERROR at line 1:
ORA-00988: missing or invalid password(s)
SQL> create user test02 identified by _123abc;
create user test02 identified by _123abc
*
ERROR at line 1:
ORA-00911: invalid character
SQL> create user test02 identified by abc123^*;
create user test02 identified by abc123^*
*
ERROR at line 1:
ORA-00922: missing or invalid option
SQL> create user test02 identified by "^*abc?";
User created.
Часть паролей, которые мы пытались задать, не подходит (выдается сообщение «ORA-00911: invalid character»). Из всего этого можно сделать простые выводы:
1. Доступные в пароле символы – это латинский алфавит (26), цифры (10) и спецсимволы _,#,$ (3), всего – 39 символов.
2. В качестве первого символа пароля могут использоваться только буквы.
3. Чтобы создать пароль с другими спецсимволами, необходимо заключать пароль в двойные кавычки, как показано в последнем примере (но этой возможностью на практике пользуются редко).
Собственно, подбор
Итак, учитывая, что на практике редко кто использует пароли не из диапазона 39 символов, задача подбора существенно упрощается. Теоретически паролей из 8 символов может быть 26*39^7= 3.6 *10^12 комбинаций.
Если посмотреть сравнение скоростей перебора паролей (http://www.red-database-security.com/whitepaper/oracle_passwords.html), можно увидеть, что самый быстрый переборщик работает со скоростью примерно миллион паролей в секунду на среднем компьютере (на core 2 duo 2.4 ГГц удалось добиться максимальной скорости перебора – 1.6 млн паролей в секунду при помощи утилиты woraauthbf, которая умеет использовать многоядерные процессоры).
Получается, чтобы перебрать 8-символьный пароль на стандартном рабочем компьютере, нам понадобится около 40 дней. И то – если переборщик знает, что первый символ может состоять только из букв, иначе и вовсе понадобится два месяца. Не слишком утешающие цифры, тем более, что столько времени мы будем подбирать пароль только для одного пользователя – ведь для генерации хэша используется соль (salt). Ну а если пароль состоит из 9 символов, то тут счет будет вестись уже на года. Но отчаиваться не стоит, всегда найдутся методы, позволяющие получить результат быстрее.
Rainbow Tables
При генерации хэша пароля в СУБД Oracle используется дополнительный параметр (salt), который, теоретически, должен предотвращать атаки посредством создания заранее сгенерированных таблиц для быстрого перебора паролей (rainbow tables). Но раз соль (salt) нам известна заранее (исключения составляют случаи, когда известен только хэш, но на практике это бывает крайне редко), значит, мы можем сгенерировать rainbow tables для распространенных имен пользователей. Есть смысл генерировать таблицы для пользователей SYS и SYSTEM, так как они есть в каждой СУБД и имеют по умолчанию права администратора (DBA).
С теорией Rainbow tables, думаю, ты знаком по прошлым номерам журнала или читал в инете. На этом я останавливаться не буду, лучше расскажу, как создавать и использовать таблицы применительно к взлому паролей Oracle.
Тут существует два способа. Первый – сгенерировать таблицы самому, второй – скачать в Сети. Плюсы второго способа очевидны: не надо тратить время на генерацию таблиц, что может занять годы на среднестатистическом компьютере. Хотя минусы тоже есть – не у всех интернет позволяет выкачать 30-60 Гб таблиц. Преимущество генерации своих таблиц на самом деле только одно – ты сможешь использовать необходимый тебе набор символов и параметры таблицы.
Oracle Rainbow Tables
Что касается rainbow таблиц для СУБД Oracle, я так и не нашел их в интернете в свободном доступе, чему в общем-то не особо огорчился, так как было желание сгенерировать их самому. Генерировать я решил, используя программу winrtgen, входящую в состав небезызвестного cain&abel. Выбор пал на нее, потому как в ней все просто и удобно.
Для начала разберемся с параметрами. Их немного:
- Hash – алгоритм генерации хэш функции. В данном случае – oracle.
- Min Len – минимальная длина пароля, обычно 0.
- Max Len – максимальная длина пароля; возьмем для начала 7.
- Index – идентификатор для группы таблиц (таблицы с разным индексом содержат разные данные). Пока оставим как есть.
- Chain Len – длина цепочки. Повышение длины отрицательно влияет на время генерации таблицы и время криптоанализа, зато повышает вероятность подбора. Не желательно выставлять более 20000. Оставим пока 2400.
- Chain Count – грубо говоря, размер таблицы на диске. Если оперативной памяти больше 1 Гб, то выставляется 67018864, так как при расшифровке таблица будет загружаться в оперативную память и желательно, чтобы она поместилась целиком. Обычно больше 1Гб таблицы не делают. Для начала оставим значение по умолчанию.
- N of Tables – количество таблиц. Соответственно, чем больше таблиц, тем больше вероятность перебора, но их дольше генерировать и необходимо иметь достаточно места для их хранения. По умолчанию – одна таблица.
- Charset – набор символов, используемый в пароле. Мы будем использовать стандартный для Oracle 39 символьный набор, приведенный в начале статьи.
- Username – имя пользователя. Используется как раз для Oracle паролей. В нашем случае будем генерировать для пользователя SYSTEM.
С описанием вроде закончили, теперь приступим к генерации. Если выставить значения, как указано выше, то вероятность подбора (Success probability) будет равняться 44 процентам, что нас совсем не устраивает. По-хорошему, приемлемая вероятность должна быть около 99 процентов, хотя это зависит от ситуации. Для повышения вероятности подбора я предлагаю просто увеличить количество таблиц хотя бы до 8 (99,00) а лучше до 12 (99,91). Подсчитаем время генерации (кнопка Benchmark) и получим что-то около 24 дней на стареньком Intel Celeron 2.4. Время подбора пароля по таблице составит около 1 минуты: заметно лучше, чем два с половиной дня при взломе методом полного перебора. Правда, нам придется потратить 25 дней на генерацию этих таблиц, зато потом пароли можно щелкать, как орешки (увы, только 7-символьные).
«Есть ли возможность ускорить процесс?», спросишь ты. И я отвечу – конечно же, если генерировать таблицы не в одиночку, а группой людей, как это делалось и делается до сих пор для LM/NTLM/MD5-хэшей на сайте www.freerainbowtables.com. Так можно значительно ускорить процесс. Быстрее сгенерировать таблицы можно и в одиночку, используя несколько компьютеров. Вся прелесть в том, что таблицы можно генерировать независимо на разных компьютерах. Утилита winrtgen, после того как ты укажешь все необходимые параметры, создает конфигурационный файл с именем tables.lst. Вот его содержимое для нашего примера:
oracle_oracle#1-7_0_2400x67108864_SYSTEM#000.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#001.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#002.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#003.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#004.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#005.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#006.rt;
oracle_oracle#1-7_0_2400x67108864_SYSTEM#007.rt;
Чтобы распараллелить работу над созданием таблиц, надо просто скопировать часть этих строк на другой компьютер в файл tables.lst и запустить на нем утилиту winrtgen. Единственный важный момент – используемый сharset должен быть прописан на каждом компьютере в файле charset.txt путем добавления специальной строки с набором символов. Причем, их порядок должен быть одинаковым, иначе таблицы окажутся несовместимы. Конфиг-файл charset.txt должен выглядеть примерно так (последняя строка описывает чарсет oracle):
# charset configuration file for winrtgen v1.2 by Massimiliano Montoro (mao@oxid.it)
# compatible with rainbowcrack 1.1 and later by Zhu Shuanglei <shuanglei@hotmail.com>
byte = []
alpha = [ABCDEFGHIJKLMNOPQRSTUVWXYZ]
alpha-space = [ABCDEFGHIJKLMNOPQRSTUVWXYZ ]
.
.
.
oracle = [ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_#$]
Теперь можно раскидать по одной таблице на каждый компьютер, и общее время генерации существенно уменьшится. Что касается многоядерных процессоров, то утилита по умолчанию их не поддерживает, но ничто не мешает нам создать две папки с программой winrtgen, переименовать экзешники в winrtgen1.exe и winrtgen2.exe и запустить параллельно генерацию таблиц на разных ядрах (прописав разные таблицы заранее в tables.lst).
Все описанные выше действия я провел на доступных мне компьютерах и получил в итоге 12 таблиц общим размером чуть более 7 Гб. Для проверки работоспособности таблиц я собрал хэши нескольких SYSTEM пользователей и запустил перебор по созданным таблицам. В итоге 2 из 3 хэшей подобрались; общее время, затраченное на перебор, составило 4 минуты. Неплохо, но что делать с более длинными паролями?
Больше символов!
Мы научились подбирать 7-символьные пароли. Чтобы сгенерировать таблицы для подбора 8-символьных паролей с тем же чарсетом и приемлемым Success Rate 99,00%, нам потребуется не много ни мало – 64 гигабайта свободного места и полтора года времени (если использовать только один компьютер). Зато подбираться пароль по этим таблицам будет, максимум, час, а в среднем – минут двадцать. В сравнении с 60 днями методом полного перебора это выигрыш, и еще какой! Распределенная генерация 8-символьных таблиц уже запущена, и вполне вероятно, к выходу журнала они могут быть доступны на сайте, посвященном исследованию безопасности баз данных и web-приложений: http://dsecrg.ru.
Oracle 11g и нововведения
Все рассмотренное касалось версий Oracle ниже 11. Хотя в продакшн среде версия 11 до сих пор встречается редко, разобраться в ней не помешает. Тем более, дела там обстоят не так прозрачно. Для начала попытаемся извлечь пароли из таблицы DBA_USERS, как это делалось в старых версиях.
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select username, password from dba_users;
USERNAME PASSWORD
------------------------------------------------------------
MGMT_VIEW
SYS
SYSTEM
DBSNMP
Очевидно, паролей тут нет, ну мы не расстраиваемся. Они есть в таблице SUS.USER$ и, соответственно, доступ к ним – только у пользователей с правами администратора (DBA). То есть прав SELECT ANY DICTIONARY для доступа к хэшам паролей уже недостаточно. Хранятся хэши также немного отлично от старых:
SQL> select user, password, spare4 from sys.user$;
0 SYS 1
77E6B621F3BB777A 0 3 15.10.07 19.02.08
0 1
0 0 DEFAULT_CONSUMER_GROUP
0
S:52D6AC184EDE6D952E94317CB1C9918D2766C34A23C476E460D72BD03F2C
Как мы видим, теперь в таблице хранится два разных хэша. Старый – 77E6B621F3BB777A, совместимый с Oracle 10g, и новый. На самом деле, последняя строка листинга – это не хэш в чистом виде. Первые 20 байт – это sha-1 хэш пароля, а последние 10 – случайный salt.
Что касается нового алгоритма, в нем исправлены предыдущие ошибки. Во-первых, пароль становится «регистро-зависимым», что существенно увеличивает алфавит символов для перебора. Во-вторых, в качестве соли используется действительно случайное значение. Это можно проверить, меняя пользователю пароль на такой же, в результате чего хэш изменится. Все говорит о том, что Oracle действительно решили заняться своей безопасностью, но, как обычно, ложку дегтя мы все-таки найдем. Дело в том, что ситуация очень напоминает историю с OC Windows и LM/NTLM-хэшами. Там, если вы помните, старый хэш хранится в системе вместе с новым, что позволяет с легкостью расшифровать любые пароли менее 14 символов, используя старый хэш. Ситуация в Oracle такая же: видимо, для совместимости со старыми приложениями в таблице, как уже упоминалось, хранится старый хэш. Значит, ничто нам не мешает подбирать к нему пароли, как мы делали это для старых версий.
Существует один нюанс, также как и с LM/NTLM-хэшами: когда хэш расшифруется, то пароль по понятным причинам может не совпасть с настоящим (старый алгоритм хранения паролей не различает регистров, а новый уже различает). Например, мы подобрали пароль к старому хэшу и он оказался «passwd». Поскольку старый хэш не различает регистров, вполне возможно, что настоящий пароль – «PassWd».
Но нас это нисколько не останавливает, ведь мы можем перебрать все варианты написания одного слова тем же кайном (cain&abel), а затем использовать THC-Orakel (переборщик паролей к Oracle 11g), – и это займет считанные секунды. Способ гораздо эффективнее, чем заморачиваться с подбором паролей к SHA-1 хэшам. В итоге, с доступом к таблице с хэшами паролей вероятность подбора практически не отличается для всех версий СУБД Oracle. И там, и там у нас есть большие шансы взломать пароль. Вот и все на сегодня, надеюсь, что ты хорошо усвоил суть рассмотренной проблемы.
DVD
На диске ищи все упомянутые в статье программы, а также увесистый документ по организации криптоалгоритмов в Oracle.
DANGER
Внимание! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несет!
VIDEO
На DVD смотри познавательный видеоурок, который раскрывает всю правду о мнимой защищенности паролей в Oracle.