Видео с 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

Именно так :)

Интересное исследование про эффективность SIEM-систем: 80% техник не детектируются с их помощью. На самом деле речь идёт о системах из коробки с дефолтным набором правил. Здесь можно выдохнуть и ... сразу вдохнуть резко и глубоко :)

Во-первых, даже дефолтные наборы правил бывают с ошибками (там в исследовании про это есть). Во-вторых, создать создать и отладить более-менее сложное правило, чтобы с умеренным количеством false positives - это весьма не тривиальная задача. Те, кто пробовал наваять правило хотя бы для Pass-The-Hash чисто по логам Windows, меня поймут :) (если SIEM вообще позволяет делать такие правила, что не всегда бывает).
В-третьих, от SIEM напрямую зависит работа SOC.

С логами история тоже довольно интересная. В принципе, логировать можно каждый чих и отправлять всё это в SIEM, но по причине экономии ресурсов так практически никто не делает. Логов недостаточно. Хватит как раз на те самые 20% эффективности :) В основном, на конечные точки (если это не IoT-устройства, конечно) ставятся средства защиты (антивирусы, EDR-агенты и т.п.), которые содержат уже свои наборы правил и генерируют уже свои логи. Равно как генерируют свои логи (по крайней мере, должны :) ) межсетевые экраны. И вот это вся сборная солянка летит уже в SIEM, которая суть есть большая такая ИБ-админка с фенечками, мулечками, рюшечками и базой за много денег. Удобно, но не панацея.

Функционал SIEM иногда несколько расширяют локальные агенты на конечных точках, которые собирают события, регистрируют фильтры, отслеживают всякое и даже могут немного что-то запрещать, но, если идти в эту сторону, то очень быстро приходишь к логике антивируса или EDR :)

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

https://venturebeat.com/2022/05/19/report-80-of-cyberattack-techniques-evade-detection-by-siems/

#почитать

Видео с Positive Hack Days 2022. Интересные технические доклады всё ещё встречаются порой. Жаль, ZeroNights не будет в этом году :(
https://www.youtube.com/channel/UCiVeQyTOl6gYVLaBkGyq80A/videos

#почитать #offensive

Про пасхалки и закладки в коде

Вот, например, интересный код в одном опенсорсном offensive-проекте (несложно догадаться, в каком именно, если внимательно поглядеть на код ниже):

hg := []byte{0x94, 0xE1, 0x89, 0xBA, 0xA5, 0xA0, 0xAB, 0xA5, 0xA2, 0xB4}
А потом вот такое:
for n, b := range hg {
hg[n] = b ^ 0xCC
}
Результат используется как название кастомного заголовка HTTP-запроса. Далее туда же добавляется домен, на котором данный софт хостится. Т.е. в запросе присутствует не просто водяной знак, а происходит утечка доменного имени.

Стоит заметить, что речь идёт о крупном opensource-инструменте, используемом теми же пентестерами, у которого практически 5.5 тысяч звёзд и более тысячи форков. Это к вопросу "сообщество всё найдёт и оттестирует, можно брать и пользоваться" ;)

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

Именно поэтому в проектах, чуть более серьёзных, чем домашние поделки на коленке, качественный аудит кода строго необходим! Мы делаем: contact@re-crypt.com

#закладки

Подъехали новые техники обхода белых списков приложений. Налетай ;)

https://github.com/bohops/UltimateWDACBypassList/commit/30ea72b3d151ae3ffc2066d2c40bcac60178de3e

#почитать #offensive

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

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