@onehellsus

Шор как угроза современной криптографии

2021-11-30T09:09:06.647Z

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

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

Проблема Y2Q

Исследователи придумали термин, обозначающий момент, когда "черепаха" будет проходить мимо "зайца". Это год Y2Q, когда возможности квантового взлома кода станут угрозой существованию классической криптографии. Когда это произойдет, остается только догадываться, но вопрос о том, произойдет ли это, для многих уже решен. В 2018 году в отчете Национальной академии наук, инженерии и медицины США (NASEM) было предсказано, что мощный квантовый компьютер, использующий алгоритм Шора, сможет взломать 1024-битную реализацию шифрования RSA менее чем за 24 часа.

Математик Питер Шор, ответственный за один из алгоритмов, в конце 2020 года добавил свое собственное предупреждение: «Я думаю, что единственным препятствием для замены RSA [криптосистемы с открытым ключом] на безопасную постквантовую криптосистему будет сила воли и время программирования... Если мы будем ждать слишком долго, будет слишком поздно».

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

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

а не экспоненциального

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

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

Алгоритм Шора

Питер Шор

В этом параграфе кратко рассмотрим сам алгоритм Шора. Цель алгоритма: для нечетного составного числа

нужно найти целое число

(строго от 1 до

которое делится на

Алгоритм Шора состоит из следующих частей:

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

Факторизация числа

Общая последовательность действий:

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

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

Перспективы развития

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

Стоит отметить, что проблема массового исчезновения информационной безопасности не нова. Шифрование, созданное немецкими военными машинами Enigma во время Второй мировой войны, в конечном итоге было взломано союзниками, но на этом криптография не закончилось. А в 1977 году в ходе публичного конкурса был нарушен современный стандарт шифрования данных (DES).

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

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

Заключение

Итак, в нашей статье мы рассмотрели опасность квантового вычисления для классического шифрования Y2Q, представили краткое описание алгоритма Шора и поговорили о перспективах развития криптографии.

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

https://habr.com/ru/post/592413/

Серьезная ошибка в процессорах Intel раскрывает ключи шифрования

2021-11-24T07:17:32.504Z

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

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

Так утверждает компания Positive Technologies (PT), которая обнаружила, что уязвимость (CVE-2021-0146) связана с возможностью отладки с чрезмерными привилегиями, которая не защищена должным образом.

Проблема, связанная с повышенной эскалацией привилегий, оценивается в 7,1 балла из 10 по шкале серьезности уязвимостей CVSS.

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

С точки зрения области распространения, уязвимость затрагивает процессоры Pentium, Celeron и Atom платформ Apollo Lake, Gemini Lake и Gemini Lake Refresh. Эти чипы используются в ноутбуках, мобильных устройствах, встраиваемых системах, медицинских приборах и различных устройствах Интернета вещей (IoT).

«Согласно исследованию Mordor Intelligence, Intel занимает четвертое место на рынке IoT-чипов, а ее IoT-процессоры Intel Atom серии E3900, которые также содержат уязвимость CVE-2021-0146, используются автопроизводителями в более чем 30 моделях, в том числе, по неофициальным данным, в Model 3 компании Tesla», — отмечает PT в статье, которой поделился с Threatpost.

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

Источник: Intel

Влияние CVE-2021-0146 на конечных пользователей

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

«Одним из примеров реальной угрозы являются потерянные или украденные ноутбуки, содержащие конфиденциальную информацию в зашифрованном виде» — говорит Марк Ермолов, исследователь PT, которому принадлежит заслуга в обнаружении ошибки (вместе с Дмитрием Скляровым из PT и независимым исследователем Максимом Горячим).

«Уязвимость опасна еще и тем, что позволяет извлечь рут-ключ шифрования, используемый в технологиях Intel Platform Trust Technology и Enhanced Privacy ID, которые применяются для защиты цифрового контента от незаконного копирования», — добавил Ермолов.

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

Кроме того, эксплойт может позволить хакерам проводить целевые атаки по всей цепочке поставок, отметил Ермолов.

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

Как Авито помогает мошенникам и усложняет жизнь обычным пользователям

2021-11-22T07:18:24.030Z

Покажи нам свое лицо! Или не свое. Главное, – покажи!

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

Авито намекает нам, что данному продавцу можно доверять.

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

Welcome To The Club

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

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

В моем профиле на момент блокировки было 21 завершенное (в разное время, это важно) объявление, 4 активных объявления, три положительных отзыва обо мне(оставленных в разное время, это важно), и пять (!) покупок через Авито Доставку.

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

Но поиск бура для перфоратора алгоритмы Авито сочли возможным "сбором контактов для продажи", о чем мне сообщила поддержка после моего обращения:

Бот поддержки выдает стандартное сообщение с предложением пройти проверку.

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

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

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

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

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

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

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

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

Проверенные пользователи (но это не точно)

Пользователь, который предоставил площадке требуемые данные, получает себе в профиль плашку "Документы проверены". При клике на нее выходит сообщение:

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

Я не знаю, как именно площадка (или упомянутая ООО-шка) проверяет документы и видео, а также с чего вдруг сотрудники Авито так уверены, что пользователь прислал именно СВОИ документы и видео именно СВОЕГО лица.

Факт: мошенники с легкостью обходят эту проверку!

Давайте заглянем в два профиля на сайте Авито:

Некий "Юрий Юрьевич" (https://www.avito.ru/user/b559799c549de7871fab976317669410/profile?id=2251833877)
И его коллега "Иван Геннадьевич" (https://www.avito.ru/user/e3d965935c280ad0ed956dec60950181/profile?id=2251837100)

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

"Юрий Юрьевич"

Теперь Юрию Юрьевичу можно доверять! Но это не точно.

"Иван Геннадьевич"

Иван Геннадьевич тоже получил одобрение площадки.

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

По мнению Авито, именно по отметке "Документы проверены" пользователи определяют надежных продавцов.

Этих двух прекрасных людей объединяет одно, – они мошенники. Самые настоящие, самые махровые. Кидалы. Жулики.

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

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

Давайте попробуем разобраться

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

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

Возможная причина кроется здесь:

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

Подытожим

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

Выводы

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

Атака на промышленную IT-инфраструктуру

2021-11-22T07:06:33.943Z

1. Введение

Здравствуйте, уважаемые читатели.

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

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

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

2. Атака по цели

В качестве тестовой жертвы будет рассмотрена несуществующая крупная организация "White Hat 631" (все совпадения случайны). Для начала мероприятий по атаке необходима точка входа. Если вы действуете удаленно, то обычно ею выступает сайт организации — в нашем случае whitehat631.com.

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

2.1 Сканирование поддоменов

Самый простой шаг — узнать, какие существуют поддомены у основного домена. Для его реализации существует множество готовых инструментов, напр., Sublist3r. Из онлайн-сервисов можно отметить nmmapper (вкладка "subdomain finder"). Принцип работы таких инструментов можно подсмотреть в реализациях с открытым исходным кодом. Также тут не будет предоставлено подробных инструкций по работе с конкретными инструментами, — достаточно воспользоваться документацией.

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

mail.whitehat631.com
dev.whitehat631.com
gitlab.whitehat631.com
api.whitehat631.com
wiki.whitehat631.com
stat.whitehat631.com
...

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

2.2 Сканирование сети

Если организация крупная, то, скорее всего, она будет использовать целую подсеть IP адресов(/24 или больше). Убедиться в этом можно по разному. Cамый простой способ заключается в том, чтобы получить IP адреса нескольких поддоменов (напр., через утилиту ping) и проанализировать их. Допустим, мы это сделали и получили:

111.101.102.5
111.101.102.37
111.101.102.49
111.101.102.11

Тут становится весьма вероятным, что организация, по меньшей мере, использует подсеть 111.101.102.0/24 (то есть диапазон адресов 111.101.102.1-111.101.102.255). Неплохой идеей будет желание просканировать на популярные порты весь этот диапазон. Утилита nmap справится с этим за считанные минуты. Просто выполните с рабочего места следующее:

> nmap 111.101.102.0/24

В результатах работы вышеприведенной команды стоит уделить особое внимание нестандартным открытым портам (под стандартными в данном случае считаются только 80/HTTP и 443/HTTPS, т.к. они подставляются в браузерах пользователей по умолчанию в зависимости от протокола). Не исключено, что, напр., по адресу 111.101.102.37:8080 разработчики оставили веб-панель для управления частью инфраструктуры и забыли прикрутить авторизацию. Тем временем, про стандартные порты тоже не стоит забывать — там тоже может быть что-то интересное (особенно если попался IP адрес который не разрешается в (под)домен, т.к. он наверняка не предназначен для общего пользования). Кстати, результаты сканирования удобно сохранять в файл.

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

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

2.3. Сканирование путей у найденных веб-сервисов

Итак, на данном этапе надо консолидировать информацию о полученных веб-сервисах в п. 2.1-2.2. Если с первого взгляда на них нет ничего интересного (напр., они могут отвечать ошибкой 404/Not Found на главной странице), то стоит заняться частным случаем фаззинга — просканировать пути. Так можно найти всякого рода админки/копии репозиториев с кодом/бэкапы/элементы управления и получения закрытой информации. Для этого я рекомендую использовать утилиту wfuzz. Так как такое сканирование осуществляется путем перебора, то потребуется хороший словарь (хотя бы на пару десятков тысяч вариантов). Начать искать словари можете, напр., отсюда. Пример работы с wfuzz (который будет исключать 404/403 ответы от сервера и работать в 20 потоков):

> wfuzz -c -u http://stat.whitehat631.com:8080/FUZZ \
	-w dict_30k.txt --hc 404,403 -t 20

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

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

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

Отсутствие авторизации в закрытых сервисах организации как таковой;
Недостаточная проверка прав доступа к частям приложения/сервиса — очень частая ошибка разработчиков и на сегодняшний день;
Использование старых версий общеизвестных приложений/веб-серверов, для которых существуют доступные вам эксплойты (см. exploit-db.com, cvedetails.com и проч.) ;
Возможность атаки, которая базируется на недостаточной фильтрации и проверке входных данных. Это может вылиться в такие вещи как SQL-инъекции, XSS, LFI, RFI, RCE и т.д. Тут уже потребуются некоторые навыки, но эта тема для отдельной статьи. Из банального: может присутствовать загрузчик файлов, который не проверяет расширения и позволяет залить исполняемый скрипт (такое особенно часто проходит с PHP).

Стоит отметить, что только лишь веб-сервисами варианты атак не ограничиваются, — можно устроить атаку на роутеры/SIP/VoIP/FTP/E-Mail и/или прочие службы (если они достаточно стары, вы, вероятно, сможете найти для них эксплойты).

Также не все эксплойты подразумевают организацию выполнения удаленного кода (RCE) и/или прочий контроль. Но "не расстраивайтесь", варианты ещё есть. Например, весьма полезным может оказаться уязвимость, которая позволяет выполнять перечисление логинов в приложении. Во-первых, зная логины, можно попробовать подобрать пароли (в скрытых сервисах часто такие пароли просты, нет проверок и ограничений на массовые попытки авторизации) — это всё ещё работает. Для этого используются специальные инструменты для проведения bruteforce-атак. Их великое множество, от hydra до patator.

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

К слову, бывают уязвимости которые позволяют проверить, существует ли тот или иной логин (напр., функция "Забыли пароль?" и/или особенности работы "Skype for business Server" в AD). В таком случае помимо перебора по словарю весьма хорошим подспорьем будет исследование открытых данных об организации (руководство, сотрудники, информация о которых может быть размещена на официальном сайте или в новостях и т.д.). Например, если ген. директора организации зовут Иванов Алексей Николаевич, а в организации используется генерация логинов по определенному алгоритму (что практически наверняка есть в месте где работают множество сотрудников), то его логином может быть ANIvanov, AIvanov, IvanovAN и т.д. Этим примером я хочу показать, что открытые данные тоже могут сыграть хорошую службу при атаке.

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

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

3. Углубление в инфраструктуру

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

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

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

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

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

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

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

Регулярно обновляйте серверное/прикладное программное обеспечение и библиотеки (включая компоненты ОС);
Закройте всё и вся. Не пытайтесь спрятать что-то (напр., на нестандартных портах) думая что никто не найдет — найдут. Это касается не только внутренних сервисов, но и баз данных и прочих служб;
Используйте современные средства авторизации и аутентификации (включая n-факторные);
Производите постоянный мониторинг активности в вашей сети автоматическими системами: кто что загружает, выгружает, сканирует. Уделите этому особое внимание;
Регулярно меняйте пароли, автоматизировав это деяние соотв. политиками безопасности;
Производите инструктаж сотрудников с периодическими контрольными проверками (присылайте им фишинговые письма на e-mail и наказывайте тех кто попался/т.д.) — это также является хорошей точкой входа для атаки на организацию;
Разграничивайте доступ среди сотрудников, чтобы утечка данных одного не повлекла за собой лавинное обрушение всей системы безопасности.

Источник:https://habr.com/ru/post/590387/

BYOD: методы защиты и рекомендации

2021-11-19T16:00:02.879Z

MDM (Mobile Device Management) — системы, позволяющие IT-службам управлять устройствами сотрудников и создавать безопасную среду для данных компании. С помощью MDM можно защититься от вредоносных программ, создать безопасное шифрование и пароли, а в случае, если устройство было утеряно, оперативно удалить данные. Это комбинация приложений, корпоративных политик и сертификатов.

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

Решить проблему человеческого фактора поможет так называемая Common Sense Provision — «Политика здравого смысла». Это общие правила, которые формулируются во внутренней политике компании и помогают справиться с опасными поведенческими привычками на работе.

Примеры Common Sense Provision:

запрет на использование девайса за рулем;
ограничение личных звонков на работе;
запрет или ограничение на видео или фотосъемку на рабочем месте;
запрет на подключение к общедоступным Wi-Fi-сетям или отслеживание GPS;
последовательность действий в случае утери устройства и пр.

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

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

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

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

BYOD: что дальше?

По данным IBM, более 80% сотрудников после окончания пандемии продолжат работать в гибридном режиме, что делает неизбежным внедрение хотя бы базового уровня BYOD в компании.

Лидерами в принятии концепции выступили компании из сферы IT / ITES, но сегодня к ним примкнули и компании из других отраслей, в т. ч., из банковского и страхового сектора, телекоммуникаций, здравоохранения и образования. К вертикалям с высоким потенциалом принятия BYOD аналитики также относят логистику, торговлю (e-commerce), сферу путешествий и транспорт.

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

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

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

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

Итак, к BYOD можно относиться как угодно — скептически или с восторгом. Но факты утверждают, что концепция Bring Your Own Device — наше неизбежное будущее.

2000000$ за найденную уязвимость

2021-11-13T12:37:38.237Z

Что такое Polygon и Plasma

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

Сначала немного терминологии, кто знаком может пропустить:

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

Решения второго уровня/слоя (L2-решения) — это проекты, приложения и технологии инфраструктурного программного обеспечения, развернутые поверх базовых блокчейнов.

Сайдчейны — технология, позволяющие токенам и другим цифровым активам одного блокчейна безопасным образом использоваться в другом блокчейне и затем (в случае необходимости) быть возвращенными в оригинальный блокчейн. Изначально концепция сайдчейнов (side chain) была описана в 2014 году в «белой бумаге» (white paper), который написали разработчики компании Blockstream. Сайдчейн (side chain) представляет собой отдельный блокчейн с двусторонней привязкой к родительскому блокчейну. Это обеспечивает взаимозаменяемость активов. Родительский блокчейн обычно называется «основной (главной) цепью» (master chain), дополнительные цепи — сайдчейнами (side-chain). Пользователь родительского блокчейна должен сначала отправить монеты на выходящий адрес, где они «запираются» участниками так называемой «федерации», что призвано исключить возможность их траты в другом месте. По завершении транзакции ее участники получают подтверждение, однако для дополнительной безопасности это происходит после некоторого периода ожидания. После этого эквивалентное количество монет переводится в сайдчейн (side chain), и у пользователя появляется возможность их потратить. При отправке монет из сайдчейна (side chain) в основной блокчейн происходит обратный процесс.

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

Plasma — решение второго уровня для масштабирования сети Ethereum, изначально предложенное Джозефом Пуном и Виталиком Бутериным. Технология предусматривает использование смарт-контрактов и деревьев Меркла для создания неограниченного числа дочерних цепей — копий родительской сети Ethereum. Они разгружают основной блокчейн, открывая возможность осуществления быстрых и недорогих транзакций. По принципу работы Plasma похожа на Lightning Network: набор умных контрактов, позволяющий множеству сайдчейнов фиксировать свое состояние в сжатом виде в корневом блокчейне. Plasma применяет экономические стимулы, включая наказание отвергнутого сетью создателя блока для предотвращения мошенничества. В июне 2020 года работающая над масштабированием Ethereum компания OMG Network запустила бета-тестирование OMG Network V1, базирующейся на спецификациях последней версии Plasma — More Viable Plasma (MoreVP). MoreVP масштабирует Ethereum, группируя транзакции и отправляя их через набор смарт-контрактов. Сгруппированные данные проходят верификацию и валидацию в децентрализованной сети хранителей. Группирование позволяет увеличить пропускную способность сети до тысяч транзакций в секунду и значительно сократить их стоимость. Это отдельный блокчейн, который привязан к основной цепочке Ethereum и использует fraud proofs (Optimistic rollups) для разрешения споров.

Matic Network (теперь Polygon) — решение второго уровня с поддержкой фреймворка Plasma и децентрализованной сети PoS-валидаторов. Проект использует сайдчейны (side chain) для офчейн-вычислений. В начале 2021 года состоялся ребрендинг проекта. Сменилось название на Polygon, изменилась стратегия в сторону создания мультичейн-системы, похожей на Polkadot. Команда проекта работает над созданием решений второго уровня на базе Ethereum. Polygon - это протокол и платформа для создания и подключения блокчейн-сетей, совместимых с Ethereum. Платформа предлагает «надежный двусторонний канал транзакций» между Polygon и Ethereum. Этот «блокчейн-мост» использует сеть под названием Plasma для аутентификации и обработки вывода средств. Именно в контракте на Plasma, доверенном лице управляющего депозитами, был обнаружен недостаток.

Архитектура Polygon Network

В архитектуре протокола содержатся 3 абстрактных слоя:

Polygon Ethereum смарт-контракты - набор смарт-контрактов на Ethereum, которые обрабатывают:

Стейкинг (Staking) для поддержания Proof-of-Stake;
Управление делегированием, включая общие ресурсы валидатора;
Plasma контракты для MoreVP, включающие checkpoints/snapshots для сайдчейна (side chain).

Heimdall (Proof of Stake layer) – PoS валидатор, который работает на основе Ethereum-контрактов для реализации PoS механизма в Polygon. Он отвечает за проверку блоков, продюсер (block producer).
Bor (Block producer layer) – ответственный за объединение транзакций в блоки. В настоящее время это базовая реализация Geth с некоторыми изменениями, внесенными в алгоритм консенсуса.

На приведенной ниже диаграмме показан поток пользовательских средств через Polygon network (source):

Пользователь вносит средства в контракт моста в L1 (основной сети Ethereum);
После подтверждения транзакции депозита в сети Ethereum, токены доступны в сети Plasma, чтобы пользователи могли их передавать;
Когда пользователь решает вывести средства обратно на L1, токены необходимо сжечь в Plasma. Нужно дождаться контрольной точки. Затем контрольная точка отправляется в мастер-чейн (master chain);
Когда контрольная точка пройдена, выпускаются Exit NFT (ERC721);
Далее необходимо подождать 7 дней;
После 7-дневного периода проверки средства могут быть выведены обратно пользователю на L1.

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

Разбор уязвимости

Логика вывода средств обратно в блокчейн Ethereum реализована, в частности, в контракте ERC20PredicateBurnOnly. Выход можно запустить, вызвав функцию startExitWithBurntTokens из данного контракта. В контракте WithdrawManager, также отвечающего за вывод средств, в функции verifyInclusion в строке 115 происходит проверка, включена ли квитанция в дерево. Уязвимость в том, как Polygon WithdrawManager проверяет включение и уникальность в предыдущих блоках.

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

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

Идентификатор выхода частично состоит из branch mask, которая поступает непосредственно из пользовательского ввода, что является слабым местом. Если бы было возможно создать альтернативную branch mask, которая каким-то образом способна создать более одного идентификатора выхода, относящегося к одной и той же транзакции. Более пристальный взгляд на функцию в библиотеке MerklePatricaProof показывает, что что-то происходит с путем до того, как будет пройден цикл из строки 40. В строке 35 branch mask передается в функцию _getNibbleArray.

Проверка функции _getNibbleArray показывает, что branch mask (аргумент функции encodedpath) закодирована (Hex Prefix encoded).

Функция _getNibbleArray проверяет с какого значения начинается переданный набор. Если первая часть байта (цифра) 1 или 3, то учитывается вторая часть первого байта и декодируются все оставшиеся значения, иначе первый байт игнорируется. Давайте рассмотрим на примере и предположим, что branch mask равна 0x00819c. Первый байт отбрасывается, так как он – 0, и его первая часть не равна 1 или 3, а остальные фрагменты расширяются до 0x0801090c.

Также в функции verifyInclusion преобразуется branchMask в uint256.

Так как getNibbleArray отбрасывает часть информации, то получаем, что одному значению декодирования getNibbleArray соответствуют несколько uint256 значений. В общей сложности можно создать 14x16 = 224 различных кодировок для одного и того же пути. Злоумышленник может использовать эту проблему для создания альтернативных выходов для одной и той же транзакции и выполнения двойных трат в сети Polygon.

Влияние

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

Атакующий:

депонирует токены на сумму 200 000 долларов США в контракт DepositManager;
запускает процесс вывода выхода (withdrawal);
ожидает семидневный период проверки;
запускает вывод, переиспользуя предыдущие данные с модифицированным параметром branch mask.

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

Исправление

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

Источник:https://habr.com/ru/company/domrf/blog/588737/

Использование БПЛА для оценки защищенности информации

2021-11-13T12:28:18.143Z

Для осуществления расчетов на высоте можно использовать БПЛА, на который устанавливается микрофон и несколько антенн (в простейшем случае используется один микрофон и две антенны, для измерения магнитной и электрической составляющей ЭМП и уровень сигнала). Возможна установка на корпус БПЛА фото/видеокамеры.

Возможны следующие системы управления полетам БПЛА:

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

Требования к исследуемой местности

Для обеспечения безопасности и сохранности БПЛА необходимо исследовать место проведения измерений:

в качестве места старта требуется выбрать ровную площадку размером не менее 100х100 м. Необходимо чтобы на прилегающей к этой площадке территории не было объектов, которые могли бы затруднить взлет и посадку БПЛА (реки, озера, овраги, строения, мачты, вышки и т.п. объекты высотой более 100 м) в радиусе 400 м;
следует определить положение сторон света для более точной навигации;
следует определить направление и скорость ветра (необходимо учитывать, что эти параметры могут отличаться в точке старта и на рабочей высоте);
перед началом полета требуется определить траекторию движения БПЛА, осуществляющего измерения, удостовериться, что по всей траектории нет объектов, которые могли бы затруднить полет или нарушить радиосвязь между пунктом управления и дроном;
необходимо выбрать место посадки аналогично месту запуска БПЛА. Местность должна быть ровной, чтобы при посадке не повредить беспилотник и посторонние объекты;
место старта и место посадки не должны быть сильно удалены друг от друга на местности, для того, чтобы оператор мог визуально отслеживать процесс посадки и взлета БПЛА.

Требования, предъявляемые к оператору, управляющим БПЛА

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

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

Оператор БПЛА должен уметь и знать:

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

Этапы использования БПЛА

Основные этапы использования БПЛА при оценке защищенности информации:

подготовительные работы;
работы перед взлетом;
процесс полета (этап включает в себя взлет, посадку и пролет по заданной траектории);
расчет показателей защищенности по измеренным с использованием БПЛА значениям.

Подготовительные работы

Данный этап проходит заблаговременно перед совершением полета и подразумевает следующее [12]:

постановка задачи полета;
исследование местности на наличие объектов, которые могут препятствовать полету;
изучение планов, карт местности;
утверждение плана действий операторов при полете БПЛА, в том числе при особых условиях, возникающих в процессе полета;
определение способ связи между операторами при выполнении взлета, посадки и при движении по маршруту полета;
выбор место старта и места посадки беспилотника, продумывание возможности подъезда (прохода) к этим точкам;
выбор маршрута и составление схемы полета;
представление плана полёта БПЛА, «а также получение разрешения центра ЕС ОрВД на использование воздушного пространства» [13]. «Использование воздушного пространства беспилотным воздушным судном в воздушном пространстве осуществляется на основании плана полета воздушного судна и разрешения на использование воздушного пространства» [3].

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

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

б) на удалении не менее 5 км от контрольных точек неконтролируемых аэродромов и посадочных площадок» [3].

Работы перед взлетом

Данный этап проводится в день совершения полета и подразумевает следующее:

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

Процесс полета

На данном этапе необходимо:

постоянно контролировать изменения погодных условий;
постоянно контролировать работоспособность беспилотника, вспомогательного оборудования и измерительных приборов;
с началом деятельности, не позднее, чем за 5 минут следует позвонить в центр ЕС ОрВД и сообщить о фактическом времени начала полета [14];
после окончания полетов необходимо позвонить в центр ЕС ОрВД и сообщить об окончании полета. Сделать это следует не позднее, чем через 10 минут, после завершения работ [14];
после посадки необходимо провести проверку беспилотника, вспомогательного оборудования и измерительных приборов и их подготовку к следующим взлетам.

Расчет показателей защищенности по измеренным с использованием БПЛА значениям

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

Используя микрофон и две антенны, которые установлены на БПЛА, в заданных КТ проводятся измерения уровня напряженности ЭМП по магнитной и электрической составляющей и уровень акустического сигнала и уровень шума.

По этим значением производится расчет показателей защищенности по формулам приеденным современных методиках. Далее делается вывод о защищенности информации в помещении от утечки по каналу ПЭМИ и по акустическом каналу.

Измерение с использованием БПЛА необходимых для оценки защищенности информации значений

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

После проведения измерений производится перерасчет необходимого радиуса КЗ по формулам из методик. Минимально необходимый радиус КЗ в воздушном пространстве выбирается из набора полученных радиусов в каждой n-ой КТ и равен максимальному из полученных значений.

Обеспечить защищенность информации можно не только с использованием САЗ, но и путем перемещения источника информации внутри помещения (например, перенести источник информации на несколько этажей вниз).

Проведение измерений

Суть методики измерения с использованием БПЛА заключается в пространственном перемещении измерительного оборудования при помощи беспилотника в автоматическом режиме по траектории, лежащей в переделах полусферы с радиусом R и с центром, находящимся в месте установки исследуемого оборудования. Радиус полусферы R – это расстояние от источника информации до места возможного перехвата информации. Перехват информации из воздушного пространства возможен с использованием все тех же БПЛА. Исходя из Федеральных правил по использованию воздушного пространства РФ в светлое время суток и при прямой видимости беспилотника «с максимальной взлетной массой до 30 кг» [3] возможно его использование на высоте «не более 150 метров от поверхности воды или земли» [15].

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

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

Зависимость радиуса облета R от частоты съема показаний измерительных приборов [16] можно записать как (1).

R=(360*v)/(2πφ_i f) (1)

Где

v – скорость движения БПЛА,

φ_i – шаг измерений,

f – частота съема показаний измерительных приборов.

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

Возможны два варианта измерения необходимых данных с использованием БПЛА:

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

Для одновременной передачи в режиме реального времени команд оператора с пульта управление на полетный контроллер и данных с датчиков и измерительного оборудования необходимо использовать несколько радиоканалов: один для передачи измерений и один для управления кинематикой БПЛА.

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

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

Маршрут движения БПЛА

Для проведения необходимых измерений в воздушном пространстве БПЛА должен оказываться над определенными точками земной поверхности (КТ). Для того чтобы полет был максимально эффективен требуется заранее продумывать маршрут полета. Маршрут будет складываться из последовательности точек над поверхностью земли, в которых будут проведены измерения. Такие точки с известным местоположением называют маршрутными, или поворотными [17].

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

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

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

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

Наиболее оптимальным маршрутом является маршрут по концентрическим кругам с центром в месте установки исследуемого оборудования. На рисунке 5 обозначен радиус полусферы измерений R, высота между сечениями h и радиус i-сечения

Рисунок – Схема полета БПЛА по концентрическим окружностям

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

При планировании маршрута следует учитывать:

не следует прокладывать маршрут возле линий электропередач и других объектов с большим уровнем электромагнитных излучений;
предполагаемое время полета не должно превышать 2/3 от заявленной производителем возможности БПЛА продолжительности полета;
на выполнение взлета и посадки дрона необходимо отводить не менее 10 минут от общего времени полета;
глубину рабочей зоны (расстояние от пульта управления до наиболее удаленной КТ маршрута) следует выбрать такую, чтобы во время всего полета был устойчив сигнал от пульта управления до БПЛА.

Выбор БПЛА и измерительного оборудования для использования при оценке защищенности информации

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

Для проведения измерений понадобится антенны – для измерения уровня напряженности по электрической составляющей ЭМП (диапазон рабочих частот 9 кГц – 1000 МГц), и для измерения уровня напряженности по магнитной составляющей ЭМП (диапазон частот 9 кГц – 30 МГц).

Измерения уровня напряженности по электрической составляющей ЭМП будем проводить с использованием измерительной антенны П6-51 [18] с диапазоном рабочих частот 9 кГц – 300 МГц (приложение A). Масса антенны не более 1,2 килограмм. И антенна П6-52 [19] с диапазоном рабочих частот 300 – 1000 МГц (приложение B). Масса антенны 1,5 килограмма. Двумя антеннами полностью перекрывается диапазон частот для измерения электрической составляющей ЭМП 9 кГц – 1000 МГц.

Для измерений измерения уровня напряженности по магнитной составляющей ЭМП будем использовать антенну EMCO-6509 [20] с диапазоном рабочих частот 1кГц – 30 МГц (приложение C) и массой 1,3 килограмма.

Для проведения измерений и оценки защищенности от утечки по акустическому ТКУИ необходимо установить на борт БПЛА конденсаторный микрофон TMS130E20 [21] с массой 25,7 грамм (приложение E), а на земле установить генератор тестовых сигналов с автоматической перестройкой частоты для непрерывности измерений.

Общий вес измерительного оборудования и минимально допустимая масса полезной нагрузки и дрона составляет 4,1 килограмма.

По требуемым характеристикам – максимально возможной подъемной массой выбираем БПЛА SOVZOND Drone 10000 [22] (приложение D). С максимально возможной полезной нагрузкой в 10 килограмм, данный беспилотник позволяет разместить на раме БПЛА не только измерительные антенны, но и микрофон и камеру для визуального наблюдения с высоты полета дрона для более точного реагирования на внештатные ситуации оператором.

Также на корпусе БПЛА необходимо разместить запоминающее устройство для записи всех данных измерения.

Расчет параметров полета выбранного БПЛА

Для определения необходимого времени полета рассчитаем суммарную длину траектории движения БПЛА по сферическим кругам. Методом подбора определим для радиуса полусферы R = 150 метров и возможной продолжительности полета для выбранного БПЛА SOVZOND Drone 10000 = 55 минут высоту между смежными сечениями при движении БПЛА по траектории концентрических окружностей.

БПЛА имеет продолжительность полета 0,917 часа и скорость 54 км/ч, следовательно на одном заряде батареи сможет пролететь 49,5 км. В характеристиках указана максимальная дальность полета 45 км, с учетом требуемого времени на взлет, посадку и измерения возьмем за дальность полета 40 км.

Рассчитаем суммарное расстояние, которое требуется преодолеть БПЛА для полного облета полусферы.

Оптимальная для данного БПЛА высота между смежными сечениями 3 метра. В этом случае БПЛА SOVZOND Drone 10000 взлетит, спокойно пролетит всю необходимую траекторию, измерит все данные и сядет на землю на одном заряде и не требуется осуществлять дополнительные взлеты и посадки для подзарядки БПЛА.

Сравнительный анализ современных методик оценки защищенности информации с методом использования БПЛА при измерениях

Рассмотрим современный метод оценки защищенности информации от утечки по каналу ПЭМИ. Рассмотрение акустического канала утечки информации, возможность перехвата такой информации и возможность оценки защищенности информации с воздуха затруднено, из-за значительного расстояния источника акустического сигнала и технического средства разведки или БПЛА, а также из-за создаваемого шума самим БПЛА.

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

В этом случае при оценке защищенности информации не рассматриваются возможности съема информации с некоторой высоты. Предположим, что источник информации находится на 1 этаже здания, а на втором этаже этого здания расположено окно, а этажи разделены менее толстым перекрытием, по сравнению с бетонной стеной между источником информации и ТСР, но, тогда следует учитывать экранирующие свойства всех ограждающих конструкций во всем здании, а не только ОК между источником информации и местом возможного съема информации. Как известно, «чем выше удельная проводимость материала экрана, тем эффективнее экранирование» [23]. Поэтому более экранирующим материалом будет бетонная стена (удельная проводимость – 〖10〗^(-1) см/м), по сравнению со стеклянным окном на 2 этаже (удельная проводимость – 〖10〗^(-11)/см/м) здания. Получается, что бетон в раза больше экранирует ЭМП от источника информации по сравнению со стеклом, перекрытие между этажами тоже менее экранирующий материал по сравнению с толстой бетонной стеной. Также предположим, что с другой стороны КЗ от источника ЭМП расположена металлическая стена, от которой будет происходить отражение сигнала ЭМП, так как металл является токопроводящей средой, от которой отражаются электромагнитные волны.

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

Используя метод оценки защищенности информации в помещении с использованием БПЛА расчеты производится с учетом возможности кражи информации из воздушного пространства, тем самым при оценке учитываются все точки возможного съема информации, в том числе и с воздуха и границы КЗ рассматриваются не только в горизонтальной, но и в вертикальной плоскости. А как показывает смоделированная ситуация, что на границе КЗ и за ее пределами при прохождении ЭМП через различные среды уровень сигнала в месте съема информации может значительно отличаться от предполагаемых уровней при съеме информации с поверхности земли, как это предполагается в современных методах оценки защищенности. И достаточно злоумышленнику подняться на некоторую высоту, даже не обязательно используя БПЛА, он сможет получить больший уровень сигнала от источника, чем он бы получил, находясь на земле.

Перспективы развития метода оценки защищенности с использованием БПЛА

Для улучшения методики оценки защищенности информации в помещении с использованием БПЛА можно определять АЧХ в каждой КТ полусферы измерений, что позволит прогнозировать уровень сигнала ЭМП не только на информационных частотах отдельно взятого источника ЭМП, но и любого другого источника с другими информационными частотами. Определив уровень ЭМП в каждой точке во всем диапазоне частот, можно будет знать, какой уровень сигнала будет в КТ на определенной частоте без надобности дополнительных измерений.

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

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

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

Источник:https://habr.com/ru/post/588869/

Что и как нужно защищать в облачной среде

2021-11-10T12:56:10.617Z

Если не погружаться в тему, может показаться, что проблема довольно надуманная. Какая разница, где находится сервер, если это всё та же Windows Server или всё тот же Linux. Просто железо, на котором он выполняется, размещено в дата-центре. Ставим привычный антивирус, IPS/IDS, подключаем к SIEM, и готово.

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

Серверы - физические, виртуальные, облачные

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

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

Консоль Trend Micro XDR с информацией о возможном инциденте. Источник (здесь и далее): Trend Micro

Всё это должно иметь удобный API и интеграцию с пайплайн-решениями и интеграцией с SIEM, XDR и пайплайн-решениями для обнаружения, блокировки и расследования инцидентов.

Ещё одно требование — поддержка всех распространённых операционных систем и облачных платформ от Windows и Linux до AWS и MS Azure.

Контейнеры и системы оркестрации

Уязвимости контейнерных платформ — довольно популярный вектор кибератак последних лет. Злоумышленники пытаются скомпрометировать Docker и Kubernetes, чтобы запустить на выполнение вредоносный контейнер, обойти аутентификацию или внедрить вредоносное ПО в популярный образ в репозитории.

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

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

Для этого необходимо, чтобы система выполняла следующие действия:

сканирование образов контейнеров в процессе разработки на:

наличие уязвимостей, вредоносного ПО, секретов и индикаторов компрометации,
соответствие отраслевым требованиям (NIST, PCI, HIPAA);

контроль развёртывания на основе:

определённых правил контроля и управления,
политик для подов, образов и контейнеров;

защиту контейнеров во время работы:

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

Файловые хранилища

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

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

Приложения

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

Перечислим требования к такой платформе:

защита от эксплуатации уязвимостей и утечек данных, в том числе от:

SQL-инъекций, XSS, CSRF,
удалённого выполнения команд (RCE),
несанкционированного доступа к файлам;

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

Сетевая инфраструктура

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

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

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

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

Безопасность Open Source

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

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

Управляемость

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

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

Очевидно, что внедрение облачной инфраструктуры добавляет ряд операционных сложностей:

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

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

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

Заключение

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

Источник:https://habr.com/ru/company/trendmicro/blog/588092/

Ontol: 58 бесплатных онлайн-курсов по кибербезопасности, криптографии и blockchain от лучших университетов мира

2021-11-05T07:41:53.029Z

HackerOne

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

Hacker101 от HackerOne

Stanford University

Один из лучших в мире университетов опубликовал 23-часовой бесплатный курс по криптографии.

Cryptography I

Caltech

Калифорнийский технологический институт рассказывает про квантовую крипттографию. 10 недель по 6-8 часов.

Quantum Cryptography от California Institute of Technology

Princeton University

Bitcoin and Cryptocurrency Technologies от Princeton University

IBM

Cybersecurity Compliance Framework & System Administration от IBM

еще курсы

Software Security от University of Maryland, College Park
Cryptography от University of Maryland, College Park
Intro to Information Security от Georgia Institute of Technology
Bitcoin and Cryptocurrencies от University of California, Berkeley
Finding Your Cybersecurity Career Path от University of Washington
Building a Cybersecurity Toolkit от University of Washington
Cybersecurity: The CISO's Viewот University of Washington
Introduction to Cybersecurity от University of Washington
Cyber Attack Countermeasures от New York University (NYU)
Introduction to Cyber Attacks от New York University (NYU)
Enterprise and Infrastructure Security от New York University (NYU)
Cryptocurrency and Blockchain: An Introduction to Digital Currencies от University of Pennsylvania
Cryptocurrency and Blockchain Technology Explained от University of Michigan
Blockchain and Cryptocurrency Explained от University of Michigan
Blockchain Technology от University of California, Berkeley
Number Theory and Cryptography от University of California, San Diego
Network Security от Georgia Institute of Technology
Real-Time Cyber Threat Detection and Mitigation от New York University (NYU)
Hacker Tools от Massachusetts Institute of Technology
Cyber-Physical Systems Design & Analysis от Georgia Institute of Technology
Cyber-Physical Systems Security от Georgia Institute of Technology
Cyber Security Economics от Delft University of Technology
Introduction to Cybersecurity for Business от University of Colorado System
Cyber Security Basics: A Hands-on Approach от Universidad Carlos iii de Madrid
The Cyber Security Landscape от Coventry University
Cybersecurity and Mobility от University System of Georgia
Homeland Security & Cybersecurity Connection — It's Not About the Terrorists от University of Colorado System
Detecting and Mitigating Cyber Threats and Attacks от University of Colorado System
Cybersecurity and Privacy in the IoT от Curtin University
Cybersecurity and the X-Factor от University System of Georgia
Cybersecurity and the Internet of Things от University System of Georgia
Cyber-Physical Systems: Modeling and Simulation от University of California, Santa Cruz
Unlocking Information Security: Part Ⅰ от Tel Aviv University
Unlocking Information Security: Part ⅠⅠ от Tel Aviv University
Internet History, Technology, and Security от University of Michigan
Web Security Fundamentals от KU Leuven University
Usable Security от University of Maryland, College Park
Identifying Security Vulnerabilities от University of California, Davis
Identifying Security Vulnerabilities in C/C++Programming от University of California, Davis
Exploiting and Securing Vulnerabilities in Java Applications от University of California, Davis
Cloud Security Basics от University of Minnesota
Proactive Computer Security от University of Colorado System
AWS Fundamentals: Addressing Security Risk от Amazon Web Services
Linux Server Management and Security от University of Colorado System
Cloud Computing Security от University of Colorado System
Cloud Computing Security от University System of Maryland
Hardware Security от University of Maryland, College Park
Information Security: Context and Introduction от University of London International Programmes
Systems and Application Security от (ISC)²
Security Operations and Administration от (ISC)²
Access Controls от (ISC)²
The Merkle Tree and Cryptocurrencies от University of California, Irvine
Malicious Software and its Underground Economy: Two Sides to Every Story от University of London International Programmes

Еще полезные онтолы

Источник:https://habr.com/ru/company/timeweb/blog/506418/

От Prototype Pollution к RCE на ZeroNights X

2021-11-01T16:30:48.290Z

Как я встретил “Вашу маму”

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

Критический уровень уязвимости Prototype Pollution

Для себя я решил ответить на несколько основных вопросов:

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

Рейтинг риска безопасности приложений

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

Все просто, существует общая система оценки рейтинга уязвимых приложений, я использовал CVSS 3.0 версии и есть калькулятор для самостоятельной оценки риска. Сам рейтинг состоит из 8 основных параметров, сочетание которых и рассчитывает риск нашего приложения от 0.0 до 10.0, от меньшего большему риску соответственно. Так как вектор атаки у нас сетевой, сложность эксплуатации небольшая и доступность высокая, вот мы и получаем рейтинг HIGH от 7.3 и выше для некоторых весьма популярных уязвимых приложений:

Прототип в JavaScript

Давайте представим, что мы создаем пустой объект в JavaScript. Пусть будет
const test = {} При создании наш новый созданный объект уже имеет множество свойств и методов. Откуда они взялись у него? Ответ — прототип.

Объектно-ориентированные языки Java или PHP к примеру, используют классы как схемы для создания объектов. Каждый объект принадлежит классу, и классы организованы в так называемую иерархии, Родитель — Потомок. Если мы вызываем любой метод объекта, среда выполнения языка или компилятор будет искать метод в классе, к которому принадлежит объект и если он его не сможет найти, то будет искать выше в родительском классе, а затем еще выше, пока не достигнет вершины иерархии классов.

Но JavaScript другой — это объектно-ориентированный язык программирования, основанный на прототипах. Каждый объект связан с «прототипом». Когда мы вызываем метод, например test.doSomething(), JavaScript сначала будет проверять, определяли ли мы его сами явно для нашего объекта и если нет, то пойдет искать его в прототипе.

Прототип есть у всех объектов, даже пустых

Как происходит загрязнение прототипа?

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

Это важно понимать, так как большинство объектов по умолчанию используют один и тот же прототип, поэтому, если мы изменим прототип только одного из объектов, мы сможем изменить поведение всех объектов!

Загрязнение прототипа пакета flat v5.0.0

Дотянуться до RCE

В последнее время появляется все больше статей про Prototype Pollution в связке с XSS. Так как JavaScript в основном используется на стороне клиента, то и вектор эксплуатации видится нам, как возможность дотянуться до XSS, но это не совсем всё что можно сделать.

Мы поговорим о другом векторе, а именно, возможно ли довести вектор атаки до эксплуатации на стороне сервера. Для понимания эксплуатации уязвимости на серверной стороне нужно знать две вещи:

место, где присутствует уязвимость Prototype Pollution
и как, или посредством чего, уязвимость может влиять на серверную логику приложения.

Если у нас на сервере стоит NodeJS, то нам на помощь приходит AST с его возможностью обрабатывать и исполнять код на сторону сервера.

AST (Abstract Syntax Tree) — абстрактное синтаксическое дерево. Это особое представление (можно представить в виде описательного JSON объекта), с которым было бы удобно программно обрабатывать код. Зачастую используемая в шаблонизаторах и при компиляции TypeScript. Для более углубленного понимания работы AST рекомендую почитать эту статью.

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

Схема корректной обработки кода в шаблонизаторе PUG

Если мы нашли уязвимости Prototype Pollution, то можем воспользоваться AST, заставив исполнить наш произвольный код, направив его в процессы parser или compiler. Шаблонизаторы Handlebars и Pug удачно подходят для этой цели.

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

Участок кода пакета шаблонизатора PUG где исполняется код

Конкурс на ZeroNights X

25 августа 2021 в Санкт-Петербурге прошла десятая конференция по информационной безопасности ZeroNights. Это хакерская конференция c атмосферной обстановкой и большим сообществом, конкурсы для которой я готовил неоднократно.

В этот раз конкурс назвали “Hack to be Hired”. Этим названием мы хотели подчеркнуть важность навыков в сфере информационной безопасности при приеме на работу в различные ИТ-компании.

Идея конкурса родилась из популярного мема.

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

Сценарий конкурса

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

Следовательно, если участник пригласил себя на собеседование – победа!
Последний флаг успешно получен, и поставленная задача выполнена.

Итоги

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

Тизер для тех, кто хочет пройти ее: лабораторная работа скоро будет включена в курс JavaScript на платформе Академии Digital Security.

Спасибо всем, кто дочитал до конца!

Список использованных материалов:

Исследования на тему AST-injection —https://blog.p6.is/AST-Injection/
Практическое применение трансформации AST-деревьев —https://habr.com/ru/post/439564/
Выступление на ZeroNights 2021 —https://youtu.be/ggqLPR6TBDw