О сервере бедном замолвите слово – II

Пугающая прелесть MS SQL Server или как удивить пользователей.

Скажи мне свой IP, и я скажу, кто ты…

Статья «О сервере бедном замолвите слово…» вызвала большой интерес читателей, поэтому я решил продолжить эту тему — тем более кроме Web-серверов есть еще и сервера баз данных…

Итак, у вас есть сервер под управлением Windows NT (2000). Как вы, наверное, знаете, под этой операционной системой могут работать различные типы серверов: Web, почтовые, файловые, печати, баз данных. Microsoft настоятельно рекомендует для каждой из перечисленных задач использовать отдельные компьютеры, а еще лучше два (три, четыре…). Для большинства организаций это неприемлемо, поэтому все сервисы очень часто можно найти на одном мощном сервере — таким образом уменьшается стоимость использования системы. Но, как известно, у любой медали две стороны, и вот на второй стороне этой медали находится как раз проблема безопасности. Ведь если хакер взломает один сервис, то велика вероятность, что он получит доступ и ко всем остальным.

После эпидемии вирусов Code Red, Code Red 2 и Nimda надежность Web-сервера IIS (Internet Information Services) от Microsoft была поставлена под большой и жирный знак вопроса. По всему миру огромное количество компьютеров стало уязвимо не на словах, а на деле. Пусть софтовый гигант бьет себя пяткой в грудь и говорит, что их Web-сервер самый популярный и поэтому в нем нашли столько много багов… Как эта популярность набрана, говорить, наверное, не надо — ровно так же, как было и с Internet Explorer. Если вам надо поставить что-то серверное, то часто без установленного IIS это сделать просто нельзя [1]. Да и про популярность можно поспорить, по крайней мере в России. Хорошо лишь, что после нашествия вирусов все-таки (наконец!!!) администраторы стали устанавливать заплатки. Ладно, если вам нравится IIS (как мне, например), используйте его на здоровье, но — будьте бдительны!

Какая фирма обходится без баз данных? Ведь при их использовании гораздо удобнее и быстрее вести учет сотрудников, аудит средств и многое другое. В качестве сервера баз данных чаще всего используют MS SQL Server, Oracle, Interbase, My SQL. Раз мы уже договорились, что у нас компьютер работает под управлением Windows, то глупо было бы предположить, что базы данных работают под My SQL. Конечно же, для этого используется MS SQL Server! Хороший продукт, мне нравится, и если вы подумали, что я сразу начну рассказывать о его взломе, то вы ошибаетесь. Лично я не слышал про способы его «опускания». Хотя… есть все же одна штука… Ладно, уговорили, записывайте.

Аутентификация пользователей в MS SQL Server возможна двумя путями: используя логин из Windows и/или конкретную учетную запись, созданную специально для базы данных. Если используется первый вариант, то пользователю предоставляется больше удобств. Зная имя и пароль в базе данных, можно что угодно делать и в домене (конечно, только то, что доступно данному пользователю). Или наоборот — если вы прописаны в домене, то можете получить доступ к данным из БД, причем очень велика вероятность того, что администратор не обрезал права доступа. А вероятность того, что в базе данных хранится много секретной или в крайнем случае конфиденциальной информации, ничуть не меньше….

А зная пароль администратора, можно вообще горы сдвигать! Так вот, вся пугающая прелесть MS SQL Server [2] в том, что по умолчанию после установки заводится учетная запись sa — это и есть администратор. Догадываетесь, какова длина его пароля? Ноль символов! Обычно все дальнейшие действия с базой данных администратор проводит через заход под своим именем из домена, а про sa все забывают. Если, конечно, вообще знали…

Таким образом, любой человек, имеющий доступ к серверу, может делать с базой всё, что угодно. Добавлять пользователей БД, менять им пароли, читать данные, удалять, изменять… Главное хорошо знать язык построения запросов SQL. Да, помните, я говорил в начале статьи, что если взломан [3] один сервис, то могут быть взломаны и все остальные? Сейчас я докажу это!

Попробуйте подсоединиться к серверу баз данных и выполнить следующий код (рис. 1):

use master
exec xp_cmdshell 'dir /O c:\'

Рисунок 1. Получение структуры каталогов на удаленном сервере.

Да-да-да, не удивляйтесь, через сервер БД можно получить доступ к командной строке. Для этого служит хранимая процедура xp_cmdshell. Какую потенциальную опасность это несет, я и говорить не буду — просто вспомните про net.exe, route.exe, format.exe… Да мало ли добра лежит в winnt\system32! К тому же и в самом SQL есть большое количество полезных команд и хранимых процедур. Больше всего мне понравилась одна, видимо, оставленная Microsoft специально для хакеров — напишешь shutdown, и сервер перезагрузится. Лепота… В общем, имея доступ к командной строке с правами администратора, имеешь [доступ ко] все[му] (рис. 2).

Рисунок 2. Меняем пароль администратора БД.

Есть одно большое НО. Чтобы подсоединиться к серверу, надо либо самому оказаться в его локальной сети, либо же «застать» оный сервер в Интернете. Второе, по идее, должно быть вообще невозможным — ведь даже если пароль администратора неизвестен, его можно подобрать, и очень легко — поверьте моему опыту. Однако, зачем такие сложности? Вспомните еще раз про две стороны медали. Например, у организации есть сервер баз данных. Через некоторое время руководство захотело иметь свой представительский Web-сервер. Второй компьютер покупать жалко, поэтому на первый поставили дополнительно Web-сервер и купили IP-адрес. Ура! Работает и первое, и второе. Про то, что база данных становится доступной извне, никто и не думает…

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

Меня с моим приятелем, работающим в провайдерской конторе, давно интересовал вопрос о соотношении использования различных Web-серверов. Несомненно, есть всевозможные независимые статистические данные, но они часто противоречат друг другу. Однажды товарищ быстренько написал программу на Perl, которая проверяет наличие Web-сервера на удаленном компьютере и определяет его название. За неделю поисков было всего просканировано102703 адресов, на которых нашлось всего 517 веб-серверов (соотношение серверов к адресам всего 0.5%). Процентное соотношение использования серверов показано на картинке - IIS не так уж и отстал от Апача (рис.3).

Рисунок 3. Статистика использования Web-серверов в мире.

Получив список адресов, где стоял IIS, я решил ради любопытства проверить их прочность. Запустив свой любимый LANguard Network Scanner [4], я стал смотреть, что, собственно, у кого открыто. Уже на третьем компьютере я обнаружил MS SQL. «А почему бы и нет?» — подумалось мне, и, запустив Query Analyzer и введя адрес + sa, я нажал Enter. В тот час пинг был быстрый и через несколько секунд глаза у меня разбежались от названий баз данных, к которым я получил доступ. Почти в каждой хранилось около сотни имен пользователей, их электронные и реальные адреса, даты рождений и, конечно, пароли. Немного побродив по таблицам, я отконнектился и забыл адрес. Даже ничего не стирал и приветов не оставлял. Я хоть и хакер, но безобидный…

Вообще же чрезвычайно весело лазить через удаленный компьютер по чужой локальной сети, подключать сетевые диски с музыкой, а потом выполнять на них что-то типа «start z:\zemfira.mp3». То-то пользователи должны удивляться, когда на заблокированном сервере внезапно начинает играть музыка… А есть еще командочка net send *, когда всем пользователям домена приходит сообщение от их же сервера (рис. 4). В общем, развлекайся — не хочу!

Рисунок 4. Отправка сообщения всем пользователем удаленного домена.

Шутки в сторону. Теперь задумайтесь, что можно сделать, если подходить к поиску информации осознанно. Если находить заказчиков на данные и продавать их. Получается промышленный шпионаж, и доступен он… практически каждому! Не надо заканчивать спецкурсы и учиться в закрытых структурах. Продвинутый школьник или студент сделает все «за таблетку, за монеточку». Страшно.

Но всего этого можно избежать. Прислушаемся к советам Microsoft и хотя бы базу данных установим на дополнительном компьютере, не имеющем выхода в Интернет. При надобности будем обращаться к данным на другом компьютере через клиентское программное обеспечение. Пусть у нас есть, к примеру, Интернет-магазин. Можно предложить такую схему: CGI-скрипт на Web-сервере посылает запросы на сервер баз данных, используя специальную облегченную учетную запись пользователя, имеющего доступ только к таблицам магазина. Чтобы максимально защитить структуру базы, можно вместо посылки готовых запросов вызывать написанные хранимые процедуры сервера БД. Если наш Интернет-магазин как-либо взломают, то достаточно лишь поменять пароль пользователя магазина и возможность потенциального доступа к другим таблицам сервера исчезнет. К тому же, если вызывать хранимые процедуры, то можно гораздо более независимо написать сам Интернет-магазин, да и данные он будет получать быстрее.

Что в итоге? В общем, достаточно банальные советы: чтобы обезопаситься от взлома, поставьте все существующие заплатки (как всегда), используйте по возможности для разных задач несколько компьютеров, привыкните чаще менять пароли и делать их большими. Правда, обычно этого никто не делает…

Ну а если вы уверены в своей безопасности — дайте мне свой IP, и постараюсь проверить ее. Об оплате поговорим потом…

[1] — Так, например, в организации, где я работаю, ставили сервер баз данных MS SQL Server и Active Directory. Чтобы это осуществить пришлось дополнительно добавить IIS, про который сразу забыли. Вспомнили только тогда, когда я решил проверить сервер на подверженность Unicode Bug.
[обратно к тексту]

[2] — Так было в MS SQL Server 7. В 2000 уже появилось предупреждение о создании пользователя sa с пустым паролем.
[обратно к тексту]

[3] — Стоит только оговориться, а «взломан» ли компьютер? Ведь ничего незаконного никто не делает. Просто заходит на компьютер и все.
[обратно к тексту]

[4] — Смотри «Мы как шпионы» и «О сервере бедном замолвите слово…»
[обратно к тексту]