Странное 9-е место в TOP-10 рисков мобильных приложений по OWASP: https://owasp.org/www-project-mobile-top-10/2016-risks/m9-reverse-engineering

Предлагают для противодействия реверсингу использовать обфускацию. Буквально цитата такая: "In order to prevent effective reverse engineering, you must use an obfuscation tool."

На самом деле обфускация никогда не противодействовала реверсингу. Она делает реверсинг несколько более сложным (потому и используется для DRM), но ни в коем разе не противодействует ему. Даже модная виртуализация кода (перевод изначального кода в байт-код некоторого виртуального процессора с последующим встраиванием интерпретатора оного в тело обфусцируемого приложения) вполне себе деобфусцируется при желании. Есть масса работ и исследований на эту тему, включая одно, соавтором которого был я, о чём мы рассказывали на ZeroNights в далёком 2014-м году:
http://2014.zeronights.org/assets/files/slides/deobfuscation-and-beyond.pdf
https://www.youtube.com/watch?v=1ODkJ4zF0YU

В дополнение обфускация (особенно - виртуализация) замедляет софт и вызывает изжогу беспокойство у антивирусов, которое выражается в фальшивых позитивных реакциях. Обычно обфускация (по крайней мере публичные протекторы и обфускаторы) напрочь "сносит" статистические характеристики софта - завышает энтропию, изменяет распределение n-грамм, модифицирует метаданные и делает их "необычными" и т.д. Впрочем, об этом мы уже писали: https://t.me/recryptor/30

#обфускация

Интересный вариант закрепления в системе с использованием (дальше будет спойлер!) профилей Windows Terminal, в которых можно задать командную строку. Особой изюминкой является возможность инициировать запрос элевации до админа
https://nasbench.medium.com/persistence-using-windows-terminal-profiles-5035d3fc86fe

#windows #offensive #почитать

Не все антивирусы одинаково полезны. Пока кратко про CVE-2022-42045. Благодаря нашим исследователям, публичную коллекцию уязвимых драйверов Windows, через которые можно попасть в ядро, пополнили аж три свежих драйвера антивирусных продуктов. Компания Zemana имеет два публичных продукта с этой уязвимостью - Antimalware и Antilogger. Соответственно, это два разных драйвера с разными хэшами и цифровыми подписями. При этом Zemana, похоже, сумели лицензировать своё SDK, как минимум, одной компании - Watchdog. Тоже антивирусный продукт. Тоже уязвимый драйвер с подписью уже от Watchdog.
Сама по себе уязвимость является, по сути, некоторым бэкдором, благодаря которому можно передать в драйвер произвольный код и затем выполнить его с привилегиями ядра. Для эксплуатации достаточно иметь сам драйвер и своё маленькое приложение, которое должно работать с правами локального администратора. Благодаря этому поистине волшебному антивирусному функционалу, несложно отключить принудительную проверку цифровой подписи драйверов и инсталлировать в систему любые неподписанные драйверы с абсолютно любым функционалом, прям как в середине нулевых, когда буйным цветом расцветали разного рода руткиты. При этом все механизмы безопасности, такие как Secure Boot, остаются включенными. Чем отличается такой антивирус от руткита - большой вопрос...
К сожалению, вендор, мягко говоря, неохотно контактировал с нами. Времени на исправление было предостаточно, вендор был оповещён сильно заранее
Пример и немного подробностей здесь: https://github.com/ReCryptLLC/CVE-2022-42045/tree/main
Подобная статья будет позже.

#windows #антивирус #закладки

Те, кто вовлечён в теорию кодирования и её применение в криптографии наверняка проводят параллель с криптографией, базирующейся на решётках и алгоритмом LLL. Действительно, очень много общего. Есть прекрасная работа, раскрывающая эту взаимосвязь и адаптирующая LLL для теоретико-кодовых систем: https://eprint.iacr.org/2020/869
Удалось выкроить немного времени и попробовать эти редукции для моего подхода: https://github.com/dmschelkunov/wb_poc
Мой подход оказался стойким к таким атакам, что радует.
Тем не менее, вышеозначенная работа определённо заслуживает пристального внимания и дальнейшего развития

#криптография #почитать #whitebox

Куда бы отрасль Информационной Безопасности (ИБ) в России (да и в других самостоятельных странах мира тоже) делась без согревающего своей регулярной заботой регулирующего органа... В нашем случае одним из таких органов является ФСТЭК, периодически выпускающий разного рода документы: рекомендации, приказы и т.д. Вот и теперь ФСТЭК выпустил, на мой взгляд, весьма важный документ: Методика тестирования обновлений безопасности программных, программно-аппаратных средств. Документу полтора месяца и все бумажные страсти вокруг него успели улечься. Посему самое время рассмотреть его сугубо с точки зрения поиска программных закладок. Итак, методика предлагает нам следующее:
1. Сверка идентичности обновлений. Полезная техника, которую имеет смысл применять. Берём обновления в разных локациях и смотрим, отличаются ли они. Если отличаются, подозрительно. Но в случае, когда вендор распространяет вредоносные обновления, техника имеет мало смысла.
2. Проверка подлинности обновлений безопасности. Это история, скорее, про защиту от атак на цепочки поставок. Критерии подлинности предполагается определять самостоятельно. Понятно, что , если вендор задумал вставить spyware или деактиватор по локации, то вряд ли такой метод от чего-то поможет.
3. Тестировать обновления анативирусом. Очевидно, вряд ли можно найти таким образом что-то относительно серьёзное.
4. Поиск подозрительных конструкций с помощью регулярок и сигнатур. Позволит защититься от ребячества, но это не точно. Да и обфускация в помощь, как и в случае с п. 3.
5. Мониторинг активности обновлений в среде тестирования. Это поставили апдейты в тестовую среду и глядим, что в них плохого. По сути, песочница. Как и все песочницы, обходится достаточно стандартно. Защитит от ребячества и глупостей, но, если серьёзно, не защитит ни от чего. Например, нужный код будет активироваться либо по времени, либо по команде из сети, либо при определённом количестве устройств в сети, либо по каким-то сигнатурам. Тогда хоть обтестируйся в песочнице - не найдёшь ничего. Все, кто занимается реверсингом и противодействием оному, прекрасно это понимают. Метод так себе. В следующих постах покажу пример и правильную обфускацию.
6. Ручной анализ обновлений безопасности. По сути, reverse engineering. Это, на мой взгляд, обязательно надо делать для софта, который всё ещё имеет место быть в критической инфраструктуре и в госкорпах. Ручной анализ обновлений, а вся автоматизация должна строиться вокруг этого. Например, невозможно чисто автоматически найти закладки, подобные найденной нами в одном из антивирусных драйверов.

В сухом остатке: документ ФСТЭК весьма полезен, не случайно появился, но сильно запоздал. Непонятно, почему речь идёт только об обновлениях безопасности, ибо привет может прилететь с любым обновлением. Ну и анализ обновлений нужно аутсорсить профессионалам. Например, нам ;)

В предыдущем посте обещал показать пример "правильной" обфускации. А вот и она:

y = 12*((~x[0])&x[1]&(~x[2])|(~x[0])&x[1]&x[2]|x[0]&(~x[1])&(~x[2])|x[0]&(~x[1])&x[2]) +
4*((~x[0])&(~x[1])&(~x[2])|(~x[0])&(~x[1])&x[2]|x[0]&(~x[1])&(~x[2])|x[0]&x[1]&(~x[2])) +
2*((~x[0])&x[1]&(~x[2])|x[0]&x[1]&(~x[2])|x[0]&x[1]&x[2]) +
4*((~x[0])&x[1]&x[2]|x[0]&x[1]&(~x[2])|x[0]&x[1]&x[2]) +
(-18)*((~x[0])&x[1]&(~x[2])|(~x[0])&x[1]&x[2]|x[0]&(~x[1])&(~x[2])) +
8*((~x[0])&(~x[1])&x[2]|(~x[0])&x[1]&(~x[2])|(~x[0])&x[1]&x[2]|x[0]&(~x[1])&(~x[2])) +
6*((~x[0])&(~x[1])&(~x[2])|(~x[0])&x[1]&(~x[2])|(~x[0])&x[1]&x[2]|x[0]&(~x[1])&(~x[2])|x[0]&x[1]&x[2]) +
(-2)*((~x[0])&(~x[1])&x[2]|(~x[0])&x[1]&x[2]|x[0]&(~x[1])&(~x[2])|x[0]&(~x[1])&x[2]|x[0]&x[1]&x[2]) +
10;

Вот это автоматически сгенерированное нашим движком выражение реализует технику под названием Mixed Boolean Arithmetic (MBA). Независимо от значений x[i] результат всегда будет нулевым. Как мы можем наблюдать, выражение выше - это сумма булевых функций от трёх переменных, умноженных на какие-то константы. Такая обфускация бессигнатурна (нет чётко выраженных шаблонов) и сложно поддаётся оптимизации. Стоит также заметить, что этот подход низкоэнтропийный - энтропия обфусцированного кода не сильно возрастёт и будет в пределах нормы. Иными словами, такая обфускация в скомпилированном виде не будет сильно бросаться в глаза и практически не выделяется из кода автоматически. Слишком линейно выглядит? Не проблема. Достаточно просто возвести выражение выше в степень n и раскрыть скобки. Результат, как мы понимаем, не изменится, а оптимизировать станет гораздо сложнее - автоматическими средствами практически невозможно. Очевидно, что подобным образом может быть представлена любая булева функция.

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

#обфускация

Снова к вопросу программных закладок и о том, что весьма серьёзные математические школы озадачены их "грамотным" встраиванием, равно, как я понимаю, финансирование этих вопросов имеется. В 2017-м году на РусКрипто имел честь заслушать весьма интересный доклад на тему создания криптоалгоритма с закладкой, которую невозможно выявить статистически. Очень интересная работа для интересующихся, с хорошими ссылками: http://www.ruscrypto.org/resource/archive/rc2017/files/02_filiol.pdf

#криптография #закладки

Немного обновил свою работу. Поправил ряд неточностей https://eprint.iacr.org/2021/136

#криптография #whitebox

Достаточно интересная атака, про которую, каюсь, не знал. Впрочем, как по мне, практического смысла в ней не особо много. Практическая суть в том, что злоумышленник для ряда криптосистем, в число которых входят RSA и DSS, может сгенерировать такой открытый ключ, отличный от исходного, что с его помощью можно валидировать модифицированное или исходное подписанное сообщение. При этом сама сигнатура останется той же самой. На рисунке это стрелочки под номерами 5 и 7. Некое крайне ограниченное применение данная атака может найти при процедуре отзыва сертификатов X.509. При этом злоумышленник должен быть центром сертификации, что уже нонсенс. Тем не менее, повод прикопаться, если больше не к чему. Ссылка на работу: https://link.springer.com/chapter/10.1007/11496137_10

#криптография

Хороший список уязвимых драйверов Windows: https://www.loldrivers.io/

Но неполный. Наших находок там нет: https://t.me/recryptor/55

UPD. Есть, но не все :)

#windows #offensive

Неплохой список точек закрепления в Windows. Неполный, но неплохой https://persistence-info.github.io/

#windows #offensive

Опубликована очень интересная модификация RC4 от основателя блокчейн-платформы Emercoin Олега Ховайко: https://github.com/emercoin/rc4ok/

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

#rc4ok #криптография

Список полезных утилит в MacOS. Пусть здесь побудет

https://github.com/infosecB/LOOBins

#offensive #mac

Пару недель назад появились новые домены верхнего уровня (TLD), включающие .mov и .zip. Решение спорное с точки зрения ИБ. Фишинг и без того был одним из самых эффективных инструментов злоумышленника, а теперь станет ещё немного эффективнее. Мы все привыкли к тёплым и ламповым zip-архивам. Теперь это ещё и доменом может быть.
А вот, кстати, эмуляция архиватора в браузере подоспела со сценариями использования для фишинга: https://mrd0x.com/file-archiver-in-the-browser/

#offensive #почитать

Закрытость - это визитная карточка Apple. Теперь понятно почему. Впрочем, в любом софте, даже open source, могут быть закладки. Не говоря уже о железе. Отличное исследование: https://securelist.com/operation-triangulation/109842/

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

Ещё мысли по поводу Приказа №213 . По сути, это будет регулярный независимый аудит периметра организации. Вероятно, автоматизированное сканирование. Это просто отлично, но, на мой взгляд, недостаточно. Есть целый зоопарк программ и программно-аппаратных комплексов, которые могут автоматически ходить из-за периметра, например, за обновлениями, отсылая при этом телеметрию. Есть не обновлённый вовремя софт, содержащий критичные уязвимости, которые могут быть проэкслплуатированы при совершении сотрудником организации каких-то действий. Таких вещей при внешнем сканировании не обнаружишь. Есть, наконец, фишинг, с помощью которого можно попасть за периметр.
Тренд с Приказом №213 задан и мне лично он нравится, как я писал выше. Подозреваю, это только первый шаг и дальше будет интереснее ;) Пожелтевшей от старости бумагой прикрыться будет сложно, нужно работать и приводить в порядок. Как говорил известный киногерой: "Не жди поездку в Гагры!"
https://www.youtube.com/watch?v=iit30fOfKSc

А вот подоспел обход антивирусов, EDR и XDR с использованием легитимного подписанного драйвера антивирусных продуктов Zemana: https://xakep.ru/2023/06/02/terminator/
Не знаем, использовался ли найденный нами бэкдор, позволяющий выполнять свой код в ядре (подозреваем, что всё-таки использовался) или какая-то другая уязвимость, но крайне странно, что, несмотря на наши публикации, на VirusTotal только один антивирус отреагировал на уязвимый драйвер. Ещё интересно, что продавец решения не продаёт версию для обхода SentinelOne, Sophos, CrowdStrike, Carbon Black, Cortex, Cylance - антивирусов, практически неизвестных в России

#offensive #антивирус #windows #закладки

Отправили информацию о CVE-2022-42045 в БДУ ФСТЭК. Посмотрим. Форма подачи ... интересная. Капча ... с первого раза не разглядели. Но хоть отправилось. В прошлый раз не получилось

Про шифровальщики и антишифровальщики.

Навеяло недавней частной беседой. Довольно часто, пожалуй, даже практически всегда встречается весьма ошибочное заблуждение, что вирусы-шифровальщики (ransomware) - это угроза. Да что там, угроза №1! На самом деле это совсем не так и мир несколько сложнее. Если свести это всё к медицинским терминам, то это не болезнь, а симптом.
Что обычно нужно, чтобы шифровальщик успешно отработал в системе:
1. Заход в систему: уязвимость, фишинг
2. Нужно в системе повыситься и закрепиться, обеспечить связь с командным центром
3. Если в системе есть доступ к каким-то полезным данным (документам, базам, паролям, фото, видео), то эти данные выкачиваются. Так происходят утечки
4. Дальнейшее продвижение и закрепление внутри периметра организации
5. п.п. 1 - 4 для всех устройств, до которых удалось дотянуться
6. А уже потом - шифровальщик. Причём, не всегда. Такой симптом сложно не заметить и шифровальщик имеет смысл запускать, когда всё, что можно, уже слито и данная инфраструктура больше не нужна ни для чего. Можно и деньги повымогать

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

И да, от шифровальщиков помогают бэкапы. Но лучше до такого, конечно, не доводить

#malware #offensive

Попытка хорошая, но опоздала лет на 5 :)
https://github.com/xforcered/bofmask
Антивирусы (правильные) и, тем более, EDR сканируют память процесса не только при наступлении каких-то событий (старт потоков, сетевых соединений, запись в файлы и т.д.), но и просто эпизодически. Потому техника "пошифровать что-то в памяти, пока оно не выполняется, а при передаче управления расшифровать обратно" уже не даёт никаких гарантий

#offensive #обфускация