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

 

 

Ошибка, связанная с правами доступа хранимой


процедуры

Популярность
5

Простота
7

Опасность
5

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

Эта ошибка позволяет пользователю SQL Server 7.0 выполнить любую хранимую процедуру, принадлежащую владельцу любой базы данных учетной записи sa. Особенно опасной эту атаку делает то, что необходимые для нее условия встречаются достаточно часто. В инсталляциях, где SQL Server работает в смешанном режиме (используется аутентификация и Windows, и SQL Server), для создания баз данных, скорее всего, используется учетная запись sa, а значит, она становится владельцем базы данных. Также при создании объектов баз данных часто используется та же самая учетная запись, которая становится владельцем базы данных.
Вес, что пользователь должен сделать для использования уязвимого места программы SQL Server при описанных условиях, — создать временную хранимую процедуру. Эта временная хранимая процедура должна исполнять хранимую процедуру, принадлежащую владельцу базы данных,
в атакуемой базе данных, которая в свою очередь принадлежит учетной записи sa. Пример кода для создания пользовательской учетной записи в фиктивном приложении представлен ниже.
CREATE PROCEDURE (tsploit AS
exec yourdb.dbo.sp_create_user 'hacked','pass','admin'
Теперь хакер выполняет созданную хранимую процедуру и создает учетную запись в приложении. Обратите внимание, что базы master, msdb и tempdb принадлежат учетной записи sa, они же являются первоочередными целями описанной атаки. В качестве бесплатного приложения к большей часта хранимых процедур этих баз данных доступна хорошая документация в службе Books Online (документация к программе SQL Server), так что при поиске потенциальных целей не потребуется строить никаких догадок.
Защита от использования уязвимого места прав доступа хранимой процедуры
Бюллетень
MS00-048

BID
1444

Исправлено в SP
3(7.0)


1(2000)

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

Компания Microsoft выпустила исправление этого уязвимого места, а также включила исправление в пакеты обновления SQL Server 7.0 Service Pack 3 и SQL Server 2000 Service Pack 1. Владение базой данных можно передавать, кроме пользователя sa, и другим пользователям, но так как пользователь sa владеет системными базами данных, исправлять эту проблему таким образом не рекомендуется. Заплаты доступны, установите их и наслаждайтесь жизнью.
Вредоносный SQL-запрос
Популярность
5

Простота
6

Опасность
8

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

Возможность отправки вредоносного SQL-запроса возникает из-за неполной проверки аргументов в неоднородном запросе (OpenRowset). После выполнения такого запроса привилегии пользователя будут повышены до привилегий владельца базы данных. Необходимое условие для этой атаки — существование учетной записи пользователя в системе безопасности программы SQL Server.
Рассмотрим пример простого вредоносного запроса к SQL Server для получения списка файлов каталога сл.
SELECT * FROM OPENROWSET!'SQLOLEDB','Trusted_Connection=Yes;
Data S our с e=iny server' , ' SET FMTONLY OFF execute master.. xp_cmdstiell
4* "dir c;\"4
После передачи запроса на уязвимый сервер пользователь получает список файлов каталога, хотя и не имеет прав на выполнение расширенной хранимой процедуры master. .xp_cmdshell. Злоумышленнику предоставляется доступ к операционной системе в контексте служебной учетной записи программы SQL Server. Эту атаку можно проводить и через существующие приложения, в которых не производится достаточная проверка параметров, просто вставив запрос в поле ввода.
Защита от вредоносного SQL-запроса


Бюллетень BID

MS00-014 1041


Исправлено в SP

2(7.0)
2000 не уязвим



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







Для устранения этого уязвимого места существует заплата, которая вошла в пакет обновления Server Pack 2. Кроме того, если специальные функции неоднородного запроса не используются, то их можно отключить (избавившись таким образом от уязвимого места), внеся в реестр следующие изменения.
[HKEY_LOCAL_MACHINE\SOFTWARE\MicrosofС\MSSQLServer\Providers\ Ь Microsoft:.Jet.OLEDB.4.0] "DisailowAdhocAccess"=dword:00000001
[HKEY_LOCAL_MACKINE\SOFTWARE\Microsoft\MSSQLServer\ProviderB\MSDAORA] ■ DisallowAdhocAccess"=dword:00000001
! HK H Y_LOC AL_MAC HI NE \ SOFTWARE \ M i с г о s о f t \ MS SQL Se rve r \ Pr о v i de r s \ F.SDASQL ] "DisallowAdhocAccess"=dword;00000001
[HKEY_LOCAL_MACHINE\SOFTWARENMicrosoft\MSSQLServer\ProvidersXSQLOLEDB] "DisallowAdhocAccess"=dvrord;00000001
Конечно, лучший способ предотвратить атаку — постоянно использовать выпускаемые заплаты. Кратковременные исправления, которые помогают избавиться от ошибки сейчас, в будущем могут отразиться на произвддительности, если вы отключили функцию и забыли об этом.
Атаки введением кода SQL
Введение кода SQL лучше всего описать как возможность вставить свои команды SQL в существующее приложение. При чтении данного раздела нужно помнить, что этот тип атак не ограничивается кодом SQL Server. В той или иной степени подобным способом можно повлиять на любую базу данных, которая поддерживает команды SQL. Опишем эту проблему для SQL Server и ассмотрим противодействие для нее.
Результат успешной атаки введением кода SQL может быть разным — от получения секретной информации до полного взлома сервера. Для успешной атаки введением кода SQL хакер на самом деле должен сделать только три операции1.
▼ найти страницу, на которой не производится необходимая проверка ввода; Ш узнать используемый язык SQL;
* создать код для введения, соответствующий используемому языку SQL.

 

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