Спецвыпуск журнала «Хакер» 47, октябрь 2004 г.
Шрифт:
Я уже упоминал выше о «продвинутых» эксплоитах, которые изредка мелькают на сайтах, посвященных компьютерной безопасности. Они позволяют не только порутать сервер, но и просканить диапазон адресов на баг. К сожалению, обычно подобные вещи ориентированы на Win-уязвимости, поэтому ты наверняка вообще не слышал об автоэксплоитах для Linux.
Тем не менее, подобные вещи есть. Одна из них называется linux_lprngautorooter. Этот эксплоит ориентирован на баг в lpr. Скомпилированный бинарник выполняет сканирование подсети, а затем атакует нужный
Обращаю твое внимание на то, что большинство подобных компактных авторутеров пишутся хакерами-энтузиастами. Поэтому ты без проблем можешь выдрать нужный код сканера из исходника и прикрутить его к другому эксплоиту.
На этом наше знакомство с программами, автоматизирующими поиск уязвимостей, завершается. Весь упомянутый софт ты можешь скачать сДаже если какой-либо баг, реализованный в авторутерах или автоэксплоитах, уже потерял актуальность, никто не мешает тебе попробовать адаптировать их под новые уязвимости.
Но не всегда удобно пользоваться Unix-консолью (элитные чуваки сидят под любимой Виндой, а *nix видят только в окошке Virtual PC :)). Многие люди предпочитают интеллектуальные сканеры под Винду. К примеру, такие сканеры способны не только определить сервис на открытом порте, но и обнаружить уязвимость в сервисе, привести ссылку на багтрак! Самый популярный в рунете среди них, пожалуй, XSpider.
Этот сканер ведет проверку на многие уязвимости и в конце процесса выводит подробный отчет. Поддерживает эвристические методы определения версии демонов. Журнал пригодится не только бдительному админу сервера, но и хакеру, который только и ждет свежей инфы о багах. Ознакомься с реальными возможностями сканера, стянув его по ссылкеК сожалению, проект уже давно является коммерческим :(, но демо-версия вполне юзабельна.
Обладая некоторым опытом программинга, ты не затруднишься модифицировать чужой авторутер под свои нужды (то есть под свой эксплоит).
Скрипт ces.pl поставляется с базой. Рекомендую найти новый список уязвимых скриптов либо составить свой.
Ищи новые авторутеры наа также на http://security.nnov.ru.
Будь осторожен! Некоторые авторутеры отсылают информацию не только тебе, но и своему автору :).
База данных под прицелом / Взлом БД
Крис Касперски aka мыщъх
Данные – это основа всего. Тут и номера кредитных карт, и личная информация пользователей, и сведения об угнанных машинах. Содержимое чатов и форумов тоже хранится в БД. Проникновение в корпоративную (военную, правительственную) базу данных – самое худшее, что только может случиться с компанией. Поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются 12-летними любителями командной строки без особых усилий.
Сервера баз данных относятся к наиболее критичным информационным ресурсам и потому должны размещаться на выделенном сервере, расположенном во внутренней корпоративной сети, огражденной маршрутизатором
Размещать сервер базы данных на одном узле с 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);