На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Перехват паролей для SQL Server

Компания Microsoft посчитала нужным ввести поддержку протокола SSL для всех типов связи в своих программах, и на это есть свои причины. Без шифрования при аутентификации пользователя в SQL Server по сети передается его пароль открытым текстом. Если вы когда-нибудь пользовались программами перехвата пакетов для наблюдения за обменом данными между клиентом и сервером, то могли заметить, что пароль легко подсмотреть.
Как видно на 6, была сделана попытка подключиться от имени sa, но в результате пароль оказался каким-то способом зашифрован. Однако взглянем на шаблон. Каждый второй байт последовательности равен ДБ (в шестнадцатеричной кодировке). У вас возникло по­дозрение, что здесь кроется что-то иное, нежели шифрование. И это действительно так. Мы не будем держать вас в неведении и откроем секрет — ничего тут не происходит, кроме выполнения обычной операции XOR для скрытия пароля.
Начнем с разбора пароля по одному байту. Первый шестнадцатеричный знак (например А) вдвоичной системе представлен как 1010. Для получения пароля просто меняем первый и второй шестнадцатеричный знаки каждого байта и выполняем операцию XOR с числом 5А (правильно, это будет число А5). После таких вычислений будет получено шестналдатеричное выражение пароля, как показано в табл. 11.2. Как видно из табл. 11.2, при известном методе "шифрования" скрытие паролей стало не более, чем легкой преградой, тольхо раздражающей хакера. Помните, что пока выключено шифрование, этот способ работает для любой сетевой библиотеки, которая передает данные по сети. Любой, кто перехватит пароли при незашифрованной передаче, сможет элементарно преобразовать пароль в обычный текст и без проблем подключиться к серверу SQL. Если пароли и данные передаются по сети и могут быть перехвачены, то обязательно нужно использовать сетевые библиотеки с шифрованием. Если на сервер установить сертификат, то SQL Server будет автоматически шифровать пароли даже без использования сетевых библиотек
с шифрованием.
Меры противодействия при перехвате аутентификационных пакетов SQL Server
Как вы сами могли догадаться, перехват паролей предотвращается шифрованием данных, передаваемых между узлами сети. Можно было бы предположить, что тут поможет коммутируемая сеть, но и для перехвата данных в коммутируемых сетях существует достаточно мето­дов, так что шифрование — это единственный способ защитить передаваемые данные. Некоторые способы перечислены втабл. 11.3.

Метод шифрования при передаче Преимущества
Недостатки

Включить многопротокольную сетевую Простота реализации библиотеку и включить шифрование
Только симметричное шифрование, требуется аутентификация NT/Windows

Применение фильтров IPSec
Разрешение шифрования SSL на SOL Server {только для версии SQL Server 2000)
Может защитить все данные, передаваемые между узлами, не требует изменений е SQL Server
Сложность устанозки для большинства администраторов баз данных и разработчиков
Устойчивое шифрование, работает со Сложность настройки без всеми сетевыми библиотеками сертификата и опыта установки
Доступ хакера к исходному коду на Web-сервере
Суровая действительность в мире систем безопасности такова, что уязвимые места приводят к эффекту падающих домино — сбои в совершенно разных системах могут свести на нет самую мощную защиту. В разработке приложений для SQL Server, особенно приложений на базе Web, строки соединения необходимо хранить таким образом, чтобы приложение "знало", как подключиться к серверу. Приложение ни в коем случае не должно разглашать строку соединения неавторизованному пользователю.
За годы работы нам встречались некоторые уязвимые места в US и других Web-серверах, которые позволяли просмотреть исходный код. Иногда причиной была одна из вышеперечисленных ошибок, иногда плохое администрирование. Пример — хранение строк соединения в файлах с расширениями . inc или . sre Неавторизированный пользователь легко может просмотреть сайт, найти файлы с именами наподобие connect. inc и узнать строку соединения, которой пользуется Web-сервер для подключения к серверу SQL. Если приложение использует собственное имя пользователя для подключения к SQL Server, то также можно будет узнать имя пользователя и пароль. Естественным в данном случае решением будет использование расширений имен .asp (на серверах IIS) для всех включаемых файлов, чтобы они обрабатывались на стороне сервера.
Мораль такова — всегда нужно учитывать, что пароль может подсмотреть посторонний человек. Делайте все возможное для изоляции сервера SQL Server, чтобы даже раскрытие исходного кода не привело к появлению бреши в системе безопасности. Также необходимо рассмотреть возможность использования аутентификации Windows в соединениях с SQL Server, поскольку в этом случае не требуется передавать имя пользователя и пароль в строке соединения.
Известные уязвимые места кода SQL Server
Программный код SQL Server не лишен многих из тех уязвимых мест, от которых страдают и другие серверы, например US. За годы существования кода SQL Server в нем были выявлены следующие ошибки:
▼ передача имени пользователя/пароля открытым текстом;
■ возможность переполнения буфера в расширенных хранимых процедурах;
■ слабая криптография, в результате — слабая защита мощных учетных записей;
■ отказ от обслуживания при неожидаемых или необычных пакетах;
* слабая система защиты — запись имени пользователя/паролей открытым текстом во время обновлений и отсутствие автоматического удаления этих записей.
Слишком часто эти уязвимые места позволяли хакерам получить доступ, "подвесить" SQL Server или расширить привилегии скомпрометированного пользовЕтеля до уровня системного администратора. Как только пользователь становится системным администратором, он получает возможность выполнять любые команды сервера SQL и получает доступ к операционной системе через расширенную хранимую процедуру xp_cmdshell. На уровне операционной системы хакер имеет те же права, что и служебная учетная запись для самой программы SQL Server. Слишком часто используется служебная учетная запись LocalSystem, учетная запись локального администратора или (!) администратора домена.
Проблемы с сервером SQL Server 7.0 также касаются программ MSDE 1.0, а проблемы SQL Server 2000 — программ MSDE 2000. Исключение составляют уязвимые места, присущие специфичным для SQL Server функциям, которые не входят в "урезанные" fvVSDE-версии сервера SQL.
Переполнение буфера в SQL-службе Resolution Service
Популярность
10

Простота
10

Опасность
10

Степень риска
10

Возможность переполнения буфера в SQL-службе Resolution Service была выявлена Дэвидом Литчфилдом (David Litchfield) из Next Generation Security Software Ltd. Его открытие привело к появлению бюллетеня безопасности Microsoft MSO2-039 в июле 2002 года. Литч-филд обнаружил уязвимое место при отправке определенного количества байтов данных на компьютер, где запущен хотя бы один экземпляр SQL Server 2000. Из-за переполнения буфера происходит отказ в работе SQL-сервера. Дэвид отправил отчет о выявленной ошибке компании Microsoft, которая немедленно выпустила заплату для устранения уязвимого места.
Сразу после полуночи 25 января 2003 года в сети Internet началось распространение "червя" (известного как "червь" SQL Slammer), использующего это уязвимое место. Распространение червя привело к значительному снижению пропускной способности сетей Internet и вызвало отказ в работе многих крупных узлов и предоставляемых ими служб. Огромная скорость распространения явилась результатом небольшого размера '"червя" SQL Slammer использования протокола, не ориентированного на установление соединений (UDP). В ре­зультате от "червя" не смогло защитить ни основанное на сигнатурах антивирусное программное обеспечение, ни плохо настроенные брандмауэры. Распространение SQL Slammer позволило сделать ряд важных выводов.
т Серверы SQL установлены повсеместно, включая многие инсталляции MSDE.
■ Многие из вариантов установки практически никак не администрируются.
* Многие из установленных серверов SQL непосредственно доступны через Internet.
Исходный код "червя" SQL Slammer был опубликован во многих периодических изданиях, например в журнале Wired, а код атаки доступен в Internet с момента выявления уязвимого места. Надеемся, что этот пример позволит нашим читателям осознать всю важность проблемы и понять, что при установке всех копий SQL Server следует проявлять равное внимание и опасаться ущерба, к которому может привести наличие уязвимого SQL-сервера.
•V Ошибка при синтаксическом анализе параметров щ расширенных хранимых процедур
Популярность
5

Простота
7

Опасность
9

Степень риска
7

Кажется, что в любой программе можно найти уязвимое место для проведения атаки на переполнение буфера. Программы SQL Server7.0 и SQL Server2000— не исключение. Для расширения функций сервера SQL Server с ним можно использовать дополнительные дина­мические библиотеки и расширенные хранимые процедуры. Оказалось, что некоторые процедуры, использующие функцию API srv_paraminf о О , не всегда правильно обрабатывают параметры — это дает злоумышленнику возможность вызвать сбои в работе сервера SQL или запустить свой код командного интерпретатора.
Код, введенный с помощью атаки на переполнение буфера, будет выполнен с уровнем привилегий служебной учетной записи MSSQLServer. Также очень часто для работы SQL Server используется учетная запись локального администратора или запись LocalSystem. Конечно, по этой причине при установке сервера SQL нужно создать учетную запись с низким уровнем привилегий и использовать ее для работы сервера. Но даже локальный пользователь сервера может нанести серьезный ущерб серверу с Неправильно настроенной зашитой, так что такая атака в любом контексте может нанести мощный удар.
Перечислим некоторые расширенные хранимые процедуры, функционирование которых также было затронуто из-за этого уязвимого места (для SQL Server 7.0/2000):
V xp_pee)cqueue
■ xp_printstatements
■ xp_proxiedmetadata
■ xp_setsqlsecurity
■ xp_sqlagentmonitor
■ xp_enumresultset Щ xp_showcolv
■ xp_displayparaiflstmt * xp__updatecolvbm Уязвимые хранимые процедуры только для программы SQL Server 2000:
т sp_oacreate
■ sp_oamethod
■ sp_oagetproperty
■ sp_oasetproperty * sp_oadestroy
пользователь имеет право выполнять по умолчанию, поскольку общая группа пользователей имеет права на запуск процедур. Использовать процедуры можно, напрямую подключаясь к SQL Server или с помощью ввода кода в существующие приложения. Простая Web-форма обратной связи, например, может стать источником для ввода кода программы атаки, который способен мгновенно перевести обычного анонимного пользователя Web в разряд локального пользователя или администратора.
т.
О Меры противодействия использованию ошибки
при синтаксическом анализе параметров расширенных хранимых процедур
Бюллетень

MS00-092

BID
2043

Исправлено в SP
3(SQL7.0) 1(SQL 2000)

Фиксируется
Нет

Компания Microsoft выпустила испрааления для этой ошибки и обещает внести их в следующий выпуск обновления для SQL Server. Компания Microsoft сообщила, что хранимые процедуры сторонних производителей должны соответствующим образом проверять пара­метры перед вызовом функции srv_paraminf о {), так что помните об этом, создавая свои процедуры. Как уже было сказано, служебная учетная запись программы SQL Server должна иметь низкий уровень привилегий, это поможет снизить ущерб, нанесенный использованием описанного уязвимого места.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика