компанией. Поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются 12-летними любителями командной строки без особых усилий.
Сервера баз данных относятся к наиболее критичным информационным ресурсам и потому должны размещаться на выделенном сервере, расположенном во внутренней корпоративной сети, огражденной маршрутизатором или брандмауэром. Взаимодействие с базами данных обычно осуществляется через Web- сервер, находящийся внутри DMZ-зоны.
Размещать сервер базы данных на одном узле с 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»).
Типичный сценарий взаимодействия с базой данных выглядит так: пользователь вводит некоторую информацию в поля запроса, оттуда ее извлекает специальный скрипт и преобразует в строку запроса к базе данных, передавая серверу ее на выполнение:
ЛИСТИНГ
$result = mysql_db_query(«database», 'select * from userTable
where login = «$userLogin» and password = «$userPassword»);
Здесь $userlogin – переменная, содержащая имя пользователя, а $userPassword – его пароль. Обрати внимание, что обе переменные размещены внутри текстовой строки, окаймленной кавычками. Это необычно для Си, но типично для интерпретируемых языков вроде Perl и PHP. Подобный механизм называется интерполяцией строк и позволяет автоматически подставлять вместо переменной ее фактическое значение.
Допустим, пользователь введет KPNC/passwd. Тогда строка запроса будет выглядеть так: «select * from userTable where login = 'KPNC' and password = 'passwd'».
Если такой логин/пароль действительно присутствует в базе, функция сообщает идентификатор результата, в противном случае возвращается FALSE.
Хочешь войти в систему под именем другого пользователя, зная его логин, но не зная пароль? Воспользуйся тем, что механизм интерполяции позволяет атакующему воздействовать на строку запроса, видоизменяя ее по своему усмотрению. Посмотрим, что произойдет, если вместо пароля ввести последовательность «fuck' or '1'= '1» (без кавычек): «select * from userTable where login = 'KPNC' and
