Часть 1

Беззащитность баз данных (Часть 2)

© А. Лукацкий,
заместитель директора по маркетингу
НИП "Информзащита"
Статья была опубликована в журнале "BYTE/Россия"

Уязвимости учетных записей

Давайте представим, что сотрудник, имевший доступ к базе данных, уволен. Какие действия должен произвести администратор безопасности? Правильно: удалить или как минимум заблокировать учетную запись, принадлежавшую этому сотруднику. И он бы рад это сделать (в Oracle это делается с помощью команды DROP USER <имя пользователя>, а в Sybase или Microsoft SQL Server - с помощью Sybase Central и Enterprise Manager соответственно), однако менеджеры по персоналу очень часто забывают оповестить администраторов о том, что сотрудник уволен (или ушел в отпуск). Это приводит к тому, что данная учетная запись может быть использована для попытки проникновения в базу данных и маскировки под другого пользователя. К сожалению, современные СУБД не имеют механизма, позволяющего обнаруживать неиспользуемые учетные записи, что открывает перед злоумышленниками большой простор для несанкционированной деятельности.

Администратор - это царь и бог в любой системе, и его учетная запись должна защищаться как зеница ока. Но увы... Не все производители уделяют этому вопросу достаточно внимания. Например, в Microsoft SQL Server 6.5 пароль администратора (учетная запись - sa) хранился в открытом виде в системном реестре (ключ HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSSQLServer\SQLEW\Registered Servers\SQL 6.5).

Рис. 2. Хранение пароля (ANEWMAN) администратора Microsoft SQL Server.

В следующих версиях (7 и выше) компания Microsoft попыталась исправить этот недочет, но не слишком успешно. Несмотря на то, что пароль хранится теперь в зашифрованном виде (ключ -HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSSQLServer\SQLEW\Registered Servers X\SQL Server Group), он легко дешифруется с помощью утилиты L0phtCrack.

Еще одна проблема Microsoft SQL Server также связана с системным реестром, в котором хранятся (пусть и в зашифрованном виде) пароли не только пользователей БД, но и пользователей операционной системы. С помощью расширенных хранимых процедур xp_regdeletevalue, xp_regwrite, xp_regread и т. д. можно манипулировать ключами системного реестра как угодно. Например, прочтя с помощью команды xp_regread

'HKEY_LOCAL_MACHINE', 'SECURITY\SAM\DOMAINS\ACCOUNT\USERS\000001F4', 'F'

неизвестный зашифрованный пароль учетной записи пользователя, можно заменить его на известный пароль и войти в систему, замаскировавшись под ничего не подозревающего пользователя. А если у злоумышленника есть время, то он может попытаться "взломать" зашифрованный пароль с помощью уже упомянутой утилиты L0phtCrack.

Компания Oracle недалеко ушла от Microsoft и не уделила пристального внимания защите системных паролей. А вот хакеры не обошли стороной этот вопрос, в результате чего выявились некоторые уязвимости, приводящие к тому, что злоумышленник может получить доступ к защищаемым ресурсам СУБД. Пароль встроенной учетной записи INTERNAL, используемой, например, для старта и останова СУБД, хранится в открытом виде в файле strXXX.cmd (XXX - это идентификатор SID, который по умолчанию соответствует "orcl") и в файле \orant\database\spoolmain.log (записывается в процессе создания базы данных). Заметим: доступ к этим файлам по умолчанию имеют все пользователи.

Рис. 3. Пароль учетной записи INTERNAL.

Рис. 4. Пароль учетной записи INTERNAL.

Кроме того, все пароли учетных записей для СУБД Oracle хранятся в файле orapwXXX (для UNIX) или pwdXXX.ora (для Windows NT), где XXX - это SID. И хотя в этом файле хранятся зашифрованные значения паролей учетных записей, они могут быть подвергнуты атаке Brute Force, позволяющей подобрать правильное значение пароля. Мало того, одно неизвестное зашифрованное значение пароля может быть заменено на другое зашифрованное, но известное значение, что откроет дорогу злоумышленнику к базе данных.

Рис. 5. Хранение паролей в Oracle.

Еще одна проблема, о которой нельзя умолчать, присуща не только СУБД, но и многим другим программным средствам. Речь идет о контроле "слабых" паролей, содержащих только буквы (без цифр), малое число символов и т.д. Предыдущие версии Oracle, Sybase, Microsoft SQL Server не содержали никаких средств контроля таких паролей, что позволяло пользователям выбирать для них абсолютно неподходящие значения типа "1111", "alex", "sex", "aaaa" и т.д. Такие пароли подбираются злоумышленниками в течение нескольких секунд, что (в случае отсутствия механизма контроля неудачных попыток регистрации в СУБД) открывает злоумышленнику доступ к конфиденциальным данным. В новых версиях Sybase и Oracle появились такие механизмы проверки, но по умолчанию они не используются.

Мало того, что пользователи выбирают "слабые" пароли, очень часто они оставляют без изменения пароли, заданные производителем по умолчанию. А таких паролей существует огромное множество. Например, по адресу http://security.nerdnet.com указано несколько сотен паролей, задаваемых по умолчанию, для различного программно-аппаратного обеспечения, в том числе и для СУБД. Например, для Oracle приводятся такие пары идентификатор/пароль, как system/manager, Scott/Tiger, internal/oracle sys/change_on_install.

Уязвимости подсистемы контроля доступа к СУБД

На минуту представим такую ситуацию. Ночь. На седьмом этаже здания, в котором размещается крупная финансовая корпорация, в вычислительном центре жужжит сервер баз данных, ежедневно обрабатывающий информацию, стоимость которой составляет несколько миллиардов долларов. И вдруг лампочки на передней панели сервера начинают мигать, сигнализируя о том, что к серверу обратились с запросом, который он и стал обрабатывать. На первый взгляд, обычная ситуация, в которой не усматривается ничего криминального. Но это только на первый взгляд. Ведь на дворе ночь (случай с удаленным доступом из другого часового пояса я сейчас опускаю). Ночью сотрудники корпорации не работают и не делают никаких запросов. А вот злоумышленник, осуществляющий свою несанкционированную деятельность в нерабочее время, может делать. СУБД должна блокировать такого рода попытки, но на практике ни одна из СУБД (Oracle, Microsoft SQL Server и т.д.) не контролирует доступ к базе данных в нерабочее время.

Любая система контроля доступа построена по принципу проверки соответствия предъявленных идентификатора и пароля пользователя эталонным значениям. Если злоумышленник не знает пароля, то он будет пытаться проникнуть в базу данных, подставляя различные слова ("атака по словарю"), сведения о пользователе или иную информацию, которая может служить паролем (например, идентификатор пользователя, прочитанный наоборот). Предыдущие версии Sybase (11.x), Oracle (7.x), Microsoft SQL Server (6.x) не содержали никаких механизмов контроля неправильных попыток регистрации в системе, что позволяло злоумышленнику неограниченное число раз пытаться проникнуть в систему. А так как и для доступа к компьютеру, и для доступа к СУБД, и для доступа к Интернету пользователи обычно используют один и тот же пароль, то, узнав пароль пользователя СУБД, нарушитель с высокой степенью вероятности может установить полный контроль над учетной записью этого пользователя. И это несмотря на то, что в операционной системе можно задать число неудачных попыток регистрации в системе, после превышения которого учетная запись блокируется. Справедливости ради необходимо сказать, что в Sybase 12.x и в Oracle 8.x и более поздних версиях появился механизм контроля неудачных попыток регистрации в системе (sp_configure "maximum failed logins" в Sybase и FAILED_LOGIN_ATTEMPT в Oracle).

Завершая статью, отметим, что для СУБД действуют те же правила, что и для операционной системы. Этот вид ПО также нуждается в регулярной проверке с целью обнаружения всех несанкционированных изменений и наличия "дыр". Делать это можно вручную, используя уже названные источники информации (например, Web-сервер "Информзащиты" и серверы производителей) или применяя автоматизированные системы анализа защищенности, такие как Database Scanner компании Internet Security Systems (http://www.iss.net), SQL <> Secure Policy компании BrainTree Security Software (http://www.braintree.co.uk), e-Secure компании Cyrano (http://www.cyrano.com), SFProtect компании Hewlett-Packard (http://www.hp.com).

Дополнительная информация

• Статьи по СУБД

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail