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

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

В дополнение к предыдущему посту про мини-фильтры файловой системы 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. Это, на мой взгляд, обязательно надо делать для софта, который всё ещё имеет место быть в критической инфраструктуре и в госкорпах. Ручной анализ обновлений, а вся автоматизация должна строиться вокруг этого. Например, невозможно чисто автоматически найти закладки, подобные найденной нами в одном из антивирусных драйверов.

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