база данных под прицелом
крис касперски ака мыщъх no-email
данные это основа всего. это и номера кредитных карт, и личная информация пользователей, и сведениях об угнанных машинах. содержимое чатов и форумов тоже хранится в БД. проникновение в корпоративную (военную, правительственную) базу данных – самое худшее, что только может случиться с компанией. поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются даже 12-летными любителями командной строки без особых усилий.
введение
Сервера баз данных относятся к наиболее критичным информационным ресурсам и потому они должны размещаться на выделенном сервере, расположенным во внутренней корпоративной сети, огражденной маршрутизатором или брандмауэром. Взаимодействие с базами данных обычно осуществляется через WEB-сервер, находящийся внутри DMZ-зоны (см. статью о брандмауэрах).
Размещать сервер базы данных на одном узле с WEB-сервером категорически недопустимо не только по техническим, но и юридическим соображениям (законодательства многих стран диктуют свою политику обращения с конфиденциальными данными, особенно если эти данные хранят информацию о клиентах компании). Тем не менее, совмещение сервера БД с WEB-сервером – обычное дело, которым сегодня никого не удивишь. Экономия… мать ее так! Захватив управление WEB-сервером (а практически ни одному WEB-серверу не удалось избежать ошибок переполнения буфера и прочих дыр), атакующий получит доступ ко всем данным, хранящимся в базе!
Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования среди которых доминируют переполняющиеся буфера, многие из которых позволяют атакующему захватывать управление удаленной машиной с наследованием администраторских привилегий. Яркий пример тому – уязвимость, обнаруженная в сервере MS SQL и ставшая причиной крупной вирусной эпидемии. Не избежал этой участи и MySQL. Версия 3.23.31 падала на запросах типа select a.AAAAAAA…AAAAAA.b, а на соответствующим образом подготовленных строках – передавала управление на shell-код, причем атаку можно было осуществить и через браузер, передав в URL что-то типа: 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]);
Листинг 1 шифрование парольного хеша случайной строкой
Нестойкие механизмы аутентификации встречались и в других серверах, однако, к настоящему моменту практически все они давно ликвидированы.
перехват пароля
Для авторизации на сайте в подавляющем большинстве случаев используются нестойкие механизмы аутентификации, разработанные непосредственно самим WEB-мастером, и передающие пароль в открытом виде. Как следствие – он может быть легко перехвачен злоумышленником, забросившим на одну из машин внутренней сети и/или DMZ-зоны сниффер, или создавшим точную копию атакуемого WEB-сервера, для заманивания доверчивых пользователей – тогда логин и пароль они введут сами.
Многие сервера хранят информацию об авторизации в куках (cookie), находящихся на машинах удаленных пользователей, и вместо того, чтобы ломиться на хорошо защищенный корпоративный сервер, хакер может атаковать никем не охраняемые клиентские узлы. Главная трудность заключается в том, что их сетевые
Читать далее...