Уязвимости Windows. Взгляд изнутри. Часть 1

Уязвимости Windows. Взгляд изнутри

Часть 1

О.М. Бойцев
эксперт

Не секрет, что в настоящее время на большинстве подключенных к Интернету машин установлены ОС семейства Windows. В общем, оно и закономерно, учитывая популярность этой "Оси". Миллионы юзеров, многие конторы, а порой и достаточно серьезные организации небезосновательно используют детище Билла Гейтса. Дружелюбный интерфейс, подавляющее большинство софта, заточенного под эту ОСь, какая-никакая служба технической поддержки - все это делает Windows вездесущей (не без помощи монопольной политики, разумеется). Но у каждой медали есть две стороны...

ЗАХОДЯ на очередной сайт "vulner"-тематики (www.sans.org, www. security-lab, ru, www.eeye.com и т.д.), приходится наблюдать огромное множество информации о багах Windows. Число таких багов (уязвимостей, дырок) достигает сотен, и разобраться во всей этой каше бывает нелегко. В рамках данной статьи я постараюсь сконцентрировать внимание читателя на главном. А именно: от чего надо защищаться в первую очередь и какие ошибки используются хакерами чаще всего.

Первое, на что следует обратить внимание, - это установка ОС и софта по умолчанию. Не секрет, что настройки, заданные фирмой-производителем, надо менять как можно скорее. Это относится и к Windows и даже к пресловутой ОС Linux. Именно настройки по дефолту (от англ. default - значение по умолчанию) как раз и являются лакомым кусочком для тех, кто готов поживиться за чужой счет, ну или просто порезвиться... Из ярких иллюстраций вышесказанного прежде всего приходят на ум "Администратор" в качестве логина и пустой пароль, ссылка в корневой директории сервера (/admin), дающая полный доступ к Web-сайту, открытый 139-й порт, позволяющий инвентаризировать ресурсы чужой сети, ну и, конечно же, расшаренные по умолчанию диски - c$, d$ и т.д. (см. рис. 1). Продолжая разговор о "шарах", конечно же, следует упомянуть общие ресурсы ADMIN$ и пресловутый IPC$, о котором, впрочем, отдельный разговор далее.

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

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

Классика жанра: переполнение буфера

Переполнение буфера (buffer overflows) на сегодняшний день является самой распространенной уязвимостью в области безопасности ПО. Причем баг этот юзают все кому не лень, начиная с червей, которые успешно "дерут" различные "оконные" службы (CodeRed, Slammer, Lovesan и т.д.), и заканчивая "злоадминами", разочаровавшимися в мирных путях заработка и переключивших свое внимание на DDoS.

Первая атака с применением данной уязвимости использовалась в вирусе-черве Морриса в 1988 г. Напомню, что червь, созданный студентом Корнельского университета, спустя всего 5 часов после активации умудрился инфицировать около 6000 компьютеров - по сегодняшним меркам не очень много, но не будем забывать про год! Среди пострадавших -Агентство национальной безопасности и стратегического авиационного командования США, лаборатории NASA (в частности, в вычислительном центре NASA в Хьюстоне червь попытался взять под контроль систему запуска кораблей многоразового использования Space Shuttle). Помимо вышеперечисленного, червь успел удовлетворить свои гастрономические пристрастия исследовательским центром ВМС США, Калифорнийским НИИ, крупнейшими университетами страны, а также рядом военных баз, клиник и частных компаний. С тех пор число багов на переполнение буфера только увеличилось. В настоящее время можно смело говорить, что уязвимости, связанные с переполнением буфера, являются превалирующими при удаленных атаках, когда злонамеренный пользователь получает частичный или полный контроль над атакуемым хостом. Анализ атак и обнаруженных уязвимостей последних лет показывает, что данная проблема является первостепенной и ее актуальность с каждым днем растет. Достаточно ознакомиться с бюллетенями безопасности Microsoft, отчетами Bugtraq и контор типа SANS, чтобы окончательно убедиться - абсолютное большинство уязвимостей приходится на переполнение буфера. Уязвимость подобного рода в основном позволяет осуществлять выполнение произвольного кода на машине жертвы и отказ в обслуживании. Хотя на самом деле возможности данного бага для осуществления атак куда более разнообразны. Существует даже целая классификация атак на переполнение буфера (см. таблицу 1).

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

Предположим, что некая процедура для хранения данных использует буфер. Буфер находится в стеке (в определенной области памяти, которая используется во время выполнения программы). Представим в стеке несколько переменных и адрес возврата функции - число, показывающее, куда передать управление после выполнения текущей процедуры. Каким образом программа записывает данные в N-й байт буфера? К адресу начала буфера прибавляется число N. Полученный результат и есть адрес, по которому будут записаны данные. Если размер буфера равен 1024 байта, а мы попытаемся "втиснуть" в него больше, то некоторая часть данных попадет в другую область памяти. Может произойти так, что адрес возврата функции затеряется, и как следствие, программа выполнит не тот код, на который указывал предыдущий адрес возврата.

Кстати,для того чтобы собственными глазами увидеть переполнение буфера, вовсе не обязательно записываться в орды "кулхацкеров". Подобное может увидеть самый обычный пользователь ПК на примере сбоя в работе какого-либо приложения.

Если атакующий сознательно переполняет буфер, то возможно выполнение практически любого кода. Данная возможность используется не только для выполнения произвольного кода, но и с успехом может использоваться для создания DOS-атак. Простейший пример, реализующий вышеописанный баг, - создание заведомо длинных строк в некоторых протоколах (SMTP, FTP, HTTP и т.д.). Запрос к серверу, сформированный с использованием недопустимого размера какого-либо строкового параметра при наличии переполнения, приводит к приостановке нормальной работы обслуживающего сервера:

>ftp vaviorka.com

Connected to vaviorka.com.

220 VAVIORKA Microsoft FTP Service (Version 4.0).

User (poor. vaviorka .com:(none)): ftp

331 Anonymous access allowed, send identity (e-mail name) as password.

Password:

230 Anonymous user logged in.

ftp>Is AAAAAAAAAAAAAAA-AAAAAAAAAAAAAAAAAAAA-AAAAAAAAAAAAAAAAAAAA- AAAAAAAAAAAAAAAAAAAAA-AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA;

200 PORT command successful.

150 Opening ASCII mode data connection for file list.

-> ftp: get :connection reset by peer.