вектор атаки что это такое

Гарантированный взлом. Пять слабых звеньев ИБ

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

Дмитрий Евтеев
Эксперт по информационной безопасности отдела консалтинга и аудита компании Positive Technologies.
Источник: http://devteev.blogspot.com/2009/04/blog-post_27.html

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

Итак, наиболее опасным вектором проникновения, конечно же, является использование человеческого фактора. Социальная инженерия – это самый пробиваемый вектор атаки при проведении внешнего пентеста. Что тут можно добавить? Во-первых, для минимизации последствий подобной атаки, безусловно, необходимо обучать пользователей основам безопасности при работе в Интернете. Однако этого недостаточно, т.к. при грамотно организованной социалке, даже матерые системные администраторы могут допустить оплошность и осуществить переход по ссылке на вроде бы безобидный сайт, тем самым сдав свою сеть атакующему. Поэтому необходима организация комплекса мер по защите информации, в том числе организация работы конечных пользователей и системных администраторов с пониженными привилегиями, различные проактивные механизмы защиты на рабочих местах, контроль трафика и пр. Во-вторых, достаточно часто при проведении вектора атаки с использованием социальной инженерии применяется вектор атаки с эксплуатацией уязвимостей в ПО на рабочих местах. Поэтому, стоит обратить внимание на процесс управления обновлениями, и не только со стороны продуктов компании Microsoft, но и со стороны обновления таких продуктов, как уязвимых компонентов ActiveX, Flash Player или Acrobat Reader, на долю которого по заявлениям F-Secure приходится около 28,6% успешных атак.

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

Третий вектор атаки, отрабатывающий достаточно часто – это успешная атака на внешние web-приложения. Что уж тут и говорить, когда порядка 83% из них могут содержать критические уязвимости. А эксплуатируемый совместно с кривым разделением внутренних подсетей (приходилось наблюдать сети, когда ДМЗ превращают в «дуршлаг» и выйти из которого во внутреннюю сеть является достаточно простой задачей), данный вектор во многих случаях позволяет добиться отличных результатов при проникновении. Для защиты от угроз, связанных с эксплуатацией уязвимостей в web, в первую очередь стоит закладывать в ТЗ требования к безопасности при его проектировании. Совсем не лишним является независимый аудит web-приложения, и как превентивная мера – использование Web Application Firewall (WAF).

Следующий вектор, который отрабатывает гораздо реже – это эксплуатация server-side уязвимостей в сетевых сервисах пограничных узлов. Причины, по которым вектор «выстреливает» реже остальных заключается в том, что большинство уязвимых сервисов прикрыты файрволом, а вовсе не потому, что для внешних систем во время устанавливаются критические обновления от производителей. И стоит лишь пробиться в ДМЗ, как не эффективный path management позволяет скомпрометировать другие ресурсы и пентест из разряда внешнего плавно переходит во внутренний:)

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

Источник

Вектор атаки (кибербезопасность)

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

Отмечено, что в последние годы резко увеличилось количество, сложность и изощрённость наблюдаемых кибератак. Тем не менее, одним из доминирующих «поставщиков» векторов для атаки на закрытые данные остаются дефекты и уязвимости современных операционных систем практически всех видов Windows, Mac OS и Unix. Кроме них, для удалённого доступа к базам данных с ценной информацией также активно эксплуатируются возможности манипуляции SQL-запросами с внедрением SQL-кода. Нередко также в дело идут электронные письма со вложенным хакерским кодом, схемы сетевого фишинга, компьютерные черви для поиска и оценки уязвимостей, текстовые документы со встроенными макросами, инфицирующими системное окружение, DDOS-атаки и т. п. Цели и задачи злоумыщленника значительно упрощаются, если на компьютере жертвы имеются открытые порты, для авторизации используются слабые пароли, отсутствует настройка файерволла и т. п.

Связанные понятия

В Unix-подобных операционных системах пользователи идентифицируются идентификаторами пользователя (англ. User identifier, UID).

О типе данных в БД см. BLOB.Блоб (от англ. binary linked object — объект двоичной компоновки) — объектный файл без публично доступных исходных кодов, загружаемый в ядро операционной системы. Обычно этот термин применяется только по отношению к модулям, загружаемым в ядро свободной или открытой операционной системы; термин редко применяется по отношению к коду, выполняющемуся не в режиме ядра, например, код BIOS, микропрограммный код устройств, программы, выполняющиеся в пользовательском режиме.

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

Источник

Оценка уязвимостей CVSS 3.0

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

Мы используем систему оценок CVSS с момента возникновения нашей базы уязвимостей и первого нашего продукта — XSpider (надеюсь, кто-то его еще помнит). Для нас очень важно поддерживать базу знаний, которую мы используем в своих продуктах и услугах, в актуальном состоянии. Поскольку рекомендации по работе с CVSS-метриками не покрывают все возможные варианты уязвимостей, иногда приходится задаваться вопросом: «Как лучше проставить метрики, чтобы итоговая оценка отражала реальную опасность уязвимости?».

Мы постоянно следим за развитием стандарта, поэтому давно ждали окончательной версии CVSSv3. Открывая спецификацию, я прежде всего хотел ответить на вопросы: «Что стало лучше?», «Что именно изменилось?», «Сможем ли мы использовать новый стандарт в наших продуктах?» и — поскольку к ведению базы часто подключаются молодые специалисты — «Как быстро можно овладеть методикой оценки?», «Насколько четкими являются критерии?».

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

Вехи в истории CVSS
Стандарт Common Vulnerability Scoring System был разработан группой экспертов по безопасности National Infrastructure Advisory Council. В эту группу вошли эксперты из различных организаций, таких как CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec.

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

Далее стандарт стал поддерживаться рабочей группой Common Vulnerability Scoring System-Special Interest Group (CVSS-SIG) в рамках проекта Forum of Incident Response and Security Teams (FIRST). Членство в группе не накладывает на ее участников каких-либо ограничений по поддержке и распространению стандарта.

В 2007 году была опубликована вторая версия стандарта: были внесены правки в перечень показателей и изменена формула расчета итоговой метрики для более точной оценки опасности уязвимостей.

В 2014 году рекомендации по использованию CVSSv2 выпускают такие авторитетные организации, как NIST и ITU, занимающиеся разработкой руководств и стандартов в области телекоммуникации и информационных систем.

Использование метрик CVSS для оценки уязвимостей закреплено в стандартах PCI DSS и СТО БР ИББС.

В июне 2015 года FIRST опубликовал финальную версию стандарта CVSSv3, о котором и пойдет речь в данной статье.

Основы
CVSS предлагает простой инструментарий для расчета числового показателя по десятибалльной шкале, который позволяет специалистам по безопасности оперативно принимать решение о том, как реагировать на ту или иную уязвимость. Чем выше значение метрики, тем более оперативная реакция требуется.

В стандарт входят три группы метрик:

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

Нововведения в CVSSv3
Далее по тексту мы не будем подробно рассматривать CVSSv2, на эту тему есть достаточно хорошая документация [6, 9], остановимся более детально на изменениях, вносимых новым стандартом.

Базовые метрики
Компоненты системы, для которых рассчитываются метрики
В рамках стандарта вводятся следующие понятия:

Метрики эксплуатируемости
Вектор атаки

Степень удаленности потенциального атакующего от уязвимого объекта.

Примечание: здесь и далее в скобках даются буквенные мнемоники, используемые при описании CVSS-вектора.

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

Сложность эксплуатации уязвимости

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

«Сложность» сама по себе — понятие субъективное, поэтому данная метрика, всегда трактовалась экспертами по-разному. К примеру, для уязвимостей, позволяющих реализовать атаку «Человек посередине», в базе NVD можно встретить различные варианты оценки Access Complexity.

Факторы, учитываемые в CVSSv2 метрикой Access Complexity, в новом стандарте учитываются двумя метриками — Attack Complexity и User Interaction.

Аутентификация / требуемый уровень привилегий

Требуется ли аутентификация для проведения атаки, и если требуется, то какая именно.

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

Значение Multiple в базе NVD встречается достаточно редко и в основном используется для уязвимостей, информация о которых недостаточно детализирована.

CVE-2015-0501 — Неизвестная уязвимость в Oracle MySQL Server позволяет удаленным аутентифицированным пользователям нарушить доступность СУБД, используя неизвестный вектор, связанный с ‘Server: Compiling’.

Значение Single не позволяет определить, требуется ли для эксплуатации доступ уровня привилегированного пользователя или достаточно аутентификации стандартного пользователя.

Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2: 9.0 (AV:N/AC:L/Au:S/C:C/I:C/A:C)

Необходимость взаимодействия с пользователем

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

В CVSSv2 этот фактор учитывался в рамках метрики Access Complexity, в новом стандарте представлен в виде самостоятельной.

Рассмотрим две уязвимости, имеющие одинаковую оценку с точки зрения CVSSv2: 9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C).

Оценка степени влияния на конфиденциальность, целостность и доступность атакуемого компонента.

В данной метрике принципиально изменен подход к расчету веса: от количественного (Partial—Complete) к качественному (Medium—High).

Рассмотрим две уязвимости, имеющие одинаковую оценку CVSSv2: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N).

Временные метрики не претерпели никаких принципиальных изменений.

Степень зрелости доступных средств эксплуатации

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

В этой метрике изменилось только название: теперь оно точнее отражает назначение.

Доступные средства устранения уязвимости

Существуют ли официальные или неофициальные средства устранения уязвимости.

В данную метрику изменения не вносились.

Степень доверия к информации об уязвимости Степень детализации доступных отчетов об уязвимости

В новом стандарте более четко описаны критерии для отнесения отчета об уязвимости к той или иной категории:

CVE-2015-2373 — Уязвимость в сервисе Remote Desktop Protocol (RDP) операционной системы Windows позволяет удаленному атакующему выполнить произвольный код на системе путем отправки специально сформированных RDP-пакетов.

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

Контекстные метрики
Контекстные метрики изменены для упрощения оценки влияния среды на итоговую оценку.

Требования к безопасности Позволяет задекларировать, какая характеристика данных атакуемого компонента (конфиденциальность, целостность или доступность) наиболее влияет на функциональность бизнес-системы или в целом на бизнес-процессы.

В данную метрику изменения не вносились.

Скорректированные базовые метрики

Эксплуатируемость и потенциальный ущерб в условиях IТ-инфраструктуры конкретной компании.

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

Рассмотрим абстрактный пример.

Качественная шкала оценки опасности

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

Тем, кто хочет глубже освоить методику оценки уязвимостей по CVSS, рекомендую помимо спецификации [1] ознакомится с примерами расчетов [3] и рекомендациями FIRST [2], где на типовых примерах разъясняется, как правильно использовать стандарт для оценки уязвимостей.

Ряд зарубежных компаний, среди которых IBM X-Force и Security Database, уже внедрили оценки по CVSSv3 в своих продуктах и сервисах. Мы в компании Positive Technologies закладываем возможность оценки уязвимостей по стандарту CVSSv3 в корпоративной базе знаний и линейке продуктов MaxPatrol.

Начиная с уязвимости в OpenSSL, получившей запоминающееся название Heartbleed и красивый логотип с кровоточащим сердцем, в сообществе специалистов по информационной безопасности стало модно придумывать для уязвимостей звучные имена, особенно это касается уязвимостей, связанных с SSL/TLS. Проанализируем, насколько эти поименованные уязвимости реально опасны.

Источник

Роутеры, векторы атак и другие приключения Шурика

Предыстория

В августе 2016 года мир познакомился с ботнетом под названием Mirai. Исследователи из группы MalwareMustDie начали изучать зловредную сетевую активность IoT-девайсов в начале августа, а уже 20 сентября ботнет примерно из 150 000 устройств (в основном DVR и IP-камер) атаковал серверы Minecraft, расположенные у французского провайдера OVH.

Заражение IoT-устройств осуществлялось посредством подбора учетной записи Telnet на портах 23 или 2323 по списку из 62 стандартных паролей. IP-адреса генерировались абсолютно случайно по всему диапазону, и после включения в сеть каждое зараженное устройство начинало сканирование этих рандомных адресов. Код, управляющий ботнетом, не хранился в долговременной памяти и, следовательно, не мог пережить перезагрузку устройства. Однако, учитывая скорость, с которой боты сканировали интернет, после перезагрузки устройство вскоре вновь включалось в состав ботнета.

Далее последовали крупнейшие атаки на журналиста Брайана Кребса, на DynDNS, Либерию, немецкого оператора Deutsche Telekom и один из колледжей в США. Исходный код ботнета Mirai был опубликован в начале октября и атака на немецкого оператора двумя месяцами позже уже велась с использованием модифицированной версии Mirai, эксплуатировавшей уязвимость сервера RomPager на порте 7547 (протокол CWMP).

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

Что-нибудь кроме веб-камер?

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

В то время как ботнет вбирал в себя преимущественно видеокамеры и другие IoT-девайсы, у которых служба Telnet дает доступ к Linux-командам, — служба Telnet на роутерах предоставляла доступ лишь к CLI настройки. Такой CLI позволяет читать и менять конфигурацию устройства, настройки DNS, ip route и системную информацию, что уже само по себе позволит провести некоторые атаки, но не позволяет установить ПО для удаленного управления.

Однако отсутствие bash-терминала не означает отсутствия других векторов атак.

Что собой представляет среднестатистический домашний роутер? Это:

При этом средний возраст прошивки на устройстве составляет 3–4 года. Этот возраст коррелирует со средним возрастом самого роутера, или, другими словами, пользователи скорее меняют само устройство, чем обновляют его прошивку. В последнее время эта статистика меняется в лучшую сторону провайдерами, которые удаленно и без участия пользователя диагностируют, конфигурируют и накатывают обновления на роутеры пользователей. Правда, работает это только для тех устройств, которые провайдеры поставляют под собственным брендом.

На данный момент опытным путем установлено, что пароли примерно 15 из 100 устройств никогда не менялись со значений по умолчанию. И зная всего пять самых популярных пар, можно получить доступ к админке каждого десятого устройства:

Получив доступ к веб-панели, атакующий также получает уникальную возможность испортить жизнь всем пользователям по ту сторону, проводить DNS Spoofing и исследовать внутреннюю сеть. При большой удаче он способен еще и вызывать с веб-панели такие команды, как ping или traceroute, найти уязвимость в коде веб-сервера для получения шелла или воспользоваться одной из уже найденных.

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

NETGEAR DGN2200v1/v2/v3/v4 — ‘ping.cgi’ RCE (link)

Multiple vulnerabilities in GoAhead WIFICAM cameras (link)

Многочисленные уязвимости были обнаружены более чем в 1250 моделях IP-камер, в зоне риска находятся около 130 000 камер. Ошибка в реализации кастомного механизма авторизации, которая позволяет получить админский пароль, и уязвимость типа OS Command Injection на странице set_ftp.cgi, которая позволяет выполнять любые терминальные команды, вместе дают полный контроль над устройством без каких-либо ограничений. Впечатляет! Использование этой уязвимости добавил в своей арсенал ботнет TheMoon, известный с 2014 года. В ходе исследования были обнаружены зараженные камеры, в файл settings.ini которых был добавлен скрипт, загружающий зловредный код с сервера злоумышленников при загрузке устройства.

В конце цепочки загрузок с сервера злоумышленников прилетает скомпилированный под ARM-архитектуру исполняемый файл:

который 17 из 54 антивирусов идентифицируют как Linux/Proxy.

Linksys Smart Wi-Fi Vulnerabilities (link)

По результатам исследования 25 моделей активно продаваемых по всему миру роутеров из линейки Linksys Smart Wi-Fi оказались подвержены 10 уязвимостям различной степени опасности. В числе уязвимостей и те, что позволяют выполнять произвольные команды с правами root. Несмотря на то, что суммарно с помощью Shodan можно обнаружить лишь около 1000 единиц, исследователи говорят более чем о 7000 просканированных устройств.

Источник