Спецвыпуск журнала «Хакер» #47, октябрь 2004 г.

Размещать сервер базы данных на одном узле с Web-сервером категорически недопустимо не только по техническим, но и по юридическим соображениям (законодательства многих стран диктуют свою политику обращения с конфиденциальными данными, особенно если эти данные хранят информацию о клиентах компании). Тем не менее, совмещение сервера БД с Web-сервером довольно обычно из-за экономии. Захватив управление Web-сервером (а практически ни одному Web-серверу не удалось избежать ошибок переполнения буфера и прочих дыр), атакующий получит доступ ко всем данным, хранящимся в базе!

Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера, позволяющие атакующему захватывать управление удаленной машиной с наследованием администраторских привилегий. Яркий пример тому – уязвимость, обнаруженная в сервере MS SQL и ставшая причиной крупной вирусной эпидемии. Не избежал этой участи и MySQL. Версия 3.23.31 падала на запросах типа select a.AAAAAAA…AAAAAA.b, а на соответствующим образом подготовленных строках – передавала управление на shell-код, причем атаку можно было осуществить и через браузер, передав в URL уязвимому для SQL-инъекции скрипту что-то типа: script.php?index=a.(shell-code).b.

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

Нестойкость шифрования паролей

Пароли, регламентирующие доступ к базе данных, ни при каких обстоятельствах не должны передаваться открытым текстом по сети. Вместо пароля передается его хэш, зашифрованный случайно сгенерированной последовательностью байт и называемый проверочной строкой (check-string). Короче говоря, реализуется классическая схема аутентификации, устойчивая к перехвату информации и при этом не допускающая ни подбора пароля, ни его декодирования, во всяком случае, в теории.

На практике же во многих серверах БД обнаруживаются грубые ошибки проектирования. Взять хотя бы MySQL версии 3.x. Хэш-функция, используемая для «сворачивания» пароля, возвращает 64-разрядную кодированную последовательность, в то время как длина случайно генерируемой строки (random-string) составляет всего лишь 40 бит. Как следствие, шифрование не полностью удаляет всю избыточную информацию и анализ большого количества перехваченных check-string/random-string позволяет восстановить исходный хэш (пароль восстанавливать не требуется, так как для аутентификации он не нужен).

В несколько упрощенном виде процедура шифрования выглядит так:

ЛИСТИНГ

// P1/P2 – 4 левых/правый байта парольного хэша соответственно

// C1/C2 – 4 левых/правый байта random-string соответственно

seed1 = P1 ^ C1;

seed2 = P2 ^ C2 ;

for(i = 1; i <= 8; i++)

{

seed1 = seed1 + (3*seed2);

seed2 = seed1 + seed2 + 33;

r[i] = floor((seed1/n)*31) + 64;

}

seed1 = seed1+(3*seed2);

seed2 = seed1+seed2+33;

r[9] = floor((seed1/n)*31);

checksum =(r[1]^r[9] || r[2]^r[9] || r[7]^r[9] || r[8]^r[9]);

Нестойкие механизмы аутентификации встречались и в других серверах, однако к настоящему моменту практически все они давно ликвидированы.

Перехват пароля

Для авторизации на сайте в подавляющем большинстве случаев используются нестойкие механизмы аутентификации, разработанные непосредственно самим Web-мастером и передающие пароль в открытом виде. Как следствие, он может быть легко перехвачен злоумышленником, забросившим на одну из машин внутренней сети или DMZ-зоны снифер или создавшим точную копию атакуемого Web-сервера, для заманивания доверчивых пользователей – тогда логин и пароль они введут сами.

Многие сервера хранят информацию об авторизации в кукисах (cookie), находящихся на машинах удаленных пользователей, и, вместо того чтобы ломиться на хорошо защищенный корпоративный сервер, взломщик может атаковать никем не охраняемые клиентские узлы. Главная трудность заключается в том, что их сетевые координаты наперед неизвестны и атакующему приходится тыкаться вслепую. Обычно эта проблема решается массированной рассылкой почтовой корреспонденции с троянизированным вложением внутри по многим адресам – если повезет, то среди пользователей, доверчиво запустивших трояна, окажется хотя бы один корпоративный клиент. Ну а извлечь куки – уже дело техники.

Некоторые серверы баз данных (в частности, ранние версии MS SQL), автоматически устанавливают пароль по умолчанию, предоставляющий полный доступ к базе и позволяющий делать с ней что угодно (у MS SQL этот пароль «sa»).

Навязывание запроса, или SQL-инъекция

Типичный сценарий взаимодействия с базой данных выглядит так: пользователь вводит некоторую информацию в поля запроса, оттуда ее извлекает специальный скрипт и преобразует в строку запроса к базе данных, передавая серверу ее на выполнение:

ЛИСТИНГ

$result = mysql_db_query(«database», "select * from userTable

where login = «$userLogin» and password = «$userPassword»);