Все новости от 28 октября 2005 г.

Система паролей Oracle подверглась критике

Они критикуют методы защиты Oracle, призывая производителя ПО усовершенствовать механизм, применяемый для обеспечения безопасности паролей пользователей базы данных. Исследователи обнаружили способ вскрытия plain text-паролей за считанные минуты, даже если они очень длинные и составлены правильно.

Метод, используемый Oracle для хранения и шифрования паролей пользователей, не обеспечивает достаточной безопасности, утверждают Джошуа Райт из SANS Institute и Карлос Кид из Royal Holloway College при Лондонском университете. В среду Райт продемонстрировал это на конференции SANS Network Security в Лос-Анджелесе.

В своей презентации Райт рассказал, как шифруются пароли перед сохранением в базе данных Oracle, и представил написанный им инструмент для их расшифровки. С работой Райта и Кида можно ознакомиться на веб-сайте SANS (загрузить PDF).

Райт и Кид указывают на несколько уязвимостей, включая слабый механизм хэширования и несохранение регистра, — перед вычислением хэша все пароли преобразуются в прописные символы. «Используя эти слабые звенья, злоумышленник, располагающий ограниченными ресурсами, может организовать атаку, позволяющую извлечь из хэша plain text-пароль известного ему пользователя», — говорится в работе.

В июле исследователи проинформировали Oracle о своей находке, но на последующие запросы компания не отвечала. Oracle не ответила и на просьбу CNET News.com о комментарии для этой статьи.

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

Методы защиты данных Oracle все чаще подвергаются критике. Секьюрити-эксперты обвинили компанию в медлительности при исправлении уязвимостей и выпуске некачественных поправок. 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	Desperado 28 Oct 2005 10:34 AM
>В своей презентации Райт рассказал, как шифруются пароли перед сохранением в базе данных Oracle, и представил написанный им инструмент для их расшифровки. если он такое рассказывал, то это действительно крупный специалист :) оракл принципиально не хранит пароль, хранится только хеш. >Исследователи обнаружили способ вскрытия plain text-паролей за считанные минуты, даже если они очень длинные и составлены правильно. да ... чуствуется статью писал крупный спец по безопасности ... осталось расскрыть где можно взять "plain text-паролей" :)
	Просто Прохожий 28 Oct 2005 11:29 AM
Имхо, назвать хеширование криптованием - это сильно. Скорее всего он подобрал плейн-пароль, который при использовании того же самого способа хеширования дает тот же хеш. Если Оракл использовал самодельный алгоритм хеширования (скорее всего так оно и было, судя по безграмотному приведению к верхнему регистру), то это возможно хоть за миллисекунды... И вааще, где-то это я уже слышал - не МС ли приводило свои НТЛМ пароли к верхнему регисру и хэшировало? Такое впечатление, что у них установка от ... - не заморачиваться на хорошей криптографии.
	Дмитрий 28 Oct 2005 11:50 AM
Desperado Чем писать всякую фигню, почитайте оригинал, всего 11 страниц, и ссылка есть. Там описаны 3 проблемы ясным и понятным языком, с примерами. И эти проблемы unbreakable Ораклу надо решать.
	Desperado 28 Oct 2005 1:27 PM
2Дмитрий ба, да вы я смотрю большой специалист по безопасности ? может расскажите в двух словах о 3 проблемах, я потом просто задам пару вопросов ;)
	Дмитрий 28 Oct 2005 2:07 PM
http://www.sans.org/rr/special/index.php?id=oracle_pass как я уже сказал, для ленивых достаточно прочитать 3 абзаца в introduction
	Zzz.. 28 Oct 2005 2:20 PM
"In little over four minutes, the password for the supplied hash value was recovered." ;-)
	Desperado 28 Oct 2005 2:40 PM
2Дмитрий как я понял прочесть тест вы не смогли. поэтому попробую до вас донести мысль. статье (на зднет) просто измышления малограмотных людей, которые не смогли прочесть оригинал. в оригинале речь идет о хеше. автор оригинала обнаружил что дба имеющий доступ к системным вьюшкам, немного потраховшись может востановить 6-значный пароль :) действительно гениальное открытие ... а главное что новое. единственно что автор забыл объяснить зачем дба трахатся с перебором если он может просто зменить пароль.
	Пользователь 28 Oct 2005 2:42 PM
Я не большой специалист по безопасности, но полностью согласен с Дмитрием. 2Desperado 1. Вы как большой специалист по безопасности оригинал статьи по приведенной ссылке читали? 2. Или у Вас проблемы с чтением на английском языке и требуется рассказ в двух словах на русском от Дмитрия? Если первый вариант (и Вы поняли о чем говорилось в статье) - то задавать вопросы не возникает необходимости. Если второй вариант, то нет смысла пересказывать, так как возникают большие сомнения в профессианализме... Итог: прежде чем высказывать свое мнение, неплохо бы ознакомиться с предметом обсуждения, в данном случае - оригиналом статьи.
	Пользователь 28 Oct 2005 2:47 PM
Помимо ДБА, есть сеть, как правило, с нешифрованным трафиком, в котором есть хэш пароля. Есть также файл на диске сервера с хашем как минимум одного пользователя с правами DBA. Так что, для получения пароля не нужно быть ДБА...
	Пользователь 28 Oct 2005 2:49 PM
2Desperado И все таки возникает вопрос: Вы всю статью прочитали? Внимательно?
	Юрий 28 Oct 2005 2:52 PM
О том что база Oracle не различает большие и маленькие буквы в пароле это известно всем кому интересно. Не надо даже хеш пароля изучать. В данном случае западные ученые отработали как советские медики в одном старом анекдоте (когда гланды через задний проход удаляли). В действительно безопасных системах проблема лечится блокировкой пользователя после определенного количества неудачных подключений. В небезопасных системах срабатывает "внутренний предохранитель" при активном переборе паролей система ложится от перегруза. Сам видел такое. Поэтому все же интересно есть реальные баги или Oracle большой, поэтому каждая шавка должна облаять (Microsoft тоже не мелкая контора).
	Пользователь 28 Oct 2005 2:58 PM
2Юрий А как насчет offline получения текстовой формы пароля из хэша, который перехвачен во внутренней сети с последующим логином в базу с первого раза?
	Desperado 28 Oct 2005 2:58 PM
> Помимо ДБА, есть сеть, как правило, с нешифрованным трафиком, в котором есть хэш пароля если у кого-то весь трафик идет открытым тестом это проблема идиотов которые так делают. >Есть также файл на диске сервера с хашем как минимум одного пользователя с правами DBA. на диске много чего лежит, но даже ДБА туда не доберется ... если у кого-то кроме рута/пользователя оракл кто-то имеет доступ к ФС с ораклом то это личная проблема, никак не оракла. читал статью по диагонали т.к. ничего интересного в оригинале нет, "проблема" высасога из пальца.
	Просто Прохожий 28 Oct 2005 5:29 PM
ммм... канэшна сейчас я уже не такой уж и большой спец по БД (специализация другая), но точно помню что как минимум в 2-3 самых распространеных СУБД несколько лет назад не существовало понятия шифрования траффика как понятия... СУБД использовались в интранете, зашищаться от инсайдеров считалось выше достоинства таких крутых контор. Слышал, сейчас ввели ССЛ но больше в частях выложенных прямиком в Интернет. К тому же это сильно снижает скорость доступа к БД и повышает глючность, поэтому - западло. На месте Десперадо я бы проверил исходящий траффик на соединение с БД (говорят, опыт - друг ошибок трудных или как там).
	Desperado 28 Oct 2005 5:47 PM
2Просто Прохожий не, ну в mysql и foxpro (кажется это лидеры по инсталяциям) может конечно нету но в оракле как минимум 10 лет этой фишке (не знаю про 7рку)
	Просто Прохожий 28 Oct 2005 6:08 PM
http://otn.oracle.com/deploy/security/oracle9i/pdf/9ir2_chec klist.pdf 7e. Encrypt network traffic. If possible, utilize Oracle Advanced Security to encrypt network traffic between clients, databases and application servers. (Note that Oracle Advanced Security is available only with the Enterprise Edition of the Oracle database). It installs in Typical Installation mode, and if licensed, configure it with the Oracle Net Manager tool or by manually setting sixsqlnet.ora parameters to enable network encryption. Правильно ли я понял следующее Данная фича доступна лишь в Энтерпрайз эдишн и даже требует специального лицензирования (которое небось состоит в том что все за пределами штатов - козлы по умолчанию)? Данная фича не включена по умолчанию (и конечно же, опциональна)? Сколько стоит докупить эту фичу в комплекте с сотней других? Короче, мы знаем как работает подход "пользователь дольжен позаботится сам о своей безопасности" - проходили у M$ (и даже они поменяли свое мнение)
	Desperado 28 Oct 2005 6:57 PM
ну значит стандарт можно только с 3-tier с dmz юзать. если у тебя man-in-the-middle имеет доступ к трафику то этот орел может подменить пакет с delete ... where на delete без where и никакой возьни с хешом :)
	earl 28 Oct 2005 9:42 PM
>>ну значит стандарт можно только с 3-tier с dmz юзать. если у >>тебя man-in-the-middle имеет доступ к трафику то этот орел >>может подменить пакет с delete ... where на delete без where и >>никакой возьни с хешом :) а IPfilter или чтото подобное под никсами могёт такое сделать? интересно было бы попробовать
	To Desperado 29 Oct 2005 3:49 PM
> зачем дба трахатся с перебором если он может > просто зменить пароль Если вы специалист по безопасности, то вам должног быть понятно зачем. Смену пароля возможно отследить. А вот то что кто-то воспользовался привилегиями другого пользователя отследить очень тяжело. Как вам наверняка известно в серьезных конторах dba не имеют доступ ко всем данным и не могут их изменять, например, проводить банковские транзакции. А теперь поставьте себя на место бухгалтера от имени которого dba провел перевод денег из банка. При расследовании выяснится что виноват бухгалтер и ему придется сидеть, а dba спокойно поедет снимать деньги.
	Desperado 29 Oct 2005 5:18 PM
>Как вам наверняка известно в серьезных конторах dba не имеют доступ ко всем данным и не могут их изменять, например, проводить банковские транзакции. почитайте все таки про атаки man-in-the-middle, а то похоже вы совсем не понимаете о чем идет речь.
	Просто Прохожий 31 Oct 2005 10:16 AM
Десперадо, ну это слишком грубо... а если мне бы хотелось не удалять просто все из БД (еще и ошибку даст на референциал констрайнтс), а сделать маааленькую распределенную транзакцию по переводу денег с одного счета на другой, в конце каждой недели да еще и используя оччень удобный клиент-сайд софт, разработанный славными банковскими ИТ специалистами, хорошо протестированный и вылизаный годами? Просто этот софт мне даст на блюдечке с золотой каемочкой и список счетов (длиной в полмиллиона) и заполнит пгавильно все атрибуты (с дифолтами), и осуществит десяток других совершено необходимых операций в БД (софт не идеален) и выдаст диагностику ошибок (если я ничего не смыслю в финансах данной конторы). Зачем мне заморачиваться на весь траффик, если единожды вскрыв пароль я получу все эти вкусности? Дисклаймер - большинство вышеперечисленного не относится к н-тир.
	Просто Прохожий 31 Oct 2005 10:18 AM
В этом плане особено изящно подойдут Оракл Формс.
	Desperado 31 Oct 2005 11:40 AM
формс не подойдут они давно 3-тиер - аплет в бровсере. попробуйте понять, если я имею доступ к трафику то мне по барабану как осуществляется авторизация - сильным хешом, слабым, это неважно. т.к. подменить пакет на alter user несоизмеримо проще, тем более что вода из статьи никак не поможет написать генератор ораклового хеша.
	To Desperado 1 Nov 2005 9:27 PM
А причем тут вообще многозвенка. Речь ведь о том, что существует возможность получения пароля ЧУЖОЙ учетной записи. Для этого надо быть всего лишь админом. А админы довольно часто меняются в организации раз в два или три года. Так вот такой человек должен только обслуживать БД, но не должен иметь доступ к содержимому. Как видно из статьи Oracle не может гарантировать построения системы удовлетворяющей таким требованиям безопасности. Вот собственно и все. А потом у нас люди удивляются а кто это слил базу проводок Центрального банка, так что они концов не могут у себя найти.
	Desperado 5 Nov 2005 7:47 PM
>человек должен только обслуживать БД, но не должен иметь доступ к содержимому. похоже вы совсем не понимаете по каким принципам работает ось. как вы представляете контролировать человека который имеет права на файлы/процессы на уровне ос ? а команды ос он может выполнять прямо из субд, т.е. ему не нужно перебирать хеши, он просто может записать нужный хеш в файл orapw а потом вернуть тот что был и никто его не остановит.