Positive Technologies Research

Актуальные киберугрозы: II квартал 2018 года

2018-09-10T20:09:00.000-07:00

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

Подводя итоги II квартала 2018 года, мы отмечаем следующие тенденции:

Количество уникальных киберинцидентов продолжило расти и на 47% превысило показатели аналогичного периода в 2017 году.
Преобладали целенаправленные атаки — на конкретные организации и их клиентов, на криптовалютные биржи. В ходе этих атак злоумышленники были довольно изобретательны. Они не только использовали вредоносное ПО, но и искали уязвимости нулевого дня, узнавали пароли администраторов с помощью социальной инженерии, получали доступ к ресурсам контрагентов.
Во второй половине квартала произошло большое количество (в два раза больше, чем за I квартал) атак на криптовалютные площадки, в результате которых злоумышленники похитили более 100 млн долл. США.
Продолжила расти доля кибератак, выполненных с целью получения информации. Причем злоумышленники больше всего были заинтересованы в персональных и учетных данных, а также в данных банковских карт. Их похищали в основном посредством компрометации различных онлайн-площадок — интернет-магазинов, сервисов для продажи билетов, бронирования отелей и т. п.
Частные лица страдали от различного вредоносного ПО: большую его часть они устанавливали сами по невнимательности или незнанию, однако встречались и такие методы атак, когда, например, новые смартфоны продавались в магазине с уже установленным в прошивку ВПО.

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

Сводная статистика

Во II квартале 2018 года продолжила расти доля атак, направленных на получение данных. В 40% киберинцидентов злоумышленники были нацелены на получение информации, а в 39% — на финансовую выгоду. В нашем аналитическом исследовании «Рынок преступных киберуслуг» мы подробно рассмотрели спрос и предложение теневого рынка на различные данные (персональные, учетные, платежные и т. д.). Так, например, 59% всех предложений о продаже данных в дарквебе — учетные записи пользователей для доступа к различным ресурсам, в том числе к банковским приложениям. Учетные данные могут продаваться поштучно по цене до 10 $ или целыми партиями до нескольких миллионов записей, стоимость которых достигает сотен долларов. Поэтому вслед за атакой, в которой была получена информация, довольно скоро может последовать новая — на владельцев этих данных или на компанию, учетные данные сотрудников которой были скомпрометированы.

Рисунок 1. Мотивы злоумышленников

Мы рассмотрели, какая информация больше всего привлекала преступников во II квартале 2018 года. В половине случаев это были персональные данные (31%) либо учетные записи и парольная информация для доступа к различным сервисам и системам (22%), в том числе и к онлайн-банкам частных лиц. В 15% случаев были украдены данные платежных карт, их злоумышленники чаще всего получали с помощью шпионского ВПО или со скомпрометированных сайтов.

Рисунок 2. Типы украденных данных

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

Рисунок 3. Категории жертв

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

Доля атак, нацеленных на инфраструктуру, во II квартале 2018 года составила 44%, доля атак на веб-ресурсы выросла по сравнению с аналогичным периодом прошлого года и составила 32% против 23%. Кроме того, по сравнению с I кварталом выросла доля атак на IoT-устройства: это связано главным образом с появлением новых ботнетов, таких как PyRoMineIoT, Muhstik, Wicked Mirai.

Рисунок 4. Объекты атак

Во II квартале 2018 года снизилась доля атак, в которых злоумышленники использовали вредоносное ПО (49% вместо 63% в I квартале). На 12% по сравнению с I кварталом текущего года выросла доля атак, в которых были подобраны учетные данные. Далее мы подробнее остановимся на каждом методе и укажем, какие объекты и отрасли больше всего от них пострадали.

Рисунок 5: методы атак

Распределение киберинцидентов по метрикам (мотивы, методы, объекты атак) внутри отраслей:

*Градацией цвета показана доля атак внутри одной отрасли.

Динамика атак

Количество уникальных киберинцидентов во II квартале 2018 года на 47% превысило показатели аналогичного периода в 2017 году.

Рисунок 6. Количество инцидентов в 2018 и 2017 годах (по месяцам)

Рисунок 7. Количество инцидентов во II квартале 2018 года (по неделям)

Методы атак

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

Использование вредоносного ПО:

Рисунок 8. Типы вредоносного ПО

Как мы уже говорили, киберпреступники активно собирают данные с компьютеров жертв. Для этих целей они используют шпионское ПО (26% заражений) или ВПО для удаленного управления (22%). Во II квартале встретилось меньше киберинцидентов с использованием шифровальщиков и майнеров, чем в первые месяцы года. Злоумышленники продолжают активно использовать уязвимости из базы АНБ для создания вредоносного ПО. Так, майнер PyRoMine, применяя эксплойт EternalRomance (MS17-010), не только использовал вычислительные мощности жертвы, но и создавал скрытый аккаунт с правами администратора и возможностью удаленного подключения, что могло быть лишь подготовкой к последующей атаке.

Рисунок 9. Способы распространения ВПО

Тремя основными путями заражения во II квартале 2018 года стали:

компрометация серверов и рабочих станций; злоумышленники предварительно получали доступ к целевой системе, используя уязвимости, социальную инженерию или подбирая пароль (29% случаев);
сайты, при посещении которых вредоносное ПО устанавливалось на устройство жертвы (29%);
электронная почта: вредоносное вложение или ссылка на зараженный ресурс отправлялись жертве в письме (23%).

Именно вредоносные рассылки используются в большинстве APT для проникновения в целевую систему. Во II квартале 2018 года эксперты PT ESC отметили ряд целенаправленных атак, в ходе которых жертвам были направлены документы MS Word, которые на деле оказывались загрузчиками вредоносного ПО.

Рисунок 10. Пример вредоносного вложения в целенаправленной атаке

Для того чтобы письмо выглядело наиболее правдоподобно, злоумышленники могут подменить адрес отправителя. Так, например, в ходе одной из атак, зафиксированных экспертами PT ESC, бэкдор отправлялся якобы от лица российской государственной корпорации «Ростех».
Кроме того, специалисты PT ESC обнаружили фишинговую атаку, нацеленную на крупную российскую IT-компанию, в ходе которой распространялся троян PlugX. Это вредоносное ПО представляет собой RAT (remote access trojan) и уже несколько лет используется злоумышленниками в атаках на различные компании с целью шпионажа.

Рисунок 11. Пример фишингового письма

Социальная инженерия:

Рисунок 13. Фишинг через социальную сеть Facebook

Киберпреступники продолжают изобретать новые методы воздействия на пользователей, которые позволили бы им заразить целевую систему вредоносным ПО, украсть деньги или получить доступ к конфиденциальной информации. В мае исследователи из Lookout рассказали об атаках на чиновников, дипломатов, военнослужащих и других высокопоставленных лиц из Пакистана, Афганистана, Индии, ОАЭ, в ходе которых была похищена важная информация с их смартфонов, включая изображения, аудиозаписи и текстовые сообщения. Для того чтобы заразить мобильные телефоны шпионским ПО, злоумышленники заводили с жертвами беседу в социальной сети Facebook, в ходе которой делились фишинговой ссылкой, например на видеозапись, при переходе по которой на смартфон устанавливалось вредоносное ПО из стороннего магазина приложений.

Тогда же в мае еще одна вредоносная кампания, распространяющаяся через Facebook, была обнаружена экспертами Radware. Фишинговые ссылки отправлялись от зараженных ранее лиц и вели на фальшивую страницу YouTube, где жертве предлагалось установить расширение для браузера Google Chrome. Вредоносные расширения маскировались под легитимные в официальном каталоге Chrome Web Store, а на деле превращали зараженный компьютер в новое звено ботнета: похищали учетные данные пользователей в Facebook и Instagram, а затем продолжали распространение вредоносного ПО среди друзей жертвы. При этом мощности зараженных устройств использовались для майнинга криптовалюты.

Рисунок 12. Схема атаки, описанной экспертами Radware

Продолжает вести активность, направленную на организации в Республике Беларусь и Казахстане, группировка SongXY. В рамках данной кампании злоумышленники с помощью целевых фишинговых рассылок распространяют вредоносное ПО CMstar и Lurid для компрометации целевой системы.

Хакинг

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

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

Продолжая тему интернет-трафика и DNS, отметим, что уязвимости в публичных DNS-серверах делают возможным фишинг в адрес посетителей сайтов. Так, например, в апреле злоумышленники скомпрометировали несколько DNS-серверов с целью перенаправления пользователей криптокошелька MyEtherWallet на фишинговый сайт. Как правило, в случае подобной атаки браузер жертвы предупреждает о некорректности используемого SSL-сертификата, однако многие это уведомление игнорируют. В результате этой атаки злоумышленникам, предположительно, удалось украсть порядка 160 тыс. долл. США.

Рисунок 14. Уведомление об атаке на пользователей MyEtherWallet.com

Подбор учетных данных

Существует множество инструментов, которые помогают пользователям сохранять сложные пароли, однако получив доступ к менеджеру паролей, злоумышленник получает неограниченный доступ ко всем ресурсам жертвы. Так, ICO-стартап Taylor потерял более 1,47 млн долл. США в мае 2018 года. По словам организаторов, киберпреступники получили доступ к одному из устройств сотрудника и к файлам 1Password, хранящимся на нем, включая пароли от платформы. Следующим шагом стал перевод всей криптовалюты на счет преступников.

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

Эксплуатация веб-уязвимостей

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

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

Рисунок 15. Дефейс сайта администрации города Болонья

Рисунок 16. Сообщение о взломе сайта министерства обороны Индии

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

DDoS

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

Киберпреступники используют DDoS-атаки и для получения финансовой выгоды. В этом случае они шантажируют жертву, выводя из строя важные для компании веб-ресурсы, требуя выкуп за прекращение атаки. Аналогичный инцидент эксперты PT ESC расследовали в июне, когда злоумышленники выполнили серию кратковременных (длительностью менее 2 минут) DDoS-атак на сайт компании для демонстрации своих возможностей и угрожали продолжить атаку в случае отказа в переводе денежных средств. Для атаки киберпреступники использовали вредоносное ПО Wreckuests — свободно распространяемую утилиту для проведения DDoS-атак типа HTTP flood. Wreckuests генерировала большое количество GET-запросов со случайными параметрами через сеть прокси-серверов, что и приводило к отказу в обслуживании сайта из-за чрезмерной нагрузки.

Рисунок 17. Схема DDoS-атаки с использованием ВПО Wreckuests

Категории жертв

Далее мы подробнее остановимся на анализе атак на отдельные отрасли, которые нам показались наиболее интересными во II квартале 2018 года.

Методы атак на государственные организации в Q2 2018

Государственные организации продолжают оставаться излюбленной мишенью для киберпреступников. Конечно, злоумышленников в первую очередь интересует коммерческая тайна целевых организаций, однако мы отмечаем учащение случаев атак на сотрудников и слежки за ними. Так, например, группировки APT-C-23 и mobile APT распространяли вредоносное ПО, используя методы социальной инженерии и официальный магазин приложений Google Play.

Объекты атак Украденные данные

Злоумышленники из APT-C-23 от лица молодых девушек в социальных сетях убеждали жертв установить зараженный мессенджер Dardesh из Google Play, который загружал второй компонент вредоносного ПО, замаскированный под программу для настройки. После этого киберпреступники могли тайно следить за жертвами, в том числе записывать аудио и копировать данные.

Рисунок 18. Фишинговый профиль в Facebook со ссылкой на вредоносный мессенджер Dardesh

Методы атак на медицинские учреждения в Q2 2018

Объекты атак Украденные данные

Медицинские учреждения обрабатывают большое количество данных. А поскольку основная цель их работы это помощь людям, защите этих данных обычно уделяется недостаточно внимания. Как следствие, в 88% кибератак на медицинские учреждения во II квартале 2018 года были похищены данные. Причем помимо персональных сведений и привычных видов медицинских данных злоумышленники начинают интересоваться и другой информацией, например результатами генетических исследований. Так, в апреле стало известно об атаке на компанию Sangamo Therapeutics, занимающуюся расшифровкой генома человека и терапией генетических заболеваний. Злоумышленники скомпрометировали электронную почту одного из топ-менеджеров и потенциально могли развить атаку на внутренние ресурсы компании.

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

Методы атак на криптовалютные биржи в Q2 2018

Объекты атак Украденные данные

Во II квартале 2018 года произошел ряд атак (51%) на криптовалюты, поддерживающие алгоритм консенсуса proof of work (PoW). В ходе данной атаки злоумышленник (чаще всего это группа людей) получает в распоряжение «контрольный пакет» генерирующих мощностей сети (хешрейта), то есть мощности большие, чем у всей остальной сети. Злоумышленник, который контролирует больше половины хешрейта, получает возможность манипулировать операциями и, например, не подтверждать новые транзакции или отзывать совершенные транзакции, используя одну и ту же монету несколько раз.

Рисунок 19. Новости об атаках на криптовалютные сети

В результате атак на криптовалютные сети Verge, Monacoin, Bitcoin Gold, ZenCash, Litecoin Cash злоумышленники смогли заработать десятки миллионов долларов. Несмотря на то что в ходе этих атак преступники воруют деньги не напрямую у пользователей, в конечном счете могут пострадать все равно клиенты криптовалютных сетей, поскольку атакованные ресурсы рискуют обанкротиться, организаторы могут запретить обналичивать криптовалюту — и, несомненно, происходящее отражается на курсе криптовалют.

Методы атак в сфере торговли в Q2 2018

Объекты атак Украденные данные

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

Именно так стало известно о крупнейшей атаке в сфере розничной торговли, в результате которой злоумышленники похитили данные более 5 млн банковских карт из торговых сетей Saks Fifth Avenue и Lord & Taylor. Кража происходила с помощью вредоносного ПО, установленного на POS-терминалы в розничных магазинах, а значит, для клиентов и продавцов оплата покупки выглядела обычным образом.

Более половины (60%) атак в сфере торговли были нацелены на веб-ресурсы. Интернет-магазины, бизнес которых построен на работе сайта, несут серьезные потери в случае нарушения его работы. Так, например, из-за дефейса главной страницы сайта временно прекращал свою работу сервис по продаже билетов Ticketfly. Кроме того, именно веб-уязвимости могут позволить злоумышленникам получить доступ к персональным и банковским данным пользователей. Например, онлайн-пекарни Panera Bread не обеспечили достаточную защиту веб-ресурсов, в результате чего имена, адреса электронной почты и физические адреса, даты рождения и последние четыре цифры номеров кредитных карт нескольких миллионов клиентов были доступны в виде обычного текста.

Рисунок 20. Недостаточная защита веб-ресурсов пекарни Panera Bread

Методы атак на частных лиц в Q2 2018

Объекты атак Украденные данные

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

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

В начале лета специалисты по ИБ обнаружили вредоносную кампанию, нацеленную на пользователей macOS. Злоумышленники использовали каналы Slack и Discord, посвященные криптовалютам, для распространения сообщений о необходимости ввести на компьютере определенную команду, чтобы решить какие-то проблемы. После ввода вредоносной команды жертвы сами предоставляли атакующим доступ к компрометированной системе. В дальнейшем злоумышленники могут продолжить атаки, например похищая криптовалюту.

Злоумышленники продолжают втираться в доверие к пользователям, маскируя фишинговые сайты под госсервисы. Во II квартале 2018 года от подобных атак пострадало более 300 тыс. граждан из Республики Беларусь, Казахстана, России и Украины.

Так, например, злоумышленники создали шесть идентичных сайтов «Активный гражданин», где за прохождение опроса обещали выплатить от 65 000 рублей. После прохождения опроса участникам предлагалось активировать аккаунт за 170 рублей, а затем еще предоставлялся целый список платных услуг, однако выигрыш, естественно, никто не получал.

Пример сайта злоумышленников

Как защититься организации

1. Используйте эффективные технические средства защиты

средства централизованного управления обновлениями для используемого ПО;
антивирусные программы (на всех устройствах), в том числе специализированные, например позволяющие пользователям отправлять подозрительные файлы на проверку перед открытием вложения из письма;
SIEM-решения — для своевременного обнаружения атаки, если инфраструктура оказалась заражена;
автоматизированные средства анализа защищенности и выявления уязвимостей в ПО;
межсетевой экран уровня приложений (web application firewall) в качестве превентивной меры защиты веб-ресурсов;
специализированный сервис для защиты от DDoS-атак.

2. Защищайте данные

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

3. Не допускайте использования простых паролей

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

4. Контролируйте безопасность систем

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

5. Позаботьтесь о безопасности клиентов

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

Как вендору защитить свои продукты

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

Как защититься обычному пользователю

1. Не экономьте на безопасности

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

2. Защищайте ваши данные

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

3. Не используйте простые пароли

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

4. Будьте бдительны

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

Обозначения

Низкоуровневый взлом банкоматов NCR

2018-08-10T06:00:00.000-07:00

Изображение: Sascha Kohlmann, CC BY-SA 2.0

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

Взять хотя бы банкоматы (АТМ). Нередки случаи, когда к АТМ подходят неизвестные, подключают ноутбук, забирают деньги и уходят, не оставляя каких-либо логов в системе. А недавние истории с «котлетами» (вредоносное ПО под названием Cutlet Maker) и подавно подтверждают, что неуязвимых систем нет — есть недоисследованные.

Начало исследования

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

После непродолжительных поисков на Ebay у меня на столе оказалась платка диспенсера NCR USB S1 Dispenser с прошивкой. Цели были такие:

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

Прошивка

Прошивка представляет из себя ELF-файл под процессор NXP ColdFire (Motorola 68040, мой любимый процессор), работающий на VxWorks v5.5.1.

В ELF-файле интерес представляют две основные секции — .text и .data:

В одной из них содержится код, который крутится все основное время (назовем его основной прошивкой), когда диспенсер подключен к системнику в верхней части АТМ.
Во второй лежит упакованный с помощью zlib код загрузчика (его местное название USB Secure Bootloader), который отвечает за заливку прошивки и запуск основного кода.

И самое приятное то, что в файлике остались невырезанными символы — бери да ищи что-нибудь интересное.

Внутреннее устройство основной прошивки

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

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

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

В итоге нашлись следующие сервисы, которые как раз должны выполнять то, что я ищу:

1) DispTranService (Dispenser Transaction Service): работа с шифрованными командами, формирование пачек банкнот, аутентификация. Можно сказать, самое интересное — здесь.

2) securityService: после аутентификации на стороне диспенсера генерируется сессионный ключ, который по запросу компьютера отправляется на него в зашифрованном виде. Этим ключом будут шифроваться все важные команды — выдача, формирование пачки банкнот.

Впоследствии на глаза попался еще один сервис: UsbDownloadService. Его задача — Его задача – при подключении диспенсера к компьютеру и несоответствии версии прошивки диспенсера той, что хранится на компьютере банкомата, переходить в bootloader с целью заливки прошивки, с которой должна работать ОС (лежит в папке с ПО вендора на компьютере). Этот сервис также умеет отдавать информацию о версии прошивки.

Физическая аутентификация

Физическая аутентификация реализована на высочайшем уровне и защищает АТМ от простой отправки по USB команд на выдачу без авторизации. В данном случае она заключается в том, что только при открытом сейфе с деньгами нужно выполнить одно из следующих действий:

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

Но все это требуется только если уровень доступа установлен на максимальный, то есть физический. Всего их три: USB (0), логический (1) и физический (2). Остальные два используются сервисниками и разработчиками для отладки и тестирования прошивки. Ну а физический — крайне рекомендуется вендором к использованию по умолчанию.

Уязвимость

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

Как выяснилось, UsbDownloadService принимает команды, не требующие шифрования. Звучит заманчиво. Но вдруг дальше все защищено, и название Secure Bootloader оправдает себя? Увидим :)

(Спойлер: не оправдает!)

We need to go deeper

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

Пока наличие загрузчика было тайной, оставался открытым вопрос: как же все-таки ПО на компьютере заливает прошивку? Ведь в основной прошивке ничего такого обнаружить не удалось.

Итак, bootloader распакован, загружен в IDA по смещению 0x100000 — теперь можно исследовать... Только символов нет!

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

Выяснилось, что заливка прошивки хоть и выглядит защищенной, таковой на деле не является. Всего-то нужно знать, как заливать ее правильно :)

На полное понимание этого процесса было потрачено довольно много усилий и времени (подробнее об этом можно узнать из доклада «Blackbox is dead—Long live Blackbox!» на конференции Black Hat 2018 в Лас-Вегасе). Чего только стоит перепайка памяти NVRAM, заливка в нее бэкапа с целью «раскирпичивания» всего контроллера...

Спасибо коллеге Алексею за терпение! :)

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

1) Сгенерировать пару RSA-ключей и залить публичный ключ в контроллер.

2) Записать последовательно секции .data и .text из ELF по их физическим адресам из заголовков секций.

3) Подсчитать SHA-1 от записанных данных, зашифровать хеш приватным ключом, отправить в контроллер.

4) Подсчитать и отправить сумму всех записанных word-ов прошивки.

После чего, если все подсчитано и записано успешно, загрузится основная прошивка.

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

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

Выдача

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

Самый что ни на есть настоящий банкомат начал натужно жужжать и охотно поделился с нами свежими хрустящими банкнотами (в данном случае вендорскими «фантиками»). Никакой магии не применялось: только ноутбук, мозг и USB-шнурок.

Выводы

Мы в очередной раз убедились, что, руководствуясь принципом security through obscurity, обеспечить надлежащую защиту невозможно. Проприетарность кода или прошивки совершенно не означает, что к ней в один прекрасный момент не получит доступ злоумышленник и не воспользуется найденными уязвимостями. Всем необходимым для реализации корыстных целей можно обзавестись при наличии определенной суммы денег.

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

P.S. Вендор подтвердил уязвимость (брешь также обнаружена и в другой модели — S2), которая была заявлена как исправленная в февральском фиксе 2018-го года.

Список CVE:

CVE-2017-17668 (NCR S1 Dispenser),
CVE-2018-5717 (NCR S2 Dispenser).

Благодарности

До меня над прошивкой (правда без платы диспенсера) уже работали мои коллеги — Дима Скляров и Миша Цветков. Их наработки мне очень помогли в исследовании, за что им огромное спасибо! По части «железа» мне очень помог Алексей Стенников.

Автор: Владимир Кононович, Positive Technologies

Анализ поведения трояна Pegasus в сети

2018-07-30T04:19:00.000-07:00

Недавно был опубликован исходный код банковского трояна Pegasus. Несмотря на упоминание группы Carbanak в названии архива, исследователи из компании Minerva Labs опровергли причастность этой группы к трояну и доказали его связь с группой Buhtrap (Ratopak). Внутри архива находится краткое описание работы трояна, его исходный код, информация о системе банковских платежей и данные сотрудников многих российских банков.

Архитектура исходного кода Pegasus довольно интересна. Функциональность поделена на модули, собираемые в единый binpack на этапе компиляции. Процесс компиляции также включает в себя подпись исполняемых файлов сертификатом из файла tric.pfx, который отсутствует в архиве.

Не менее любопытна и сетевая активность трояна: после заражения он пытается распространиться внутри домена, умеет проксировать данные между машинами, используя пайпы и транспорт Mailslot. Мы сфокусировались на изучении особенностей сетевой активности трояна и оперативно добавили детекты для Pegasus в продукт PT Network Attack Discovery. Это позволит всем пользователям PT NAD своевременно обнаружить активность этого трояна и его модификаций в своей сети. В статье я дам подробное описание механизмов распространения по сети и взаимодействия между копиями Pegasus.

Попав на машину, главный модуль InstallerExe внедряет код в svchost.exe при помощи техники process hollowing, и после инициализации главных модулей Pegasus запускает несколько параллельных процессов:

Domain replication занимается разведкой внутри сети и пытается распространиться на другие Windows-машины.
Mailslot Listener слушает широковещательные mailslot-сообщения, при помощи которых Pegasus рассылает добытые учетные записи. Имя слота генерируется во время компиляции.
Pipe Server Listener слушает Windows Pipe с именем, генерируемым от имени машины. Эти пайпы используются в основном для обнаружения других копий Pegasus в сети и их взаимодействия.
Logon passwords раз в несколько минут пытается сдампить данные учетных записей модулем из Mimikatz.
Network connectivity отвечает за связь с C&C-сервером и периодический обмен сообщениями.

// start transports which links data with our CB-manager
pwInitPipeServerAsync(dcmGetServerCallback());
mwInitMailslotServer(dcmGetServerCallback());
...
// start broadcasting creds to other machines
cmStartupNetworkBroadcaster();

Domain replication

Одна из подсистем в Pegasus отвечает за горизонтальное распространение (lateral movement) в Windows-сети. Распространение делится на два важных этапа:

обнаружение соседних машин,
попытка репликации на машину.

Обнаружение соседних машин в домене осуществляется через два API-вызова — NetServerEnum, требующий для работы сервис Browser и вызовы WNetOpenEnum/WNetEnumResource.

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

Репликация происходит следующим образом. При помощи найденных учетных записей (УЗ) на хосте Pegasus предпринимает попытку авторизоваться на машине по протоколу SMB к шарам IPC$ и ADMIN$. Если доступ к IPC$ есть, а к ADMIN$ нет, то Pegasus делает вывод о том, что прав учетной записи недостаточно и их необходимо пометить как невалидные. Получив доступ к шаре ADMIN$, что является алиасом для папки %windir%, вредонос пытается определить архитектуру машины, чтобы в дальнейшем использовать подходящий модуль.

Алгоритм определения архитектуры основывается на заголовках PE-файлов на удаленной машине. В качестве такого файла Pegasus пытается прочитать первые 4 килобайта notepad.exe из папки %windir%. Неочевидный недостаток такого метода заключается в том, что на Windows Server 2012 блокнот находится по пути %windir%\System32.

Местоположение notepad.exe на Windows 7:

C:\Users\Administrator>where notepad.exe
C:\Windows\System32\notepad.exe
C:\Windows\notepad.exe

На Windows Server 2012:

C:\Users\Administrator>where notepad.exe
C:\Windows\System32\notepad.exe

Не обнаружив notepad.exe, Pegasus не может заразить сервер, даже имея данные учетной записи с необходимыми правами. Простое отсутствие блокнота в %windir% может остановить распространение Pegasus на Windows Server 2012. Использование regedit.exe в этом плане более надежно.

После успешного определения архитектуры целевого сервера Pegasus загружает небольшой дроппер RSE (Remote Service Exe) размером около 10 килобайт, задача которого загрузить binpack из модулей от Pegasus через пайп в открытом виде и передать управление на модуль shellcode. Имя дроппера составляется псевдослучайным образом и состоит из строки шестнадцатеричных символов длинной от 8 до 15 символов. Псевдослучайный генератор инициализируется в зависимости от имени целевой машины и будет одинаковым между запусками, чтобы избежать возможное засорение %windir% прошлыми копиями дроппера.

Дроппер проверяется на целостность и возможное удаление антивирусом, после чего запускается одним из двух реализованных механизмов — SCM или WMI. Причем в первую очередь Pegasus предпринимает попытку запуска RSE через механизм WMI, а только потом при помощи SCM (Service Control Manager). Делается это по той причине, что SCM оставляет больше следов в журналах Windows. В планах создателей Pegasus были и другие методы распространения (WSH Remote, PowerShell Remoting, Task Scheduler), и модуль для исполнения команд через RDP находился в разработке.

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

Поскольку код Pegasus инджектируется методом process hollowing в процесс svchost.exe, на диске не должно остаться ни первоначального модуля InstallerExe в случае первичного заражения, ни дроппера RSE в случае распространения. Если дроппер все еще доступен по известному пути, Pegasus удаляет его собственным способом:

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

После успешного заражения процесс распространения Domain replication начинается снова.

Mailslot works

После того как Pegasus получит доступ к данным учетных записей либо от другой копии Pegasus, либо от модуля mod_LogonPasswords, он начнет широковещательную рассылку данных УЗ по домену. Рассылка осуществляется при помощи основанного на SMB механизма Mailslot, который позволяет осуществить однонаправленную широковещательную рассылку небольшой порции данных по домену. Рассылка происходит по случайно сгенерированному имени слота, и, чтобы все зараженные машины в домене могли отправлять и получать данные по единому имени, псевдослучайный генератор для имен инициализируется от переменной TARGET_BUILDCHAIN_HASH, задаваемой в конфиге при билде.

Поскольку механизм Mailslot накладывает ограничение на максимальный размер пакета, рассылается за раз только одна УЗ по принципу последнего времени рассылки: среди всех имеющихся УЗ по домену рассылается та, чья дата последней рассылки самая ранняя.

Данные в мейлслотах передаются не в открытом виде, а обернутые тремя слоями XOR-шифрования, причем ключи передаются вместе с данными. Первый слой данных — это конверт NetMessageEnvelope с проверкой целостности данных алгоритмом SHA1, используемый для всех данных, передаваемых по локальной сети. Четыре байта данных в начале пакета являются ключом, который изменяется битовыми сдвигами на пять бит вправо за цикл. Внутри конверта содержится кодированная посредством XOR структура данных с полями УЗ и датой их добавления. Восьмибайтовый ключ также находится в начале структуры, но применяется без сдвигов. После декодирования структуры УЗ останется лишь десериализовать отдельные поля из структур ENC_BUFFER, такие как имя компьютера, имя домена, имя пользователя и его пароль. Шифрование этих полей осуществляется 8-байтовым ключом со смещениями. Скрипт для расшифровки пакета Mailslot и пример такого пакета можно найти на GitHub и PCAP.

Период рассылки Mailslot-сообщений в релизной версии колеблется от 20 секунд до 11 минут.

// some random wait before making next step
DbgPrint("going to sleep");
#ifdef _DEBUG
// debug - 2-5 s
Sleep(rg.rgGetRnd(&rg, 2000, 5000));
#else
// release - 20 - 650 s
//Sleep(rg.rgGetRnd(&rg, 2000, 65000) * 10);
Sleep(rg.rgGetRnd(&rg, 2000, 15000));
#endif

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

Pipe works

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

При одностороннем общении (например, передаче binpack во время репликации на другую машину) данные не шифруются и передаются в открытом виде. Binpack начинается со структуры SHELLCODE_CONTEXT длинной 561 байт.

Во время двусторонней передачи (например, проксирования данных между копией Pegasus без доступа в интернет и C&C-сервером) используется та же структура конверта NetMessageEnvelope с XOR-шифрованием, как и в случае Mailslot, так как она позволяет различать разные типы сообщений в поле id.

Архитектурноe проксирование данных выполняется через запрос на передачу порции данных (PMI_SEND_QUERY), получения id-запроса в ответ и опроса состояния задачи по id (PMI_CHECK_STATUS_QUERY). Как правило, в качестве нагрузки передается другая Envelope-структура, добавляющая различные функциональные возможности и еще один слой шифрования.

Кроме того, работа с пайпами не заканчивается на взаимодействии между зараженными машинами. Модуль mod_KBRI_hd инджектит в процессы cmd.exe код, перехватывающий вызовы MoveFileExW и анализирующий все копируемые данные, поскольку это часть механизма проведения платежей. Если копируемый файл содержит интересные злоумышленникам данные — данные с платежами, — нотификация об этом отправляется на C&C-сервер. Общение между инджектируемым в cmd.exe модулем mod_KBRI и копией Pegasus осуществляется внутри зараженной машины через пайп, имя которого не генерируется, а жестко задано в исходном коде:

\.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2

В функциональность модуля также входит подмена данных счетов на лету по шаблону. Пример паттернов для поиска на скриншоте.

C&C-трафик

За непосредственный обмен данными с C&C-сервером отвечает отдельный поток, который раз в несколько минут проверяет очередь чанков данных от внутренних процессов или от других копий вредоноса и отправляет их на сервер.
Во время инициализации модуля mod_NetworkConnectivity он проводит многоступенчатую проверку работоспособности сетевого подключения:

1) Обнаружение настроек прокси-сервера и попытка соединения с www.google.com:

в ветке реестра \\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings;
через WPAD (вызов WinHttpGetProxyForUrl);
через конфигурацию прокси-сервера для текущего пользователя (вызов WinHttpGetIEProxyConfigForCurrentUser).

2) Проверка соединения с серверами обновлений Microsoft и возвращаемых данных (authrootseq.txt, authrootstl.cab, rootsupd.exe).

3) Тестирование HTTPS-соединений с одним из шести адресов:

https://safebrowsing.google.com
https://aus3.mozilla.org
https://addons.mozilla.org
https://fhr.data.mozilla.com
https://versioncheck-bg.addons.mozilla.org
https://services.addons.mozilla.org

Только по прохождении всех проверок Pegasus считает, что имеет необходимый доступ во внешнюю сеть и может анонсировать это по домену Mailslot-сообщением. Причем Pegasus может маскироваться и общаться с C&C-сервером только в рабочие часы — с 9:00 до 19:00 по местному времени.

Чанки данных, обернутых в конверт с подсчетом хеш-суммы, Pegasus посылает в зашифрованном виде с использованием DES в режиме CRYPT_MODE_CBC/PKCS5_PADDING. Ключ шифрования зависит только от переменной во время компиляции, и таким образом мы можем расшифровывать трафик между зловредом и сервером, зная только его BUILDCHAIN_HASH. В исходных кодах внутри архива эта переменная имела значение 0x7393c9a643eb4a76. Скрипт для расшифровки «отстука» (check-in) на сервер и пример такого пакета можно найти на GitHub и PCAP.

Такой контент (структура INNER_ENVELOPE) он передает на C&C-сервер во время check-in, либо вместе с какими-либо данными. В начале находятся 28 байт конверта с полем длины и SHA1-суммой.

Те же самые данные передаются между машинами во время проксирования через пайпы, но завернутые внутрь известного нам конверта NetMessageEnvelope с хеш-суммой и XOR-шифрованием.

Оператор C&C может рассылать команды для исполнения на копии Pegasus и сообщения с командами или другими данными (например, EID_CREDENTIALS_LIST) могут содержать свои собственные слои шифрования полей, как мы уже видели на примере широковещательной рассылки учетных записей.

Detection

В первую очередь нас интересовало обнаружение активности Pegasus в сети. После тщательного изучения исходных кодов и запуска в тестовом окружении мы обнаружили те сетевые аномалии и артефакты, которые явно говорят о присутствии этого сложного вредоноса в сети. Pegasus действительно можно назвать разносторонним: он активно использует протокол SMB для рассылки сообщений и установления связи с другими копиями, распространяется на другие машины и взаимодействует с C&C-сервером на свой особый лад. Устанавливая одноранговую сеть в домене, копии Pegasus прокладывают путь до внешней сети и общаются с C&C-сервером, проксируя трафик друг через друга. Использование сертификатов для подписи исполняемых файлов и обращение к ресурсам компаний Microsoft и Mozilla во время проверки соединения затрудняет выявление его активности и обнаружение на хосте.

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

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

Мы разработали несколько сигнатур для PT NAD и IDS Suricata, позволяющих выявить специфичную для Pegasus активность в сети на разных стадиях, начиная с самых первых секунд его активности. Найти открытые сигнатуры для IDS Suricata можно на нашем GitHub и Twitter — они автоматически попадут к вашей Suricata, если вы используете механизм обновлений suricata-update.

То, как срабатывают сигнатуры на активность Pegasus, можно посмотреть на скриншоте ниже. Это наш новый продукт PT Network Attack Discovery, выявляющий инциденты и помогающий в их расследовании.

Кроме того, для обнаружения можно использовать следующие индикаторы компрометации (IC):

MAILSLOT\46CA075C165CBB2786
pipe\pg0F9EC0DB75F67E1DBEFB3AFA2

hxxp://denwer/pegasus/index.php
hxxp://mp3.ucrazy.org/music/index.php
hxxp://support.zakon-auto.net/tuning/index.asp
hxxp://video.tnt-online.info/tnt-comedy-tv/stream.php

Автор: Кирилл Шипулин из команды @attackdetection, Twitter | Telegram

Intel выпустила исправления новых уязвимостей прошивки ME

2018-07-18T01:32:00.002-07:00

В начале июля компания Intel выпустила два security advisory (SA-00112 и SA-00118), в которых описала исправления в прошивке Intel Management Engine. Оба бюллетеня безопасности описывают ошибки, позволяющие атакующему произвольное выполнение кода на внутреннем процессоре PCH (Minute IA).

Эти ошибки аналогичны тем, которые специалисты по безопасности компании Positive Technologies обнаружили в ноябре прошлого года (SA-00086). Однако история на этом не закончилась, и теперь Intel выпустила новые исправления уязвимостей в ME.

Что случилось

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

В случае с CVE-2018-3628 (описана в SA-00112) дела обстоят еще хуже. Уязвимость в процессе AMT прошивки Management Engine приводит к удаленному выполнению кода (Remote Code Execution), причем атакующему не нужно иметь учетную запись администратора AMT, как при эксплуатации CVE-2017-5712 из SA-00086.

Intel описывает эту ошибку как «Buffer Overflow in HTTP Handler», что позволяет предположить возможность выполнения кода удаленно без авторизации. Это и есть тот наихудший сценарий, которого боятся все пользователи платформ Intel. Эта ошибка аналогична нашумевшей CVE-2017-5689, найденной в мае 2017 года компанией Embedi, однако с гораздо более тяжелыми последствиями.

Что дальше

Хоть немного сгладить ситуацию может тот факт, что для CVE-2018-3628 Intel сообщает о возможности эксплуатации только из локальной подсети.

Специалисты Positive Technologies планируют в будущем провести более детальное исследование данных ошибок. Примечательно, что Intel указала те же версии прошивок, что и для SA-00086 с рекомендациями по исправлению уязвимостей. Вполне возможно, эти ошибки были найдены в процессе security review кода Intel ME как часть SA-00086, однако Intel решила опубликовать их позже, чтобы сгладить негативный эффект от количества критических ошибок в SA-00086.

Другие материалы Positive Technologies по теме безопасности Intel ME:

В компьютерах Apple закрыта уязвимость прошивки, найденная экспертами Positive Technologies

2018-06-14T06:15:00.000-07:00

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

Компания Apple выпустила обновление для macOS High Sierra 10.13.4, которое устраняет уязвимость в прошивке персональных компьютеров (CVE-2018-4251), обнаруженную экспертами Positive Technologies Максимом Горячим и Марком Ермоловым. Подробная информация об этом представлена на сайте технической поддержки Apple.

«Уязвимость позволяет злоумышленнику с правами администратора получить несанкционированный доступ к критически важным частям прошивки, записать туда уязвимую версию Intel ME и через ее эксплуатацию тайно закрепиться на устройстве. В дальнейшем он сможет получить полный контроль над компьютером и осуществлять шпионскую деятельность, без малейшей вероятности быть обнаруженным», — рассказал Максим Горячий.

О Manufacturing Mode

Intel ME имеет специальный режим работы — так называемый Manufacturing Mode, который предназначен для использования исключительно производителями материнских плат. Данный режим предоставляет дополнительные возможности, которые может использовать злоумышленник. Об опасности данного режима и его влиянии на работу Intel МЕ уже говорили исследователи, в том числе и нашей компании (How to Become the Sole Owner of Your PC), но многие производители до сих пор данный режим не выключают.

Находясь в режиме Manufacturing Mode, Intel ME позволяет выполнять специальную команду, после чего ME-регион становится доступным на запись через встроенный в материнскую плату SPI-контроллер. Имея возможность запускать код на атакуемой системе и отправлять команды в Intel ME, злоумышленник может перезаписывать прошивку Intel ME, в том числе на версию, уязвимую для CVE-2017-5705, CVE-2017-5706 и CVE-2017-5707, и таким образом выполнять произвольный код на Intel ME даже в системах с установленным патчем.

Оказалось, что в MacBook этот режим также включен. Хотя в самой прошивке предусмотрена дополнительная защита от атаки на перезапись регионов SPI Flash (в случае если доступ к какому-либо региону открыт, прошивка не позволяет загрузить ОС), исследователи обнаружили недокументированную команду, которая перезагружает Intel ME без перезагрузки основной системы, что делало возможным обход данной защиты. Стоит отметить, что похожую атаку можно провести не только на компьютерах фирмы Apple.

Positive Technologies разработали специальную утилиту, позволяющую проверить статус режима Manufacturing Mode. Скачать ее можно по этой ссылке. Если результат проверки показывает, что режим включен, мы рекомендуем вам обратиться к производителю вашего компьютера для получения инструкций по его выключению. Утилита предназначена для ОС Windows и Linux, поскольку пользователям компьютеров Apple достаточно установить указанное выше обновление.

Об Intel Management Engine

Intel Management Engine представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Через PCH осуществляется почти все общение процессора с внешними устройствами, поэтому Intel ME имеет доступ практически ко всем данным на компьютере. Исследователям удалось найти ошибку, которая позволяет выполнять неподписанный код внутри PCH на любой материнской плате для процессоров семейства Skylake и выше.

О масштабе проблемы

Уязвимые чипсеты Intel используются во всем мире, от домашних и рабочих ноутбуков до корпоративных серверов. Ранее выпущенное Intel обновление не исключало возможность эксплуатации уязвимостей CVE-2017-5705, CVE-2017-5706 и CVE-2017-5707, так как при наличии у атакующего доступа на запись к ME-региону он всегда может записать уязвимую версию МЕ и проэксплуатировать уязвимость в ней.

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

2018-03-05T03:14:00.002-08:00

Крупнейшее событие телеком-индустрии в этом году получило особенно широкое освещение в СМИ – на открытие ежегодного Всемирного мобильного конгресса (Mobile World Congress, MWC-2018) в столице Каталонии – Барселоне - прибыл лично король Испании, что вызвало волну протестов среди сторонников независимости региона от властей Мадрида. Как итог – на первых полосах всех газет и в прайм-тайме на телеканалах - высокие технологии и телеком-инновации на фоне митингующей толпы. А всем участникам и посетителям конгресса для большей безопасности рекомендовано не носить бейдж за пределами территории проведения мероприятия.

Всемирный мобильный конгресс проводится ежегодно уже более 30 лет.

В нем принимают участие операторы сотовой связи, производители всевозможных устройств связи и приложений, и даже автомобильные гиганты и международные платежные системы. К дате проведения мероприятия, без преувеличения, все игроки индустрии стараются приурочить анонс долгожданных новинок. Негласный девиз – если ты хоть что-то из себя представляешь в мобильном мире, ты должен быть в Барселоне! Даже Apple, традиционно не присутствующий на выставках, включая MWC, все равно незримо тут – журналисты, описывая новые версии гаджетов десятков азиатских вендоров, нет-нет - да и ударятся в сравнения: «как у Apple», «не хуже, чем у Apple», «совсем как у Apple».

В этом году на выставке сразу бросалось в глаза обилие роботов:

и буквально засилье автомобильных брендов, включая Mercedes, Audi, Smart:

и даже Bentley на стенде Visa, призванного символизировать концепт Connected car.

Роботы не только привлекают внимание посетителей, но и успешно работают стендистами, а также напоминают о расширенных возможностях интернета вещей. С машинами сложнее – с одной стороны, все больше и больше компонентов в них в той или иной мере имеют выход в интернет, с другой – посетителям это мало интересно, и они используют их исключительно для фотосессии. Хотя именно наличие таких высокотехнологичных устройств на столь статусном мероприятии должно было бы заставить задуматься о том, как это действительно работает и насколько это безопасно, когда твой автомобиль куда-то там подключен «вовне», а главное – зачем. И как тут не вспомнить всякие страшилки про взлом гаджетов интернета вещей. Да что там далеко за примерами ходить – уже и угрозы безопасности connected car были описаны не раз и не два. Кстати, в одном из залов был замечен болид Феррари, усыпанный логотипами спонсоров, в том числе «Лаборатории Касперского», что не может не радовать – может быть, хотя бы такое напоминание заставит участников наконец всерьез задуматься об аспектах безопасности мобильных решений, которые они предлагают.

Вообще, лучше всего все главные темы MWC-2018 и его ключевые слова сформулированы на стенде французской корпорации Atos: там упоминается буквально все, включая блокчейн.

Что же касается аспектов безопасности, то наиболее ярко выступили на MWC антивирусные вендоры, хотя стендов ИБ-компаний должно быть в разы больше, и скоро это понимание неизбежно придет! Ну а пока среди антивирусников отметим уже упомянутую выше «Лабораторию Касперского», которая свое участие в шоу в этом году посвятило аспектам безопасности интернета вещей, а также Avast c новым решением Smart Life для безопасности IoT-устройств.

Кстати, одна из стен стенда «Лаборатории Касперского» посвящена видеографике - как злоумышленники используют дыры в IoT и что они реально могут сделать. Это пресловутые «юзкейсы», которые должны убедить вендоров в важности учета безопасности при выводе на рынок своих умных девайсов (встроить видео из инсты).

Учитывая недостаток внимания к теме ИБ, мы - Positive Technologies - не могли остаться в стороне и решили восполнить этот пробел – в формате специального мероприятия для ключевых экспертов телеком-отрасли. Я и мои лондонские коллеги рассказали представителям крупнейших телеком-операторов о том, как хакеры атакуют сети SS7 и что можно делать для защиты от злоумышленников на уровне самих операторов.

Мы уже три года подряд не только анализируем возможные угрозы и векторы атак через мобильные сети, но и на практике с помощью продукта PT Telecom Attack Discovery выявляем реальные атаки.

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

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

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

Серьезные опасения связаны и с мошенничеством в отношении оператора или абонентов. Существенная часть таких атак пришлась на несанкционированную отправку USSD-запросов (81%). Подобные запросы позволяют осуществить перевод денег со счета абонента, подписать абонента на дорогостоящую услугу или отправить фишинговое сообщение от имени доверенного сервиса.

Эту тему мы поднимаем из года в год, наша задача – предупредить о реальных угрозах, чтобы операторы в разы больше внимания уделяли аспектам безопасности, а все простые абоненты тоже были начеку и не становились жертвой хотя бы банальной социальной инженерии. Отрадно, что операторы уже осознают существующие риски и делают выводы: в 2017 году во всех исследованных сетях функционировала система SMS Home Routing, а в каждой третьей сети была установлена система фильтрации и блокировки сигнального трафика. Но этого мало. На сегодняшний день мы по-прежнему видим, что все сети, которые мы проанализировали, оказались подвержены уязвимостям, связанным как с частными случаями некорректной настройки оборудования, так и с архитектурными проблемами сигнальных сетей SS7, которые невозможно устранить имеющимися средствами.

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

Автор: Дмитрий Курбатов, руководитель отдела безопасности телекоммуникационных систем Positive Technologies

В продуктах Apple закрыта уязвимость в подсистеме Intel ME, найденная экспертами Positive Technologies

2018-02-02T04:52:00.006-08:00

Компания Apple выпустила системное обновление для macOS High Sierra 10.13.2, macOS Sierra 10.12.6 и OS X El Capitan 10.11.6, устраняющее уязвимость в подсистеме Intel Management Engine, которая была обнаружена экспертами Positive Technologies Марком Ермоловым и Максимом Горячим. Подробная информация об этом представлена на сайте технической поддержки Apple.

Intel Management Engine представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Через PCH осуществляется почти все общение процессора с внешними устройствами, поэтому Intel ME имеет доступ практически ко всем данным на компьютере. Исследователям удалось найти ошибку, которая позволяет выполнять неподписанный код внутри PCH на любой материнской плате для процессоров семейства Skylake и выше. Центр безопасности Intel детально описал это в обзоре от 20 ноября и выпустил соответствующий патч. Уязвимые чипсеты используются во всем мире: от домашних и рабочих ноутбуков до корпоративных серверов.

Максим Горячий и Марк Ермолов представили доклад о технических аспектах проблемы на конференции Black Hat Europe в Лондоне в начале декабря прошлого года. С полным текстом исследования можно ознакомиться в нашем блоге.

В то же время исследователи обнаружили, что выпущенное Intel обновление не исключает возможность эксплуатации уязвимостей CVE-2017-5705, CVE-2017-5706, CVE-2017-5707, так как при наличии у атакующего доступа на запись к ME-региону, он всегда может записать уязвимую версию МЕ и проэксплуатировать уязвимость в ней.

Как взломать выключенный компьютер или выполнить код в Intel ME

2018-01-18T08:15:00.001-08:00

На прошедшей недавно конференции Black Hat Europe исследователи Positive Technologies Марк Ермолов и Максим Горячий рассказали об уязвимости в Intel Management Engine 11, которая открывает злоумышленникам доступ к большей части данных и процессов на устройстве.

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

1. Введение

Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода позволяет полностью скомпрометировать платформу. Такие безграничные возможности привлекают исследователей не первый год, но сейчас интерес к технологии Intel ME значительно вырос. Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC. К сожалению, анализ Intel ME 11-й версии был затруднен тем, что исполняемые модули упакованы кодом Хаффмана с неизвестными таблицами. Но нашей исследовательской группе удалось их восстановить (утилиту для распаковки образов можно найти на нашей странице в GitHub [2]).

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

1.1. Обзор Intel Management Engine 11

Детальное описание внутреннего устройства Intel ME и его компонентов можно найти в работах: [1], [3], [4]. Отметим, что, начиная с 2015 года в PCH было интегрировано процессорное ядро LMT набором команд х86. Такое ядро применяется в SOC Quark.

LMT2 IdCode ядра ME

C Intel Management Engine связано большое количество современных технологий Intel — Intel Active Management Technology, Intel Platform Trust Technology (fTPM), Intel Software Guard Extensions, Intel Protected Audio Video Path. Также ME является root of trust для технологий технологии Intel Boot Guard, которая не позволяет злоумышленнику внедрять свой код в UEFI. Основное назначение МЕ – начальная инициализация платформы, и запуск основного процессора. ME так же обладает практически безграничными возможности доступа к данным, которые обрабатываются на компьютере МЕ может перехватывать и модифицировать сетевые пакеты, изображение на видеокарте, имеет полный доступ к USB устройствам. Такие возможности означат, что, если злоумышленник получит возможность выполнять свой код внутри МЕ это будет означать новую эру зловредного программного обеспечения, которое невозможно обнаружить современными средствами защиты. Но к счастью за все 17 лет истории этой технологии было найдено всего 3 уязвимости (публично).

1.2. Публично известные уязвимости в Intel ME

1.2.1. Ring-3 Rootkits

Первая публичная уязвимость в Intel ME была найдена в 2009 году Alexander Tereshkin и Rafal Wojtczuk представили доклад на Black Hat Introducing Ring-3 Rootkits. Атака производилась через инъекцию кода в специализированную область памяти UMA, в которую МЕ выгружает неиспользованный в данный момент страницы памяти.

После оглашения результатов исследования Intel внедрил защиту UMA – теперь эта область шифруется AES-ом и для каждой страницы МЕ хранит ее контрольную сумму, которая проверяется при «возвращении» страницы в основную память МЕ.

1.2.2. Zero-Touch Provisioning

В 2010 году Vassilios Ververis представил атаку на реализацию МЕ в GM45. Используя режим конфигурирования «zero touch», он смог обойти авторизацию AMT.

1.2.3. Silent Bob is Silent

В мае 2017 году была опубликована уязвимость в системе авторизации AMT (CVE-2017-5689), которая позволяла неавторизованному пользователю получить полный доступ к основной системе на материнских платах с поддержкой технологии vPro.

Таким образом, до сегодняшнего времени была найдена только одна уязвимость (Ring-3 rootkits), которая позволяет выполнять произвольный код внутри Intel ME.

2. Векторы атак

Практически все данные, которые использует ME в своей работе либо явно, либо косвенно подписаны Intel. Но МЕ все-таки предоставляет некоторые возможности для взаимодействия с пользователем:

Локальный управляющий интерфейс — HECI
Сеть (только для vPro)
Память хоста (UMA)
SPI флеш
Внутренняя файловая система

2.1. HECI

HECI – представляет собой отдельное PCI-устройство, которое представляет собой кольцевой буфер и служит для обмена сообщениями между основной системой и ME.
Приложения, расположенные внутри МЕ, могут регистрировать свои обработчики для HECI. Это увеличивает количество потенциальных проблем безопасности (CVE-2017-5711). Отметим, что на компьютерах Apple HECI отключен по умолчанию.

2.2. Сеть (только vPro)

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

2.3. Аппаратная атака на SPI-интерфейс

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

2.4. Внутренняя файловая система

Intel Management Engine использует SPI flash в качестве основного файлового хранилища с собственной файловой системой. C одной стороны файловая система имеет достаточно сложную структуру [6], с другой многие привилегированные процессы хранят именно здесь свои конфигурационные фалы. Исходя из чего, файловая система показалась нам наиболее перспективным местом для воздействия на ME.

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

2.5. Выбор модуля для анализа

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

Пример статических правил для процесса

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

Одним из процессов с возможностью порождать новые является – BUP (BringUP). В процессе реверс-инжиниринга этого модуля, в функции инициализации устройства Trace Hab мы нашли переполнение стекового буфера. Файл «/home/bup/ct» не имел подписи, и мог быть интегрирован в прошивку МЕ через сервисную программу – Flash Image Tool. Это давало возможность вызвать переполнение буфера внутри процесса BUP с помощью файла инициализации BUP большого размера. Но поэксплуатировать ее можно было только после обхода защиты от переполнения стекового буфера.

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

2.6. Обход защиты от переполнения буфера

В ME реализован классический способ защиты от переполнения буфера в стеке – стековая канарейка. Реализован данный механизм следующим образом:

Для каждого процесса в момент его создания из аппаратного генератора случайных чисел в специальную область (доступную только для чтения) копируется 32-битное значение;
В прологе функции — это значение копируется над адресом возврата в стеке, тем самым защищая его;
В эпилоге функции происходит сравнение сохранённого значения с эталонным. Если оно не совпадает генерируется программное прерывание int 81h завершающие процесс.

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

Изучая функции, которые вызываются после переполнения и до проверки целостности нами было обнаружено, что функция, которую мы назвали bup_dfs_read_file косвенно вызывает memcpy. Она в свою очередь использует в качестве значения целевого адреса, данные полученные из некоторой структуры, которую мы назвали TLS (Tread Local Storage). Стоит отметить, что функции bup для чтения и записи файлов, используют сервисы системной библиотеки для работы с общей памятью (shared memory). Используя его, функции чтeния и записи, получают и записывают информацию. Но никто кроме BUP эти данные не использует, поэтому использование этого механизма может показаться сомнительными. Мы считаем, что это связано с тем, что часть кода BUP, который взаимодействует с MFS скопирован из другого модуля – драйвера файловой системы, где использование общую память оправдано.

Вызов функции memcpy

Получение адреса из TLS

Как выяснилось позже, при переполнении буфера эта область TLS может быть перезаписана функцией чтения файла, что позволяет обойти защиту от переполнения буфера.

2.7. Tread Local Storage

Все обращение к структуре TLS происходит через сегментный регистр gs сама же структура имеет следующий вид:

Структура TLS

Получение полей TLS

Сегмент, на который указывает gs, не доступен на запись, но сама структура TLS расположена на дне стека (!!!), что позволяет изменять ее в обход ограничения. Таким образом, при переполнении буфера мы можем перезаписать указатель на TLS и формировать структуру SYSLIB_CTX. А алгоритм работы алгоритм работы функции bup_dfs_read_file, используя этот трюк, позволяет получить arbitrary write.

2.8. Использование реализации функции чтения для получения arbitrary write primitive

Функция bup_dfs_read_file считывает данные с SPI-flsh блоками по 64 байта, что позволяет вначале перезаписать указатель на SYSLIB_CTX а TLS. На следующей итерации функция sys_write_shared_mem извлекает адрес, который мы сформировали и передает его в memcpy в качестве целевого адресса. Это позволяет получить примитив записи внутри процесса BUP.

Итеративное чтение файла внутри bup_dfs_read_file

Отсутствие ASLR позволяет перезаписать адрес возврата функцией memcpy и перехватить управление. Тут так же поджидает неприятность для атакующего – стек не является исполняемым. Но пользуясь тем, что BUP умеет создавать новые процессы и сам проверяет подпись для запускаемых модулей, мы можем с помощью возвратно-ориентированного программирования (Return Oriented Programming — ROP) создать новый процесс с заданными правами.

2.9. Возможные векторы эксплуатации

Для успешной эксплуатации данной уязвимости необходим доступ на запись в MFS или целиком в Intel ME регион. Производителям оборудования должны блокировать доступ к региону с ME региону, но к сожалению, это делают далеко не все [8]. В случае, если на системе присутствует такая ошибка конфигурации – это автоматически делает ее уязвимой.

В Intel ME предусмотрена штатная возможность обеспечивать доступ на запись к МЕ региону через отправку специального сообщения HMR-FPO по HECI из BIOS [9]. Атакующий может послать такое сообщение используя уязвимость в BIOS или DMA-атаку.
В случае физического доступа к атакуемой машине атакующий всегда может переписать на свой образ (через SPI-программатор или используя специальную перемычку), что приводит к полному взлому платформы.

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

Атакуется платформа с активированным AMT.
Атакующий знает пароль администратора AMT или использует уязвимость для обхода авторизации.
BIOS не имеет пароля (или он известен злоумышленнику).
BIOS имеет опцию, позволяющую открывать доступ на запись в ME регион.

Выполнение этих условий позволяет атакующему получить доступ к ME региону удалённо.

Отметим так же, что ROM не контролирует версию Intel ME при запуске, что делает возможным обновлением на старую версию, содержащую уязвимость.

2.10. Обзор уязвимостей CVE-2017-5705,6,7

Найденной уязвимости был присвоен номер INTEL-SA-00086 (CVE-2017-5705, CVE-2017-5706, CVE-2017-5707). Приведем небольшую выдержку из его описания:

CVSSv3 Vectors:

8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected products:

6th, 7th & 8th Generation Intel Core Processor Family
Intel Xeon Processor E3-1200 v5 & v6 Product Family
Intel Xeon Processor Scalable Family
Intel Xeon Processor W Family
Intel Atom C3000 Processor Family
Apollo Lake Intel Atom Processor E3900 series
Apollo Lake Intel Pentium
Celeron N and J series Processors

2.11. Disclosure Timeline

June 27, 2017 — Bug reported to Intel PSIRT
June 28, 2017 — Intel started initial investigation
July 5, 2017 — Intel requested proof-of-concept
July 6, 2017 — Additional information sent to Intel PSIRT
July 17, 2017 — Intel acknowledged the vulnerability
July 28, 2017 — Bounty payment received
November 20, 2017 — Intel published SA-00086 security advisory

3. Заключение

Таким образом, нами была найдена уязвимость Intel ME, которая позволяет выполнять произвольный код. Это ставит под угрозу все технологии такие технологии как Intel Protected Audio Video Path (PAVP), Intel Platform Trust Technology (PTT или fTPM), Intel BootGuard, Intel Software Guard Extention (SGX) и многие другие.

Эксплуатируя найденную нами уязвимость в модуле bup, нам удалось включить механизм, называемый PCH red unlock, который открывает полный доступ ко всем устройствам PCH, для использование их через DFx chain, иначе говоря с помощью JTAG. Одним из таких устройств и является само ядро ME. Это дало возможность отлаживать код, выполняемый на ME, читать память всех процессов и ядра, а так же, управлять всеми устройствами внутри PCH. Мы насчитали в совокупности порядка 50 внутренних устройств, полный доступ к которым имеет только ME, а основной процессор только к весьма ограниченному их подмножеству.

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

Авторы: Марк Ермолов и Максим Горячий

Список литературы

[1] Dmitry Sklyarov, Intel ME: The Way of the Static Analysis, Troopers 2017.
[2] Intel ME 11.x Firmware Images Unpacker.
[3] Xiaoyu Ruan, Platform Embedded Security Technology Revealed.
[4] Igor Skochinsky, Intel ME Secrets. Hidden code in your chipset and how to discover what exactly it does, RECON 2014.
[5] Alexander Tereshkin, Rafal Wojtczuk, Introducing Ring-3 Rootkits, Black Hat USA, 2009.
[6] Dmitry Sklyarov, Intel ME: flash file system explained, Black Hat Europe, London, 2017.
[8] Alex Matrosov, Who Watch BIOS Watchers?
[9] Марк Ермолов, Максим Горячий, «Как стать единоличным владельцем собственного компьютера», PHDays VI.

Восстановление таблиц Хаффмана в Intel ME 11.x

2017-12-06T04:54:00.001-08:00

Сегодня эксперт Positive Technologies Дмитрий Скляров на конференции Black Hat в Лондоне расскажет о том, как устроена файловая система на которой располагается часть Intel CSME / ME версий 11.x и некоторые файлы для этой системы. Мы представляем вашему вниманию его статью о восстановлении таблиц Хаффмана в Intel ME 11.x.

Как известно [1], многие модули Intel ME 11.x хранятся во Flash-памяти в упакованном виде, и для сжатия применяются два алгоритма — LZMA и Huffman Encoding [2]. Для LZMА существует публичная реализация [3], которую можно использовать для распаковки, но для Huffman все сложнее. Распаковщик Huffman Encoding в ME реализован на аппаратном уровне, и построение эквивалентного программного кода представляет собой сложную и нестандартную задачу.

Предыдущие версии ME

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

Также примечательны следующие свойства:

Для разных наборов таблиц диапазоны длин кодовых слов различаются (7–19 и 7–15 бит включительно).
Каждая кодовая последовательность кодирует целое количество байт (от 1 до 15 включительно).
В обоих наборах используется Canonical Huffman Coding [5] (это позволяет быстро определять длину очередного кодового слова при распаковке).
В пределах одного набора длины закодированных значений для любого кодового слова совпадают во всех таблицах (Code и Data).

Постановка задачи

Можно предположить, что в таблицах Хаффмана для ME 11.x три последних свойства также соблюдаются. Тогда для полного восстановления таблиц требуется найти следующее:

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

Разбиение сжатых данных на отдельные страницы

Для получения информации об отдельных модулях можно использовать имеющиеся знания о внутренних структурах прошивки [6].

Разобрав Lookup Table, являющуюся частью Code Partition Directory, легко определить, для каких модулей применяется кодирование Хаффмана, где начинаются их упакованные данные и какой размер модуль будет иметь после распаковки.

Разобрав Module Attributes Extension для конкретного модуля, несложно найти размер сжатых и распакованных данных и SHA256 от распакованных данных.

Бегло проанализировав несколько прошивок для ME 11.x, легко заметить, что размер данных после распаковки Хаффманом всегда кратен размеру страницы (4096 == 0x1000 байт). В начале упакованных данных располагается массив четырехбайтовых целочисленных значений. Количество элементов массива соответствует количеству страниц в распакованных данных.
Например, для модуля размером 81920 == 0x14000 байт массив будет занимать 80 == 0x50 байт и состоять из 20 == 0x14 элементов.

В двух старших битах каждого из Little-Endian-значений хранится номер таблицы (0b01 для кода и 0b11 для данных). В оставшихся 30 битах хранится смещение начала сжатой страницы относительно конца массива смещений. Приведенный выше фрагмент описывает 20 страниц:

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

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

На скриншоте видно, что последняя сжатая страница (начинающаяся по смещению 0xFA40) состоит из байта 0xB2 == 0b10110010, за которым идет 273 байта со значением 0xEC == 0b11101100, и дальше — только нули. Так как битовая последовательность 11101100 (или 01110110) повторяется 273 раза, можно предположить, что она кодирует 4096/273 == 15 одинаковых байт (скорее всего со значениями 0x00 или 0xFF). Тогда битовая последовательность 10110010 (или 1011001) кодирует 4096-273*15 == 1 байт.

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

Нахождение пар «сжатый текст — открытый текст»

Как было показано ранее [6], в разных версиях прошивок для ME 11 модули с одинаковыми названиями могут упаковываться разными алгоритмами. Если разобрать Module Attributes Extension для одноименных модулей, упакованных как LZMA так и Хаффманом, и извлечь значения SHA256 для каждого модуля, — то не обнаружится ни одной пары модулей, упакованных разными алгоритмами и имеющих одинаковые значения хешей.

Но если вспомнить, что для модулей, упакованных LZMA, SHA256 обычно считается от сжатых данных, и посчитать SHA256 для модулей после распаковки LZMA, — обнаружится достаточно много подходящих пар. И для каждого такого «парного» модуля мы сразу получим несколько пар страниц — в упакованном Хаффманом и распакованном виде.

Shape, Length, Value

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

Самое важное — хотя бы примерно определить Shape (точки изменения длин кодовых последовательностей). Например, что 7-битовые последовательности имеют значения от 1111111 до 1110111, 8-битовые от 11101101 до 10100011, и т. д. Так как используется Canonical Huffman Coding, знание Shape позволяет определить длину следующей кодовой последовательности (самая короткая последовательность состоит только из единиц, самая длинная — только из нулей, и чем меньше значение, тем длиннее последовательность).

Так как мы не знаем точный размер сжатых данных, можно выкинуть из «хвоста» все последовательности, состоящие только из нулевых бит (так как они самые длинные, и появление самой редкой кодовой последовательности в последней позиции маловероятно).

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

При наличии достаточного количество страниц (и уравнений) единственное решение системы легко находится методом Гаусса. А имея открытый текст, зная длину каждого значения и порядок их следования, несложно получить соответствие кодовых последовательностей и кодируемых ими значений.

Неизвестные последовательности

После обработки всех доступных «парных» страниц получится выяснить значения примерно для 70% последовательностей из кодовой таблицы и 68% последовательностей из таблицы данных. Длины будут известны примерно для 92% последовательностей. И останется некоторая неопределенность в Shape: в некоторых местах может использоваться или одно значение меньшей длины или два значения большей длины, и определить границу невозможно, пока одно из значений не встретится в упакованных данных.

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

Верификатор и brute-force

К счастью, в метаданных хранится SHA256 от распакованного модуля. И если мы правильно угадаем значение всех неизвестных кодовых последовательностей во всех страницах, составляющих модуль, вычисленное значение SHA256 должно совпасть со значением SHA256 из Module Attributes Extension.

Когда суммарная длина неизвестных последовательностей составляет 1 или 2 байта, неизвестные байты элементарно находятся лобовым перебором. Так же можно поступать с 3 и даже 4 неизвестными байтами (особенно если они расположены близко к концу модуля), но перебор может занять от нескольких часов до нескольких дней на одном ядре (легко распараллелить на несколько ядер или машин). Попытки перебора 5 и более байт не предпринимались.

Таким образом удается восстановить еще несколько кодовых последовательностей (и несколько модулей). Но потом остаются только модули, в которых суммарный объем неизвестных байт превышает возможности brute-force-подбора.

Эвристики

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

Использование второй таблицы Хаффмана

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

Многократное использование

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

Константы и таблицы со смещениями

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

Строковые константы из открытых библиотек

Некоторые фрагменты кода ME явно были позаимствованы из open-source-проектов (например, wpa_supplicant), и фрагменты текстовых строк легко угадываются по контексту и путем подглядывания в исходники.

Код из открытых библиотек

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

Сходимость процесса

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

Этот модуль самый большой по размеру (порядка 2 мегабайт, примерно 30% от общего объема), содержит множество кодовых последовательностей, которые не встречаются ни в одном другом модуле, но встречаются во всех версиях amt. Можно с высокой вероятностью угадать несколько последовательностей, но единственный способ проверить предположение — угадать их все (чтобы совпало SHA256). Благодаря неоценимой помощи Максима Горячего нам удалось преодолеть и этот барьер, вследствие чего мы получили возможность распаковывать любой из модулей, содержащийся в имеющихся у нас прошивках и упакованный алгоритмом Хаффмана.

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

Финальный штрих

К середине июня 2017 года мы смогли восстановить примерно 89,4% последовательностей для кодовой таблицы и 86,4% последовательностей для таблицы данных. Но шансы построить за разумное время 100% покрытие таблиц через анализ новых модулей весьма слабы.

19 июня на GitHub пользователем с ником IllegalArgument были опубликованы фрагменты таблиц Хаффмана [7], покрывающих 80,8% последовательностей для кодовой таблицы и 78,1% последовательностей для таблицы данных. Вероятно, автор (или авторы) использовали аналогичный подход, основанный на анализе имеющихся прошивок. И в опубликованных таблицах не оказалось ничего нового.

А 17 июля Марк Ермолов и Максим Горячий получили возможность узнавать распакованные значения для любых сжатых данных. Мы подготовили 4 сжатых страницы (по две для кода и для данных), и восстановили все 1519 последовательностей для обеих таблиц [8].

При этом обнаружилось одно непонятное место. В таблице Хаффмана для данных значение 00410E088502420D05 соответствует как последовательности 10100111 (длиной 8 бит), так и последовательности 000100101001 (длиной 12 бит). Это явная избыточность, но скорее всего она обусловлена случайной ошибкой.

Итоговый Shape имеет следующий вид:

Ссылки

Автор: Дмитрий Скляров, Positive Technologies

Intel устранила найденную экспертами Positive Technologies уязвимость в подсистеме Management Engine

2017-11-23T07:39:00.000-08:00

Компания Intel опубликовала бюллетень безопасности, в котором сообщила о выпуске патча для устранения уязвимости в подсистеме Intel ME, которая была обнаружена экспертами Positive Technologies Марком Ермоловым и Максимом Горячим. Также компания Intel опубликовала специальный инструмент, который поможет администраторам Windows и Linux-систем узнать о том, уязвимо ли их оборудование.

Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Через PCH осуществляется почти все общение процессора с внешними устройствами, поэтому Intel ME имеет доступ практически ко всем данным на компьютере. Исследователям удалось найти ошибку, которая позволяет выполнять неподписанный код внутри PCH на любой материнской плате для процессоров семейства Skylake и выше.

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

В бюллетене безопасности Intel представлен полный список уязвимых процессоров:

Intel Core поколений 6, 7 и 8;
Intel Xeon E3-1200 v5 и v6;
Intel Xeon Scalable;
Intel Xeon W;
Intel Atom C3000;
Apollo Lake Intel Atom E3900;
Apollo Lake Intel Pentium;
чипы Celeron серий N и J.

Как пояснил Максим Горячий, «модуль Intel ME — это основной компонент огромного количества устройств по всему миру. Именно поэтому мы сочли необходимым оценить степень его защищенности. Этот модуль сидит глубоко под ОС и позволяет увидеть обширный ряд данных. Злоумышленник может воспользоваться этим привилегированным уровнем доступа для проведения атак, скрытых от внимания таких традиционных способов защиты, как антивирусное ПО. Наше тесное сотрудничество с компанией Intel было нацелено на ответственное раскрытие, и Intel предприняла превентивные меры и разработала инструмент, позволяющий определить, уязвима ли система. Подробно это описано на сайте Intel. Мы планируем выступить на конференции Black Hat Europe и рассказать о выявленной уязвимости подробнее».

Критические уязвимости в протоколе защиты Wi-Fi: последствия и советы по защите

2017-10-23T09:15:00.000-07:00

Группа исследователей информационной безопасности обнаружила критические уязвимости в протоколе WPA2 (Wi-Fi Protected Access II protocol). По словам специалистов, найденные ошибки позволяют перехватывать Wi-Fi трафик, передаваемый между устройствами и точками доступа.

PoC-эксплоит для демонстрации атаки получил название KRACK (сокр. от Key Reinstallation Attacks). Эксперты Positive Technologies объясняют, насколько серьезна проблема и как не стать жертвой хакеров.

Масштаб проблемы

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

Хакеры могут перехватить все, что пользователь решит ввести после подключения к сети Wi-Fi: логины и пароли для доступа к почте, сайтам, банковским ресурсам, данные кредитных карт, приватные сообщения, личную переписку. Исключение составляет - HTTPS. Атака с использованием обнаруженной уязвимости не позволяет получить в открытом виде защищенный HTTPS-трафик, если только злоумышленник не использует достаточно сложные и при этом заметные для подготовленного пользователя атаки.

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

Как защититься

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

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

Как защититься от вредоносного ПО, эксплуатирующего уязвимость Windows CVE-2017-8759

2017-09-20T07:18:00.000-07:00

Эксплуатация этой уязвимости позволяет атакующему получить полный контроль над системой жертвы. Эксперты Positive Technologies предупреждают о росте угроз для пользователей Windows с установленным .NET Framework и дают рекомендации по защите.

12 сентября стало известно об уязвимости CVE-2017-8759 в .NET Framework (версии 2.0, 3.5, 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2 и 4.7), приводящей к выполнению произвольного кода на атакуемой системе. В отчете компании FireEye говорится об использовании данной уязвимости при распространении трояна FinSpy.

Эксплойт для CVE-2017-8759 появился в сети уже на следующий день после публикации уязвимости, и сейчас эксперты Positive Technologies прогнозируют лавинообразный рост количества вредоносного ПО, эксплуатирующего ее. Также в публичном доступе можно найти демонстрационное видео, на котором показано, как вредоносный код встраивается в документы MS Word и выполняется в случае, когда пользователь открывает файл для просмотра на уязвимом узле. В результате этого действия нарушитель получает полный контроль над атакуемой системой и может выполнять любые действия на компьютере жертвы, в частности:

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

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

Злоумышленник получает возможность удаленно управлять компьютером после открытия на нем документа

Эксплойт можно адаптировать для использования в качестве плагина к распространенному ПО для проведения тестов на проникновение Metaspoit Framework или Cobalt Strike. В таком случае злоумышленнику, который будет использовать доступный публично плагин, не нужно обладать специальными знаниями: за счет автоматизации сложность атаки существенно снижается. Достаточно лишь отправить по почте фишинговое письмо с прикрепленным вредоносным документом, название которого заинтересует получателя. Когда жертва откроет документ, атакующий получит доступ к системе.

Такой подход используют киберпреступники из группы Cobalt, методы которых детально описаны в наших отчетах (первый, второй). Поэтому мы не исключаем переход группы на эксплойт для CVE-2017-8759 в самое ближайшее время.

Уязвимости ПО и операционных систем, для которых существуют опубликованные эксплойты, представляют угрозу для компаний и простых пользователей, поэтому для минимизации возможных рисков, связанных с CVE-2017-8759, мы рекомендуем как можно скорее установить актуальное обновление Microsoft (от 12.09.2017), устраняющее выявленную проблему.

Необходимо регулярно проводить анализ ресурсов на наличие уязвимых версий ПО и обновлять системы. В ходе работ по тестированию на проникновение мы в 91% случаев обнаруживаем в исследуемых системах уязвимые версии ПО. Использование уязвимого ПО ежегодно входит в топ-10 наиболее распространенных векторов атак на инфраструктуру и во многих случаях позволяет либо преодолеть периметр сети, либо повысить привилегии на сервере до максимальных (при компрометации узла).

Для поиска узлов инфраструктуры, подверженных уязвимостям, можно использовать MaxPatrol 8 — систему контроля защищенности и соответствия стандартам.

Статистика атак на веб-приложения: II квартал 2017 года

2017-09-14T05:39:00.000-07:00

В данном исследовании представлена статистика атак на веб-приложения за II квартал 2017 года. Исходные данные были получены в ходе пилотных проектов по внедрению межсетевого экрана уровня приложений PT Application Firewall, а также по итогам работы PT AF для защиты веб-приложений компании Positive Technologies.

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

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

Ресурсы Positive Technologies рассматриваются в совокупности с ресурсами компаний из сферы информационных технологий.

Основные результаты

Статистика атак на веб-приложения

Типы атак

Наиболее часто во II квартале 2017 года встречались атаки на пользователей веб-приложений «Межсайтовое выполнение сценариев». Атаки «Внедрение SQL-кода», направленные на получение доступа к чувствительной информации или выполнение команд ОС и проникновение в систему, составили, как в I квартале, примерно четверть от общего числа зафиксированных атак. Мы ожидаем, что два этих типа атак будут и впредь совместно составлять по меньшей мере половину всех атак на веб-приложения. Кроме того, в рейтинг вошли атаки «Утечка информации» и «Внедрение конструкций XML», также позволяющие получить доступ к информации.

Рисунок 1. Топ-10 атак на веб-приложения

Возросло число атак на пользователей веб-приложений

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

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

Рисунок 2. Топ-5 атак на веб-приложения госучреждений

Кража конфиденциальной информации является основным мотивом нарушителей и в сфере здравоохранения: более половины атак были направлены на получение доступа к данным. В сфере здравоохранения за последнее время произошло несколько крупных утечек данных, например в мае хакерская группировка The Dark Overlord опубликовала около 180 000 записей пациентов из трех медицинских центров. Затем произошел инцидент в литовской клинике пластической хирургии: хакеры опубликовали более 25 000 интимных фото пациентов до и после операций. Предварительно хакеры требовали выкуп как у самой клиники (в размере 344 000 евро), так и у пациентов (сумма выкупа за удаление данных достигала 2000 евро). Кроме того, в мае из-за уязвимости в веб-приложении пострадала компания Molina Healthcare, инцидент затронул почти 5 миллионов пациентов, чьи персональные данные оказались в открытом доступе.

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

Рисунок 3. Топ-5 атак на веб-приложения сферы здравоохранения

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

Рисунок 4. Топ-5 атак на веб-приложения IT-компаний

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

Рисунок 5. Топ-5 атак на веб-приложения сферы образования

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

Рисунок 6. Топ-5 атак на веб-приложения энергетических и промышленных компаний

На рисунке ниже приведен пример обнаружения удаленного выполнения команд — эксплуатации уязвимости CVE-2017-5638 в Apache Struts. Это бесплатный фреймворк с открытым исходным кодом, который используется для создания веб-приложений на Java. Уязвимость позволяет атакующему выполнять произвольный код на сервере, изменив содержимое HTTP-заголовка Content-Type. Информация об уязвимости появилась в марте этого года, а первые попытки эксплуатации в рассматриваемых системах были зафиксированы 3 апреля.

Рисунок 7. Пример обнаружения атаки «Удаленное выполнение кода и команд ОС»

Еще один пример атаки «Удаленное выполнение кода и команд ОС» демонстрирует, как злоумышленники пытаются эксплуатировать не только уязвимости веб-приложений, но и уязвимости прошивок сетевых устройств. Уязвимость CVE-2017-8220 была опубликована 25 апреля, а 28 апреля злоумышленники уже начали атаковать устройства.

Рисунок 8. Пример обнаружения атаки «Удаленное выполнение кода и команд ОС»

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

Использование устаревшего ПО значительно облегчает работу злоумышленников, ведь в открытом доступе можно найти не только информацию обо всех известных уязвимостях, но готовые эксплойты к ним. Нарушитель может узнать версию используемых компонентов как вследствие раскрытия информации из-за недостатков конфигурации приложения, так и по результатам эксплуатации уязвимостей, специфичных для определенных версий. В одной из компаний, где проводились пилотные проекты, использовалась устаревшая версия Joomla, чем и намеревался воспользоваться злоумышленник, пытаясь эксплуатировать уязвимость, известную еще с 2015 года, которая позволяет выполнить произвольный код (CVE-2015-8562).

Рисунок 9. Пример обнаружения атаки «Удаленное выполнение кода и команд ОС»

Таковы основные типы отдельно взятых атак на веб-приложения, но существуют также цепочки, состоящие из нескольких целенаправленных атак, и при расследовании инцидентов крайне важно вовремя выявлять их и останавливать их развитие. Межсетевой экран при этом должен в реальном времени выявлять корреляции среди всех зафиксированных событий. Необходимо учитывать, что злоумышленники в целях маскировки могут прибегать к различным приемам для сокрытия своих действий: применять различные методы взлома, делать перерывы между отдельными атаками или изменять IP-адрес. Пример выявленной цепочки атак «Внедрение SQL-кода» в интерфейсе PT AF представлен на рисунках ниже. В цепочку вошло 38 атак, каждой из которых был присвоен высокий уровень риска.

Рисунок 10. Пример выявленной цепочки атак «Внедрение SQL-кода»

Рисунок 11. Атаки «Внедрение SQL-кода», входящие в одну корреляционную цепочку

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

Рисунок 12. Среднее число атак в день по отраслям

Во II квартале повысился интерес нарушителей к атакам на пользователей приложений. В то же время целью значительной части атак является доступ к чувствительной информации.

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

Источники атак

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

Рисунок 13. Источники атак по числу уникальных IP-адресов

Также можно разбить исследуемые системы по отраслям. Страны-источники атак представлены для каждой отрасли на рисунках ниже. Диаграммы распространения источников атак были автоматически созданы в веб-интерфейсе межсетевого экрана PT AF. Анализ проводился по количеству заблокированных запросов.

Атаки на государственные организации в первую очередь осуществлялись с IP-адресов, принадлежащих провайдерам из России (61% атак), Великобритании (8%), Франции (20%), США (4%) и Украины (2%).

Как и в первом квартале, среди источников атак на IT-компании выделяются IP-адреса США (27% атак), России (22%), Китая (9%), Франции (9%) и Нидерландов (5%).

В сфере образования IP-адреса нарушителей в основном относились к США (22% атак), России (30%), Индонезии (7%), Франции (5%) и Китаю (4%).

В связи с тем, что большинство «пилотов» в сфере здравоохранения проводились для российских компаний, почти три четверти IP-адресов нарушителей принадлежали российским провайдерам (74% атак), следом идут Украина (5%), Франция (4%) и США (4%).

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

Динамика атак

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

Рисунок 19. Количество атак в сутки по типам

Существенную часть атак составляет «Межсайтовое выполнение сценариев», причем средние значения находятся в диапазоне от 100 до 250, число таких атак являлось высоким на протяжении всего квартала.

На диаграмме выделяются и атаки «Внедрение SQL-кода». Средние значения лежат в промежутке от 40 до 200 атак в день. Поиски уязвимостей, связанных с недостаточной фильтрацией входящих данных перед использованием в SQL-запросах, характеризуются высокой интенсивностью в рамках отдельной атаки. Самая мощная атака на веб-приложение во II квартале года представляла собой поиск такой уязвимости с помощью перебора всевозможных параметров, всего нарушитель отправил более 35 000 запросов.

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

В целом среднее количество атак других типов редко превышает 100 в день.

На следующем рисунке приведена общая интенсивность атак за II квартал по всем отраслям — среднее количество запросов в сутки для одной компании.

Рисунок 20. Распределение атак по дням недели

Во II квартале уровень активности нарушителей снизился незначительно по сравнению с предыдущим периодом. В среднем число атак в сутки варьировалось от 300 до 800 и не опускалось ниже 140. Максимальное количество зафиксированных атак на одну компанию в день составило 35 135, что почти в два раза превысило рекордное значение прошлого квартала. Практически все эти атаки были совершены с одного IP-адреса. Злоумышленник пытался найти уязвимость «Внедрение SQL-кода», по всей видимости используя специальные сценарии. На следующих рисунках продемонстрирована динамика атак на эту компанию за три дня и за час, в который сайт подвергался мощной атаке.

Рисунок 21. Интенсивная атака «Внедрение SQL-кода» 3 мая (интерфейс PT AF)

Рисунок 22. Интенсивная атака «Внедрение SQL-кода» в течение часа (интерфейс PT AF)

Подсчитаем усредненное распределение зафиксированных атак в течение суток для одной компании. На рисунке ниже представлены средние значения по всем отраслям (учитывалось местное время атакуемой организации).

Рисунок 23. Распределение атак по времени суток

Разброс атак схож с картиной, которую мы получили в I квартале, число атак снова стабильно в любое время суток, с увеличением интенсивности в дневные и вечерние часы. Для наглядности приведем график за 17 апреля, построенный в интерфейсе PT AF для одной из компаний. На рисунке также видно, что значительная часть атак пришлась на вторую половину дня: на графике присутствуют пики, соответствующие повышенной частоте запросов.

Рисунок 24. Динамика атак 17 апреля (интерфейс PT AF)

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

Атаки злоумышленников в ночное время могут быть вызваны тем, что в это время вероятность обнаружения атаки и реагирования на нее со стороны службы безопасности компании значительно ниже. Это относится именно к целевым атакам. В случае же с массовыми атаками, например когда злоумышленники отрабатывают технику или проверяют работоспособность эксплойта на случайных сайтах или целом списке IP-адресов, данная закономерность не прослеживается. Исследование показало, что атаки совершаются из разных частей земного шара, поэтому — в связи с разницей в часовых поясах — сложно предсказать наиболее вероятное время их реализации в отношении конкретной системы.

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

Выводы

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

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

Выключаем Intel ME 11, используя недокументированный режим

2017-08-28T06:57:00.000-07:00

В ходе исследования внутренней архитектуры Intel Management Engine (ME) 11-й версии был обнаружен механизм, отключающий эту технологию после инициализации оборудования и запуска основного процессора. О том, как мы нашли этот недокументированный режим, и о его связи с государственной программой построения доверительной платформы High Assurance Platform (HAP) мы расскажем в этой статье.

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

Введение

Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода позволяет полностью скомпрометировать платформу. Такие безграничные возможности привлекают исследователей не первый год, но сейчас интерес к технологии Intel ME значительно вырос. Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC. К сожалению, анализ Intel ME 11-й версии был затруднен тем, что исполняемые модули упакованы кодом Хаффмана с неизвестными таблицами. Но нашей исследовательской группе (Дмитрий Скляров, Марк Ермолов, Максим Горячий) удалось их восстановить (утилиту для распаковки образов можно найти на нашей странице в GitHub).

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

Как выключить ME

Как выключить ME — этот вопрос часто задают некоторые владельцы компьютеров x86-архитектуры. Тема деактивации неоднократно поднималась, в том числе и исследователями нашей компании.

Актуальности этому вопросу добавляет недавно обнаруженная критическая (9,8 из 10) уязвимость в Intel Active Management Technology (AMT) — технологии, которая базируется на Intel ME.

Сразу огорчим читателя — полностью выключить ME на современных компьютерах невозможно. Это связано прежде всего с тем, что именно эта технология отвечает за инициализацию, управление энергопотреблением и запуск основного процессора. Сложности добавляет и тот факт, что часть кода «жестко прошита» внутри микросхемы PCH, которая выполняет функции южного моста на современных материнских платах. Основным средством энтузиастов, которые «борются» с данной технологией, является удаление всего «лишнего» из образа flash-памяти при сохранении работоспособности компьютера. Но сделать это не так просто, так как, если встроенный в PCH код не найдет во flash-памяти модули ME или определит, что они повреждены, система запущена не будет. Уже несколько лет в сети развивается проект me_cleaner, в рамках которого доступна специальная утилита, позволяющая удалить большую часть образа и оставить только жизненно необходимые для основной системы компоненты. Но даже если система запустилась, радоваться рано — приблизительно через 30 минут может произойти автоматическое отключение, так как при некоторых сбоях ME переходит в Recovery-режим, в котором не функционирует больше некоторого фиксированного времени. В итоге процесс очистки усложняется. Например, до 11-й версии удавалось уменьшить размер образа до 90 KБ, но в 11-й — уже только до 650 КБ.

Рисунок 1. Поддержка архитектур Skylake+ в me_cleaner

Секреты в QResource

Intel дает производителям материнских плат возможность задать небольшое количество параметров ME. Для этого компания предоставляет производителям оборудования специальный набор программного обеспечения, в который входят такие утилиты, как Flash Image Tool (FIT) для настройки параметров ME и Flash Programming Tool (FPT), реализующая поддержку программирования flash-памяти напрямую через встроенный SPI-контроллер. Данные программы недоступны конечному пользователю, но их без труда можно найти в интернете. Из этих утилит можно извлечь большое количество файлов формата XML (подробное Intel ME: The Way oftheStatic Analysis), изучение которых позволяет узнать много интересного: структуру прошивки ME и описание PCH strap — специальных конфигурационных битов для различных подсистем, интегрированных в микросхему PCH.

Рисунок 2. Упакованные XML-файлы

Нас заинтересовало одно из таких полей с именем «reserve_hap», так как напротив него имелся комментарий — High Assurance Platform (HAP) enable.

Рисунок 3. PCH strap для High Assurance Platform

Поиск в Google не был долгим. Буквально вторая ссылка говорит, что такое название носит программа по созданию доверительных платформ, связанная с Агентством национальной безопасности (АНБ) США. Презентацию с описанием программы можно найти тут. Нашей первой мыслью было поставить этот бит и посмотреть, что будет. Это может сделать любой желающий, если у него есть SPI-программатор или доступ в Flash Descriptor (на многих материнских платах некорректно выставлены права доступа к регионам flash-памяти).

Рисунок 4. Статус ME после активации HAP-бита

После загрузки платформы утилита meinfo сообщает странный статус — Alt Disable Mode. Беглые проверки показали, что ME не отвечает на команды и никак не реагирует на воздействия из операционной системы. Мы решили разобраться, как система переходит в этот режим и что он означает. К этому времени у нас уже была проанализирована основная часть модуля BUP, который отвечает за начальную инициализацию платформы и, исходя из вывода meinfo, устанавливает этот статус. Для понимания алгоритма работы BUP необходимо более подробно описать программное окружение Intel ME.

Программная часть Intel ME 11

Начиная с PCH 100-й серии компания Intel полностью переработала эту микросхему. Был осуществлен переход на новую архитектуру встроенных микроконтроллеров — с ARCompact компании ARC на x86. За основу был выбран 32-битный микроконтроллер Minute IA (MIA), который используется в микрокомпьютерах Intel Edison и SoC Quark. Он основан на дизайне весьма старого, скалярного микропроцессора Intel 486 с добавлением системы команд (ISA) от процессора Pentium. Однако для PCH компания выпускает данное ядро с применением 22-нм полупроводниковой технологии, получая высокую энергоэффективность микроконтроллера. Таких ядер в новом PCH три: Management Engine (ME), Integrated Sensors Hub (ISH) и Innovation Engine (IE). Последние два могут активироваться и деактивироваться в зависимости от модели PCH и целевой платформы, а ME-ядро работает всегда.

Рисунок 5. Три x86-процессора в PCH

Такие глобальные изменения потребовали изменения и программной составляющей ME. В частности, в качестве основы для операционной системы был выбран MINIX (ранее ThreadX RTOS). Теперь прошивка ME включает полноценную операционную систему со своими процессами, потоками, диспетчером памяти, драйвером аппаратных шин, файловой системой и многим другим. В ME интегрирован аппаратный криптопроцессор, поддерживающий алгоритмы SHA256, AES, RSA, HMAС. Доступ к оборудованию для пользовательских процессов производится посредством локальной таблицы дескрипторов (LDT). Через LDT организовано также и адресное пространство процесса — оно является всего лишь частью глобального адресного пространства ядра, границы которого заданы в локальном дескрипторе. Таким образом, ядру не нужно переключаться на память разных процессов (меняя каталоги страниц), как, например, в Microsoft Windows или Linux.

На этом закончим обзор программного окружения Intel ME и рассмотрим более подробно, как происходит загрузка операционной системы и модулей.

Стадии загрузки Intel ME

Запуск начинается с программы ROM, которая содержится во встроенной в PCH статической памяти. К сожалению, способ прочесть или перезаписать эту память широкой общественности не известен, но в интернете можно найти «предпродажные» версии прошивки ME с разделом ROMB (ROM BYPASS), который, по нашему предположению, дублирует функции ROМ. Таким образом, исследуя такие прошивки, можно восстановить основную функциональность программы первичной инициализации.

Изучение ROMB позволяет понять назначение ROM — выполнение начальной инициализации оборудования, например SPI-контроллера, проверка цифровой подписи заголовка раздела FTPR, загрузка модуля RBE, который расположен уже во flash-памяти. RBE, в свою очередь, проверяет контрольные суммы модулей KERNEL, SYSLIB, BUP и передает управление на точку входа в ядро.

Следует заметить, это эти три сущности — ROM, RBE и KERNEL — выполняются на нулевом уровне привилегий (в ring-0) ядра MIA.

Рисунок 6. Проверка целостности SYSLIB, KERNEL и BUP в RBE

Первый процесс, который создается ядром, — это BUP, который уже выполняется в своем адресном пространстве, в ring-3. Других процессов ядро по своей инициативе не запускает, этим занимается сам BUP, а также отдельный модуль LOADMGR, к нему вернемся позже. Назначение BUP (platform BringUP) — это инициализация всего аппаратного окружения платформы (в том числе процессора), выполнение первичных функций управления энергопитанием (например, запуск системы по нажатию кнопки включения) и запуск все остальных процессов ME. Таким образом, можно с уверенностью говорить, что PCH в 100-й серии и выше просто физически не имеют возможности запуска без корректной прошивки ME. Во-первых, BUP инициализирует контроллер управления энергопитанием (power management controller, PMC) и ICC-контроллер. Во-вторых — запускает целую вереницу процессов; часть из них «жестко прошита» в коде (SYNCMAN, PM, VFS), а другая часть содержится в InitScript (аналог автозапуска), который хранится в заголовке тома FTPR и защищен цифровой подписью.

Рисунок 7. Запуск SYNCMAN и PM

Таким образом, BUP считывает InitScript и запускает все процессы, которые удовлетворяют типу запуска ME и являются IBL-процессами.

Рисунок 8. Обработка InitScript

Рисунок 9. Список модулей c флагом IBL

В случае если запуск процесса не удался, BUP не будет запускать систему или переведет ее в Recovery режим, в котором произойдет автоматическое отключение питания после нескольких десятков минут. Как можно видеть на иллюстрации, последним в списке IBL-процессов является LOADMGR. Именно он дает старт оставшимся процессам, но в отличие от BUP, если в процессе запуска модуля происходит ошибка, LOADMGR просто перейдет к следующему.

Таким образом, первый вариант ограничить функционирование Intel ME — удалить все модули, которые не имеют флаг IBL в InitScript, что позволит существенно уменьшить размер прошивки. Но первоначально мы хотели выяснить, что происходит с ME в режиме HAP. Для этого рассмотрим программную модель BUP подробнее.

Рисунок 10. Схема запуска модулей в ME

BringUP

Если присмотреться к алгоритму работы модуля BUP, можно сказать, что внутри него реализован классический конечный автомат. Выполнение функционально разделено на две составляющие: стадии инициализации (представляют собой тот самый конечный автомат) и выполнение сервисных запросов других процессов после инициализации системы. Число стадий инициализации разное, в зависимости от платформы и SKU (TXE, CSME, SPS, consumer, corporate), но основные, общие для всех версий, все же можно выделить.

Первая стадия

На начальной стадии происходит создание внутренней диагностической файловой системы sfs (SUSRAM FS — файловая система, расположенная в энергозависимой памяти), считывание конфигурации, и, самое главное, получение информации от PMC о том, что привело к данному старту — включение питания платформы, глобальный перезапуск всей платформы, перезапуск только ME или же пробуждение из состояния сна. Эта стадия называется boot flow determination. От нее зависят последующие стадии работы конечного автомата инициализации. Кроме того, поддерживаются несколько режимов работы: нормальный и набор сервисных режимов, при которых ME штатно не функционирует — HAP, HMRFPO, TEMP_DISABLE, RECOVERY, SAFE_MODE, FW_UPDATE и FD_OVERRIDE.

Вторая стадия

На следующей стадии происходят инициализация ICC-контроллера и загрузка ICC-профиля (отвечает за тактовые частоты основных потребителей), инициализация Boot Guard и начало циклического опроса подтверждения запуска процессора.

Третья стадия

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

Четвертая стадия

На этой стадии происходит инициализация внутреннего оборудования. Также BUP запускает цикл опроса heci (специального устройства, предназначенного для получения команд от BIOS или операционной системы) на предмет получения DID (DRAM Init Done message) от BIOS. Именно это сообщение позволяет ME понять, что основной BIOS инициализировал оперативную память и зарезервировал для ME специальный регион, UMA, и после этого перейти к следующей стадии.

Пятая стадия

Как только DID получен, BUP, в зависимости от режима работы, который определяется по разным составляющим, либо запускает IBL-процессы из InitScript (при нормальном режиме работы), либо зависает в цикле, выйти из которого он может только при получении сообщения от PMC, например, в результате запроса на перезагрузку или выключение системы.

Именно на этой стадии мы и находим обработку HAP, причем в этом режиме BUP не выполняет InitScript, а зависает. Таким образом, остальная последовательность действий при нормальном режиме работы не имеет отношения к HAP и нами рассматриваться не будет. Главное, что хочется отметить: в режиме HAP BUP выполняет всю инициализацию платформы (ICC, Boot Guard), но не запускает основные процессы ME.

Рисунок 11. Определение режима HAP

Рисунок 12. Перевод ME в пятую стадию, что равноценно зависанию

Рисунок 13. Пятая стадия

Установка HAP-бита

Исходя из вышесказанного, второй вариант отключения состоит в установке HAP-бита и удалении или повреждении всех модулей, кроме тех, которые необходимы BUP для старта — RBE, KERNEL, SYSLIB, BUP. Сделать это можно просто убрав их из CPD-раздела FTPR и пересчитав контрольную сумму заголовка CPD (подробнее структура прошивки ME описана тут).

Остается еще один вопрос: как установить этот бит? Можно воспользоваться конфигурационными файлами FIT и определить, где он расположен в образе, но есть путь проще. Если открыть FIT, то в секции ME Kernel можно найти некий параметр Reserved. Именно этот бит и отвечает за включение режима HAP.

Рисунок 14. Бит активации режима HAP

HAP и Boot Guard

Нами также был найден код в BUP, который при активированном режиме HAP устанавливает дополнительный бит в политиках Boot Guard. К сожалению, выяснить, чем управляет этот бит, нам пока не удалось.

Рисунок 15. Установка дополнительного бита для Boot Guard

Поддержка ME 11 в me_cleaner

Пока эта статья готовилась к печати, разработчики обновили me_cleaner, в результате чего он стал так же удалять из образов все модули, кроме RBE, KERNEL, SYSLIB и BUP, но без установки HAP-бита, что вводит ME в режим «TemporaryDisable». Нам стало любопытно, что происходит при таком подходе.

Мы выяснили, что удаление разделов с файловой системой ME приводит к ошибке при чтении файла cfg_rules. Данный файл содержит ряд различных настроек системы. Среди них, как мы полагаем, есть флаг, который мы назвали «bup_not_temporary_disable». Если он не установлен, вся подсистема переводится в режим TemporaryDisable, а так как этот флаг – глобальная переменная, по умолчанию инициализированная нулем, то ошибка чтения расценивается как конфигурация, требующая отключения.

Отметим также, что мы проверили также прошивки от серверной и мобильной версии ME (SPS 4.x и TXE 3.x). В серверной версии этот флаг всегда устанавливается в 1, а в мобильно не анализируется. Из вышесказанного следует, что данный способ не сможет работать на серверных и мобильных версиях (Apollo Lake) ME.

Рисунок 16. Чтение файла cfg_rules

Вместо заключения

Таким образом, мы нашли недокументированный PCH strap, который позволяет перевести Intel ME в режим отключения на ранней стадии. Хотя физическое удаление модулей из образа с сохранением работоспособности неявно доказывает, что этот режим производит отключение ME, бинарный анализ не оставляет поводов для сомнений. C большой долей уверенности можно сказать, что выйти из этого режима Intel ME уже не в состоянии, так как в модулях RBE, KERNEL и SYSLIB не найдено кода, который позволял бы это осуществлять. Также мы считаем, что ROM, интегрированный в PCH, практически не отличается от ROMB, в котором тоже не найдено ничего похожего. Таким образом, HAP позволит защититься от уязвимостей, присутствующих во всех модулях, кроме RBE, KERNEL, SYSLIB, ROM и BUP, но, к сожалению, от эксплуатации ошибок на более ранних этапах этот режим не предохранит.

Мы ознакомили представителей Intel с деталями исследования. Их ответ подтвердил нашу догадку о связи недокументированного режима с программой High Assurance Platform. С разрешения компании приведем отрывок из ответа:

Mark/Maxim,

In response to requests from customers with specialized requirements we sometimes explore the modification or disabling of certain features. In this case, the modifications were made at the request of equipment manufacturers in support of their customer’s evaluation of the US government’s “High Assurance Platform” program. These modifications underwent a limited validation cycle and are not an officially supported configuration.

Мы полагаем, что данный механизм — удовлетворение обычной просьбы любой правительственной службы, которая хочет уменьшить вероятность утечки по побочным каналам. Но остается главный вопрос: как HAP влияет на функционирование Boot Guard? Из-за закрытости этой технологии ответить на этот вопрос пока не представляется возможным, но мы надеемся, что в скором будущем нам это удастся.

Авторы: Горячий Максим, Ермолов Марк

Блокирование двойного освобождения памяти в ядре Linux

2017-08-25T04:18:00.000-07:00

7 августа эксперт Positive Technologies Александр Попов выступил на хакерском фестивале SHA2017 (Still Hacking Anyway). Запись его выступления:

В своем докладе Александр рассказал о уязвимости CVE-2017-2636 в ядре Linux и технике ее эксплуатации для локального повышения привилегий. Многое из его доклада уже было описано в статьях журнала Хакер и в нашем блоге.

В данной статье описаны новые результаты его исследования, затронутые в
выступлении на SHA2017.

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

Однако в случае CVE-2017-2636 освобождаются сразу 13 элементов, причем двойное
освобождение происходит одним из первых. Поэтому вышеописанная техника
оказывается непригодной. Но все-таки Александру удалось привести это состояние
системы к ошибке использования после освобождения. Он воспользовался наивным
поведением SLUB, основного аллокатора ядра Linux.

Оказывается, SLUB-аллокатор не препятствует последовательному двойному
освобождению одного и того же участка памяти. В отличие от него аллокатор libc
выполняет проверку под названием "fasttop", сравнительно дешевую в отношении
производительности. Идея проста: сообщить об ошибке в случае совпадения адреса
освобождаемого элемента с адресом последнего элемента в списке свободных.

Александр Попов добавил аналогичную проверку в функцию set_freepointer()
SLUB-аллокатора и отправил патч в список рассылки ядра Linux (LKML). Патч вызвал оживленное обсуждение.

В этой доработке мейнтейнерам SLUB не понравилось то, что:

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

Александр привел свои аргументы:

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

В итоге при содействии Кейса Кука (Kees Cook) была достигнута договоренность
включить предлагаемую проверку в опцию ядра CONFIG_SLAB_FREELIST_HARDENED.

На данный момент патч Александра принят и находится в ветке linux-next. В скором времени он должен попасть в основную ветку, Linux Kernel mainline.

Как на самом деле будет исполняться закон о запрете анонимайзеров и VPN

2017-08-24T01:55:00.001-07:00

С ноября 2017 года в России начнут блокировать анонимайзеры и VPN-сервисы, владельцы которых откажутся закрыть доступ к запрещенным в стране ресурсам. Дмитрий Кузнецов, директор по методологии и стандартизации компании Positive Technologies, объясняет, чем все это может грозить Рунету.

О чем речь

Поправки к закону «Об информации, информационных технологиях и о защите информации» были внесены на рассмотрение в Государственную Думу РФ в конце июня 2017 года. Президент России подписал закон о внесении этих изменений в конце июля.

Документ вводит возможность блокировки анонимайзеров, VPN и других сервисов, с помощью которых можно получить доступ к запрещенным в стране сайтам. Выявлять такие сервисы будут ФСБ и МВД. Если в ходе расследования этими ведомствами преступления выяснится, что какой-либо сервис использовался для обхода заблокированных ресурсов, то Роскомнадзор должен будет добиться от владельцев сервиса соблюдения действующих черных списков под угрозой блокировки. Если решение о такой блокировке будет вынесено, то интернет-провайдеры будут обязаны его исполнить, иначе на них может быть наложен штраф до 700 тыс. рублей.

Как это повлияет на Рунет

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

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

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

Что в итоге

Фактически поправки в закон вводят на территории России процедуру информирования о злоупотреблениях (abuse reporting procedure), принятую во многих странах мира.

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

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

Уязвимости веб-приложений: пора анализировать исходный код

2017-08-08T02:24:00.001-07:00

Введение

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

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

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

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

1. Методика

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

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

Обнаруженные уязвимости классифицировались согласно соответствующим угрозам по системе Web Application Security Consortium Threat Classification (WASC TC v. 2), за исключением категорий Improper Input Handling и Improper Output Handling, поскольку они реализуются в рамках множества других атак. Кроме того, дополнительно мы выделили категории Insecure Session, Server Side Request Forgery и Clickjacking. Эти категории отсутствуют в классификации WASC, однако достаточно часто встречаются в исследуемых системах.

В категорию Insecure Session мы относим недостатки защиты сессии, например такие, как отсутствие флагов Secure и HttpOnly. Эти недостатки позволяют злоумышленнику перехватить значения Cookie пользователя при реализации различных атак.

Server-Side Request Forgery (подделка запроса со стороны сервера) — уязвимость, позволяющая выполнять произвольные HTTP-запросы от имени системы. Приложение, получив URL-адрес или HTTP-сообщение, осуществляет недостаточную проверку адреса назначения перед отправкой запроса. Используя данный недостаток, злоумышленник может отправлять запросы на серверы с ограниченным доступом (например, компьютеры в локальной сети), что приводит к разглашению важных данных, получению злоумышленником исходных кодов приложения, к отказу в обслуживании и т. п. В результате эксплуатации этой уязвимости злоумышленник может получить информацию о структуре сегментов сети, недоступных внешнему пользователю, обращаться к внутренним ресурсам, производить сканирование портов (сервисов) и т. п.

Clickjacking — разновидность атак на пользователей, заключающаяся в визуальном обмане. Ее принцип основан на том, что уязвимое приложение загружается во фрейме на страницу приложения, после чего маскируется под кнопку или какой-либо другой элемент. При клике по данному элементу пользователь выполняет задуманное злоумышленником действие в контексте уязвимого сайта. Уязвимость, позволяющая проводить эту атаку, возникает, когда приложение не возвращает специальный заголовок X-Frame-Options и тем самым разрешает показывать его во фреймах. Также в некоторых браузерах эта уязвимость может позволить выполнить атаку «Межсайтовое выполнение сценариев».

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

Степень риска уязвимостей оценивалась согласно системе Common Vulnerability Scoring System (CVSS v. 3); на основе этой оценки выделялись качественные оценки высокого, среднего и низкого уровней риска.

2. Резюме

Все веб-приложения уязвимы

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

Под угрозой пользователи

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

Утечки — по-прежнему актуальная проблема

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

Уязвимости веб-приложений — простой вектор проникновения в ЛВС

Каждое четвертое веб-приложение позволяет проводить атаки на ресурсы внутренней сети. Например, злоумышленник может получить доступ к файлам, сканировать устройства внутренней сети или проводить атаки на ресурсы сети. Также каждое четвертое веб-приложение содержит критически опасную уязвимость «Внедрение операторов SQL» и позволяет получить доступ к базе данных. Кроме того, эта уязвимость может дать возможность злоумышленнику прочитать произвольные файлы или создать новые, а также проводить атаки на отказ в обслуживании.

Промышленные компании наиболее уязвимы

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

64% веб-приложений на основе ASP.NET содержат критически опасные уязвимости

Приблизительно каждое второе веб-приложение, созданное на базе языков PHP и Java, также содержит критически опасные уязвимости. При этом на одно веб-приложение, разработанное на языке PHP, приходится максимальное количество таких уязвимостей — 2,8 на систему.

Продуктивные системы более уязвимы, чем тестовые

Продуктивные системы в 2016 году являются менее защищенными. При ручном анализе критически опасные уязвимости выявляются в 50% тестовых систем и в 55% продуктивных систем. Уязвимостей высокого и среднего уровня риска в одной продуктивной системе выявлено в среднем в два раза больше, чем в одной тестовой.

Анализ исходного кода эффективнее «черного ящика»

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

Автоматизированный анализ выявляет уязвимости в кратчайшее время

В среднем на одно приложение автоматизированный анализатор исходного кода позволил выявить 4,6 уязвимости высокого уровня риска, 66,9 уязвимости среднего уровня риска и 45,9 уязвимости низкого уровня риска. Анализ исходного кода автоматизированными средствами показывает высокую эффективность, а скорость работы превосходит возможности ручного тестирования.

3. Портрет участников исследования

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

Рисунок 1. Портрет участников исследования

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

Рисунок 2. Доли продуктивных и тестовых систем

В этом году среди средств разработки веб-приложений преобладают PHP, Java, по сравнению с прошлым годом значительно увеличилась доля приложений, созданных на основе технологии ASP.NET. Иные средства разработки (Ruby, Python) объединены в категорию «Другие» и составляют всего 7%.

Рисунок 3. Средства разработки веб-приложений

4. Тенденции

Все веб-приложения, исследованные в рамках анализа защищенности ручными методами или с использованием автоматизированных средств, были подвержены уязвимостям той или иной степени опасности. При этом всего в 1% приложений были выявлены уязвимости только низкой степени опасности. Позитивные изменения состоят в значительном сокращении (с 70 до 58%) доли веб-приложений, содержащих уязвимости высокого уровня риска. Частично на статистические данные повлиял тот факт, что компании, которые в прошлом году проводили анализ защищенности, учли результаты проверок при разработке новых веб-приложений. Причем в первую очередь внимание уделялось устранению критически опасных уязвимостей.

Рисунок 4. Доля уязвимых сайтов по максимальной степени риска уязвимостей

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

Практически во всех исследованных приложениях были обнаружены уязвимости среднего уровня риска. Это число незначительно колеблется каждый год в пределах 90—100%. Возросла доля веб-приложений, подверженных уязвимостям низкого уровня риска.

Рисунок 5. Доли сайтов с уязвимостями различной степени риска

5. Ручной анализ защищенности веб-приложений

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

Рисунок 6. Доля уязвимостей различной степени риска (ручное тестирование)

Недостатки безопасности найдены во всех исследованных веб-приложениях. Критически опасные уязвимости обнаружены более чем в половине приложений, для которых проводились ручные проверки (54%), 44% приложений подвержены уязвимостям среднего уровня риска и ниже, и лишь в 2% приложений были выявлены уязвимости только низкой степени опасности.

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

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

Рисунок 8. Среднее число уязвимостей на одну систему (ручное тестирование)

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

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

Рисунок 9. Наиболее популярные уязвимости, выявленные ручным тестированием (доля систем)

Как и в прошлом году, на первой строчке рейтинга находится уязвимость среднего уровня риска «Межсайтовое выполнение сценариев» (Cross-Site Scripting), которая встречается в 75% исследованных систем. В результате эксплуатации данной уязвимости злоумышленник может внедрить в браузер пользователя произвольные HTML-теги, включая сценарии на языке JavaScript и других языках, и таким образом получить значение идентификатора сессии атакуемого и совершить иные неправомерные действия, например фишинговые атаки.

Эксперты Positive Technologies в прошедшем году проводили также исследования атак злоумышленников на веб-приложения, в том числе составили рейтинг наиболее популярных атак. Исходными данными для статистического отчета послужили результаты множества пилотных проектов по внедрению межсетевого экрана уровня приложений PT Application Firewall среди российских и зарубежных компаний. Для того чтобы взломать сайт или атаковать его пользователей, злоумышленники пробуют эксплуатировать различные уязвимости приложения — как ошибки, допущенные при разработке, так и недостатки администрирования. По результатам исследований было установлено, что в 58% приложений, для которых проводились пилотные проекты, злоумышленники предпринимали попытки атаковать пользователей путем эксплуатации самой распространенной в этом году уязвимости «Межсайтовое выполнение сценариев».

Рисунок 10. Атака «Межсайтовое выполнение сценариев» (доля систем)

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

Отсутствие защиты от перебора учетных данных (Brute Force) остается на третьем месте, но доля приложений, уязвимых для такого перебора, увеличилась на 10%.

На пятом и шестом местах находятся недостатки защиты пользовательских сессий и отсутствие защиты от атак типа Clickjacking. Сравнение с прошлым периодом исследований для этих недостатков не приводится, поскольку в отдельные категории они были выделены лишь в этом году. В то время как разработчики стали более внимательно относиться к устранению критически опасных уязвимостей, несущих угрозу непосредственно для владельцев веб-приложений, на первый план в этом году выходят ошибки, затрагивающие пользователей. В 35% систем выявлена уязвимость, которая также позволяет проводить атаки на пользователей, — «Подделка межсайтовых запросов» (Cross-Site Request Forgery).

Как уже отмечалось, общая доля сайтов, содержащих уязвимости высокого уровня риска, уменьшилась, и в этом году в рейтинге оказалась всего одна критически опасная уязвимость — «Внедрение операторов SQL», которой, тем не менее, подвержены 25% веб-приложений. По итогам исследований атак на веб-приложения в 2016 году попытка эксплуатации этой уязвимости находится на первом месте в рейтинге наиболее популярных атак и встречается в 84% систем.

Рисунок 11. Атаки «Внедрение операторов SQL» (доля систем)

Уязвимости клиентской части в 2016 году составили 59% от общего числа. Среди них «Межсайтовое выполнение сценариев», «Подделка межсайтовых запросов», недостатки защиты сессии и другие проблемы безопасности, позволяющие совершать атаки на клиентов веб-приложения. 41% выявленных уязвимостей относятся к серверной части приложений, например «Утечка информации» или «Недостаточная авторизация».

Рисунок 12. Уязвимости по объекту атаки

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

Рисунок 13. Типы уязвимостей

5.2. Анализ угроз и уровней защищенности

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

Общий уровень защищенности веб-приложений остается достаточно низким. По результатам проведенного анализа уровень защищенности 16% систем был оценен экспертами как крайне низкий.

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

Рисунок 14. Уровень защищенности веб-приложений

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

Рисунок 15. Уровень защищенности веб-приложений по отраслям

Самой распространенной угрозой в 2016 году оказались атаки на пользователей веб-приложений: такие атаки возможны практически во всех веб-приложениях (94%). Четверть веб-приложений, как было показано в предыдущем разделе, содержит уязвимости, пользуясь которыми злоумышленник может получить доступ к базам данных. Столько же веб-приложений (25%) могут стать вектором проникновения во внутреннюю сеть компании, в частности они позволяют сканировать устройства, получать информацию о структуре сети, отправлять запросы к локальным узлам. Приблизительно каждое пятое приложение (19%) дает возможность выполнять произвольные команды ОС на сервере.

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

Рисунок 16. Самые распространенные угрозы

В основном совершать атаки на пользователей приложений позволяли такие уязвимости, как «Межсайтовое выполнение сценариев», «Подделка межсайтовых запросов», «Открытое перенаправление», а также недостаточная защита сессий и отсутствие защиты от атак типа Clickjacking. Эти ошибки вошли в топ-10 самых распространенных уязвимостей в этом году.

Рисунок 17. Соотношение уязвимостей, позволяющих проводить атаки на пользователей

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

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

Рисунок 18. Доля систем, в которых злоумышленник может получить доступ к исходному коду

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

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

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

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

Рисунок 20. Критически опасные угрозы по отраслям

5.3. Статистика для различных отраслей экономики

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

Как показывают полученные результаты, во всех отраслях, за исключением финансовой, преобладают веб-приложения, подверженные уязвимостям высокой степени опасности. Так, уязвимости высокого уровня риска найдены в 74% веб-приложений телекоммуникационных компаний, 67% приложений государственных организаций и интернет-магазинов, 57% приложений промышленных компаний. В финансовой сфере таким уязвимостям оказались подвержены всего треть веб-приложений (38%).

Рисунок 21. Доли веб-приложений с уязвимостями различной степени риска

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

Рисунок 22. Максимальная степень риска (доли веб-приложений)

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

Также высокое число критически опасных уязвимостей присутствует в веб-приложениях компаний, занимающихся электронной коммерцией. Эти веб-приложения содержат и наибольшее количество уязвимостей среднего уровня риска: 39,3 уязвимости на систему в среднем выявляется для интернет-магазинов и 27,5 уязвимости — для государственных организаций.

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

Рисунок 23. Среднее число уязвимостей различного уровня риска на одно приложение

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

Рисунок 24. Доли отраслевых сайтов с распространенными уязвимостями

5.4. Анализ различных средств разработки

Как и в предыдущем году, все исследованные приложения, независимо от средства разработки, содержат уязвимости как минимум среднего уровня риска. В приведённой здесь статистике рассматриваются сайты на PHP, Java и ASP.NET. Приложения, написанные на других, менее популярных языках, присутствовали в выборке в малом количестве, поэтому статистика по ним не приводится - однако во всех приложениях, разработанных с использованием этих средств, обнаружены критически опасные уязвимости, и лишь в одном выявлены только уязвимости низкого уровня риска.

Рисунок 25. Доля веб-приложений по максимальному уровню риска уязвимостей

В 2016 году распределение приложений, созданных с использованием языков программирования PHP и Java, по уровню опасности выявленных уязвимостей оказалось практически одинаковым: все приложения подвержены уязвимостям среднего уровня риска, а более половины приложений содержат критически опасные уязвимости.

Наиболее высокий процент приложений, содержащих критически опасные уязвимости (64%), наблюдается среди систем, разработанных на базе технологии ASP.NET. При этом доля приложений, в которых были обнаружены уязвимости среднего и низкого уровня риска, несколько ниже, чем для PHP и Java: 93% и 50% соответственно. В то же время на одно приложение ASP.NET в среднем приходится меньше критически опасных уязвимостей, чем для приложений на основе PHP и Java.

Рисунок 26. Доли систем с уязвимостями разной степени риска

Как уже упоминалось, по сравнению с прошлыми периодами исследований заметно сократилось количество критически опасных уязвимостей. В среднем на одну систему приходится около 2 уязвимостей высокого уровня риска, максимальное число таких уязвимостей (2,8) содержат приложения, разработанные на языке PHP. Число уязвимостей среднего уровня опасности, напротив, увеличилось в сравнении с показателями предыдущего года (для языков PHP и Java), при этом приложения, созданные на базе языка Java, содержат почти в два раза больше таких уязвимостей, чем остальные приложения.

Рисунок 27. Среднее количества уязвимостей на одну систему в зависимости от средства разработки

Рейтинг самых распространенных недостатков в зависимости от средств разработки представлен в таблице 1.

Самой распространенной уязвимостью для всех приложений оказалась уязвимость «Межсайтовое выполнение сценариев», она обнаружена более чем в 60% приложений для всех языков программирования. Распространены также недостатки, связанные с раскрытием чувствительных данных: «Утечка информации» и «Раскрытие информации о версии ПО».

Для языков PHP и Java по сравнению с прошлым годом сократилась доля приложений, содержащих уязвимости высокого уровня риска. Так, например, в приведенном рейтинге отсутствует популярная в прошлые годы уязвимость «Выход за пределы назначенного каталога».

Тем не менее от 26% до 29% приложений в каждой категории содержат критически опасную уязвимость «Внедрение операторов SQL», более четверти приложений (26%) на базе языка PHP содержат уязвимость «Выполнение команд ОС», а для остальных средств разработки в десятку наиболее распространенных недостатков входит «Внедрение внешних сущностей XML».

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

Рисунок 28. Доля веб-приложений, подверженных наиболее распространенным уязвимостям, по средствам разработки (часть 1)

Рисунок 29. Доля веб-приложений, подверженных наиболее распространенным уязвимостям, по средствам разработки (часть 2)

5.5. Сравнение тестовых и продуктивных систем

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

Рисунок 30. Максимальный уровень риска уязвимостей (доли систем)

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

Рисунок 31. Доли веб-приложений с уязвимостями разной степени риска

Рисунок 32. Среднее количество уязвимостей на одну систему

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

5.6. Сравнение методов тестирования

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

Рисунок 33. Доля приложений по методу тестирования

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

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

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

Рисунок 34. Доли систем с уязвимостями разной степени риска в зависимости от метода тестирования

В среднем при наличии доступа к исходному коду в одном приложении специалисты Positive Technologies выявляли 2,8 уязвимости высокого уровня риска, в то время как методом черного ящика были обнаружены 1,9 уязвимости на систему. В связи с тем, что существенная часть работ по анализу исходного кода проводилась в отношении тестовых версий новых приложений для компаний, которые уже проводили тестирование своих систем годом ранее, разница не столь велика, как в прошлый период исследований. Эффективность метода белого ящика можно подтвердить и на основе результатов автоматизированного анализа исходного кода, которые представлены в следующем разделе.

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

Рисунок 35. Среднее число уязвимостей на одну систему в зависимости от метода тестирования

Метод белого ящика, как и в прошлые периоды исследований, оказался эффективнее при выявлении критически опасных уязвимостей. Например, анализ исходного кода позволял в четыре раза чаще выявлять уязвимости «Внедрение внешних сущностей XML». Кроме того, представленные результаты показывают, что недостатки защиты сессии, «Подделка межсайтовых запросов» и «Открытое перенаправление» также были обнаружены в основном при использовании метода белого ящика.

Рисунок 36. Среднее число уязвимостей определенного типа на одну систему

6. Автоматизированный анализ защищенности

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

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

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

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

Рисунок 37. Распределение уязвимостей по уровню риска (автоматизированное тестирование)

Во всех исследованных веб-приложениях были обнаружены уязвимости не ниже среднего уровня риска. Критически опасные уязвимости, также как и в 2015 году, выявлены в подавляющем большинстве приложений (89%).

Рисунок 38. Распределение систем по максимальной степени риска уязвимостей (автоматизированное тестирование)

Уязвимости среднего уровня риска обнаружены во всех исследованных системах.

Рисунок 39. Доли систем с уязвимостями различной степени риска (автоматизированное тестирование)

Методами автоматизированного анализа исходного кода в среднем в одном приложении было обнаружено 4,6 уязвимости высокого уровня риска, 66,9 уязвимости среднего уровня риска и 45,9 уязвимости низкого уровня риска. Более того, в двух исследованных приложениях были обнаружены сотни критически опасных уязвимостей и около двух тысяч уязвимостей средней степени опасности, однако эти приложения были исключены из приведенной статистики для отображения более объективных значений. Тем не менее эти данные позволяют получить представление об эффективности использования автоматизированных средств анализа и о том, насколько применение подобных средств может повысить уровень защищенности разрабатываемых веб-приложений. Анализ исходного кода, в отличие от метода черного ящика, позволяет выявить все «точки входа», то есть все возможные варианты эксплуатации каждой уязвимости, что позволяет устранить уязвимость полностью.

Рисунок 40. Среднее число уязвимостей на одну систему (автоматизированный анализ)

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

Рисунок 41. Пример обнаружения уязвимости «Межсайтовое выполнение сценариев»

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

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

Рисунок 42. Пример обнаружения уязвимости «Чтение произвольных файлов»

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

Рисунок 43. Пример обнаружения уязвимости «Внедрение операторов SQL»

Менее распространена в 2016 году, но также встречается критически опасная уязвимость «Внедрение внешних сущностей XML», которая может быть использована злоумышленником для чтения произвольных файлов или проведения атак на ресурсы внутренней сети. На рисунке представлен пример такой уязвимости.

Рисунок 44. Пример обнаружения уязвимости «Внедрение внешних сущностей XML»

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

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

Заключение

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

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

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

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

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

Все, что вы хотели узнать о #NotPetya, но боялись спросить

2017-06-27T14:29:00.000-07:00

Эксперты Positive Technologies представили детальный разбор нового зловреда и дали рекомендации по борьбе с ним

Вслед за нашумевшей кампанией вируса-шифровальщика WannaCry, которая была зафиксирована в мае этого года, 27 июня более 80 компаний России и Украины стали жертвой новой атаки с использованием шифровальщика-вымогателя NotPetya. И эта кампания оказалась вовсе не связана с WannaCry.

Жертвами вымогателя уже стали украинские, российские и международные компании, в частности, Новая Почта, Запорожьеоблэнерго, Днепроэнерго, Ощадбанк, медиахолдинг ТРК "Люкс", Mondelēz International, TESA, Nivea, Mars, операторы LifeCell, УкрТелеКом, Киевстар и многие другие организации. В Киеве оказались заражены в том числе некоторые банкоматы и кассовые терминалы в магазинах. Именно на Украине зафиксированы первые атаки.

Анализ образца вымогателя, проведенный нашими экспертами, показал, что принцип действия NotPetyaоснован на шифровании главной загрузочной записи (MBR) загрузочного сектора диска и замене его своим собственным. Эта запись – первый сектор на жёстком диске, в нем расположена таблица разделов и программа-загрузчик, считывающая из этой таблицы информацию о том, с какого раздела жёсткого диска будет происходить загрузка системы. Исходный MBR сохраняется в 0x22-ом секторе диска и зашифрован с помощью побайтовой операции XOR с 0x07.

После запуска вредоносного файла создается задача на перезапуск компьютера, отложенная на 1-2 часа, в это время можно успеть запустить команду[1] bootrec /fixMbr для восстановления MBR и восстановить работоспособность ОС. Таким образом, запустить систему даже после ее компрометации возможно, однако расшифровать файлы не удастся. Для каждого диска генерируется свой ключ AES, который существует в памяти до завершения шифрования. Он шифруется на открытом ключе RSA и удаляется. Восстановление содержимого после завершения требует знания закрытого ключа, таким образом, без знания ключа данные восстановить невозможно. Предположительно, зловред шифрует файлы максимум на глубину 15 директорий. То есть файлы, вложенные на большую глубину, находятся в безопасности (по крайней мере для данной модификации шифровальщика).

В случае, если диски оказались успешно зашифрованы после перезагрузки, на экран выводится окно с сообщением о требовании заплатить выкуп $300 (на 27 июня 2017 - примерно 0,123 биткойна) для получения ключа разблокировки файлов. Для перевода денег указан биткоин-кошелек 1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX[2]. Через несколько часов после начала атаки на кошелек уже поступают транзакции, кратные запрошенной сумме – некоторые жертвы предпочли заплатить выкуп, не дожидаясь, пока исследователи изучат зловред и попытаются найти средство восстановления файлов.

За несколько часов число транзакций увеличилось втрое.

NotPetya использует 135, 139, 445 TCP-порты для распространения (с использованием служб SMB и WMI). Распространение внутри сети на другие узлы происходит несколькими методами: с помощью Windows Management Instrumentation (WMI) и PsExec[3], а также с помощью эксплойта, использующего уязвимость MS17-010[4](EternalBlue[5]). WMI – это технология для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. PsExec широко используется для администрирования Windows и позволяет выполнять процессы в удаленных системах. Однако для использования данных утилит необходимо обладать привилегиями локального администратора на компьютере жертвы, а значит, шифровальщик может продолжить свое распространение только с тех устройств, пользователь которых обладает максимальными привилегиями ОС. Эксплойт EternalBlue позволяет получить максимальные привилегии на уязвимой системе. Также шифровальщик использует общедоступную утилиту Mimikatz[6]для получения в открытом виде учетных данных всех пользователей ОС Windows, в том числе локальных администраторов и доменных пользователей. Такой набор инструментария позволяет NotPetya сохранять работоспособность даже в тех инфраструктурах, где был учтен урок WannaCry и установлены соответствующие обновления безопасности, именно поэтому шифровальщик настолько эффективен.

В рамках тестирований на проникновение современных корпоративных инфраструктур эксперты Positive Technologies регулярно демонстрируют возможность применения эксплойта EternalBlue (в 44% работ в 2017 году), а также успешное применение утилиты Mimikatz для развития вектора атаки до получения полного контроля над доменом (в каждом проекте).

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

О существующей угрозе компрометации мы сообщали более месяца назад в оповещениях об атаке WannaCry[7]и давали рекомендации[8], каким образом определить уязвимые системы, как их защитить и что делать, если атака уже произошла. Дополнительные рекомендации мы дадим и в данной статье. Кроме того, наша компания разработала бесплатную утилиту WannaCry_Petya_FastDetect [9]для автоматизированного выявления уязвимости в инфраструктуре. Система MaxPatrol выявляет данную уязвимость как в режиме Audit, так и в режиме Pentest. Подробная инструкция указана в наших рекомендациях[10]. Кроме того, в MaxPatrol SIEMзаведены соответствующие правила корреляции для выявления атаки NotPetya.

Эксперты Positive Technologiesвыявили “kill-switch” – возможность локально отключить шифровальщик. Если процесс имеет административные привилегии в ОС, то перед подменой MBR шифровальщик проверяет наличие файла perfc (либо другого пустого файла с иным названием) без расширения в директории C:\Windows\ (директория жестко задана в коде). Этот файл носит то же имя, что и библиотека dll данного шифровальщика (но без расширения).

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

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

С другой стороны, если процесс изначально не обладает административными привилегиями, то шифровальщик не сможет выполнить проверку наличия пустого файла в директории C:\Windows\, и процесс шифрования файлов все же запустится, но без подмены MBR и перезапуска компьютера.

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

Если заражение уже произошло, мы не рекомендуем платить деньги злоумышленникам. Почтовый адрес нарушителей wowsmith123456@posteo.netбыл заблокирован, и даже в случае оплаты выкупа ключ для расшифрования файлов наверняка не будет получен. Для предотвращения распространения шифровальщика в сети рекомендуется выключить другие компьютеры, которые не были заражены, отключить от сети зараженные узлы и снять образы скомпрометированных систем. В случае, если исследователи найдут способ расшифрования файлов, заблокированные данные могут быть восстановлены в будущем. Кроме того, данный образ может быть использован для проведения анализа шифровальщика, что поможет исследователям в их работе.

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

Для выявления атаки NotPetya в инфраструктуре могут быть использованы следующие индикаторы:

· C:\Windows\perfс

· Задача в планировщике Windows с пустым именем и действием (перезагрузка) "%WINDIR%\system32\shutdown.exe /r /f"

Срабатывание правил IDS/IPS:

· msg: "[PT Open] Unimplemented Trans2 Sub-Command code. Possible ETERNALBLUE (WannaCry, Petya) tool"; sid: 10001254; rev: 2;

· msg: "[PT Open] ETERNALBLUE (WannaCry, Petya) SMB MS Windows RCE"; sid: 10001255; rev: 3;

· msg: "[PT Open] Trans2 Sub-Command 0x0E. Likely ETERNALBLUE (WannaCry, Petya) tool"; sid: 10001256; rev: 2;

· msg: "[PT Open] Petya ransomware perfc.dat component"; sid: 10001443; rev: 1

· msg:"[PT Open] SMB2 Create PSEXESVC.EXE"; sid: 10001444; rev:1

Сигнатуры:

· https://github.com/ptresearch/AttackDetection/blob/master/eternalblue(WannaCry%2CPetya)/eternalblue(WannaCry%2CPetya).rules

[1] https://twitter.com/msuiche/status/879722894997278720

[2] https://blockchain.info/address/1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX

[3] https://technet.microsoft.com/ru-ru/library/bb545021.aspx

[4] https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

[5] https://vulners.com/seebug/SSV-92952

[6] https://github.com/gentilkiwi/mimikatz

[7] https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/WannaCry-analytics-rus.pdf

[8] https://www.ptsecurity.com/ru-ru/about/news/250571/?utm_source=slider&utm_content=wannacry-protect

[9] https://github.com/ptresearch/Pentest-Detections/tree/master/WannaCry_Petya_FastDetect

[10] https://www.ptsecurity.com/ru-ru/about/news/250571/?utm_source=slider&utm_content=wannacry-protect

Эксперты Positive Technologies подтверждают схожесть нового шифровальщика с Petya ransomware 2016 года

2017-06-27T09:07:00.000-07:00

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

По предварительным данным, мы готовы подтвердить некоторую схожесть данного зловреда с ВПО Petya ransomware (вирусом-вымогателем, известным с 2016 года, который также был нацелен на блокировку работоспособности компьютера).

Если говорить о причинах возникновения сегодняшней ситуации, то проблема снова в небрежном отношении к проблемам информационной безопасности. Коротко говоря, уроки WannaCry пострадавшими организациями так и не выучены: обновления все так же устанавливаются несвоевременно (по данным Positive Technologies, для 20% обследованных экспертами компании систем характерны критически опасные уязвимости, связанные именно с отсутствием обновлений безопасности; средний возраст наиболее устаревших выявленных неустановленных обновлений по системам составляет 9 лет, а самая старая из обнаруженных уязвимостей опубликована более 17 лет назад); общий уровень информированности сотрудников об ИБ низкий (все так же актуальны загрузка вложений и переход по ссылкам, полученным из недоверенных источников); а также зачастую присутствует некорректная конфигурация информационных систем с точки зрения архитектуры.

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

Статистика атак на веб-приложения: I квартал 2017 года

2017-06-16T02:00:00.000-07:00

В данном исследовании представлена статистика атак на веб-приложения за первый квартал 2017 года. Исходные данные были получены по результатам пилотных проектов по внедрению межсетевого экрана уровня приложений PT Application Firewall, а также по итогам работы PT AF для защиты веб-приложений компании Positive Technologies.

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

Исследование атак позволяет оценить текущие тенденции в области безопасности веб-приложений, выявить актуальные угрозы и понять, на какие аспекты следует обратить внимание в первую очередь при разработке веб-приложения и построении системы защиты.
Автоматизированный поиск уязвимостей с помощью специализированного ПО для сканирования веб-приложений (например, Acunetix) был исключен из исходных данных. Приведенные в отчете примеры атак были проверены вручную на предмет ложных срабатываний и являются достоверными.

Ресурсы Positive Technologies рассматриваются в совокупности с ресурсами компаний из сферы информационных технологий.

Основные результаты

Статистика атак на веб-приложения

Типы атак

Наиболее часто в первом квартале 2017 года встречались атаки «Внедрение операторов SQL» и «Межсайтовое выполнение сценариев», каждая составляет примерно треть от общего числа зафиксированных атак. Если атака «Внедрение операторов SQL» используется для получения доступа к чувствительной информации или выполнения команд ОС и дальнейшего проникновения в систему, то атака «Межсайтовое выполнение сценариев» направлена на пользователей приложений. Заметим, что именно возможность проведения атак на пользователей вышла на первое место в рейтинге самых распространенных угроз веб-приложений в прошедшем году.

Рисунок 1. Топ-10 атак на веб-приложения

Более половины атак направлены на получение доступа к чувствительной информации

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

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

Рисунок 2. Топ-5 атак на веб-приложения государственных организаций

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

Рисунок 3. Топ-5 атак на веб-приложения финансовых организаций

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

Рисунок 4. Топ-5 атак на веб-приложения IT-компаний

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

Рисунок 5. Топ-5 атак на веб-приложения сферы образования

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

Рисунок 6. Пример обнаружения атаки «Удаленное выполнение кода и команд ОС»

На следующем рисунке отображен пример выявления атаки «Выход за пределы назначенной директории». Целью злоумышленника был доступ к конфигурационному файлу WordPress wp-config.php, содержащему важные данные.

Рисунок 7. Пример обнаружения атаки «Выход за пределы назначенной директории»

В рамках одного вектора атаки злоумышленник может применять различные методы взлома, делать длительные перерывы между отдельными атаками или изменять IP-адрес в целях маскировки. Однако среди большого количества разрозненных на первый взгляд событий можно выявить цепочки взаимосвязанных атак. Для этого PT AF использует механизмы, позволяющие в реальном времени анализировать все регистрируемые события на наличие корреляций. Такая функциональность незаменима как при выявлении целенаправленных атак, так и при расследовании инцидентов. Возможность своевременного обнаружения целенаправленных атак крайне актуальна для банков и финансовых организаций. Пример выявленной цепочки атак «Внедрение операторов SQL» представлен на рисунках ниже. В цепочку вошла 31 атака, каждой из которых был присвоен высокий уровень риска.

Рисунок 8. Пример выявленной цепочки атак «Внедрение операторов SQL»

Рисунок 9. Атаки «Внедрение операторов SQL», входящие в одну корреляционную цепочку

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

Рисунок 10. Среднее число атак в день по отраслям

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

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

Источники атак

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

Рисунок 11. Источники атак по числу уникальных IP-адресов

Также можно разбить исследуемые системы по отраслям. Страны-источники атак представлены для каждой отрасли на рисунках ниже. Диаграммы распространения источников атак были автоматически созданы в веб-интерфейсе межсетевого экрана PT AF. Анализ проводился по количеству заблокированных запросов.

Атаки на государственные организации в первую очередь исходят от IP-адресов, принадлежащих провайдерам из России, США, Китая, Франции и Украины.

Рисунок 12. Источники атак на государственные организации в интерфейсе PT AF

Атаки на финансовые организации чаще осуществлялись с IP-адресов России, Швейцарии, США, Франции и Украины.

Рисунок 13. Источники атак на финансовые организации в интерфейсе PT AF

Среди источников атак на IT-компании преобладали IP-адреса США, России и Китая.

Рисунок 14. Источники атак на IT-компании в интерфейсе PT AF

В сфере образования IP-адреса нарушителей в основном относились к США, России и Франции. Высокий процент атак из США связан с использованием утилит для эксплуатации уязвимостей и сервисов для сокрытия действительного IP-адреса источника.

Рисунок 15. Источники атак на образовательные учреждения в интерфейсе PT AF

По сравнению с результатами прошлого года общая картина источников атак несколько изменилась. Главное отличие состоит в резком сокращении украинских IP-адресов в рейтинге источников. В остальном изменения незначительны, Россия, Китай и США по-прежнему остаются на первых местах.

Динамика атак

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

Рисунок 16. Количество атак в сутки по типам

Существенную часть атак составляет «Межсайтовое выполнение сценариев», причем средние значения находятся в диапазоне от 250 до 800, число таких атак являлось высоким на протяжении всего первого квартала.

На диаграмме выделяются и атаки «Внедрение операторов SQL». Средние значения лежат в промежутке от 100 до 300 атак в день. Попытки найти и эксплуатировать уязвимости, связанные с неправильной обработкой SQL-запросов, характеризуются высокой интенсивностью в рамках целенаправленной атаки. В некоторых компаниях число запросов в отдельные дни превышало 8000, однако эти результаты не учитывались на графике для получения объективных значений. Такое количество запросов связано и с применением автоматизированных утилит для эксплуатации уязвимостей.

Интенсивные атаки присутствуют также в категории «Подключение локальных файлов». Помимо значений, представленных на рисунке, были зафиксированы дни, в которые число запросов для отдельных компаний достигало 10 730 и 6270. Для поиска уязвимостей нарушители также используют автоматизированные утилиты, например для перебора имен файлов и директорий. На рисунках продемонстрирован ряд запросов, направленных на поиск уязвимости, и пример заблокированного запроса, с помощью которого злоумышленник намеревался получить доступ к файлу .htaccess.

Рисунок 17. Множество атак «Подключение локальных файлов»

Рисунок 18. Пример атаки «Подключение локальных файлов»

Среднее количество атак других типов не превышает 2000 в день (за исключением категории «Отказ в обслуживании» — максимум 2079 атак).

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

Рисунок 19. Распределение атак по дням

Как видно из диаграммы, общий уровень активности злоумышленников в первом квартале был высоким, каждый день веб-приложения подвергались множеству атак. В среднем число атак в сутки варьировалось от 500 до 1500 и не опускалось ниже 300 за исключением одного значения. В одной из компаний, для которых проводился пилотный проект, было зафиксировано два пика, соответствующих максимально интенсивным атакам: 21 февраля число атак составило 11 533, а 22 февраля — 19 889. Эти даты выделяются на следующем графике, отображающем для компании динамику атак за январь, февраль и март.

Рисунок 20. Динамика атак в течение первого квартала (интерфейс PT AF)

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

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

Рисунок 21. Распределение атак по времени суток

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

Рисунок 22. Динамика атак 1 марта в интерфейсе PT AF

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

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

Выводы

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

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

Эксперт Positive Technologies помог устранить критически опасную уязвимость в Viber для Windows

2017-05-26T04:51:00.001-07:00

Уязвимость Windows-клиента Viber, обнаруженная некоторое время назад группой исследователей информационной безопасности из России и Казахстана, в числе которых эксперт Positive Technologies, успешно устранена. Ошибка позволяла похищать технические данные для аутентификации пользователя под Windows.

«Суть атаки заключалась в том, что при отправке в чат ссылки вида http://host/img.jpg приложение сначала загружало ее от имени клиента, который осуществлял отправку, — и если по данному адресу содержалась картинка, то затем Viber пытался загрузить ее уже от имени принимающего клиента; схема не срабатывала, если клиент-инициатор не подтверждал наличие изображения по ссылке», — рассказывает Тимур Юнусов, руководитель отдела безопасности банковских систем Positive Technologies.

Если вместо изображения сервер отправлял сообщение с кодом 401 на второй запрос и запрашивал NTLM-аутентификацию вместо изображения, то приложение ее проводило.

Помимо разглашения NTLM-хеша, уязвимость позволяла совершать произвольные GET-запросы от имени атакуемого клиента. Это, к примеру, могло позволить осуществлять перепрограммирование домашних роутеров и других устройств.

«Атаку мог произвести только злоумышленник, чей номер мобильного телефона сохранен в списке контактов пользователя. Поэтому массовой атаки на пользователей Windows удалось избежать. Также заметим, что, как правило, для успешной атаки требуется совершить целую серию GET-запросов. Иными словами, злоумышленнику нужно отправить несколько ссылок потенциальной жертве. Около 6% из общего числа активных пользователей в России за последний месяц хотя бы один раз отправляли сообщение, использовали звонки или просматривали паблик-чат с устройств на Windows », — прокомментировали в пресс-службе Viber.

Уязвимость Windows-клиента Viber была устранена и отсутствует в обновленной версии Viber 6.7.2, которая уже доступна для загрузки.

Intel и Lenovo ограничили доступ к отладочному механизму процессоров после презентации экспертов Positive Technologies

2017-04-13T06:32:00.000-07:00

Компании Intel и Lenovo выпустили обновления безопасности для блокировки сценария атаки, который был обнаружен экспертами Positive Technologies в декабре 2016 года.

Несколько месяцев назад на конференции Chaos Communication Congress (33C3) в Гамбурге Максим Горячий и Марк Ермолов рассказали о том, что cовременные процессоры Intel позволяют использовать отладочный интерфейс через доступный на многих платформах порт USB 3.0 для получения полного контроля над системой. Подобные атаки не отслеживаются современными системами безопасности.

Спустя несколько месяцев, в апреле 2017 года Intel официально признала наличие уязвимости, выпустив обновление BIOS, которое отключает возможность активации доступа к отладочному интерфейсу через порт USB 3.0 из ОС. Корпорация поблагодарила экспертов Positive Technologies Максима Горячего и Марка Ермолова.

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

Выступление экспертов компании, в котором описывается проблема и раскрываются механизмы возможных атак, представлено ниже:

Слайды презентации доступны по ссылке.

Кроме того, Максим Горячий и Марк Ермолов провели вебинар, в ходе которого ответили на вопросы и подробнее рассказали о внутреннем устройстве отладочного механизма JTAG. Ниже представлено видео этого выступления:

Угрозы интернета вещей: как защититься от возможных атак

2017-04-12T07:27:00.000-07:00

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

Заместитель директора по развитию бизнеса Positive Technologies в России Алексей Качалин рассказывает о том, почему с защищенностью IoT-устройств все так плохо и как компании могут минимизировать риски ИБ-инцидентов с их участием.

Какие угрозы несет Интернет вещей

Одна из самых распространенных целей взлома устройств Интернета вещей — проведение DDoS-атак. Распространение всевозможных подключаемых к Интернету устройств дает злоумышленникам возможности по созданию ботнетов огромных размеров, с помощью которых можно «уронить» даже очень крупный сервис.

Пример — в прошлом году состоящий из сотен тысяч устройств ботнет Mirai был использован для DDoS-атак, в результате которых был выведен из строя сегмент сети Интернет в США, а также оказались недоступны многие популярные онлайн-проекты, вроде Twitter. Эта атака достигла рекордных показателей по объему генерируемого трафика, т.е. в несколько раз превзошла предыдущие «рекорды».

Помимо организации DDoS-атак для злоумышленников могут представлять интерес устройства, которые можно заблокировать. Были инциденты с «локерами» умных кондиционеров и телевизоров. Для этих сценариев важна массовость устройств – это необходимое условие рентабельности атаки.

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

Безопасность IoT: почему все плохо

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

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

Важная проблема, стоящая на пути к улучшению ситуации здесь, — это позиция производителей «умных» гаджетов. Уровень осознанности построения безопасности среди производителей IoT-устройств крайне низок: почти никто из них добровольно не тратит время и средства на дополнительное тестирование своей продукции на наличие уязвимостей, так как в ряде случаев это может поставить под угрозу темпы вывода продукта на рынок. Также нельзя сбрасывать со счетов и общее увеличение числа таких устройств, а также скорость появления новых их типов. В результате на рынке представлена масса уязвимых устройств, с помощью которых злоумышленники могут осуществлять даже глобальные атаки.

Как исправить ситуацию

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

Само IT-сообщество также занимается проработкой вопросов обеспечения безопасности IoT. Так, эксперты крупных IT- и ИБ-компаний подготовили список рекомендаций The Industrial Internet Security Framework. Этот документ интересен тем, что связывает ICS и IoT общими практиками безопасности. Однако это лишь рекомендации: не факт, что производители IoT-устройств будут их применять, поэтому в настоящий момент противодействием возможным проблемам должны заниматься сами владельцы инфраструктуры, на которую могут быть организованы атаки.

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

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

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

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

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

Заработал R&D-центр Positive Technologies в Брно

2017-04-07T05:11:00.001-07:00

Компания Positive Technologies объявила о старте работы R&D представительства в городе Брно, Чешская республика. Команда нового центра разработки и исследований займется развитием продуктов для обеспечения безопасности телекоммуникационных систем.

Задачи нового офиса

Одна из стратегических задач компании — стать ближе к своим заказчикам во всем мире. Поэтому Positive Technologies не только открывает офисы продаж в разных регионах, но и занимается развитием самостоятельных центров разработки.

«Брно подходит для такого подразделения как нельзя лучше — помимо удачного географического расположения, здесь расположены центры разработки крупных IT компаний — IBM, NetSuite, Red Hat, AVG Technologies, а также работают компании, близкие к сфере ИБ. Кроме того, в городе сложилась соответствующая атмосфера для разработки инновационных продуктов — из 350 тысяч жителей почти 90 тысяч составляют студенты.

В настоящий момент в нашем центре R&D уже работают четверо первых сотрудников — они занимаются разработкой продукта для обеспечения безопасности мобильных сетей PT Telecom Attack Discovery», - рассказал Борис Симис, заместитель генерального директора Positive Technologies по развитию бизнеса.

Команда центра разработки Positive Technologies в Брно

Планы

«Офис рассчитан на 35-50 человек, и мы планируем по максимуму развивать его. Сейчас пополняем команду разработки продуктов для SS7. Начали именно с них, потому что они наиболее востребованы на европейском рынке и в мире. Не исключено, что в будущем будем разрабатывать в Брно и другие продукты, а также развивать экспертизу», — говорит управляющий директор Positive Technologies Максим Шияновский.

Наш офис на первом этаже в Spielberk Office Centre, здесь же расположены компании AVG Technologies, SolarWinds и Xura

Риски безопасности: стоит ли разрешать сотрудникам банка пользоваться соцсетями на работе

2017-03-29T06:55:00.001-07:00

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

Зачастую кибератаки на банки начинаются с того, чтобы преступники убеждают работников финансовой организации открыть специально созданный вредоносный файл. Эксперт Positive Technologies Тимур Юнусов рассказывает о том, стоит ли запрещать сотрудникам банков пользоваться социальными сетями на работе, чтобы снизить риски подобных атак.

Атаки через сотрудников: главная опасность для банков

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

Исследования Positive Technologies показывают, что уровень осведомленности сотрудников компаний в вопросах ИБ остается на низком уровне. Очень часто работники открывают потенциально вредоносные вложения и выполняют действия, которые могут поставить под угрозу безопасность ИТ-инфраструктуры организации — цифры верны и для тех компаний, в которых сотрудники проходят обучение по информационной безопасности.

Одним из самых эффективных инструментов хакера является телефон — в ходе разговоров с сотрудниками банка им в 100% проанализированных нами ситуаций удавалось убедить собеседника открыть заранее отправленный им вредоносный файл или узнать логин или пароль работника. Все это говорит о том, что сотрудники банка зачастую могут являться слабым звеном в его безопасности, и финансовым организациям следует задумываться о том, как снизить риск атаки на свой персонал.

Соцсети: не все так просто

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

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

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

Заключение: запрещать или нет

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

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

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

Более эффективный путь для бизнеса — обучение персонала базовым знаниям о защите информации, а также использование специализированных средств защиты и обнаружения атак — например, SIEM-систем и межсетевых экранов WAF.