Классификация уязвимостей программного обеспечения по типу по. Уязвимость — это что такое? Какие методы борьбы для защиты ПК

27.03.2019

Уязвимости современных ОС

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

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

Количество обнаруженных уязвимостей

Источник: NIST

* - за 7 месяцев

По данным mi2g, ущерб от различных видов атак достиг в 2004 г. $150 млрд., что примерно в два раза больше, чем в годом ранее. По мнению экспертов, ежегодно хакерами взламывается до 90% сетей предприятий

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

Основополагающие посылы защиты информации

Текущее состояние защищенности системы может иметь одно из двух состояний: полностью защищена, либо полностью незащищена. Переход системы из одного состояние в другое осуществляется при обнаружении хотя бы одной уязвимости защиты, возвращение в исходное состояние - при устранении известной уязвимости. Другими словами, рассуждения о степени защищенности ОС неуместны - любая обнаруженная в системе уязвимость делает ее полностью незащищенной.

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

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

Считая, что обнаружение каналов НСД к информации (уязвимостей) - (или в терминологии теории надежности - отказов системы защиты), и процесс их устранения являются пуассоновскими потоками (соответственно, с интенсивностями λ и μ ), можно оценить с использованием простейшей формулы:

Ρ=1-λ/μ

Уязвимости устраняются по мере их обнаружения, иначе нельзя обеспечить высокую интенсивность исправлений. Надежность системы защиты - вероятность того, что в любой момент времени система защищена (определяется тем условием, что число не устраненных уязвимостей равно 0)

Вероятность защищенности системы

Интенсивность отказов		1 в год	2 в год	5 в год	10 в год
Восстановление	1 нед.
	2 нед.
	1 мес.
	2 мес.
	3 мес.
	4 мес.

Рассмотрим, например, значение “0,98” (лучшее значение надежности системы защиты в таблице). Оно достигается в том случае, если в среднем обнаруживается одна уязвимость в год при среднем времени ее восстановления разработчиком, составляющим одну неделю. При этом вероятность того, что в любой момент времени система защищена, равна 0,98, т.е. в любой момент времени с вероятностью 0,02 систему защиты можно считать отказавшей. Для современных систем это практически идеальная ситуация. Сегодня во многих современных системных средствах за год находится отнюдь не одна уязвимость, а продолжительность устранения уязвимости разработчиком может составлять несколько месяцев.

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

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

Угроза - это потенциально возможное событие, явление или процесс, которое посредством воздействия на компоненты информационной системы может привести к нанесению ущерба

Уязвимость - это любая характеристика или свойство информационной системы, использование которой нарушителем может привести к реализации угрозы.

Атака - это любое действие нарушителя, которое приводит к реализации угрозы путём использования уязвимостей информационной системы.

Классификация уязвимостей

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

Источники возникновения уязвимостей

Часть уязвимостей закладывается ещё на этапе проектирования. В качестве примера можно привести сервис TELNET , в котором имя пользователя и пароль передаются по сети в открытом виде. Это явный недостаток, заложенный на этапе проектирования. Некоторые уязвимости подобного рода трудно назвать недостатками, скорее это особенности проектирования. Например, особенность сетей Ethernet - общая среда. передачи.

Другая часть уязвимостей возникает на этапе реализации (программирования). К таким уязвимостям относятся, например, ошибки программирования стека TCP/IP приводящие к отказу в обслуживании. Сюда следует отнести и ошибки при написании приложений, приводящие к переполнению буфера.

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

Классификация уязвимостей по уровню в инфраструктуре АС

Следующий вариант классификации - по уровню информационной структуры организации. Это наиболее наглядный вариант классификации, т. к. он показывает, что конкретно уязвимо.

К уровню сети относятся уязвимости сетевых протоколов - стека TCP/IP, протоколов NetBEUI , IPX / SPX .

Уровень операционной системы охватывает уязвимости Windows , UNIX , Novell и т. д., т.е. конкретной ОС.

На уровне баз данных находятся уязвимости конкретных СУБД - Oracle , MSSQL , Sybase . Этот уровень рассматривается отдельно, потому что базы данных, как правило, являются неотъемлемой частью любой компании.

К уровню приложений относятся уязвимости программного обеспечения WEB , SMTP серверов и т. п.

Классификация уязвимостей по степени риска

Этот вариант классификации достаточно условный, однако, если придерживаться взгляда компании Internet Security Systems , можно выделить три уровня риска:

Высокий уровень риска

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

Средний уровень риска

Уязвимости, позволяющие атакующему получить информацию, которая с высокой степенью вероятности позволит получить доступ к узлу.

Низкий уровень риска

Уязвимости, позволяющие злоумышленнику осуществлять сбор критической информации о системе.

Информацию об известных обнаруженных уязвимостях можно найти на сайтах, таких как:

Reference: BID: 1312

Reference: XF:fw1-packet-fragment-dos

Подробнее узнать о CVE и получить список CVE entry можно по адресу: http://cve .mitre .org /cve .

Классификация атак

Также как и уязвимости, атаки можно классифицировать по различным признакам. Далее приведено несколько вариантов такой классификации.

Классификация атак по целям

Производя атаку, злоумышленник преследует определённые цели. В общем случае это могут быть:

(отказ в обслуживании)

Получение контроля над объектом атаки

Модификация и фальсификация данных

Классификация атак по мотивации действий

Этот перечень является классическим и относится не только к IP -сетям, но и к другим областям деятельности:

Случайность

Безответственность

Самоутверждение

Идейные соображения

Вандализм

Принуждение

Корыстный интерес

Местонахождение нарушителя

Следующий возможный вариант классификации атак - по местонахождению атакующего:

В одном сегменте с объектом атаки; . в разных сегментах с объектом атаки.

От взаимного расположения атакующего и жертвы зависит механизм реализации атаки. Как правило, осуществить межсегментную атаку бывает сложнее.

Механизмы реализации атак

Наиболее важный для понимания сути происходящего - это вариант классификации атак по механизмам их реализации:

Пассивное прослушивание

Пример: перехват трафика сетевого сегмента

подозрительная активность

Пример: сканирование портов (служб) объекта атаки, попытки подбора пароля

Пример: исчерпание ресурсов атакуемого узла или группы узлов, приводящее к снижению производительности (переполнение очереди запросов на соединение и т.п.)

Нарушение навигации (создание ложных объектов и маршрутов)

Пример: Изменение маршрута сетевых пакетов, таким образом, чтобы они проходили через хосты и маршрутизаторы нарушителя, изменение таблиц соответствия условных Internet -имен и IP -адресов (атаки на DNS ) и т.п.

Выведение из строя

Пример: посыпка пакетов определённого типа на атакуемый узел, приводящая к отказу узла или работающей на нём службы ( WinNuke и др.)

Запуск приложений на объекте атаки

Пример: выполнение враждебной программы в оперативной памяти объекта атаки (троянские кони, передача управления враждебной программе путём переполнения буфера, исполнение вредоносного мобильного кода на Java или ActiveX и др.)

Статистика по уязвимостям и атакам за 2000 год

Согласно данным компании Internet Security Systems за 2000 год, наиболее часто при проведении атак использовались следующие уязвимости:

1. Уязвимости, приводящие к отказу в обслуживании (Denial of Service)

2. Уязвимости системной политики (пользовательские бюджеты, пароли)

3. Уязвимости Microsoft Internet Information Server

4. Уязвимости СУБД

5. Уязвимости Web -приложений

6. Уязвимости электронной почты

7. Уязвимости сетевых файловых систем

8. Уязвимости протокола RPC

9. Уязвимости BIND

10. Уязвимости, связанные с переполнением буфера в Linux -приложениях

Примеры атак

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

Прослушивание трафика

Описание; Перехват и анализ трафика сетевого сегмента, основанный на возможности перевода сетевого адаптера в неселективный режим работы.

Цель: Получение конфиденциальной и критичной информации

Механизм реализации; Пассивное прослушивание

Используемые уязвимости; Основанная на общей среде передачи технология (Ethernet)

Недостаток проектирования. Передача конфиденциальной информации в открытом виде

Недостаток проектирования.

Сеть. Степень риска; Высокая

Термин "сниффер" («нюхач») впервые был использован компанией Network Associates в названии известного продукта " Sniffer (г) Network Analyzer ". В самом общем смысле, слово "сниффер" обозначает устройство, подключенное к компьютерной сети и записывающее весь ее трафик подобно телефонным "жучкам", записывающим телефонные разговоры. Однако чаще всего "сниффером" называют программу, запущенную на подключенном к сети узле и просматривающую весь трафик сетевого сегмента. Работа "сниффера" использует основной принцип технологии Ethernet - общую среду передачи. Это означает, что любое устройство, подключенное к сетевому сегменту, может слышать и принимать все сообщения, в том числе предназначенные не ему. Сетевые адаптеры Ethernet могут работать в двух режимах: селективном (non - promiscuous) и неселективном (promiscuous). В первом случае, принимаются только сообщения, предназначенные данному узлу. Фильтрация осуществляется на основе МАС-адреса фрейма. Во втором случае фильтрация не осуществляется и узел принимает все фреймы, передаваемые по сегменту 1.

Сканирование портов

Описание; Подключение к узлу и перебор портов из известного диапазона с целью выявления работающих на узле служб

Цель; Получение конфиденциальной и критичной информации Механизм реализации; Подозрительная активность

Используемые уязвимости; Ошибки обслуживания. Службы, неиспользуемые, но установленные и работающие.

Уровень информационной инфраструктуры: Сеть. Степень риска: Низкая

Атака SynFlood

Описание; Посылка большого числа запросов на установление TCP -соединения. Цель; Нарушение нормального функционирования объекта атаки Механизм реализации; Бесполезное расходование вычислительного ресурса

Используемые уязвимости: Особенности схемы установления соединения по протоколу TCP .

Уровень информационной инфраструктуры: Сеть. Степень риска; Высокая

В случае получения запроса на соединение система отвечает на пришедший SYN -пакет SYN / ACK -пакетом, переводит сессию в состояние SYN _ RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет АСК, соединение

1 Более подробно сетевые анализаторы и способы их обнаружения рассматриваются в курсе БТОЗ.

удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED (установлено).

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

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

Атака ARP - Spoofing

Описание: Добавление ложных записей в таблицу, использующуюся при работе протокола ARP

Цель: Нарушение нормального функционирования объекта атаки

Механизм реализации; Нарушение навигации

Используемые уязвимости; Недостаток проектирования протокола ARP

Уровень информационной инфраструктуры: Сеть

Степень риска; Высокая

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

Таким образом, нарушитель может отправить ответ, в котором указан MAC - адрес несуществующего или неработающего в данный момент узла, что приведёт к невозможности взаимодействия узла- «жертвы» с каким-либо узлом. Например, на следующем рисунке узел 223.1.2.1 не будет доступен с узла - объекта атаки после посылки нарушителем ложного ARP -ответа.

Атака IISDOS

Описание: Посылка некорректно построенного HTTP -запроса приводит к перерасходу ресурсов атакуемого WWW -с ep в epa

Цель: Нарушение нормального функционирования объекта атаки Механизм реализации: Бесполезное расходование вычислительного ресурса Используемые уязвимости: Ошибка реализации Microsoft Internet Information Server Уровень информационной инфраструктуры: Приложения Степень риска: Средняя

Выводы

Итак, для защиты от атак необходимо использовать комплекс средств безопасности, реализующий основные защитные механизмы и состоящий из следующих компонентов:

Межсетевые экраны, являющиеся первой линией обороны и реализующие комплекс защитных механизмов, называемый защитой периметра.

Средства анализа защищённости, позволяющие оценить эффективность работы средств защиты и обнаружить уязвимости узлов, протоколов, служб.

Средства обнаружения атак, осуществляющие мониторинг в реальном режиме времени.

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

В этой статье мы рассмотрим самые опасные типы уязвимостей сайтов и веб-приложений по версии проекта ТОП 10 OWASP в 2017 году. Все уязвимости отсортированы по важности. Самые частые и самые опасные - вверху, менее опасные - ниже. Но если они уже попали в этот список, значит на них стоит обратить внимание.

А теперь давайте перейдем к нашему списку.

1. Инъекции/Injection

Под инъекциями подразумеваются уязвимости, которые возникают в результате передачи не проверенных, введенных пользователем данных интерпретатору для выполнения. Таким образом, любой пользователь может выполнить произвольный код в интерпретаторе. Самые распространенные типы инъекций - SQL, OS, XXE и LDAP.

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

2. Проблемы аутентификации и проверки сессий

Многим приложениям необходимо идентифицировать пользователей для работы с ними. Часто функции для проверки подлинности и управления сессиями реализуются неверно, что позволяет злоумышленникам получать доступ к учетным записям пользователей в обход паролей. Злоумышленники могут каким-либо образом перехватить ключи или токены сеанса, которые выступают в качестве идентификаторов пользователей и использовать их временно или постоянно.

3. XSS

Первые две уязвимости представляли больше опасности для сайта и его сервера. XSS не так опасна для сервера, но опасна для пользователя. Она работает в браузере пользователя, и поэтому позволяет только украсть его данные. XSS или Cross-Site Scripting работает в JavaScript. Принцип тот же, что и в инъекциях. Злоумышленник передает специальную строку в каком-либо поле, в строке содержится JS код, далее браузер думает, что этот код отправлен сайтом и выполняет его, а код может быть любым. Для противодействия таким атакам нужно экранировать все специальные символы с помощью функции htmlspecialchars или аналогов.

4. Проблемы контроля доступа

Нередко по недосмотру администраторов обычным пользователям становятся доступны данные, которые должны быть закрыты. Этой проблеме подвержены даже популярные движки. Ярким тому примером можно привести файлы в корне сайта. Например, файл wp-config.php с паролями доступа к базе данных недоступен, потому что имеет расширение php. Но если вы редактируете его в Vim и сохраняете неверно, то создается резервная копия с расширением.swp и ее то уже можно открыть в браузере без препятствий.

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

5. Неверная конфигурация

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

6. Незащищенные конфиденциальные данные

Многие веб-приложения, сайты и API не защищают конфиденциальные данные пользователя и передают их в открытом виде. К таким данным могут относиться не только пароли, токены и ключи, но и медицинская, финансовая информация. Злоумышленники могут похитить или даже модифицировать важные данные с помощью атаки "Человек посередине". Конфиденциальные данные должны быть защищены, например, с помощью шифрования https или других методов.

7. Недостаточная защита от атак

Большинство приложений и API не имеют базовых возможностей по обнаружению, предотвращению и реагированию как на ручные, так и на автоматические атаки. Защита от атак - это нечто большее, чем базовая проверка соответствия логина и пароля. Она также должна включать обнаружение, протоколирование и даже блокирование попыток неверного входа и других несанкционированных действий. Авторы приложений также должны иметь возможность быстро развертывать исправления для защиты от новых атак.

8. Уязвимости CSRF

Атака CSRF или Cross-Site Request Forgery позволяет злоумышленнику заставить браузер жертвы отправить определенный HTTP запрос, включая куки, файлы сеанса и любую другую, автоматически включаемую информацию в уязвимое веб-приложение.

Таким образом, злоумышленник получает возможность генерировать запросы из браузера жертвы, которые приложение считает правильными и отправленными самой жертвой. Например, вы просто открываете ссылку, а сайт уже отправляет вашим друзьям сообщение с рекламным содержанием без вашего ведома или удаляет ваш аккаунт.

9. Использование компонентов с уязвимостями

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

10. Незащищенные API

Большинство современных приложений часто включают в себя клиентские приложение и богатые API интерфейсы, доступные через JavaScript в браузере или из мобильных приложений. Они могут работать по протоколам SOAP/XML, REST/JSON, RPC, GWT и так далее. Эти API очень часто не защищены и тоже содержат множество ошибок, которые приводят к уязвимостям.

Выводы

В этой статье мы рассмотрели виды уязвимостей сайта, которые встречаются чаще всего по версии ресурса owasp. Как видите, среди чисто программных проблем, таких, как SQL инъекции, XSS или СSRF есть и проблемы в настройке серверов, которые тоже часто причиняют проблемы. Во всяком случае, теперь вы знаете какие уязвимости веб-сайтов бывают, и можете сделать ваш ресурс более безопасным.

Исходные данные

В исследовании использованы результаты тестирования 17 информационных систем крупных российских и зарубежных компаний. Наибольшую долю составляют компании финансового сектора (35%). В равных долях представлены промышленные, телекоммуникационные и IT-компании (по 18%), также среди протестированных - одна транспортная компания и одна госорганизация. Большинство исследованных предприятий включали множество дочерних компаний и филиалов, расположенных в разных городах и странах; количество активных узлов, доступных на их сетевом периметре, исчислялось сотнями. Помимо тестирования на проникновение, в 24% проектов проводилась оценка осведомленности сотрудников в вопросах информационной безопасности.

Общие результаты

В 76% исследованных систем выявлена возможность получения злоумышленником полного контроля над отдельными критически важными ресурсами. При этом в 35% систем такой уровень привилегий может быть получен от лица любого внешнего нарушителя. Не удалось получить контроль над какими-либо критически важными ресурсами в 24% проектов. В целом видна тенденция к повышению общего уровня защищенности критически важных ресурсов, по сравнению с 2013 и 2014 годами.

В половине исследованных систем возможно получение полного контроля над всей корпоративной инфраструктурой. При этом в 19% случаев такие привилегии могут быть получены со стороны внешнего нарушителя, а еще в 31% компаний - от лица внутреннего нарушителя из пользовательского сегмента сети.

Минимальный уровень доступа, необходимый нарушителю для получения полного контроля над отдельными критически важными ресурсами

Как и в предыдущие годы, практически в каждой корпоративной инфраструктуре были обнаружены уязвимости высокой степени риска. С 2013 года сохраняется тенденция к росту доли организаций, корпоративная инфраструктура которых подвержена критически опасным уязвимостям, связанным с использованием устаревших версий ПО и с отсутствием обновлений безопасности. Средний возраст наиболее устаревших неустановленных обновлений - 73 месяца (более шести лет).

Недостатки защиты сетевого периметра

По сравнению с 2014 годом общий уровень защищенности сетевого периметра повысился: в рамках почти половины проектов, где проводились работы, не было выявлено недостатков, которые позволили бы получить доступ к критически важным ресурсам из внешних сетей. Сложность осуществления атак также возросла: для получения доступа к ресурсам внутренней сети внешнему нарушителю лишь в 46% случаев достаточно обладать низкой квалификацией (против 61% в 2014 году).

Сложность преодоления периметра

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

В 55% систем для преодоления сетевого периметра без использования методов социальной инженерии требовалась средняя либо низкая квалификация, либо вовсе тривиальные действия нарушителя. В среднем для получения доступа к ресурсам внутренней сети, как и в 2014 году, требовалась эксплуатация двух различных уязвимостей.

При преодолении сетевого периметра в 47% случаев вектор атаки основывался на эксплуатации уязвимостей веб-приложений . В целом уязвимости различного уровня риска в коде веб-приложений были обнаружены в 69% исследованных систем. Например, уязвимость «Загрузка произвольных файлов» была выявлена в 56% проектов, а «Внедрение операторов SQL» оказалось возможно в 44%.

Другие 53% атак, в результате которых был получен доступ к ресурсам внутренней сети, пришлись на использование словарных учетных данных . Данная уязвимость была наиболее распространенной в 2014 году, а в 2015 году выявлена на сетевом периметре 78% систем. Во всех этих системах были обнаружены простые пароли привилегированных пользователей. В 44% компаний словарные учетные данные использовались для доступа к общедоступным веб-приложениям.

Во всех исследованных системах были выявлены недостатки, связанные с использованием на сетевом периметре уязвимых версий ПО ; главным образом это устаревшие версии веб-серверов (78%) и прикладного ПО (67%).

Наиболее распространенные уязвимости на сетевом периметре

Недостатки защиты внутренней сети

Как и в предыдущие годы, в рамках всех проектов удалось получить максимальные привилегии в критически важных системах при тестировании от лица внутреннего злоумышленника (например, рядового сотрудника, находящегося в пользовательском сегменте сети). При этом полный контроль над инфраструктурой был получен в 71% случаев. Полученные результаты совпадают с показателями 2013 года.

В среднем при наличии доступа во внутреннюю сеть для контроля над критически важными ресурсами злоумышленнику требуется эксплуатация четырех различных уязвимостей, что на один шаг больше, чем в предыдущем году, и на один шаг меньше, чем в 2013 году. Однако сложность реализации атак существенно снизилась - в 82% случаев для доступа к критически важным ресурсам нарушителю достаточно было обладать квалификацией низкого уровня; аналогичный показатель в 2014 году составлял лишь 56%.

Самой распространенной уязвимостью ресурсов внутренней сети остается использование словарных паролей. Данный недостаток обнаружен в рамках всех без исключения проектов. При этом в 91% случаев было выявлено использование слабых паролей для привилегированных учетных записей.

Словарные пароли во внутренней сети

Во всех системах также были выявлены недостатки защиты служебных протоколов, которые могут привести к перехвату и перенаправлению сетевого трафика. Недостаточный уровень защиты привилегированных учетных записей и недостатки антивирусной защиты по-прежнему распространены во внутренней сети компаний: уязвимости каждой из этих категорий были обнаружены в 91% систем.

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

Наиболее распространенные уязвимости внутренней сети

Недостатки осведомленности сотрудников в вопросах ИБ

В целом уровень осведомленности сотрудников в вопросах информационной безопасности оценивается выше, чем в 2014 году, но по-прежнему остается достаточно низким: ни в одной из протестированных систем он не был оценен как приемлемый, хотя вдвое снизилась доля компаний, для которых уровень осведомленности сотрудников был оценен как крайне низкий (25% против 50% в 2014 году).

В 2015 году в среднем 24% пользователей осуществили переход по поддельной ссылке (в 2014 году было 20%). Не изменилась доля испытуемых, которые ввели свои учетные данные в заведомо ложную форму аутентификации или загрузили исполняемый файл: показатель остался на уровне 15%.

Доля зафиксированных событий относительно общего количества отправленных сообщений

Недостатки защиты беспроводных сетей

В рамках данных работ проводится поиск недостатков в использовании точек доступа и клиентских устройств Wi-Fi для диапазонов 2,4 и 5 ГГц с использованием технологий 802.11a/b/g/n, а также недостатков в архитектуре и организации беспроводного доступа. Лишь для 33% систем уровень защищенности беспроводных сетей был оценен как «приемлемый».

Среди выявленных недостатков стоит отметить использование механизма WPS для упрощения процесса настройки беспроводной сети. Для подключения к точке доступа используется специальный PIN-код, состоящий только из цифр. Нарушитель может подобрать PIN-код и подключиться к точке доступа.

Также выявлены факты использования несанкционированных точек доступа ; в случае их подключения к локальной вычислительной сети злоумышленник имеет возможность получить доступ к внутренним сетям. В ряде систем обнаружено отсутствие защиты отдельных беспроводных сетей , что может привести к перехвату важной информации. К распространенным уязвимостям можно также отнести использование стандартных учетных записей для доступа к веб-интерфейсу управления сетевым оборудованием.

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

Заключение

Для снижения рисков компрометации критически важных систем со стороны внешних нарушителей рекомендуется особое внимание уделять ресурсам, доступным из внешних сетей. Как показывает практика, подавляющее большинство успешных атак основаны на эксплуатации уязвимостей не официальных сайтов организаций и их серверов, а каких-либо других ресурсов компании, которые не должны быть доступны на сетевом периметре (например, СУБД, неиспользуемых отладочных интерфейсов, интерфейсов удаленного доступа или управления, интерфейсов инфраструктурных служб, таких как LDAP). Интерфейсы для доступа к таким ресурсам могут быть открыты для подключения по ошибке администраторов; зачастую представители крупных компаний, отвечающие за безопасность, не могут точно сказать - сколько и каких ресурсов организации доступны из внешних сетей.

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

Что касается защиты корпоративных систем от атак со стороны внутреннего нарушителя, необходимо ввести парольную политику, запрещающую использование простых паролей, предусматривающую обязательную двухфакторную аутентификацию для привилегированных пользователей критически важных систем, а также требования к регулярной смене паролей (например, раз в 60 дней). Также необходимо обратить особое внимание на устаревшие версии ПО, на открытые протоколы передачи данных и на хранение важной информации в открытом виде на серверах и рабочих станциях сотрудников. Кроме базовых мер защиты информации, следует на регулярной основе проводить аудит безопасности информационных систем и тестирование на проникновение со стороны внешнего и внутреннего нарушителя.

Ежедневно сотнями хакеров обнаруживаются тысячи уязвимостей, – после чего
взламывается куча сайтов, и детали багов выкладываются в багтрак на всеобщее
обозрение. Наверняка, ты читал подобные обзоры и замечал, что каждый баг
определенным образом классифицируется. Что собой представляет измерение
уязвимости, по каким критериям производится и на кой черт это вообще нужно
знать? Ответы ты найдешь в этой статье.

"Общепринятых систем по классификации брешей в нашей стране не существует" –
эту фразу я поставлю во главу угла. Продвинутым государством в этом плане стали
США. Там ведут несколько классификаций и активно используют их как в
образовательном процессе, так и в технологиях. Одной из самых известных систем
классификации является CVE , которая курируется компанией NCSD (National Cyber
Security Division) при одном из Министерств США. Рассмотрим эту систему
подробнее.

СVE (Common Vulnerabilities and Exposures)

По сути, CVE — это "словарь" известных уязвимостей, имеющий строгую
характеристику по описательным критериям, что отличает его, скажем, от
Bugtrack-ленты. Полностью CVE можно отыскать в Национальной Базе Уязвимостей США
(NVD — nvd.nist.gov) или на
официальном сайте (cve.mitre.org/data/downloads).
Причем, распространяется база в нескольких форматах: xml, html, csf, xsd schema.
Из-за такой доступности, открытости и удобства к базе CVE часто обращаются сами
разработчики различного ПО (в первую очередь, нацеленного на рынок
информационной безопасности).

Общий вид записи CVE выглядит примерно так:

CVE ID, Reference и Description.

ID записывается с указанием кода и порядкового номера, например
"CVE-1999-03". В поле Reference записываются различного рода ссылки на патчи,
рекомендательного рода документы или комментарии разработчика. Description
отвечает за описание самой уязвимости. Короче, CVE — система широкого профиля и
никоим образом не сосредотачивается только на клиентских уязвимостях или,
скажем, исключительно на WEB-протоколе. Изначально она задумывалась как единый
стандарт идентификации уязвимостей, который должен охватывать несколько звеньев
информационной системы: систему поиска и обнаружения брешей (например, сканер
безопасности), антивирусное ПО, а также исследуемое ПО.

Как появилась идея ее создания? Многие компании занимаются поиском брешей в
различных продуктах на основе политики (не)разглашения информации и
взаимодействия с производителями. Как-то, при исследовании одного из продуктов
десятью различными компаниями, одной и той же уязвимости были присвоены
абсолютно разные названия. После выявления сей вопиющей несправедливости было
принято соглашение о едином стандарте. Тогда же компания MITRE Corporation (mitre.org)
предложила решение, независимое от различных производителей средств поиска
уязвимостей, и взяла на себя ответственность за его воплощение. Нельзя сказать,
что после этого все баги стали упорядоченными. Разработчики продолжают активно
развивать самостоятельные начинания. Часть из них имеют платную подписку, и
антивирусные компании частенько обращаются к ним и добавляют соответствующие
сигнатуры в свои продукты. Стоимость такой годовой подписки составляет около
$5000 и выше.

BID

Эта классификация присутствует исключительно на портале Securityfocus
(используется в ленте

securityfocus.com/vulnerabilities). Одна из отличительных особенностей BID –
совместимость с CVE. Условно говоря, найденная уязвимость в BID имеет ссылку на
номер CVE и, соответственно, равнозначна по информации. У системы есть ряд
описательных свойств – например, класс, возможность локального или удаленного
исполнения и т.п. В будущем ты убедишься, что этих параметров недостаточно для
полной характеристики, но, тем не менее, BID дает разработчику вполне наглядную
информацию о выявленной бреши.

OSVDB

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

Secunia

Эта датская компания, лента уязвимостей которой доступна по адресу
secunia.com , уже заработала
себе достаточно славы. Не сказать, чтобы их портал внес какую-то особую,
добавочную классификацию, но именно он предлагает услуги платной подписки на
базу уязвимостей.

ISS X-Force

ISS затрагивает все перечисленные выше критерии, но вдобавок описывает
бизнес-импакт, а именно – материальный ущерб, который может повлечь за собой
угроза эксплуатации. Например, баг "Microsoft Excel Remote Code Execution",
нацеленный на компьютер сотрудника банка или предприятия, способен привести к
краже важных документов, ущерб от разглашения которых может исчисляться
миллионами. Оценить урон от различных видов атак можно, ознакомившись с одним из
ведущих блогов в русскоязычном сегменте о security-бричах и утечках — Perimetrix.

Также в системе присутствует качественно новая черта — переход к метрикам
безопасности для описания свойств уязвимости. Для этого используется общая
система подсчета рисков уязвимостей CVSS версии 2. Она представляет собой шкалы,
на основе которых выставляются баллы. Система метрик была придумана для
разделения приоритетов над исправлением уязвимостей. Каждая шкала относится к
определенному смысловому разделу, который называется метрикой. В CVSS v.2 их
три: базовая метрика, временная метрика и контекстная метрика. Хакеров
заинтересует только первая.

Базовая метрика

Нередко на солидных порталах по безопасности можно увидеть фразу – "CVSS Base
Score = 9.2". Как это понимать? Параметр вычисляется по специальной формуле:

– плюс еще несколько. Все эти формулы можно найти по адресу
first.org/cvss .

Чтобы все стало понятнее, рассмотрим пример. Задан вектор уязвимости базовой
метрики вида: "AV:N/AC:L/Au:N/C:N/I:N/A:C". Все красуется на странице описания,
но ты абсолютно не можешь расшифровать эти иероглифы! Я тебе помогу. Итак,
расшифровываем по порядку.

Access Vector: Network — возможность доступа к объекту исключительно
через сеть. Для эксплуатации уязвимости злоумышленник должен обладать доступом к
уязвимому ПО, причем этот доступ ограничен только величиной сетевого стека.
Локального доступа или доступа из соседней сети не требуется. Такие уязвимости
часто называют эксплуатируемыми удаленно. Примером такой сетевой атаки служит
переполнение буфера RPC.

Access Complexity : Low — сложность доступа к ресурсу: низкая. Для
эксплуатации специальных условий и особых обстоятельств не требуется — все
стандартно, шаблонно, общедоступно.

Authentication : None – для эксплуатации не нужна авторизация.
Например, если бы это был сервис, который требует предварительной авторизации по
какой-нибудь мудреной схеме (смарт-карты, ключи, токены), то значение этого
вектора было другим.

Confidentiality Impact : None — влияние на разглашение критичной
информации.

Integrity Impact : None — нарушение целостности. Понятие "целостность"
связано с достоверностью и точностью информации. Если бы у злоумышленника была
возможность модификации файлов, изменения области исполнения файлов, то мы бы
поставили здесь C (полное) или P (частичное, от "partial").

Availability Impact : Complete — атаки, потребляющие пропускную
способность сети, циклы процессора или дисковое пространство, которые влияют на
доступность системы. Если эксплуатация уязвимости вызывает отказ в обслуживании,
то Availability Impact имеет значение "Complete".

Временная метрика

Более глубоким анализом занимаются временные и контекстные метрики. Дело в
том, что описанные векторы базовой метрики со временем не меняются. Они
постоянны и могут характеризовать уязвимость по назначению и опасности. А какие
критерии могут изменяться с течением времени? Представь, что ты нашел
критическую уязвимость и уведомил разработчика. Временной интервал исправления
уязвимости в таком случае имеет значение, да и к тому же сам изменяется во
времени (это может быть день, час, либо производитель вообще никак не
отреагирует). Или ситуация, когда твой друг написал боевой эксплойт на недавнюю
уязвимость "нулевого дня". Как долго этот код будет актуален? Он ускорит риск
эксплуатации, следовательно, должен учитываться при ее описании. Доступна ли
будет его технология к завтрашнему дню?

На все эти вопросы отвечают временные метрики. Рассмотрим некоторые их
векторы.

Exploitability (E) — возможность эксплуатации. Пожалуй, один из
важнейших критериев. Речь идет конкретно о доступности средства (кода, эксплойта,
технологии), которое успешно работает. Важно учитывать и то, что доступный
эксплойт можно использовать далеко не всегда. Используемые описательные флаги: U
(недоступен или непроверен), Proof-of-Concept (POC — опубликована наглядная
демонстрация уязвимости), F (функциональный, и рабочий эксплойт у тебя в руках),
H ("high risk" всей темы, чаще всего характерен для червей или для уязвимостей с
широко популярным описанием), ND (без разницы, вектор метрики не влияет ни на
что существенное, поэтому учитывать его не надо).

Remediation Level (RL) — уровень исправления. Голос уязвимости услышал
весь свет, вот только как поступят разработчики? Порой они просто молчат, потому
что их уже не осталось в живых (простите, за цинизм и черный юмор), а иногда
абсолютно сторонние организации и неофициальные источники начинают заботиться о
безопасности на первый взгляд чужих продуктов и оперативно писать заплатки.

Report Confidence (RC) — степень достоверности отчета. Сколько слухов
и разговоров крутится вокруг! Банальный пример: человек написал информацию якобы
о рабочей критической уязвимости. А на деле оказалось, что это программный
дефект и ничего существенного собой не представляет. Подтверждена ли уязвимость
экспертами или же это просто проделки хакерских слухов? Ответ на этот вопрос
даст вектор Report Confidence.

Параметры всех указанных векторов градируются вариантами "да/нет/возможно".

Контекстная метрика

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

Collateral Damage Potential (CDP) — вероятность нанесения косвенного
ущерба. Описывает экономические или технические потери. Скажем, нам встретится
уязвимость, приводящая к DoS-атаке. После ее эксплуатации часть сетевого
оборудования перегревается, не справляясь с работой, и выходит из строя. Но при
этом ущерб оказывается незначительным из-за низкой стоимости устройства и его
расположения (вне защищаемых и важных объектов).

Target Distribution (TD) — плотность целей. Влияет ли уязвимость
только на одну цель, либо с ее помощью можно поработить огромное число машин?
Если это стендовое показательное выступление, лабораторный практикум или
эксплуатация на машине, изолированной от других, то значение этого вектора равно
нулю.

Использование классификаторов в сканерах

Современные автоматизированные аудиторы принято затачивать под какую-либо
конкретную базу знаний. Во-первых, это престижно, во-вторых — полезно. К
примеру, при подготовке к аттестации по одному из современных стандартов (NERC-CIP,
PCI, FISMA, GLBA или HIPAA) администратору предоставляется возможность получить
шаблонный отчет, соответствующий документу, издаваемому аудитором. Я встречал
такое в современных сканерах беспроводной безопасности, типа AirMagnet, а также
дорогих коммерческих сканерах вроде ISS Security Scanner. Порой сканеры
безопасности прибегают к использованию собственного разделения брешей по ID.
Подобная практика применяется в Nessus, который таки сменил лицензию на
полукоммерческую.

Отдельные классификации

Подчас в Сети можно заметить абсолютно самопальные классификации, вроде
Common Criteria Web Application Security Scoring (CCWAPSS) 1.1. Естественно,
большого веса такая система не имеет, потому что составляться она должна
реальными экспертами, которые понимают суть проблемы.

Так ли оно все важно?

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

INFO

Истинные корни создания единой классификации багов и их контроля – это
Unix Known Problem List , Internal Sun Microsystems Bug List , каталоги
служб реагирования на компьютерные инциденты CERT ранних версий.

Список "междоусобной" совместимости систем классификаций:

CVE : ISS, BID, Secunia, SecurityTracker, OSVDB
BID : CVE, Bugtraq, ISS, Secunia, SecurityTracker, OSVDB
ISS : CVE, BID, Secunia, SecurityTracker, OSVDB
Secunia : CVE, OSVDB
SecurityTracker : CVE, OSVDB, Nessus
Nessus : CVE, BID, OSVDB
OSVDB : CVE, BID, Secunia, SecurityTracker, ISS, Nessus, Snort

Политика разглашения информации об уязвимости

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

Недокументированные уязвимости

В настоящее время эксперты мозгуют над включением вектора
"недокументированные уязвимости" в одну из метрик. Этот параметр имеет высокое
значение. В недалеком будущем мы сможем лицезреть строку "undercover
vulnerabilities " – вероятно, возможные к исполнению. На сайте, посвященном
развитию метрик информационной безопасности (securitymetrics.org/content/Wiki.jsp)
вывешено публичное обращение по поводу того, как и каким образом исчислять этот
параметр. Все желающие могут отправить туда свои предложения.