Всякие разные техники обхода всяких разных ИБ-решений. Пусть тут побудет

https://unprotect.it/map/
#почитать #offensive

Немного про UNC-пути и мини-фильтры файловой системы Windows. Как известно, мини-фильтры активно используются антивирусами и прочими средствами контроля за файликами. Мини-фильтр регистрирует callback, в который при открытии HANDLE прилетает путь. Что-то типа такого: "C:\Temp\sub\file.txt" И можно по этому пути понять, что за файл и где лежит. Да, но нет :) На самом деле может прилететь такое: "\\machine-name\\SHARED\\file.txt". Также в UNC может использоваться IP-адрес и доменное имя. Но самое интересное в том, что преобразовать UNC-путь к обычному на уровне мини-фильтра очень не тривиально по той причине, что мини-фильтры находятся чуть ниже по стеку, чем I/O Manager, но выше UNC-провайдеров. А вся работа с путями идёт как раз на уровне UNC-провайдеров и ниже. Т.е., да, callback сработает, но что туда прилетело, если это UNC, непонятно. Мы во всяком случае не нашли хорошего документированного способа, как это обработать в ядре и привести к какому-то унифицированному виду. Сделали, конечно, но не так это просто :)
Как здесь часто ошибаются разработчики:
1. Забивают или не знают об этом. Это нехорошо. Через UNC-пути можно получать доступ к объектам файловой системы, к которым нет доступа с использованием путей обычных. По сути, это обход мини-фильтра файловой системы (если в callback-е некорректно обрабатывается доступ к файлам из ядра или не обрабатывается вообще, что встречается).
2. Пытаются сами открыть файлик (или помещают в защищаемую директорию файл-маркер), чтобы проверить. Здесь возможна история с Net-NTLMv2, как в CVE-2022-25165, о которой мы писали.

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

В дополнение к предыдущему посту про мини-фильтры файловой системы Windows. Стоит обратить внимание на "ядерный" вызов callback мини-фильтра (операция обращения к файлу инициирована компонентом ядра). Порой разработчики забивают на это и ошибочно считают, что, раз callback "ядерный", то надо пропускать и это "что-то системное", либо инициировано другим драйвером. Но, например, в случае использования SMB (например, обращение к расшаренной папке с удалённого хоста) callback будет "ядерным". Кстати, с работой через UNC-пути на локальной машине тоже похожая история: сначала срабатывает "юзермодный" callback (обращение к файлу инициировано приложением ring 3), где UNC-путь, потом происходит обработка в mup и дальше уже идёт "ядерный вызов" с нормальным локальным путём

#windows #почитать

Подробно про внутренности Duo Authentication, обход 2FA (если повезёт) и вообще интересно. Пусть здесь полежит. Лишним не будет: https://www.mandiant.com/resources/abusing-duo-authentication-misconfigurations

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

Повышению выше админа уделяется мало внимания. На мой взгляд, совершенно зря. Пожалуй, на большинстве Windows-машин локальный администратор. Вот совершенно потрясающее описание инжекта в защищённые процессы Windows:
https://tastypepperoni.medium.com/running-exploit-as-protected-process-ligh-from-userland-f4c7dfe63387

И рабочий пример: https://github.com/tastypepperoni/RunAsWinTcb

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

Неплохо и сжато про механизмы аутентификации, дискреционный контроль доступа и токены доступа Windows: https://www.elastic.co/blog/introduction-to-windows-tokens-for-security-practitioners
Ссылки в конце статьи также весьма полезны

#windows #почитать

Странное 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