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

 

 

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

Взломать Web-сервер, заменить домашние странички фотографиями потгураздетых женщин и издевательскими комментариями — это все, конечно, весело. Но что делать с хакерами, которые хотят больше, чем просто заменить несколько страниц? Рано или поздно, вы столкнетесь с противником, который будет стремиться получить доступ к самым ценным ресурсам, просто из желания досадить или чтобы заработать на этом. Что может быть более ценным, чем информация, спрятанная глубоко внутри вашей базы данных? Информация о сотрудниках, учетные записи пользователей, пароли, данные о кредитных карточках — вот к чему стремится настоящий хакер.
Среди компаний, использующих технологии от компании Microsoft, в качестве средства хранения данных очень популярен сервер реляционных баз данных Microsoft SQL Server, а также различные варианты программ MSDE (Microsoft Data Engine), которые поставляются в составе более чем 220 известных пакетов программного обеспечения. Использование MSDE становится практически повсеместным, благодаря бесплатному распространению и широким возможностям. Однако не все пользователи знают об установке по умолчанию MSDE, поэтому встретить безопасный экземпляр MSDE довольно сложно.
К сожалению, несмотря на все заботы о масштабируемости и надежности, большинство компаний при использовании сервера SQL упускают ключевую составляющую его стабильной работы — обеспечение безопасности. Общее несчастье многих компаний состоит в том, что они проводят уйму времени, укрепляя защиту "ворот замков", в то время как "королевские подвалы" остаются открытыми.
Кроме того, как нас научил "червь" SQL Slammer (http://www.cert.org/advisories/ CA-2003-04.html), возможны и другие последствия при недостаточной защите сервера SQL. Когда уязвимое место в выпущенной шесть месяцев назад SQL Server чуть не разрушило работу всей сети Internet, стали очевидными два вывода: существует много вариантов установки SQL Server и ни один из них не является абсолютно безопасным.
В этой главе мы продемонстрируем, как злоумышленники-собирают информацию, атакуют и взламывают сервер SQL Начнем с рассмотрения примера общепринятых методов атаки, далее будут подробно описаны концепции безопасности SQL, средства и методы хакинга, а также меры противодействия атакам. Затем вернемся к описанию методов и средств защиты сервера SQL.
Изучение на примере: взлом SQL-сервера
В этом гипотетическом, но весьма близком к реальности примере будет рассмотрен сценарий, который нам встречается в разных инсталляциях сервера SQL снова и снова. Будет показано, как недостатки на первый взгляд несвязанных подсистем могут "сложиться" в полностью готовое к использованию уязвимое место. Отметим, что в примере хакер использует некоторые средства, описанные в данной главе несколько позже, но они необязательны для выполнения любого из приведенных в примере взломов.
Предположим, что хакер Макс вынашивал мысль о жестокой мести некоторой (вымышленной) компании X. После шестимесячного контракта с компанией Макса вдруг выдернули из платежной ведомости, как сорную траву. Он решил, что компания должна полностью осознать ошибку, которую совершила, уволив кое-кого из явно талантливых работников.
Макс был осведомлен о многих политиках внутренней безопасности компании X, но поскольку он был лишь программистом по контракту, а не инженером безопасности или администратором NT, он не знал всех подробностей внутренней инфраструктуры, конфигураций брандмауэров или другой полезной информации, которая помогла бы свершить возмездие. Чтобы не вызывать подозрений, Макс воспользовался услугами общедоступного Internet-провайдера и провел полное сканирование портов граничных маршрутизаторов компании X. Чтобы определить диапазон IP-адресов компании, он сначала обратился к базам данных ARIN и Network Solutions, а затем просканировал их все с помощью программы f scan, ис-
пользуя для доступа в Internet только что созданную учетную запись (предварительный сбор данных и сканирование более подробно описаны в главе 3, "Предварительный сбор данных и сканирование"). В результате сканирования Макс обнаружил около четырех Web-серверов, сервер SMTP/POP3 и какую-то программу, ожидающую подключения к ТСР-порту 1433. Все серверы точно находятся в домене компании X.
Ага! Как разработчик Макс хорошо знал, что ТСР-порт 1433 по умолчанию используется для подключения к серверу SQL в библиотеке для работы с сокетами по протоколу TCP/IP. Он запустил утилиту osql. ехе, которая поставляется с пакетом MSDE (Microsoft Data Engine, его можно загрузить со страницы: http; / /premium.microsof t. com/msde/msde .asp, используя серийный номер любой из других программ компании Microsoft), и попытался под^ючиться, использовав пароль, который существовал во время его работы в компании.
C:\5-oeql.exe -S 10.2.3.13 -U dev -Р М34яЗк35
Login failed for user "dev.
He вышло! Администраторы подготовились заранее и сменили пароли после увольнения Макса, следуя политике безопасности компании. Но Макс не остановился, а задумался, что же делать дальше. Ему нужен был способ получить пароль учетной записи sa. Эта учетная за­пись дает административный доступ к серверу SQL, а в конфигурации по умолчанию прямая атака даже не оставит следов в журналах. Макс поискал в Internet и обнаружил утилиту sqlbf (http: //packet s tormsecuri ty. org/Crackers/sqlbf .sip), которая обещала найти пароль, если он присутствует в используемом словаре. Настроенный несколько скептически, Макс установил и запустил утилиту, хотя, зная политику безопасности компании X, предполагал, что пароль должен быть очень сложным, — не лучшая цель для атаки по словарю.
Он помнил, что данные учетной записи sa хранятся в файле global.asa каталога Webroot. Конечно, запросы файла global. asa через браузер обычно запрещены, но Макс просмотрел свою любимую базу программ атаки и попробовал использовать для получения исходного текста файла недостаток нескольких версий сервера IIS, связанный с наличием ошибки + . htr (уязвимое место + .htr подробно описано в главе 10, "Хакинг сервера IIS"). Ура! На втором сервере в ответ на запрос была возвращена пустая страница, но когда он просмотрел источник страницы, увидел следующий текст.
"Provider-SOLOLEDB.1;Persist Security Info-True:
u.id=sa;pvjd=m2ryh2dallttleLanib; Initial Catalog=data;Data Source=10.2.3.12;' End Sub </CRPT>
Макс не мог поверить своим глазам. Конечно, он сразу запустил утилиту osql и ввел только что полученные данные (Имя пользователя^ 'sa', Пароль='т2гуЬ^а11^1е11атЬ'). Отлично. Он проверил сервер, просто чтобы убедиться в наличии доступа к базе пользовательских запросов (и отметил, что надо бы вернуться сюда позже и стереть ее в порошок). Пользуясь хранимой процедурой xp_cmdshell, Макс получил возможность узнать, какие соединения может устанавливать сервер.
C:\soBql.exe -S 10.2.3.12 -П аа. -V m2ryh2dallttleLanib -Q % "jcp^emdahell 'cemte print'"
В результате выполнения запроса он получил таблицу маршрутизации сервера, к которому он подключился, и понял, что это машина с несколькими сетевыми адаптерами, один из которых соединен с внутренней сетью. Естественно, пакеты из Internet не могли напрямую попадать во внутреннюю сеть, но сервер SQLдoлжeн иметь возможность устанавливать внутренние соединения. Почему бы и нет? Персонал обслуживания клиентов должен иметь доступ к запросам клиентов, а значит, они должны иметь доступ к соответствующей базе. Все шло как нельзя лучше.

-
Теперь Макс должен был подтвердить привилегии для системы безопасности операционной системы, он воспользовался следующей командой.
C:\i-osql.exe -S 10.2.3.12 -О sa -Р m2ryn2dallttleLamb -Q Ч> "хр_спк1вЬа11 'net config workstation,л
Computer name WSQL-DMZ Full Computer name SQL-DMZ User name Administrator
Workstation active on
KetbiosSmb (000000000000)
NetBT_Tcpip_(9F09B6FC-BBF2-4C04-SCA4-8AABFDB18DAl) (0080C77B8A3D)
Software version Windows 2000
Workstation domain WORKGROUP Workstation Domain DNS Name (null) Logon domain SQL-DM2
COM Open Timeout (sec| 0 COM Send Count {byte] 16 COM Send Timeout (msec) 250
По значению поля с именем пользователя Макс понял, что сервер SQL работает от имени локальной учетной записи Administrator. Вполне возможно, что это переименованная учетная запись пользователя с более ограниченными правами, поэтому Макс проверил, дей­ствительно ли учетная запись принадлежит локальному администратору.
C:\sosql.exe -S 10.2.3.12 -О ва -Р tt2ryh2dellttlaLamb -Q Ь Bxp_emdshell 'net localgroup administrators'"
Alias name administrators
Comment Administrators have complete and unrestricted access
to the computer/domain
Members
Administrator
The command completed successfully.
Теперь он точно знал, что эта учетная запись добавлена в группу локальных администраторов и не является подложной для обмана незадачливых хакеров.
Можно и дальше следить за путешествием Макса в недра компании X, но в этом нет необходимости. С тем уровнем прав, который получил Макс, его ничто не ограничивает внутри системы. Итак, урон нанесен, а теперь разберемся, как компания X могла предотвратить эту катастрофу.

 

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