Защита баз данных

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

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

       1 Nimda=Admin наоборот. Тонкий  намек ;)

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

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

       4 Стоит только  оговориться, а "взломан"  ли компьютер? Ведь ничего незаконного  никто не делает. Просто заходит  на компьютер и все.

       P.S. Уже спустя через довольно  продолжительный для компьютерной  сферы промежуток времени, я  прочитал, что большое распространение  получил вирус, сканирующий сеть  в поисках MS SQL Server и пробующий  зайти на них под пользователем  sa с пустым паролем.

       Взлом паролей в MS SQL Server

       Система парольной защиты пакета SQL Server оказалась  не такой устойчивой, как принято  было считать. Такое открытие сделал Дэвид Личфилд (David Litchfield), специалист по компьютерной безопасности из компании Next Generation Security Software (NGSS), изучив работу недокументированной функции pwdencrypt(), отвечающей за хэширование паролей  в SQL Server. Первым делом Личфилд решил  проверить, добавляется ли в хэш  пароля случайный шум, позволяющий  более надежно зашифровать информацию. Для этого он сверил значения, возвращаемые pwdencrypt() от одного и того же пароля (для  проверки Личфилд выбрал слово foo), но в разное время. При этом оказалось, что результаты действительно различаются - то есть, к хэшу пароля добавляется  случайное значение, которое генерируется в зависимости от времени суток  и позволяет замаскировать одинаковые по написанию пароли. Далее Личфилд  проанализировал механизм генерации  шума, который представляет собой  целое число, получаемое в результате объединения двух псевдослучайных  чисел, которые, в свою очередь, генерируются, исходя из системного времени.

       Сведения  о механизме создания шума уже  облегчают взлом паролей, однако дальнейшие изыскания показали, что  в система хранения паролей еще  более уязвима. Как оказалось, вводимый пользователем пароль сначала переводится  в формат unicode, затем к нему добавляется  шум, а после этого осуществляется хэширование пароля. Однако в SQL Server хранится не одна, а две версии пароля. Первая из них зависит от регистра символов, а вторая состоит исключительно  из символов в верхнем регистре. При этом к обеим версиям пароля добавляется одинаковый шум. Таким  образом, зная механизм генерации шума можно простым перебором слов подобрать пароль в верхнем регистре - для этого требуется значительно  меньше ресурсов, чем при подборе  пароля, чувствительного к регистру - после чего подбор последнего становится тривиальной задачей.

       Для демонстрации обнаруженной уязвимости Литчфилд написал простую программу  на Си, которая вначале хэширует все имеющиеся в ее распоряжении слова, сравнивая ее с хранящимся в SQL Server хэшем пароля в верхнем  регистре. На компьютере с процессором Pentium III с частотой 1 ГГц и 256 Мб ОЗУ  программа за две секунды перебирает 200 000 слов.

       Обзор уязвимостей с наглядными примерами

       Стало модным хранить информацию в БД - от сообщений на попсовых форумах  до генетических кодов новейших белковых соединений. Понятно, что для хакеров  такие базы являются предметом страстного желания и возможностью поправить  свое материальное положение. А чтобы  встать на защиту СУБД, надо понимать основные приемы ее взломщика.

       Несмотря  на то что SQL-сервер находится за брандмауэром и принимает подключения только с доверенных машин, стащить важную информацию с него не так уж и  сложно. Более того, для этого  даже не нужно быть суперхакером, достаточно получить доступ к одному серверу  из локальной сети, и данные окажутся в преступных руках. Если, конечно, администратор  не уделил серверу особого внимания.

       Парольная проблема

       Чаще  всего взлом СУБД происходит из-за "плохого" пароля или из-за его  полного отсутствия. Но даже если он и существует, взломать БД для хакера не составит особого труда. Чтобы  ты в полной мере осознал проблему, приведем ряд примеров-взломов (от простого к сложному).

       1. Как-то раз хакер баловался  и сканировал nmap’ом какую-то русскую  подсеть в зоне *.rose.ru, в которой  находились серверы одного крупного  хостера. Сканер записал в лог  информацию об основных сервисах  в этой подсети. На трех адресах  (из 120) вертелись демоны MySQL. Хакеру  стало интересно, какая информация  хранится в этих СУБД. Он набрал  в шелле команду "mysql –h host –u root", и... сервис сказал, что с  его хоста не разрешено соединяться  с базой. Тогда хакер попробовал  другой хост, и... его пустили внутрь! Поразительно, но админ даже не  удосужился установить пароль  на вход. Кстати, информация была  не такой уж и профанской: в  БД хранились сведения о концертах  каких-то московских музыкальных  групп. Однако хакер ничего  не стал изменять, а просто  создал дополнительную базу с  названием hack :). Через пару дней  администратор ее заметил и  взялся за ум.

       2. Поздним вечером другой хакер  сканировал на различные сервисы  буржуйскую подсеть (хакеры вообще  любят сканировать порты) Windows'овским  сканером LanGuard. Просмотрев его отчет  по диагонали, он, к своей радости,  обнаружил два хоста с открытым  портом 1433. Это означало, что на  сервере крутился небезызвестный MS SQL. Ситуация похожа на предыдущий  случай. Первый демон не пустил  в гости, а второй поддался. Только вместо логина root хакер  использовал учетную запись sa с  пустым паролем. В базе хранился  каталог кредитных карт одного  крупного интернет-магазина. По-видимому, админ решил поднять бэкап-сервер  и не позаботился о защите.

       3. Подобным образом некий хакер  несколько раз проникал на Windows'овские mysqld. Дело в том, что в ранних  версиях разработчики забили  на аутентификацию в Win32-сервисах. Действительно, даже при грамотной  настройке сервис пускал абсолютно  всех под любым именем пользователя  без пароля :). Как-то раз, благодаря  этому, хакеру удалось дефейснуть  один популярный форум в локальной  сети (правда, потом получил подзатыльник  от администратора). Поэтому обязательно  проверяй безопасность сервиса,  если он крутится на Windows.

       Прицел  на MySQL

       Большинство ценных баз данных хранятся в СУБД под названием MySQL. По правилам безопасности этот демон должен быть установлен на *nix-like-системах на отдельно взятом сервере. Но часто происходит так, что все  сервисы (включая mysqld) вертятся на одной  машине, обычно ради экономии денег. Отсюда возможности взлома MySQL. Ниже приводим три примера из жизни, чтобы показать проблему наглядно.

       Пример 1: Root - спаситель

       Рассмотрим  один из типичных случаев взлома БД. Однажды некий хакер нашел  сервер, на котором крутился бажный mod_php. Через пару часов эксплойт 7350fun предоставил ему шелл-доступ к  машине. Быстро залив хороший backdoor, хакер зашел по телнету на порт 31337 ;), затем добил сервер известным  эксплойтом для ядерной баги ptrace (не стоит говорить про то, как  администраторы патчат ядра) и получил  рутовые права.

       Помимо web-сервера, на машине располагался MySQL. По всем правилам порт 3306 был зафильтрован файрволом, на сервисе стоял сложный  пароль и запрет на вход с посторонних  машин. Однако mod_php и дырявое ядро создали все условия для хищения  данных, лежащих в MySQL. Даже без знания заветного пароля хакер мог зайти  в СУБД. Ему даже не пришлось копировать таблицы на свой винчестер и извращаться  с заменой некоторых файлов. Он просто убил процесс mysqld, а затем  запустил его с ключиком --skip-grant-tables. Оставалось лишь обратиться к БД под  суперпользователем, и сервис впустил  хакера без запроса пароля! Бережно  скопировав нужные таблицы, хакер перезапустил демон в обычном режиме и удалился с сервера. Вся грязная работа была выполнена в кратчайшие сроки :). А в таблицах были пароли клиентов на раскрученный интернет-магазин...

       Пример 2: Поиск пароля

       Как-то раз в аську к некому хакеру постучался его друг и стал слезно умолять достать пароль одного недруга  на форум, чтобы отправить несколько  нецензурных сообщений от его  имени. Работа была простая, взломщик даже нашел баг в www-скрипте, позволяющему выполнять команды на сервере. Хакер  залил backdoor и забрался в консоль. К сожалению, на сервере стояла новенькая FreeBSD, для которой не существует хороших  локальных эксплойтов. Следовательно, прием с перезапуском mysqld тут  не прокатит. СУБД и web-сервер находились на одной машине, а хакер был  наделен правами nobody. В таком положении  ему требовалось найти конфиг от форума, что он успешно сделал с помощью команды "locate config.inc.php". В конфигурационном файле находилась учетная запись на сервис MySQL. Последняя  команда "mysql –uuser –ppassword –e ‘select password from users where username=’user’’ forum" выдала хакеру зашифрованный пароль пользователя. Оставалось только расшифровать пароль с помощью Md5Inside (http://inattack.ru/program/25) или другого брутфорсера.

       Здесь же уместен другой случай взлома MySQL. Однажды некому хакеру посчастливилось  подобрать пароль одного пользователя на раскрученном хостинге. Его права  были урезаны по самые уши, даже компилятор не запускался. Тогда хакеру пришло в голову выполнить команду "find / -name *history". И что ты думаешь? Он нашел целых пять читабельных  файлов .mysql_history. В них, конечно же, была строчка с паролем доступа  в незашифрованном виде. Таким  вот образом хакер получил  доступ к пяти таблицам MySQL. Правда, информация там не была особо ценной, в основном аккаунты к форуму или  к free email-сервису...

       Пример 3: Атака эксплойтом

       Не  так давно для MySQL появился рабочий  эксплойт. Суть его в том, что пользователь может отправить сложный пароль, переполнив буфер на серверной стороне. В итоге сервис авторизует клиента  даже в том случае, если админ  устанавливал сложнейший пароль. Обидно, но данный баг реально работает лишь в третьей версии mysqld. Но полгода  назад (аккурат после выхода эксплойта) хакеры здорово поглумились над  демонами. Через несколько дней после  выхода эксплойта кто-то переделал MySQL-клиент и выложил его в public-источник. С виду это обычный бинарник, но на самом деле в него зашит вышеописанный  эксплойт. С его помощью можно  быстро проверить хост на уязвимость. Достаточно соединиться с сервером без указания пароля и, если версия сервиса устаревшая, тебя пустят внутрь.

       Помимо  этого эксплойта, существуют и другие. Однако рассказывать про них не имеет  смысла, потому что сейчас ты уже  не найдешь дырявые версии. А пару лет назад была возможность не только проникнуть в СУБД, но и выполнять  команды на сервере с правами  суперпользователя.

       Кстати, о командах. Через MySQL невозможно выполнить  запрос, который бы интерпретировался  каким-либо шеллом. Однако никто не запретит тебе создать файл с произвольными  данными, владельцем которого будет  пользователь, под которым ты зашел  в СУБД. Для этого выполняется нехитрый SQL-запрос: "SELECT * FROM table INTO OUTFILE ‘/home/user/blah.txt’". Если файл blah.txt существует, он успешно перезапишется. В некоторых целях этот трюк может быть очень полезен, особенно если зайти под рутовым аккаунтом.

       Атака MS SQL

       Вторая  по популярности СУБД носит гордое имя MS SQL и используется на многих раскрученных (чаще всего зарубежных) серверах. Несмотря на то, что для этого сервиса  вышло целых три сервиспака, баги в творении MicroSoft были, есть и будут :).

       Самый первый баг, о котором пишут уже  много лет, заключается в недостаточной  настройке MS SQL. Действительно, некоторые  админы устанавливают сервер, видят, что все работает, и экспортируют ценную БД. Особо одаренные администраторы даже не задумываются, что вход в  СУБД через пользователя sa с пустым паролем - не совсем безопасная идея :). Вспоминается случай, когда пару лет  назад некий хакер проверял защиту одного зарубежного интернет-магазина, торгующего постерами. На главном сервере  была установлена Windows с седьмым MS SQL. Факт отсутствия файрвола очень заинтриговал хакера. Он нашел в интернете клиент isql.exe, с помощью которого осуществляется обращение к СУБД, а затем попробовал залогиниться под пользователем Administrator. Хакера послали куда подальше, но он не стал отчаиваться, а просто сменил логин на sa. И... побывал внутри системы :).

       Получить  доступ к MS SQL значит завладеть всей системой. В отличие отсвоих конкурентов, разработчики этой СУБД включили некоторые  функции, выполняющие системные  команды. Одна из них называется xp_cmdshell. Причем в ряде случаев никто не запрещает выполнять внешние  запросы даже под гостевым логином (если администратор не уделил должное  внимание настройке СУБД). К примеру, однажды хакер баловался одним  сканером Windows, определяющим возможность  гостевого входа. Примечательно, что  хакерское творение реализовано  в виде единого bat-файла, который  быстро сканирует заданную подсеть  на наличие гостевого входа в MS SQL. Чтобы проверить сеть на уязвимость, необходимо положить в каталог с  файлом scan.bat (www.securitylab.ru/35715.html) клиент isql.exe, а затем запустить сканер с параметром адреса сети (192.168.0.1/24, например). Сначала bat-файл проверит наличие MS SQL, затем попробует залогиниться под гвестом, а после этого попытается выполнить командный запрос через встроенную функцию xp_cmdshell. Полгода назад этот способ работал на ура :).