Взлом SQL-сервера

Опубликовано: 14 Апреля, 2023

Microsoft SQL Server — это популярная и надежная среда для многих приложений, использующих базы данных. Она отличается превосходными возможностями множественного доступа, всеобъемлющей защитой и может быть легко перенесена на другие платформы баз данных. К сожалению, такой потенциал не будет реализован, несмотря на использование бесплатного MSDE (Microsoft Database Engine, оптимизированного для индивидуальных решений или решений для небольших рабочих групп), если не будет обеспечена как минимум адекватная защита безопасности баз данных. Почему это обязательная технология? Поскольку высокие возможности SQL Server сочетаются с высокой гибкостью, чрезмерная гибкость может нанести ущерб при неправильном использовании. Цель этой статьи — определить определенные типы рисков, которые могут возникнуть в результате неправильного управления Microsoft SQL Server.

При правильной настройке каждый SQL Server разрешает всем пользователям доступ к базе данных master, которая содержит все параметры SQL Server и всю информацию, которую SQL Server использует для открытия баз данных. Он также содержит все идентификаторы входа в SQL, данные подключенных серверов и т. д. Конечно, «обычным» пользователям не разрешен доступ ко всем информационным ресурсам. На рис. 1 показано, как ведет себя сервер при попытке доступа к списку учетных записей — как видно, сервер запретил пользователям читать пароли. Тем не менее, имена учетных записей и базы данных (включая хранящуюся в них информацию) могут быть доступны непривилегированным пользователям. Пример, показывающий часть информации, полученной пользователем, показан на рисунке 2 ниже.

РИСУНОК 1: Неудачная попытка доступа к списку учетных записей.
РИСУНОК 2: Когда обычному пользователю удается получить доступ к списку учетных записей.

(затронуты 4 ряда)
1> выберите имя, dbid из sysdatabases
2> идти
имя
dbid
———————————————
———————-
мастер
1
база данных tempdb
2
модель
3
msdb
4
пабы
5
Северный ветер
6
страницы
7
(затронуто 7 рядов)
1>

Как видите, защитить свои данные от посторонних глаз пользователей сложно.

Однако…

Конечно, теперь читатель может захотеть заметить: «Но в конце концов, моим пользователям не разрешено выполнять специальные запросы на SQL Server!» Однако внимательное рассмотрение показывает, что это довольно сомнительное утверждение, потому что возможность или невозможность размещения преднамеренно созданных запросов в приложении SQL Server не обязательно означает, что то же самое правило действительно для самого сервера! Несмотря на то, что конкретное приложение явно защищено от такой ситуации, я бы посоветовал вам пересмотреть идею о том, что все скрипты защищены от атак путем внедрения кода SQL» [1][2]. Что, если пользователь при определении условий запроса может прикрепить таблица с результатами? И какая определяемая сервером схема аутентификации должна применяться для потенциальных пользователей? Даже если предположить, что приложение хорошо защищено от несанкционированного доступа к данным, сам пользователь не может запустить на своем компьютере стандартные средства связи для подключения к SQL-серверу — osql.exe, VBScript, использующий ADO, или любую другую программу, работающую с ODBC (или OLEDB) непосредственно на сервере базы данных. Единственным условием является знание пароля SQL Server. Тем не менее, во многих ситуациях достаточно возможности аутентификации пользователей локальной сети в службах каталогов. Однако не допускайте возникновения паранойи — мы должны просто признать, что возможность аутентификации пользователя с помощью SQL Server связана с автоматическим правом задавать уточняющие или даже нескромные вопросы.

Каковы выводы?

Давайте еще раз посмотрим на приведенный выше пример запроса, который возвращает имена учетных записей — некоторые из них определены на сервере SQL и распознаются по значению 0 в столбце «isntname». Если настроено выполнение аутентификации в режиме смешанной аутентификации, SQL Server будет принимать попытки входа в систему с этими учетными записями, не отключая учетную запись при повторных попытках. Это недостаток механизма, с помощью которого SQL Server аутентифицирует соединения в смешанном режиме. К счастью, его использование является необязательным, и даже если оно присутствует, оно не рекомендуется, поскольку создает возможности для атаки грубой силы, в которой пытаются использовать каждый возможный ключ или пароль до тех пор, пока не будет найден правильный. Конечно, хакер может сделать это с помощью подходящей программы для автоматизации такой работы (не буду вдаваться в подробности по понятным причинам). Наиболее «почитаемой» является учетная запись «sa» (системный администратор), которая имеет доступ ко всему, созданному специально для SQL-сервера (это похоже на root в Linux или LocalSystem в Windows NT). Он имеет права на управление любой базой данных (включая «главную» базу данных), полный доступ для выполнения любых функций на сервере SQL и даже для запуска процессов, которые унаследованы службой сервера, а именно процесса SQLSERVR.EXE. Более того, во многих инсталляциях SQL Server работает в контексте безопасности администратора машины — таким образом, пользователь «sa» может управлять компьютером с установленной службой MS SQL Server, помимо управления всеми базами данных. При работе с MSDE ситуация еще хуже — служба устанавливается под LocalSystem, с учетной записью «sa» по умолчанию и ПУСТЫМ паролем! На рисунке 3 показаны две последовательные попытки взломать учетную запись «sa», одна неудачная попытка, а другая успешная.

РИСУНОК 3: Две атаки на учетную запись «sa» с пустым паролем — вторая попытка успешна.

Использование учетной записи системного администратора

Прежде всего, пользователь «sa» имеет контроль над всеми данными, схемой и настройкой SQL-сервера. Здесь нет необходимости вдаваться в подробности, ведь список привилегий системного администратора может содержать практически что угодно. Вместо этого давайте сосредоточимся на некоторых специально отобранных типах вредоносных атак. Самый простой заключается в создании новой учетной записи с теми же привилегиями, что и у пользователя «sa». Листинг ниже является примером:

1> sp_addlogin 'взломанный','h4xor'
2> идти
Создан новый логин.
1> sp_addsrvrolemember «взломанный», «сисадмин»
2> идти
'hacked' добавлен к роли 'sysadmin'.
1> выйти
C:>osql -U hacked -P h4xor -Q «ВЫБЕРИТЕ ИМЯ_БД(),ИМЯ_ПОЛЬЗОВАТЕЛЯ()»
——— ——-
мастер ДБО
(затронут 1 ряд)
С:>

Вместо процедуры «sp_addlogin» можно использовать, например, «sp_grantlogin» — последняя установит учетную запись, аутентифицируемую операционной системой, на которой работает SQL-сервер. Хочу отметить, что получить привилегии «sa» очень просто – просто назначив роль sysadmin выбранной учетной записи пользователя (или группы пользователей, определенной на этапе установки SQL Server). Помимо этой роли, служба SQL Server позволяет использовать некоторые другие функции, которые, однако, не могут быть использованы для полноценного управления сервером. Заинтересованных отсылаю к [3]. Конечно, нельзя исключать, что администратор обнаружит такую учетную запись (даже если ее имя не выделяется ничем необычным). Если это так, у хакера нет других вариантов, кроме как использовать существующую учетную запись — самый простой способ — изменить пароль с помощью процедуры «sp_password». Если злоумышленник хочет замести следы, он может попытаться расшифровать пароли, дающие пользователям доступ к серверу. Здесь можно вспомнить, что при аутентификации в смешанном режиме SQL Server может использовать свой собственный механизм аутентификации, который хранит информацию не только об именах учетных записей (аналогично аутентификации на основе операционной системы), но и о паролях. Это делается в столбце «password» таблицы sysxlogins — он содержит хэш пароля пользователя, созданный функцией pwdencrypt(). Это достаточно известный факт, блестяще описанный Дэвидом Литчфилдом в [4]. Инструменты, которые можно использовать для проведения атак грубой силы, описаны в [5]. Если ваш SQL Server не настроен для аутентификации SQL Server, вам не нужно беспокоиться о том, что вас взломают описанным выше способом. Более злонамеренный злоумышленник может попытаться установить бэкдор. Ниже представлены две возможности.

Расширенные хранимые процедуры

В SQL Server предусмотрена возможность запуска процедур, написанных пользователем. Эти процедуры могут быть написаны на языке SQL и храниться в любой базе данных или представлять собой библиотеки динамической компоновки (DLL), которые SQL Server может динамически загружать и выполнять при необходимости. Последний тип называется «расширенными хранимыми процедурами» и означает процедуры с интересными характеристиками: они добавляются непосредственно в SQL Server и совместно используют контекст безопасности исполняемого файла SQL Server. На практике расширенные хранимые процедуры можно заставить выполняться с привилегиями «sa» в базе данных. Они могут быть определены только в «главной» базе данных, с помощью которой они могут быть добавлены в базу данных только администратором (пользователем «sa»).

Конфигурация SQL Server по умолчанию содержит практически огромное количество этих процедур, однако большинство из них недокументировано. Расширенные хранимые процедуры можно настроить для работы с различными схемами аутентификации — определенные процедуры доступны для всех пользователей либо по умолчанию, либо потому, что этого требует функционирование сервера. Только системный администратор может запускать другие расширенные хранимые процедуры. Это создает ряд операционных трудностей для администратора, особенно при обнаружении «специальных» процедур, которые могут быть внедрены в сервер злоумышленником. Достаточно загрузить на компьютер заранее подготовленный DLL-файл (используя Open Data Services API, который опционально устанавливается вместе с SQL Server), затем вызвать процедуру «sp_addextendedproc» с соответствующими аргументами, после чего предоставить право на выполнение эту процедуру для всех пользователей (т.е. для общедоступной группы пользователей). Такая процедура может затем использоваться хакером для выполнения преднамеренных операций с привилегиями «sa» с любого уровня учетной записи пользователя!

Почему бы не отозвать авторизацию?

Крис Энли в своем документе, озаглавленном «Нарушение базы данных — принудительные механизмы безопасности» [6], описал подход к усилению безопасности, который включает модификацию функционирования SQL Server для игнорирования запросов от кого-либо, кроме пользователей «sa». Его изобретение основано на идее обработки исключений процедуры авторизации кодом SQL Server. « Вместо статического анализа всей кодовой базы SQL-сервера небольшая предварительная отладка, вероятно, укажет нам правильное направление ». Конечно, такое изменение возможно при определенных условиях — либо путем манипулирования исполняемым файлом, содержащим кодовую базу SQL-сервера, либо путем выполнения операций с образом в памяти — в обоих случаях системный администратор SQL Server является единственным лицом, уполномоченным на это. сделай это. Однако это упрощенная ситуация. Реальность довольно мрачная. Прежде чем перейти к дальнейшим подробностям, позвольте мне напомнить вам, что соблюдение текущих бюллетеней безопасности имеет первостепенное значение, иначе буфер может переполниться.

Почему проблема переполнения буфера вызывает беспокойство? Как вы, возможно, помните, SQL Server имеет множество расширенных хранимых процедур по умолчанию, т. е. функции DLL, поставляемые с SQL Server. Они пишутся на любом языке высокого уровня (например, C), а затем компилируются как DLL. При запуске они считывают пользовательские параметры в буфер памяти. Однако, как может случиться по какой-либо причине, программист может забыть зашифровать проверку данных, помещая их в переменные в программе, и если злоумышленник отправляет слишком много данных, данные могут «переполниться» заданным размером и записать данные в соседние области буфера компьютера. Это переполнение буфера может позволить злоумышленникам выполнять произвольные команды в удаленной системе. (См., например, «Анализ атак переполнения буфера» Петра Фрея и Мацея Огоркевича). Проблема в том, что Microsoft SQL Server содержит процедуры, уязвимые для атак с переполнением буфера. Это как ранее описанные расширенные хранимые процедуры, так и функции, реализованные на языке Transact-SQL (примером может служить ранее упомянутая функция «pwdencrypt»). Это также может произойти с библиотеками OLEDB, которые представляют собой COM-объекты, загружаемые в клиентский процесс. Помните, что в контексте COM каждая программа, основанная на компонентах, становится клиентом. Всякий раз, когда активируется команда OPENROWSET, SQL Server становится клиентом поставщика данных, что автоматически делает его уязвимым для ошибок в коде конкретной OLEDB. Для тех, кто заинтересован, вы можете прочитать различные бюллетени по безопасности [7] для получения подробной информации о проблемах и предлагаемых решениях. Если это так, имейте в виду, что успешная атака переполнения буфера означает, что каждый пользователь может запускать произвольный код на сервере SQL в контексте учетной записи локального администратора. И, как мы уже знаем, эти («sa») привилегии позволяют произвольно манипулировать службой SQL, тем не менее у нас остается следующая проблема — насколько мощными являются привилегии «sa» в контексте операционной системы?

Они одинаково сильны для службы SQL, и, строго говоря, с точки зрения безопасности, эти привилегии соответствуют привилегиям процесса SQLSERVR.EXE. По «стандартному» умолчанию SQL Server включает несколько очень мощных расширенных хранимых процедур для связи с операционной системой. Просто упомянем некоторые из них:. «xp_cmdshell», «sp_OACreate», «xp_regwrite», «xp_instance_regwrite», «xp_adsirequest». Хотя некоторые из них задокументированы (два первых), мы все еще не уверены в последствиях других. Используя эти процедуры, администраторы SQL Server могут взаимодействовать с операционной системой только в рамках авторизации для службы MSSQLServer. Если бы это был случай запуска этой службы в учетной записи LocalSystem, «sa» были бы предоставлены высшие привилегии для доступа к рабочему столу, но не к сетевым каталогам. Злоумышленник может использовать эти привилегии, как показано на рисунке 4.

РИСУНОК 4: Использование учетной записи «sa» для загрузки программы из Интернета на сервер.

Если вместо этого мы запустим службу с учетной записью домена, которая имеет доступ к сети, то пользователь «sa» может получить доступ ко всей сети. Однако для обычных пользователей это будет сюрпризом. Привилегии учетной записи «sa» зависят от того, как настроена служба MSSQLServer. В документации SQL Server четко указано, что учетная запись MSSQLServer является учетной записью пользователя, а не системной учетной записью. Несмотря на то, что недавно мы прочитали в бюллетенях Microsoft по безопасности, касающихся SQL Server: «SQL Server 2000 может работать под учетной записью без прав администратора, однако для этого требуется полный доступ к разделу реестра:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesMSSQLServer»

Имея этот уровень доступа, процесс SQL-сервера может изменять значение «ObjectName» в реестре. Он содержит имя учетной записи, необходимой для запуска службы. Этого достаточно, чтобы перенастроить службу для работы от имени LocalSystem. Следовательно, злоумышленник, который может запускать код под учетной записью SQL Server, может перенастроить службу для работы с максимально возможными локальными привилегиями, даже если SQL Server работает как обычный пользователь! Эта проблема рассмотрена в третьем разделе бюллетеня Microsoft по безопасности MS02-034 [8]. Чтобы прочитать о разрешениях, необходимых для SQL Server, обратитесь к документу по безопасности SQL Server 2000 [9].

Локальная система по умолчанию?

Microsoft SQL Server 2000 Desktop Edition (MSDE 2000), последняя версия MSDE устанавливается с учетной записью LocalSystem по умолчанию. Конечно, это создает потенциальную уязвимость для атак, как описано выше. Естественно, обновление SQL Server до Service Pack 3 повышает безопасность, но безопасности самой службы SQL Server, а не машины, на которой она запущена. Вместо этого, установив SP3, вы можете столкнуться с проблемами, если сервер работает не на LocalHost. Это следствие разрешений, которые устанавливаются для ключа реестра и файловой системы при установке SP3. Конечно, сведение к минимуму нежелательных привилегий — положительный фактор, но оставлять этот подход с недостаточной документацией — плохая практика. Ниже приводится некоторая основная информация, которая поможет заполнить документацию по мере необходимости.

Чтобы уменьшить связанные с MSDE привилегии в операционной системе:

Замените обе учетные записи службы MSSQLServer и SQLServerAgent (на LocalSystem) выбранной учетной записью.
Предоставьте этой новой учетной записи право на чтение в каталоге C:Program FilesMicrosoft SQL ServerMSSQL, не забывая установить флажок «Сбросить разрешения для всех дочерних объектов» в диалоговом окне «Дополнительно».
Предоставьте полные привилегии в подкаталогах DATA и LOG для этой новой учетной записи.
Запустите реестр с помощью regedt32.exe (таким образом, чтобы разрешить редактирование привилегий — используйте regedit.exe, если в Windows XP) и предоставьте полные права для учетной записи в ключе реестра: HKLMSOFTWAREMicrosoftMSSQLServer. Повторно запустите «Сброс разрешений для всех дочерних объектов…»
Предоставьте разрешение на чтение учетной записи (только чтение!) в разделе реестра HKLMSYSTEMCurrentControlSetServicesMSSQLSERVER.
Запустите службу MSSQLServer
Добавьте учетную запись службы к роли сервера sysadmin (для поддержки службы SQLServerAgent), используя следующие команды SQL:

1> sp_grantlogin 'КОМПЬЮТЕРaccount_sql'
2> идти
Предоставлен доступ для входа в 'COMPUTERaccount_sql'.
1> sp_addsrvrolemember 'COMPUTERaccount_sql', 'sysadmin'
2> идти
'COMPUTERaccount_sql' добавлен к роли 'sysadmin'.

Запустите службу SQLServerAgent.

Команды SQL необходимо запускать с помощью программы osql.exe под учетной записью системного администратора, указав параметр E. Очевидно, вы должны указать реальное имя учетной записи службы SQL, которому должно предшествовать имя машины. Если вы не хотите предоставлять доступ к вашему серверу MSDE из сети, отключите следующий раздел реестра:

HKLMSOFTWAREMicrosoftMSSQLServerMSSQLServerSuperSocketNetLib

По понятным причинам рекомендуется заранее экспортировать этот раздел реестра в файл.reg. Если возникают проблемы с запуском службы MSDE, используйте программы FileMon и RegMon, доступные на сайте www.sysinternals.com — это очень полезные инструменты для анализа и устранения проблем, возникающих из-за чрезмерных ограничений, налагаемых на ключи реестра или файловые системы. Также стоит ознакомиться с документацией по SQL Server 2000 [3][9].

Библиография

[1] http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
[2] http://www.it-faq.pl/itfaqarticle.asp?id=136
[3] http://msdn.microsoft.com/library/en-us/startsql/portal_7ap1.asp
[4] http://www.nextgenss.com/papers/cracking-sql-passwords.pdf
[5] http://www.cqure.net/tools10.html
[6] http://www.nextgenss.com/papers/violating_database_security.pdf
[7] http://www.microsoft.com/technet/security/current.asp?productid=30
[8] http://www.microsoft.com/technet/security/bulletin/MS02-034.asp
[9] http://www.microsoft.com/technet/prodtechnol/sql/maintain/security/sql2ksec.asp

Кибер-безопасность