Стоит прочитать: обзор книги Александра Полякова «Безопасность Oracle глазами аудитора. Нападение и защита»

Игорь Буслов

Директор Exiting Vim, амбассадор всероссийского конкурса для IT-специалистов «Цифровой прорыв» — флагманского проекта президентской платформы «Россия — страна возможностей».

Автор книги «Безопасность Oracle глазами аудитора. Нападение и защита» Александр Поляков — ведущий аудитор по информационной безопасности консалтинговой ИТ-компании.

Изначально я отнёсся к книге с недоверием. Добавил в корзину, чтобы получить бесплатную доставку на остальной заказ. Книга пылилась на полке до тех пор, пока я не взял её почитать в самолет. Выяснилось, что она достойна внимания гораздо больше, чем могло показаться на первый скептический взгляд.

Постановка проблемы в «Безопасность Oracle глазами аудитора. Нападение и защита»

У большинства разработчиков и администраторов нет полной картины о работе СУБД. Поэтому может возникнуть ложная уверенность в том, что информационная система полностью неуязвима. Отсюда — халатность в обращении с данными компании и пренебрежение ко внешним угрозам.

В книге на примере Oracle версий 9i-11gR1 и Oracle Application Server (сейчас его заменяет Weblogic) автор рассказывает о разнообразии возможных атак на СУБД на всех уровнях модели ISO/OSI. Он рассматривает уязвимости служб СУБД Oracle, недостатки хранимых процедур в пакетах DBMS, проблемы системы разграничения прав доступа, авторизации и другие нюансы информационной безопасности.

Кроме того, в «Безопасность Oracle глазами аудитора. Нападение и защита» отражена противоположная сторона обратной совместимости в долгоживущих программных продуктах. Так, в Oracle совместимость с устаревшими клиентскими ПО достигается за счёт устаревших протоколов, которые не отвечают современным требованиям информационной безопасности. Как итог, хакеры атакуют на понижение версии, в частности, службу Listener. Похожая проблема может быть и в алгоритме хеширования паролей пользователей.

Также автор показывает: закрытый код не гарантирует, что злоумышленник не обнаружит уязвимости. И опровергает рассуждения про открытый исходный код: если код посмотрело множество людей — он безопасен. Зачастую это не так.

Важно, что Александр Поляков не просто перечисляет возможные угрозы, а показывает ход мыслей хакера при атаке на информационную систему. Оказывается, что даже у дорогих и качественных систем есть проблемы в самых неожиданных местах и уязвимости «нулевого дня».

Как ищут уязвимости

Метод поиска уязвимостей «нулевого дня» показался мне самым интересным из описанных в книге. Если известно, на какой платформе работает система, всегда можно перейти на сайт разработчика. А на сайтах крупных программных продуктов или в их Git-репозиториях принято публиковать changelog-и. В этом файле разработчик пишет об исправленных ошибках, новых функциях и других обновлениях. В том числе в части информационной безопасности.

Если заранее знать версию платформы атакуемой системы или график обновлений, можно увидеть, какие дыры безопасности исправили с момента последнего релиза. При этом, чем крупнее система, тем реже и менее значимо она обновляется.

Если это ПО с открытым исходным кодом, можно посмотреть конкретные изменения в свежей версии и найти места, где исправлены проблемы безопасности. И исходя из этого понять, в чём заключалась уязвимость и как её можно использовать. Производители зачастую оперативно закрывают проблемы с безопасностью, но пользователи обновляют свои программы не всегда своевременно.

В системах с закрытым исходным кодом публикуют только описание уязвимости, версию исправлений и интерфейс измененного объекта в ПО. Но даже этого достаточно, чтобы проанализировать потенциальные проблемы. При этом для злоумышленника неважно, какой тип системы. В обоих случаях у него уйдёт схожее количество времени на поиск проблем в безопасности.

Также автор рассмотрел такие вопросы, как скорость реакции вендора на обнаруженные уязвимости, оперативность их закрытия с приложенными примерами. Примечателен вывод о неудовлетворительности этих показателей, например, некоторые уязвимости не закрываются десятилетиями.

Типичная ошибка администратора

Чтобы получить от прочтения книги максимум пользы, нужны знания в области сетевого администрирования, администрирования баз данных, разработки приложений и хранимых процедур. А также базовое понимание принципов информационной безопасности и опыт работы с СУБД Oracle или аналогичными.

Даже несмотря на то, что представленные уязвимости уже устарели и частично потеряли свою актуальность в СУБД Oracle, они могут оказаться в других системах. Например, MySQL сейчас развивается той же командой, что и Oracle. А PostgreSQL вдохновлялся гигантом по многим вопросам. Поэтому мысли автора дают большое поле для рассуждений и поиска уязвимостей в других системах.