Бэкдоры

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

P.S. Вчера мы рассказывали, чем интересен рынок интернет-провайдеров Румынии.

Что-то пошло не так

Весной мы рассказывали о предполагаемых поправках в 230 раздел федерального закона о коммуникациях США. Их планируют внести с помощью EARNITA или EARN IT Actа расшифровывается как Eliminating Abusive and Rampant Neglect of Interactive Technologies Act.

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

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

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

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

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

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

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

От постов к чатам

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

В свою очередь, в UK тему продвигают аж с 2017-го, а в прошлом году местный Центр правительственной связи (GCHQ) даже предложил внедрять невидимых собеседников в подозрительные чаты и звонки. На инициативу последовала острая реакция IT-компаний, но Великобритания только усилила давление и на днях использовала международный рычаг в виде так называемого альянса Пяти глаз, в который входит та же Австралия, Канада, Новая Зеландия и США.

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

Что дальше

Совместное заявление Пяти глаз не имеет законодательного статуса, поэтому IT-сектор и общественность может его просто проигнорировать. С другой стороны, в этому году вышло множество разоблачительных публикаций surveillance-программ АНБ, но сделал ли кто-то выводы на их основе относительно перспектив принятия чего-то вроде EARN IT Act'а, предполагающего массовую фильтрацию (и ответственность) контента, но уже на стороне компаний покажет время.

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

• Чем интересен рынок интернет-провайдеров Румынии

• Работа интернет-провайдеров и развитие систем связи

• Доступный интернет: промежуточные итоги и мнения

• Как запустить бесплатный Wi-Fi согласно законодательству

• Интернет в деревню как построить радиорелейную Wi-Fi-сеть

• Экономия на спичках: обсуждаем ошибки в строительстве сетей связи

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

P.S. Вчера мы рассказывали, чем интересен рынок интернет-провайдеров Румынии.

Что-то пошло не так

Весной мы рассказывали о предполагаемых поправках в 230 раздел федерального закона о коммуникациях США. Их планируют внести с помощью EARNITA или EARN IT Actа расшифровывается как Eliminating Abusive and Rampant Neglect of Interactive Technologies Act.

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

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

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

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

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

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

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

От постов к чатам

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

В свою очередь, в UK тему продвигают аж с 2017-го, а в прошлом году местный Центр правительственной связи (GCHQ) даже предложил внедрять невидимых собеседников в подозрительные чаты и звонки. На инициативу последовала острая реакция IT-компаний, но Великобритания только усилила давление и на днях использовала международный рычаг в виде так называемого альянса Пяти глаз, в который входит та же Австралия, Канада, Новая Зеландия и США.

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

Что дальше

Совместное заявление Пяти глаз не имеет законодательного статуса, поэтому IT-сектор и общественность может его просто проигнорировать. С другой стороны, в этому году вышло множество разоблачительных публикаций surveillance-программ АНБ, но сделал ли кто-то выводы на их основе относительно перспектив принятия чего-то вроде EARN IT Act'а, предполагающего массовую фильтрацию (и ответственность) контента, но уже на стороне компаний покажет время.

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

• Чем интересен рынок интернет-провайдеров Румынии

• Работа интернет-провайдеров и развитие систем связи

• Доступный интернет: промежуточные итоги и мнения

• Как запустить бесплатный Wi-Fi согласно законодательству

• Интернет в деревню как построить радиорелейную Wi-Fi-сеть

• Экономия на спичках: обсуждаем ошибки в строительстве сетей связи

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

Введение

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

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

1. Суд ФБР и Apple

2. История взаимодействия Роскомнадзора и Telegram

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

А вообще, узнать больше про терроризм как феномен информационного общества можно тут.

Inspiration

Данная статья вдохновлена выступлением французских исследователей на конференции Black Hat в 2017 году. Для более детального изучения статья и книга.

Как работают алгоритмы шифрования?

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

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

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

1. Симметричные

2. Ассиметричные

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

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

В данной статье будет рассмотрен возможный механизм создания уязвимости в системах с симметричным шифрованием.

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

Современные алгоритмы симметричного шифрования

К симметричным алгоритмам шифрования можно отнести такие игрушечные алгоритмы шифрования, как:

• Простая перестановка

• Одиночная перестановка по ключу

• Перестановка Магический квадрат

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

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

На данный момент времени, в основном используются блочные шифры. Например, широко известный AES, как раз симметричный блочный алгоритм шифрования. Ровно как и наш подозреваемый - симметричный блочный алгоритм шифрования, который незамысловато называется Backdoored Encryption Algorithm 1, BEA-1 сокращённо. Давайте разберёмся, где же там спрятан бэкдор.

Ещё немного про уязвимости

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

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

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

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

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

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

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

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

static DSStatus SSLVerifySignedServerKeyExchnge(....){     DSStatus err;     ....     if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)          goto fail;          goto fail;     if ((SSHashSHA1.final(&hashCtx, &hashOut)) != 0)          goto fail;     ....     fail:          ....          return err;}

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

Ну так где же кроется уязвимость в BEA-1?

Для того чтобы разобраться в том, где кроется уязвимость, придётся погрузиться в дебри математики, на которых базируются современные блочные алгоритмы шифрования. Основа теории кодирования - поля Галуа. Очень качественно и детально про это написано вот тут. Облегчая математическую нагрузку, предлагаю для начала разобраться с тем, что такое Substitution-Permutation Networks, основа современных блочных алгоритмов шифрования.

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

Шифр на основе SP-сети получает на вход блок и ключ и совершает несколько чередующихся раундов, состоящих из чередующихся стадий подстановки (англ. substitution stage) и стадий перестановки (англ. permutation stage). Стоит отметить, что S и P блоки одинаковы для всех раундов. В целях повышения безопасности на каждом раунде используются разные ключи (обозначены как на изображении). Можно обратить внимание, на то что в последнем раунде нет P блока и используется два раунда

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

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

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

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

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

• Применения нелинейности в виде S-блоков

• Линейного преобразования в виде P-блока

• Побитового XOR с раундовым ключом

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

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

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

Чуть более подробно про BEA-1

Для наилучшего понимания того, как устроена уязвимость я приведу некоторую информацию касательно реализации шифра BEA-1, построенного на вычислительной SP сети.

Этот блочный шифр:

• Оперирует с блоками данных в 80 бит

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

• Состоит из 11 раундов, из которых 10 одинаковые, а последний требует два раундовых ключа. Таким образом, необходимо 12 раундовых 80-битных ключей

Для вашего удобства привел реализацию алгоритмов из статьи

Алгоритм генерации раундов ключей на базе мастер ключаАлгоритм шифрованияАлгоритм расшифровкиПроцедура генерации раундовых ключей на базе мастер ключаТак выглядит один раунд алгоритма шифрования

На Fig. 2. P-блоки обозначены как M

В случае с алгоритмом BEA-1, который удовлетворяет современным стандартам шифрования для взлома в лоб потребуется перебор по огромному числу вариантов. Стоит заметить, что такой перебор невозможен, потому что шифр оперирует с блоками размером 80 бит, то есть множество всех открытых текстов (и шифротекстов) имеет размер равный 2^80.

Максимально подробное описание данного алгоритма можно найти в оригинальной статье, там приведены все данные.

Загадочные S-блоки и их секретные напарники

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

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

Чтобы не быть голословным, для алгоритма BEA-1 для S0, S1, S2 количество входных данных для которых выходные данные секретного S-блока и обычного одинаковы есть 944 (из 1024, так как блоки работают с сегментами данных по 10 бит) для S3 это число 925 (также из 1024)

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

Для процесса перебора необходимо некоторе количество известных пар (открытий текст, зашифрованный текст). Для взлома BEA-1 необходимо 30.000 таких пар, то есть (2 300 Kb) данных, сам процесс взлома занимает порядка 10 секунд на intel Core i7, 4 cores, 2.50GHz.

Стандарты алгоритмов шифрования

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

Сейчас в основном используется стандарт AES, например шифрование данных на устройствах компании Apple соответсвует этому стандарту. Упомянутый французскими исследователями. Backdoored Encryption Algorithm 1 был создан по образу и подобию алгоритма Rijndael, который как раз таки лёг в основу стандарта AES. Если вам интересно, то вот тут можно посмотреть S-блоки и реализацию стандарта AES, а тут можно посмотреть хардверную реализацию алгоритма Rijandel.

Предшественником стандарта AES был упомянутый ранее DES, также блочный шифр. Интересна история, когда в конце 1970 к разработке S-блоков приложило руку АНБ. Агенство Национальной Безопасности обвиняли в сознательном снижении криптостойкости данного алгоритма.

Однако в 1990 году Эли Бихам и Ади Шамир провели независимые исследования по дифференциальному криптоанализу основному методу взлома блочных алгоритмов симметричного шифрования. Эти исследования сняли часть подозрений в скрытой слабости S-перестановок. S-блоки алгоритма DES оказались намного более устойчивыми к атакам, чем если бы их выбрали случайно. Это означает, что такая техника анализа была известна АНБ ещё в 1970-х годах. Авторы статьи уделили этому моменту внимание. Они выразили опасение, что алгоритмы начала 1990 могли быть слабыми к дифференциальному криптоанализу.

Про отечественные стандарты шифрования хорошо написано вот тут. В частности, на блочные шифры распространяется ГОСТ 34.12-2018. Если что, S-блоки там обозначены как , это если вам вдруг захочется поискать бэкдоры в отечественных алгоритмах. Приведу ряд статей про странности S-блоков отечественных алгоритмов шифрования: раз, два и три.

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

Возвращаясь к новости про взлом айфона террориста, упомянутой в начале статьи, ФБР всё таки удалось его взломать, по разным оценкам они потратили на это около миллиона долларов (1.3M USD). Про сам процесс взлома известно немного.

Более подробно про взаимодействие Apple и ФБР касательно предоставления бэкдора (на английском).

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

Так как теперь шифровать?

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

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

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

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

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

По данным Linux Foundation, ещё в 2017 году под управлением Linux работали 90% клиентских ресурсов у всех облачных провайдеров, причём в девяти из десяти случаев и сам облачный провайдер использовал в качестве основной ОС именно Linux. Но облаками дело не ограничивается: 82% всех выпущенных в мире смартфонов также используют Linux, а среди суперкомпьютеров доля Linux составляет 99%.

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

Уязвимости

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

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

Каждый производитель дистрибутива Linux выполняет свою процедуру обработки уязвимостей. В то время как исправления от вендоров приходят в разное время, заплатки upstream, будь то оригинальный пакет или исходный код утилиты, появляются первыми. Вендоры Linux отвечают за исправление уязвимостей в таких компонентах, как ядро, утилиты и пакеты. В 2019 году Red Hat исправил более 1000 CVE в своём дистрибутиве Red Hat Enterprise Linux (RHEL), согласно их отчёту Product Security Risk Report. Это более 70% от общего числа уязвимостей, исправленных во всех продуктах.

Уязвимости приложений, работающих под управлением Linux, были причиной нескольких серьёзных инцидентов. Например, нашумевшая утечка данных в Equifax произошла в результате эксплуатации уязвимости CVE-2017-5638 в Apache Struts. Тогда хакеры проникли в корпоративную сеть бюро кредитных историй Equifax 13мая 2017года, но подозрительную активность служба безопасности заметила только в конце июля. Киберпреступники провели внутри сети 76дней, успев за это время скачать из 51базы данных личную информацию 148млн американцев это 56% взрослого населения США. Помимо американских граждан в утечку попали сведения 15млн клиентов Equifax в Великобритании и около 20тыс. граждан Канады. Общие расходы Equifax в результате этого инцидента за два следующих года составили более 1,35млрд долларов США и включают расходы на укрепление систем безопасности, поддержку клиентов, оплату юридических услуг, а также выплаты по судебным искам.

Уязвимости публичных приложений входят в состав фреймворка MITRE ATT&CK (IDT1190), а также перечислены в топ-10 уязвимостей OWASP и являются наиболее популярными векторами проникновения в Linux-системы.

Ошибки конфигурации

Небезопасные настройки довольно распространены и всегда были критическим вопросом в области безопасности. Первая версия OWASP Top 10 Web Risks от 2004года, включала в себя Небезопасное управление конфигурацией (Insecure Configuration Management); в версии списка 2017года название изменилось на Ошибочные настройки безопасности (Security Misconfiguration).

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

Ниже перечислены наиболее распространённые проблемы безопасности в конфигурации Linux.

Слабые пароли в Linux как массовое явление

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

Например, в дистрибутивах Debian/Ubuntu время жизни пароля по умолчанию составляет 99999дней, а если требуется принудительно задать сложность пароля, придётся устанавливать пакет libpam-pwquality или его аналог.

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

В ноябре 2020 года ФБР выпустило предупреждение о том, что злоумышленники злоупотребляют неправильно настроенными экземплярами SonarQube, который обнаруживает ошибки и уязвимости в безопасности исходного кода. Из-за того, что некоторые организации не поменяли настройки систем по умолчанию, они были доступны через порт 9000 с использованием учётных данных admin/admin.

Такая же проблема массово присутствует среди работающих под управлением Linux IoT-устройств, производители которых часто не утруждают себя безопасными настройками паролей. Многие IP-камеры и роутеры также поставляются без паролей или с паролями по умолчанию, которые можно легко найти в общедоступной базе паролей по умолчанию (Default Passwords Database). Причём в некоторых случаях пароли жёстко прошиты и не могут быть изменены.

Уязвимые службы в интернете

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

Открытые файловые ресурсы на Linux-серверах

Публично доступные FTP-, SMB- и NFS-ресурсы, разрешённый листинг каталогов на веб-серверах под управлением Linux, открытые облачные службы хранения данных Amazon S3 и Azure Blobсоздают потенциальный риск несанкционированного доступа. С помощью Shodan мы обнаружили более 3млн уязвимых публичных FTP-серверов.

Вредоносное ПО

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

Ниже перечислены наиболее распространённые типы вредоносных программ в экосистеме Linux.

Вымогатели

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

В качестве примера Linux-вымогателей можно привести RansomEXX/Defray7777, относительно недавно портированный под эту операционную систему. Его применяла кибергруппировка Gold Dupont, атакующая организации из сфер здравоохранения и образование и технологические отрасли.

Другой вымогатель Erebus, впервые замеченный в сентябре 2016 года, в июне 2017года Erebus заразил 153Linux-сервера южнокорейской хостинговой компании NAYANA и вывел из строя 3400 клиентских сайтов.

Криптомайнеры

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

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

Для проникновения в систему майнеры используют распространённые уязвимости. Например, программа coinminer, детектируемая компанией Trend Micro под названием Coinminer.Linux.MALXMR.SMDSL64, использует уязвимости обхода авторизации SaltStack (CVE-2020-11651) и обхода каталога SaltStack (CVE-2020-11652).

Вредоносные скрипты

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

Причин популярности вредоносных скриптов для атак на Linux:

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

• они имеют небольшой размер;

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

• они могут быть созданы на лету.

Веб-шеллы и бэкдоры

Веб-шелл установленный на веб-сервере скрипт, который выполняет команды преступника и обеспечивает ему прямой доступ к взломанной системе. Например, в августе 2020 года мы столкнулись с Ensiko, веб-оболочкой PHP, нацеленной на Linux, Windows, macOS или любую другую платформу, на которой установлен PHP. Помимо удалённого выполнения кода с помощью Ensiko злоумышленники могут выполнять команды оболочки и повреждать веб-сайты.

Руткиты

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

В ходе наших исследований мы сталкивались с несколькими семействами руткитов. Чаще всего это были Umbreon, Drovorub или Diamorphine.

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

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

Вот несколько рекомендаций по обеспечению безопасности систем Linux:

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

• используйте принцип наименьших привилегий и модель совместной ответственности;

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

• отслеживайте сетевой периметр, проводите мониторинг всех устройств, систем и сетей;

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

• регулярно устанавливайте обновления и исправления ошибок.

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

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

В сегодняшней статье мы разберем бэкдор Spyder именно так окрестили найденный вредоносный модуль наши вирусные аналитики. Мы рассмотрим алгоритмы и особенности его работы и выявим его связь с другими известными инструментами APT-группы Winnti.

Чем примечателен Spyder

Вредоносный модуль представляет собой DLL-библиотеку, которая на зараженном устройстве располагалась в системной директории C:\Windows\System32 под именем oci.dll. Таким образом, модуль был подготовлен для запуска системной службой MSDTC при помощи метода DLL Hijacking. По нашим данным, файл попал на компьютеры в мае 2020 года, однако способ первичного заражения остался неизвестным. В журналах событий мы обнаружили записи о создании служб, предназначенных для старта и остановки MSDTC, а также для исполнения бэкдора.

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:45:17Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: IIJVXRUMDIKZTTLAMONQService File Name: net start msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:42:20Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: AVNUXWSHUNXUGGAUXBREService File Name: net stop msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Также мы нашли следы запуска других служб со случайными именами, их файлы располагались в директориях вида C:\Windows\Temp\<random1>\<random2>, где random1 и random2 являются строками случайной длины из случайных символов латинского алфавита. На момент проведения исследования исполняемые файлы этих служб отсутствовали.

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

Исследуемый вредоносный модуль oci.dll был добавлен в вирусную базу Dr.Web как BackDoor.Spyder.1. Это название пришло к нам из артефактов бэкдора. В одном из найденных образцов остались функции ведения отладочного журнала и сами сообщения, при этом те из них, которые использовались при коммуникации с управляющим сервером, содержали строку Spyder.

Бэкдор примечателен рядом интересных особенностей. Во-первых, oci.dll содержит основной PE-модуль, но с отсутствующими файловыми сигнатурами. Заполнение сигнатур заголовка нулями предположительно было сделано с целью затруднения детектирования бэкдора в памяти зараженного устройства. Во-вторых, полезная нагрузка сама по себе не несет вредоносной функциональности, но служит загрузчиком и координатором дополнительных плагинов, получаемых от управляющего сервера. С помощью этих подключаемых плагинов бэкдор выполняет основные задачи. Таким образом, это семейство имеет модульную структуру, как и другие семейства бэкдоров, используемые Winnti, упомянутые ранее ShadowPad и PlugX.

Анализ сетевой инфраструктуры Spyder выявил связь с другими атаками Winnti. В частности инфраструктура, используемая бэкдорами Crosswalk и ShadowPad, описанными в исследовании Positive Technologies, перекликается с некоторыми образцами Spyder. График ниже наглядно показывает выявленные пересечения.

Принцип действия

Бэкдор представляет собой вредоносную DLL-библиотеку. Имена функций в таблице экспорта образца дублируют экспортируемые функции системной библиотеки apphelp.dll.

Функционально образец является загрузчиком для основной полезной нагрузки, которую хранит в секции .data в виде DLL, при этом некоторые элементы DOS и PE заголовков равны нулю.

Работа загрузчика

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

Далее следует стандартный процесс загрузки PE-модуля в память и вызов точки входа загруженного модуля (DllMain) с аргументом DLL_PROCESS_ATTACH, а после выхода из нее повторный вызов с DLL_PROCESS_DETACH.

Работа основного модуля

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

• IMAGE_DOS_HEADER.e_magic

• IMAGE_NT_HEADERS64.Signature

• IMAGE_NT_HEADERS64.FileHeader.Magic

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

Анализ основного модуля затруднен, так как периодически используются нетипичные способы вызова функций. Для хранения и обработки структур используется библиотека UT hash. Она позволяет преобразовывать стандартные C-структуры в хеш-таблицы путем добавления одного члена типа ut_hash_handle. При этом все функции библиотеки, такие как добавление элементов, поиск, удаление и т. д., реализованы в виде макросов, что приводит к их принудительному разворачиванию и встраиванию (inline) компилятором в код основной (вызывающей) функции.

Для взаимодействия с управляющим сервером используется библиотека mbedtls.

Функция DllMain

В начале исполнения проверяется наличие события Global\\BFE_Notify_Event_{65a097fe-6102-446a-9f9c-55dfc3f45853}, режим исполнения (из конфигурации) и командная строка, затем происходит запуск рабочих потоков.

Модуль имеет встроенную конфигурацию следующей структуры:

structcfg_c2_block{inttype;charfield_4[20];charaddr[256];}structcfg_proxy_data{DWORDdw;charstr[256];charproxy_server[256];charusername[64];charpassword[32];charunk[128];};structbuiltin_config{intexec_mode;charurl_C2_req[100];charhash_id[20];charstring[64];charfield_BC;cfg_c2_block srv_1;cfg_c2_block srv_2;cfg_c2_block srv_3;cfg_c2_block srv_4;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;intCA_cert_len;charCA_cert[cert_len];};

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

Поле string содержит строку из одного символа: 1.

CA_cert сертификат центра сертификации в формате DER. Он используется для установки соединения с управляющим сервером по протоколу TLS 1.2.

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

• Основной поток thread_1_main

• Поток запроса нового сервера thread_2_get_new_C2_start_communication

• Поток исполнения зашифрованного модуля thread_4_execute_encrypted_module

Основной поток

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

В структуру funcs_struc типа funcs_1 заносятся 3 указателя на функции, которые будут поочередно вызваны внутри функции init_global_funcs_and_allocated_cfg.

В функции set_global_funcs_by_callbacks происходит вызов каждой функции-инициализатора по очереди.

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

1) каждой функции передаются две структуры: первая содержит указатели на некоторые функции, вторая пустая;

2) каждая функция переносит указатели на функции из одной структуры в другую;

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

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

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

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

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

Фрагмент кода формирования хеш-таблицы.

Стоит отметить, что здесь располагается значение сигнатуры, которое позволяет определить используемую библиотеку: g_p_struc_10->hh.tbl->signature = 0xA0111FE1;.

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

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

Инициализация соединения с управляющим сервером

После ряда подготовительных действий бэкдор разрешает хранящийся в конфигурации адрес управляющего сервера и извлекает порт. Адреса в конфигурации хранятся в виде строк: koran.junlper[.]com:80 и koran.junlper[.]com:443. Далее программа создает TCP-сокет для подключения. После этого создает контекст для защищенного соединения и выполняет TLS-рукопожатие.

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

• пакет, полученный после обработки протокола TLS, транспортный пакет;

• пакет, полученный после обработки транспортного пакета, пакет данных. Содержит идентификатор команды и дополнительные данные.

Заголовок транспортного пакета представлен следующей структурой.

structtransport_packet_header{DWORDsignature;WORDcompressed_len;WORDuncompressed_len;};

Данные располагаются после заголовка и упакованы алгоритмом LZ4. Бэкдор проверяет значение поля signature, оно должно быть равно 0x573F0A68.

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

structdata_packet_header{WORDtag;WORDid;WORDunk_0;BYTEupdate_data;BYTEid_part;DWORDunk_1;DWORDunk_2;DWORDlen;};

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

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

Порядок обработки команд сервера:

• верификация клиента;

• отправка информации о зараженной системе;

• обработка команд по идентификаторам.

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

Этап верификации

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

Процесс верификации состоит в следующем:

1. Бэкдор формирует буфер из 8-байтного массива, который следует после заголовка пакета и поля hash_id, взятого из конфигурации. Результат можно представить в виде структуры:

struct buff{BYTEpacket_data[8];BYTEhash_id[20];}

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

Отправка информации о системе

Следующий полученный пакет от управляющего сервера должен иметь значения tag, равное 5, и id, равное 3. Данные о системе формируются в виде структуры sysinfo_packet_data.

structsession_info{DWORDid;DWORDState;DWORDClientBuildNumber;BYTEuser_name[64];BYTEclient_IPv4[20];BYTEWinStationName[32];BYTEdomain_name[64];};structsysinfo_block_2{WORDfield_0;WORDfield_2;WORDfield_4;WORDsystem_def_lang_id;WORDuser_def_lang_id;DWORDtimezone_bias;DWORDprocess_SessionID;BYTEuser_name[128];BYTEdomain_name[128];DWORDnumber_of_sessions;session_info sessions[number_of_sessions];};structsysinfo_block_1{DWORDunk_0;//0DWORDbot_id_created;DWORDdw_const_0;//0x101DWORDos_version;WORDdw_const_2;//0x200BYTEcpu_arch;BYTEfield_13;DWORDmain_interface_IP;BYTEMAC_address[20];BYTEbot_id[48];WCHARcomputer_name[128];BYTEcfg_string[64];WORDw_const;//2WORDsessions_size;};structsysinfo_packet_data{DWORDid;sysinfo_block_1 block_1;sysinfo_block_2 block_2;};

Поле sysinfo_packet_data.id содержит константу 0x19C0001.

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

Версия ОС кодируется значением от 1 до 13 (0, если возникла ошибка), начиная с 5.0 и далее по возрастанию версии.

В поле sysinfo_packet_data.block_1.cfg_string помещается значение string из конфигурации бэкдора, которое равно символу 1.

Обработка команд

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

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

Заключение

Рассмотренный образец бэкдора для целевых атак BackDoor.Spyder.1 примечателен в первую очередь тем, что его код не исполняет прямых вредоносных функций. Его основные задачи скрытое функционирование в зараженной системе и установление связи с управляющим сервером с последующим ожиданием команд операторов. При этом он имеет модульную структуру, что позволяет масштабировать его возможности, обеспечивая любую функциональность в зависимости от нужд атакующих. Наличие подключаемых плагинов роднит рассмотренный образец с ShadowPad и PlugX, что, вкупе с пересечениями сетевых инфраструктур, позволяет нам сделать вывод о его принадлежности к деятельности Winnti.

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

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

Восстанавливаем события

Мы считаем, что найденные в сети бэкдоры принадлежат двум разным хакерским группировкам. Для удобства обозначим их как APT-группа 1 и APT-группа 2.

В ходе расследования было установлено, что APT-группа 1 скомпрометировала внутреннюю сеть института осенью 2017 года. Первичное заражение осуществлялось с помощьюBackDoor.Farfli.130 модификации бэкдора, также известного как Gh0st RAT. Позднее, весной 2019 года в сети был установлен Trojan.Mirage.12, а в июне 2020 BackDoor.Siggen2.3268.

APT-группа 2 скомпрометировала сеть института не позднее апреля 2019, и в этот раз заражение началось с установки бэкдораBackDoor.Skeye.1. В процессе работы мы также выяснили, что примерно в то же время в мае 2019 года Skeye был установлен в локальной сети другого российского НИИ.

Тем временем в июне 2019 года компания FireEye опубликовала отчет о целевой атаке на государственный сектор ряда стран центральной Азии с использованием Skeye. Позднее, в период с августа по сентябрь 2020 года вирусные аналитики Доктор Веб зафиксировали установку различных троянов APT-группой 2 в сети пострадавшего НИИ, включая ранее не встречавшийся DNS-бэкдорBackDoor.DNSep.1, а также хорошо известный BackDoor.PlugX.

Более того, в декабре 2017 года на серверы НИИ был установленBackDoor.RemShell.24. Представители этого семейства ранее были описаны специалистами Positive Technologies в исследовании Operation Taskmasters. При этом мы не располагаем такими данными, которые позволили бы однозначно определить, какая из двух APT-групп использовала этот бэкдор.

Кто стоит за атаками?

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

Второй APT-группой, атаковавшей НИИ, по нашему мнению является TA428, ранее описанная исследователями компании Proofpoint в материале Operation Lag Time IT. В пользу нашего вывода говорят следующие факты:

1) в коде бэкдоров BackDoor.DNSep и BackDoor.Cotx имеются явные пересечения и заимствования;

2) BackDoor.Skeye.1 и Trojan.Loader.661 использовались в рамках одной атаки, при этом последний является известным инструментом TA428;

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

Теперь подробнее рассмотрим выявленные связи. На графе приведена часть задействованной в атаке инфраструктуры с пересечениями бэкдоров Skeye и другим известным APT-бэкдором PosionIvy:

На этом графе изображены пересечения в инфраструктуре бэкдоров Skeye и Cotx:

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

Другой интересной находкой этого исследования стал бэкдор Logtu, один из его образцов мы ранее описывали в рамках расследования инцидента в Киргизии. Адрес его управляющего сервера совпал с адресом сервера бэкдора Skeye atob[.]kommesantor[.]com. В связи с этим мы также провели сравнительный анализ BackDoor.Skeye.1 с образцами BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Подробный разбор алгоритмов работы найденных бэкдоров читайте в нашем исследовании на сайте.

Сравнительный анализ кода DNSep и Cotx

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

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

structst_arg{_BYTE cmd;st_string arg;};

При этом, если нужная функция принимает несколько аргументов, то они все записаны в поле arg с разделителем |.

Набор команд BackDoor.Cotx.1 обширнее, чем у BackDoor.DNSep.1, и включает все команды, которые есть у последнего.

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

Обработчик команды на отправку листинга каталога или информации о диске

Функция получения информации о дисках

Функция перечисления файлов в папке

Функция сбора информации о файлах в папке

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

Сравнительный анализ кода бэкдоров Skeye, Mikroceen, Logtu

В процессе исследования бэкдора Skeye мы обнаружили, что адрес его управляющего сервера также используется бэкдором семейства Logtu. Для сравнительного анализа мы использовали ранее описанные нами образцы BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Функции логирования

Логирование во всех случаях так или иначе обфусцировано.

• BackDoor.Mikroceen.11 сообщения в формате %d-%d-%d %d:%d:%d <msg>\r\n записываются в файл %TEMP%\WZ9Jan10.TMP, где <msg> случайная текстовая строка. В образце 2f80f51188dc9aea697868864d88925d64c26abc сообщения записываются в файл 7B296FB0.CAB;

• BackDoor.Logtu.1 сообщения в формате [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n перед записью в файл %TEMP%\rar<rnd>.tmp шифруются операцией XOR с ключом 0x31;

• BackDoor.Skeye.1 сообщения в формате %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n записываются в файл %TEMP%\wcrypt32.dll.

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

• начало исполнения фиксируется;

• в Logtu и Mikroceen в журнал записывается прямое подключение к управляющему серверу;

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

• в случае ошибки на этапе получения прокси из того или иного источника в журнале фиксируется отдельная запись.

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

• начало исполнения;

• попытка подключения напрямую;

• получение адресов прокси;

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

Поиск прокси-сервера

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

Получение адресов прокси-серверов BackDoor.Mikroceen.11:

• из файла %WINDIR%\debug\netlogon.cfg;

• из собственного лог-файла;

• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Поиск прокси в своем лог-файле:

Поиск в активных соединениях:

Получение адресов прокси-серверов BackDoor.Logtu.1:

• из реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;

• из раздела HKU реестра по SID активного пользователя;

• с помощью WinHTTP API WinHttpGetProxyForUrl путем запроса к google.com.

Получение адресов прокси-серверов BackDoor.Skeye.1:

• из раздела HKCU Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;

• из раздела HKU по SID активного пользователя;

• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Пересечения в сетевой инфраструктуре

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

Идентификаторы

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

Кроме того, в значительном числе образцов данный идентификатор равен значению TEST или test.

Пример в BackDoor.Logtu.1 (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

Пример в BackDoor.Mirkoceen.11 (81bb895a833594013bc74b429fb1f24f9ec9df26):

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

• логике ведения журнала событий и его обфускации;

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

• используемой сетевой инфраструктуре.

Заключение

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

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

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

Индикаторы компрометации