включить редактирование

Обход аутентификации в Oracle 11g

Создан:

Сегодня рассмотрим интересную проблему в СУБД Oracle. СУБД Oracle очень распространенный продукт, а для многих даже слишком критичный. Не давно на конференции Ekoparty была рассмотрена данная проблема. Нашел ее Эстебан Марти-нес Файо (Esteban Martinez Fayo).
Фишка её в том, что можно перебирать пароль к СУБД Oracle 11g (11.1.0.6,11.1.0.7,11.2.0.1,11.2.0.2,11.2.0.3), причем в СУБД даже не останется логов о неверном вводе пароля. Затем вышел нормальный патч от Oracle.
Немного о самом процессе аутентификации в Oracle 11:
когда кто-то пытается подключиться к БД, он отправляет имя пользователя. Сервер же в ответ посылает случайный сессионный ключ и соль, с помощью которых пользователь может зашифровать свой хеш пароля и отправить его на сервер.
В общем, уязвимость состоит в том, что на основании имеющегося сессионного ключа и соли злоумышленник имеет возможность достаточно быстро перебирать хеши паролей. По PR-заявке — 5 часов на восьмибуквенный пароль. Естественно, как я уже сказал выше, в СУБД не останется логов о неверном вводе пароля. Просто подключившись к СУБД и указав правильный ID базы данных (заполучить его просто) и имя пользователя (например, стандартного SYS, SYSTEM), и получить от сервера сессионный ключ и соль. Далее отключаемся от СУБД (пароли не вводили, соответственно и записи в логах нет). Все, затем у себя запускаем перебор и ждем результата. Разберем почему это возможно. Это интересно.
Сессионный ключ — это случайное число длиной в 40 байт и шифрован с использованием AES. А клиенту необходимо расшифровать сессионный ключ, для того чтобы потом использовать его для шифрования своего пароля . Для расшифровки ключа, клиенту нужна соль и свой пароль. Он их конкатенирует и хеширует SHA-1:

key_for_session_key=sha1(password+salt);

Из всего этого важен только один момент: AES — блочный, СВС-алгоритм. А это значит, что работает он с блоками. Размер — 16 байт. Длина сессионного ключа — 40 байт. Значит, чтобы зашифровать данные должны быть дополнены. И, как говорит Эстебан, здесь был главный прокол 11-й версии аутентификации (метод аутентификации в каждой версии свой — в 9,10,11,12-й.
В добавлении данных используется метод от стандарта PKCS7. Принцип которого: значение каждого байта должно быть равно количеству добавляемых байт. Например, если добавляем 3 байта — значение будет «03 03 03», добавляем 5 — «05 05 05 05 05» итд
В нашем случае для заполнения последнего блока AES не хватает 8 байт (40 -3*16 = -8), то в конец сессионного ключа добавляется PKCS7 паддинг «08 08 08 08 08 08 08 08».
Для получения зашифрованного вида сессионного ключа (того, что клиент получает от сервера) используется примерно следующая формула:
Для получение того вида сессионного ключа, что получает клиент, используем формулу:
 

E_sk= AES_192_СВС (sk+{0х08}*8, sha1(password+salt));
• E_sk — зашифрованный сессионный ключ;
• sk —сессионный ключ.

В таком постоянстве и есть проблема. Далее брутфорс и расшифровывать полученный нами от сервера зашифрованный сессионный ключ с различными значениями пароля, а проверять успешность расшифровки по добавлению(паддинг) (08 08 08 ...).
Для понятия идеи скрипт на Python'e (скрипт для перебора паролей к сессионному ключу для Oracle 11 g), но для реального перебора лучше воспользоваться JohnTheRipper с jumbo-паком .

import hashlib
from Crypto.Cipher import AES
def decrypt(session,salt,password):
pass_hash = hashlib.shal(password+salt)

key = pass_hash.digest() + '\x00\x00\x00\x00"
decryptor = AES.new(key, AES.MODE_CBC)
plain = decryptor.decrypt(session)
return plain

sessionhex = 'EA2043CB8B46E3864311C68BDC161F8CA170363C1E6F57F3EBC6435F541A8239B6DBA16EAAB5422553A7598143E78767'
# 10
salt_hex = 'A7193E546377EC56639E'
passwords = [‘test’, ‘password’, ‘oracle’, ‘demo’]
for password in passwords:
session_id = decrypt(session_hex.decode(‘hex’), salt_hex.decode(‘hex’),password)
print "Decrypted session_id for password "%s" is %s ‘ % (password, session_id.encode(‘hex’))
if session_id[40:] == '\x08\x08\x08\x08\x08\x08\x08\x08':
print "PASSWORD IS "%s"’ % password
break

Иде надеюсь понятна. Еще раз: мы подключаемся, получаем данные от сервера и пытаемся расшифровать эти данные с различными значениями паролей. Успешность нахождения пароля определяем по получаемому паддингу. Oracle закрыла уязвимость тем, что отказалась от 11 -й версии протокола. И теперь новые версии работают под 12-й , в ней паддинг случайный.

Автор: xvzL Просмотров: 2422


Рейтинг статьи: 0

Общий рейтинг из всех статей автора :
{0 [724]} [ - - - - - - - - - - ]

Общий рейтинг из всех статей на сайте :
{0 [888]} [ - - - - - - - - - - ]

[?]
комментариев к данной статье нет

Добавить комментарий к статье


Ctrl+Enter

Для активации кнопки, введите символы, которые Вы видите на картинки.

новая

тема

Заметки на тему IT

Монитор поиска
[x]
Новое сообщение

Сообщения в чате

Вы спрашиваете у гостей/у зарегистрированных/ У Вас спрашивают
всем Ctrl+Enter
зарегистрированным Ctrl+Enter
Ctrl+Enter

Краткая инструкция по работе с чатом

  • Вы должны ввести имя, которое будет запомнено и применяться для чата и комментариев на сайте.
  • Выбрать одну из возможностей
    "Вы спрашиваете у гостей/
    у зарегистрированных/
    У Вас спрашивают"
  • Кликните на один из способов и появиться дополнительная информация