Добавили комментарии

Хороший список статей (и не менее хороший блог про offensive security) про использование Windows Management Instrumentation (WMI) в offensive-целях: https://0xinfection.github.io/posts/wmi-basics-part-1/

Потрясающее описание свеженьких уязвимостей CVE-2022-25165 и CVE-2022-25166 в AWS VPN Client
Обе ошибки логические. Первая связана с гонками (race condition), вторая с путями UNC, которые мы тоже очень любим :)
Подобного рода ошибки не найдёт никакой сканер кода. Только ручной аудит

https://rhinosecuritylabs.com/aws/cve-2022-25165-aws-vpn-client/

В Windows есть такая замечательная штука - Antimalware Scan Interface (AMSI). Используется антивирусами для анализа поведения PowerShell-скриптов, например. Подробнее, что это за технология и как это обходится (спойлер: dll-ка в user mode 😉) можно почитать, например, здесь: https://www.hackingarticles.in/a-detailed-guide-on-amsi-bypass/

Пара слов про эвристический анализ исполняемых файлов. Про нечёткие хэши я уже говорил ранее: https://t.me/recryptor/9. Очень важным показателем является информационная энтропия по Шеннону. Что это такое и как её считать - скажет поисковик, но одним предложением можно сказать, что это мера случайности информации. Измеряется она в битах. Максимальное значение - 8 бит. Если энтропия исполняемого файла или весомой его части (например, секции) близка к максимальному значению, это значит, что применялось либо сжатие, либо шифрование. Но, как правило, исполняемые файлы не могут иметь сильно высокой энтропии и, если она всё-таки высока, то это, как минимум, подозрительно, о чём эвристик антивируса заботливо проинформирует, уложив параллельно файлик в карантин. Именно поэтому прежде всего антивирусы крайне болезненно реагируют на защищённый протекторами софт.
Если хочется иметь поменьше проблем с ложноположительными реакциями антивирусов (false positives), но при этом страсть как неймётся что-то пошифровать, можно "сбить" энтропию. Для этого каждому байту зашифрованного массива ставится в соответствие какой-то уникальный набор байт (назовём его словом). Происходит замена байтов на слова. Исходный массив в результате распухнет, но энтропия упадёт. Перед расшифрованием просто применим обратное преобразование: заменим слова на байты. Ну а потом уже можно расшифровывать. Ложноположительных реакций станет меньше, но они всё равно будут :) Я позже расскажу почему ;)

Ещё одна очень хорошая книга по криптографии, а именно - по математике, которая лежит в основе криптографических алгоритмов: https://link.springer.com/book/10.1007/978-0-387-77993-5

Достаточно глубоко и при этом в доступной форме рассматриваются подходы как к созданию шифров, так и к криптоанализу с использованием решёток. Например, после прочтения станет понятно, в чём архитектурная уязвимость криптосистемы, основанной на задаче о рюкзаке с использованием гипервозрастающей последовательности. Хорошо описан алгоритм редукции базиса решётки LLL, часто используемый в криптоанализе (в том числе и RSA) и предпосылки к его созданию. Ну и криптосистемы на базе решёток, включая NTRU, рассмотрены достаточно хорошо.
Очень рекомендую!

Очередной метод инжекта DLL в другой процесс: https://www.x86matthew.com/view_post?id=import_dll_injection
Оригинальность в модификации IAT вместо запуска удалённых потоков. При загрузке этой DLL отработает PloadImageNotifyRoutine. Плюс, подозрителен запуск процесса с флагом CREATE_SUSPENDED. А так - интересная и даже оригинальная вариация на тему

Про защиту от роботов. Я сейчас не про терминатора или капчу с выбором автобусов на картинках 🙂 Я говорю про детект автоматических сканеров/скрэпперов/утилит для осуществления автоматических запросов к веб-ресурсам. Прошло то время, когда безнаказанно можно было собирать информацию с ресурсов или же осуществлять автоматизацию работы, например, по сбору цен из интернет-магазинов. Сейчас на страже веба стоят антибот-системы. Антибот-системы - это проблема, на самом деле, большинства защитных систем, заявляющих, что у них реализован DPI с использованием SSL-MITM. Причём они могут работать совершенно по-разному: могут вообще не давать использовать обычную версию сайта, а могут отдавать совершенно другое - что-то, например, заобфусцированное, чтобы помешать боту получать информацию со страницы. Рассмотрим каждый из этих вариантов. В первом случае очень известна антибот-система (здесь должно быть название, но мы в последний момент решили его убрать, поэтому назовём просто - XXX), которая отслеживает автоматические системы и блокирует (на самом деле нет 🙂 ) использование ресурса. Строго говоря, она, определяя бота, отдаёт javascript-код, который должен подтвердить догадки системы. В общем случае Антибот неким образом определяет, человек перед ним или нет (и даже смена/установка User-Agent не помогает). И мы бы были не мы (момент рекламы: проводим качественный глубокий аудит безопасности ваших проектов и помогаем решать всякие умные задачки 😉 https://re-crypt.com ), если бы не разобрались, как же эта система работает 🙂 На самом деле, выдать бота может не только User-Agent, но и просто состав Client Hello части установления SSL/TLS соединения. В данном случае разработчики XXX собрали некоторое количество отпечатков (fingerprint) современных браузеров и, получая запрос от клиента, определяли версию по User-Agent, а дальше просто сравнивали то, что пришло, с тем, что у них имелось. В состав fingerprint вошли такие параметры как: минимальная и максимальная поддерживаемая версия TLS, используемые алгоритмы шифрования, включаемые расширения. В итоге, если клиент сможет жонглировать этими параметрами, появляется возможность полноценно представиться взрослым браузером и избежать детекта Антибот-системы. Про второй случай расскажем несколько позже, подписывайтесь и включайте оповещения, чтобы не пропустить следующий пост.
P.S. Кстати, для разработчиков на Go есть прекрасная библиотека, которая обладает очень широкими возможностями по взаимодействию с Client Hello:
https://github.com/refraction-networking/utls

С антивирусом AVG то же самое :)
https://t.me/recryptor/12

Видео с OffensiveCon 2022. Налетай ;)
https://youtube.com/playlist?list=PLYvhPWR_XYJnPvrhXE4RYvwZhV26nYTIp

Про защиту .Net-сборок от компьютерного пиратства (протекторы .Net) и ложноположительные реакции антивирусов пара слов. Принцип работы эвристика антивирусного движка на самом деле имеет много общего с антибот-системами, о которых говорилось выше: https://t.me/recryptor/26
Если .Net-сборка была модифицирована или создана с использованием стороннего инструментария, то ряд антивирусов может на это нервно реагировать. Просто структура выходного файла, собранного с помощью компилятора от Microsoft, отличается от выходного файла, обработанного тем же ConfuserEx, использующим dnlib, без применения какой-либо обфускации, шифрования и т.д. Просто две практически пустые сборки имеют лёгкие отличия в своей структуре: в порядке следования секций и т.п. При этом дизассемблированный код обеих сборок идентичен с точностью до метаданных.
Лечится компиляцией сборок с использованием средств Microsoft
BTW. Речь не о водяных знаках, конечно

Лонгрид про NGAV и ошибки антивирусов при классификации софта. Один движок, например, считает все пустые .Net-сборки для платформы x86 подозрительными. Другой нервно реагирует на используемые обычным приложением функции. Порой, бывают совершенно немыслимые ляпы и реакции на сочетание совершенно немыслимых признаков, которые объяснить человеческой логикой попросту невозможно. Ответ кроется в том, что это на самом деле не человеческая логика.

В последние годы популярной стала аббревиатура NGAV (Next Generation Antivirus). Всё, что цепляет на себя эту бирку, гордо заявляет об использовании ИИ-технологий для выявления угроз. Это стильно, модно, молодёжно, звучит технологично и малопонятно, иногда реагирует на файлики. В общем, всё, что нужно, чтобы это продавать 😜

Что там под капотом на самом деле, хорошо описывает книга Introduction to Artificial Intelligence for security professionals от команды датасатанистов специалистов по Data Science из Cylance. Да и не только она. Есть масса статей про использование ИИ для классификации малвари. Суть всех этих подходов в том, что берётся большой размеченный датасет малвари (например, датасет от Sophos: https://ai.sophos.com/2020/12/14/sophos-reversinglabs-sorel-20-million-sample-malware-dataset/), в дополнение к нему берётся датасет нормального софта, выбираются признаки вручную (чаще всего) либо автоматически (есть работы по feature selection), эти признаки выдёргиваются из каждого исполняемого файла и происходит обучение некого ИИ-движка.

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

Плюсы тут очевидны: дёшево и сердито получается эвристический движок, который будет реагировать на любые аномально выглядящие файлики на ПК. А т.к. создатели малвари часто используют крипторы и обфускаторы для сокрытия сигнатур, этот эвристический движок имеет неплохие шансы такую обработанную малварь всё-таки обнаружить. Т.е. супер-дёшево удаётся существенно повысить detection rate. Ну и вообще не нужны тонны вирусных аналитиков: их заменит небольшая команда специалистов по Data Science, которая создаст наборы классификаторов для статической структуры, для трафика, поведения и т.д.

Но есть нюансы. Полноценный антивирус работает, как правило, на локальной машине пользователя, а это значит, что засунуть туда полноценную нейронку не получится. Поэтому в этом случае речь идёт не о Deep Learning, а о Machine Learning. Часто используются решающие деревья и случайный лес (Random Forest). Да и признаки файла должны легко извлекаться и подсчитываться, что тоже не прибавляет точности. В результате мы получаем что-то типа overfitting-а (слово "переобучение" мне не нравится здесь). И тут начинаются фокусы с ложноположительными реакциями. Я даже не говорю про всякого рода протекторы для защиты софта от пиратства. Они для любого антивируса, как красная тряпка, ибо то, что ими обработано, выглядит крайне аномально. Речь о совершенно безобидных программах, на которые антивирус начинает, внезапно, нервно реагировать. При этом банальная смена опции компиляции и сборки может эту реакцию убрать (зато начнёт реагировать другой антивирус 😜). То же самое и про ИИ-анализ поведения.

Что из этого следует... Да в общем - ничего особенного 😁 Все стараются экономить и ИИ - это, несмотря на заверения продавцов, в первую очередь про экономию, а не про качество. Достаточно поглядеть, сколько NGAV развелось за последние лет 5 - 7. При этом малвари тоже меньше не становится и способы обхода NGAV-движков известны: https://www.youtube.com/watch?v=RhB6Sqz-eLw

#почитать #антивирус

Задорная картинка к предыдущему посту :)

CVE-2022-0540. Jira.
Логическая ошибка при реализации механизмов аутентификации и управления доступом. Вопросы к аудиту безопасности кода
https://confluence.atlassian.com/jira/jira-security-advisory-2022-04-20-1115127899.html

В продолжение темы про Антибот-системы. Иногда сервисам не нужно полностью блокировать ботов, а лишь намекнуть им (или их владельцам) использовать не основной ресурс, а API, где можно управлять квотами и вообще отслеживать, что же за бот такой пришёл и что он спрашивает. В таких случаях чаще всего прибегают к различного рода ухищрениям по определению, кто перед ними. Например, обычно отправляют JavaScript код, который "взрослый" браузер успешно исполнит и предоставит информацию о том, кто он и какие настройки и надстройки использует. Но минус для владельцев таких сервисов в том, что JavaScript приходит в виде "as-is" для того, чтобы клиент(браузер) мог его выполнить. Тогда на помощь приходит обфускация кода, делающая текст не только нечитаемым, но и сложно исследуемым (передаём в связи с этим пламенный привет некоторым пухленьким пафосным бумажным аналитикам, вещающим нам, что обфускацию применяют сугубо в злонамеренных целях 😉). Остаётся лишь дёрнуть нужные функции, собрать информацию из браузера клиента и отправить асинхронным (а иногда даже синхронным) запросом обратно на сервер, который примет решение, какой контент выдавать. Что же делать ботам в таком случае? Исполнять JS 🙂 Но кто же может выполнять JS код? Правильно, браузер. Мы попали в петлю 🙂

Хорошо, что существуют headless-браузеры, которые работают без GUI и с которыми можно общаться по API из внешней программы. И если бы это было единственным и работающим решением... В итоге мы имеем ситуацию, когда сервис может отправить такой JS код, который кроме сбора информации о браузере может осуществлять System API вызовы и получать такие параметры, как размер окна, например. И боту остаётся только максимально похоже эмулировать поведение (и систему) пользователя. Так что эта вечная борьба между детектом и ботами будет существовать ещё долгое время, а нам нужно лишь включать голову и интуицию и изучать системы друг друга 🙂

P.S. Отличный headless/non-headless браузер Chrome имеет в своём арсенале очень много полезных возможностей. Если вы понимаете о чём я 😉
https://github.com/chromedp/chromedp

#почитать

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

https://eprint.iacr.org/2021/136

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

Хороший список. Пусть здесь побудет: https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md

#windows #почитать #антивирус

Тема использования антивирусного софта и, в частности, драйверов антивирусного софта для обхода другого антивирусного софта не нова. В данном случае используется драйвер Avast (кто бы мог подумать 😜) для завершения процессов других антивирусных средств прямо из ядра: https://www.aon.com/cyber-solutions/aon_cyber_labs/yours-truly-signed-av-driver-weaponizing-an-antivirus-driver/

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

#windows #почитать #offensive #антивирус

Хороший специалист в области ИБ и просто интересный человек Александр Леонов опубликовал у себя на странице ВКонтакте серию постов о превосходстве веб-сайтов над приложениями.

https://vk.com/wall1468099_999
https://vk.com/wall1468099_1006

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

Однако, как водится, есть нюансы. И одним из таких нюансов является возможность проведения атаки Man-In-The-Middle (MITM). Есть несколько архитектурных моментов:
1. Браузер, как правило, для проверки валидности "прилетающих" с сервера сертификатов при установке SSL-соединения использует корневые сертификаты, расположенные в хранилище на устройстве.
2. Браузер в силу своей универсальности "ходит" на любой URL и устанавливает SSL-соединение с этим ресурсом, если сертификат валиден.

Если, например, вместо happybank.ru пользователь зайдёт на happybak.ru и оба сайта имеют валидные SSL-сертификаты (пусть второй и подписан каким-нибудь Let's Encrypt-ом) и похожую вёрстку, то разницу в браузере заметить, не приглядываясь, довольно сложно. Т.е. в случае с браузером возможен фишинг, переход пользователя на ресурс злоумышленника, где расположен MITM-proxy, а далее уже переход на сайт банка, например. Злоумышленник, соответственно, находится посередине и может читать и модифицировать трафик: похитить пароли, увести сессию, увести аккаунт, увести деньги. Это же верно для почтовых аккаунтов и соцсетей. Есть для этих целей публичный фреймворк: https://github.com/kgretzky/evilginx2

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

Толстый клиент лишён этих особенностей. При создании приложений SSL Pinning (вшивание сертификата для валидации сетевого ресурса в тело приложения) считается хорошей практикой и многие так делают. Да и URL там тоже находится в теле приложения. Это делает MITM-атаку крайне затруднительной. Так что с этой точки зрения толстый клиент (приложение) гораздо безопаснее.

Небольшой апдейт исходников с примером реализации быстрого асимметричного шифрования и подписи, о котором шла речь ранее: https://t.me/recryptor/34

Исходники лежат здесь: https://github.com/dmschelkunov/wb_poc

Теоретически подход описан здесь: https://eprint.iacr.org/2021/136

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

Работаем.

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

Про атаку на Rutube 9 мая. На этой теме не оттоптался даже ленивый, а мы ребята трудолюбивые, поэтому тоже добавим некоторое число слов в копилочку :) Обсудим только то, что говорится в прессе и сделаем некоторые выводы. Поговорим только о технических вопросах, которые инициирует информация в паблике. А вопросы такие есть.

Что сразу интересно и загадочно - так это мелькавшая в новостях фраза "утечка кодов доступа". Из этой фразы следует, что к критически важным вещам можно получить доступ снаружи, имея какие-то коды доступа. Это могут быть как пароли от "торчащей наружу" админки, так и приватные ключи или пароли для доступа в VPN. Вопрос не в том, как эти коды утекли, а в том, что они вообще там делали. Существует великое множество смарт-карт с неизвлекаемым приватным ключом, которые позволяют относительно безопасно аутентифицировать пользователя в системе. По крайней мере это существенно безопаснее паролей и всяких схем 2FA с OTP хотя бы по этой причине: https://t.me/recryptor/37 Такая смарт-карта тоже не панацея, но злоумышленникам придётся работать через устройство, к которому эта смарт-карта подключена, в рамках сессии на устройстве владельца смарт-карты. Это не так просто реализовать на практике, как кражу паролей и сессий с последующим их использованием уже на своих машинах.
Бывают смарт-карты с USB-интерфейсом, которые стоят гораздо дешевле миллиарда несколько тысяч рублей и решают вопрос с кодами доступа, которых для систем, претендующих на звание национальная что-то там, не должно быть, ибо риски. Вообще мы часто встречаем ошибки и недоработки при реализации методов аутентификации, когда делаем аудит.

Второй момент, который несколько смутил, это то, как вообще там построена кибербезопасность и, в частности, реализован мониторинг логов. Атаке подверглись, судя по публикациям, системы резервирования в том числе. Действия явно нестандартные и аномальные. Много нестандартных и аномальных действий. По идее, SOC, если таковой там по факту был, должен был реагировать на это, а не дожидаться фразы в твиттере "спасибо за кибербезопасность". Да и всяких EDR-решений, как и SIEM, где можно сделать наборы правил и даже есть ML, немало и они все дешевле миллиарда стоят вменяемых денег.

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

Здесь могла бы быть наша реклама и поэтому она тут есть 😉 Делаем аудит софта, помогаем построить SSDLC, заказная разработка софта. Обращайтесь: contact@re-crypt.com