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

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

Скрипт ces.pl поставляется с базой. Рекомендую найти новый список уязвимых скриптов либо составить свой.

Ищи новые авторутеры на http://packetstormsecurity.nl, а также на http://security.nnov.ru.

Будь осторожен! Некоторые авторутеры отсылают информацию не только тебе, но и своему автору :).

Данные – это основа всего. Тут и номера кредитных карт, и личная информация пользователей, и сведения об угнанных машинах. Содержимое чатов и форумов тоже хранится в БД. Проникновение в корпоративную (военную, правительственную) базу данных – самое худшее, что только может случиться с компанией. Поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются 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'».