📨 Сегодня несколько наших сотрудников получили сообщения в Telegram — якобы от нашего коллеги, эксперта по кибербезопасности.

Начинается все со звонка для привлечения внимания, переходящего в диалог, в котором собеседник просит перевести деньги на карту или криптокошелек.

Наши сотрудники хорошо осведомлены о базовых принципах кибербезопасности и сразу поняли, что по ту сторону экрана — мошенник. И решили воспользоваться моментом, чтобы немного пошутить над ним.

Как пишут коллеги из ISACA, наш случай не единственный. Злоумышленники массово распространяют такие фишинговые сообщения и выдают себя за известных экспертов в области ИБ.

💬 На что стоит обратить внимание, если вы получили такое сообщение?

•‎ Главное: если человек уже есть в ваших контактах, то вверху диалога не должно быть кнопок «Добавить в контакты» и «Заблокировать».

•‎ Проверяйте написание ника и номера телефона. Если номера у аккаунта нет, но вы точно уверены, что пользователь есть в ваших контактах, — это еще один повод насторожиться.

• Позвоните реальному человеку по номеру телефона, который вам известен, и предупредите его.

• Заблокируйте аккаунт мошенника.

@Positive_Technologies

Всем привет! 👋
(@vkochetkov здесь)

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

Дело в том, что сей Pedram, предлагая решать проблему обработки входных данных «зря в корень», похоже, даже близко себе не представляет, где этот корень находится. Рассмотрим на примере первой части статьи. В ней автор рассматривает примеры решений одного из челленджей SecDim, основанного на CVE-2021-43798, и отбраковывает одно за другим, апеллируя к тому, что они не устраняют корень проблемы. Корень же Path Traversal, по убеждению автора, заключается в (я цитирую):

> is the lack of path canonicalization

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

Возможно для кого-то это и окажется откровением, но уязвимости в том числе к инъекциям, зачастую, и в первую очередь, являются проблемами дизайна предметной области приложения, и только потом — синтаксическими багами про недостаточную предварительную обработку.

Btw, предложенное автором решение никак не защищает от, например, обращения к альтернативным потокам NTFS, если приложение окажется (не дай бог, конечно) развёрнутым под виндой. Как и от внедрения нуль-байта, управляющих символов и прочих DoS через жестко-заданные в ОС файловые имена. Зависит от окружения, конечно, но кто ж так в корень-то смотрит? 🤦‍♂️

И потом, если уж мы протащили файловые пути на уровень бизнес-логики, то реализуя тем самым требование «отдать пользователю существующий файл по запрошенному, жестко-заданному пути». И вот что мешало вспомнить о принципе KISS и сделать как-то так — ума не приложу:

if not str.isidentifier(filename) or filename not in os.listdir("/resources"):
    return HttpResponseBadRequest()

(почему не с помощью os.path.exists() — пусть будет домашним заданием)

На две трети решённая задача обеспечения безопасности приложения — это грамотный дизайн его архитектуры и модели предметной области.

А не вот это вот всё... 🫠

❗️И да, это тоже #экспериментальная_рубрика. А вы как думали?👇

🛡 Каждая крупная российская компания, даже если она не из IT-отрасли, занимается внутренней разработкой. А значит, она должна думать о том, как сделать ее безопасной на всех этапах жизненного цикла. Иначе внутренние продукты и системы могут стать слабым местом в киберзащите.

Уже завтра, 11 октября в 11:00, Алексей Астахов, руководитель продуктов Application Security, Positive Technologies, примет участие в прямом эфире AM Live, на котором обсудят лучшие средства, инструменты и практики российской безопасной разработки, процессы ее внедрения и поговорят о том, где взять нужных для этого специалистов.

Слушайте, если хотите узнать:

• Что такое опасная и безопасная разработка на конкретных примерах.
• Из чего состоят процессы DevSecOps и как определить, насколько они зрелые у вас в компании.
• С чего начать внедрение безопасной разработки и какие IT-продукты в этом помогут.
• Какие практики и инструменты лучше всего подходят для проверки исходного кода.
• Как подготовить инфраструктуру и найти сотрудников.
• Как обеспечить DevSecOps при внешней и open-source-разработке.
• Что про все это думают регуляторы.
• Каковы перспективы безопасной разработки: прогнозы, законодательство, станет ли она must have для всех.

Регистрируйтесь и готовьте ваши вопросы. До встречи в эфире!

@Positive_Technologies
#PositiveЭксперты

📌 Наиболее интересные публикации по аппсеку за прошедшую неделю

📰 Кажущийся большим, но на деле — весьма сжатый гайд о том, как найти в аббревиатуре «IoT» ту самую букву «S», означающую «Security».

📰 Очередной метод сокрытия внедряемого в .NET-сборки кода от ресёрчеров CheckPoint.

📰 Языковой ИИ-ассистент для тех, кому слишком скучно работать в консоли с популярными security-тулами.

📰 Неплохой и весьма обширный гайд по атакам на front-end веб-приложений.

📰 Обзор и сравнительный анализ современных инструментов поиска утечек памяти.

📰 Опыт Авито по организации виртуализированной песочницы в macOS.

📰 Локальный TCP/UDP прокси для пентеста приложений с кастомными протоколами.

📰 Описание забавной атаки на клиентов Cloudflare средствами самой Cloudflare.

🔍 Наиболее интересные уязвимости прошедшей недели

🐛 CVE-2023-41580, обнаруженная в платформе управления IP-адресами phpipam до версии 1.5.2, позволяет аутентифицированному атакующему получать конфиденциальные данные из хранилища через LDAP инъекцию. Уязвимость заключается в отсутствии санитизации пользовательских данных, попадающих в функцию $adldap->user()->info, которая формирует LDAP запросы для получения данных о пользователе. В исправлении данные, попадающие в LDAP запрос, проходят через экранирующую функцию ldap_escape с флагом LDAP_ESCAPE_DN.

🐛 CVE-2023-42809 в клиенте Redisson до версии 3.22.0 позволяет исполнять произвольный код при подключении к вредоносному серверу. Уязвимость заключается в попадании пользовательских данных в функцию ObjectInputStream.readObject и их небезопасной десериализации. В патче был добавлен "белый" список классов, который определяет разрешенные объекты при десериализации. Упрощению эксплуатации способствует наличие в составе Redisson библиотеки "Apache Commons Collections 4", для которой существует стандартный ysoserial гаджет "CommonsCollections2".

🐛 CVE-2023-43793 в децентрализованной социальной медиа платформе Misskey до версии 2023.9.0 позволяет обходить процесс аутентификации, для эндпойнтов, начинающихся с /queue. Проблема затрагивала процедуру сравнения пути эндпойнта с закодированным URI, что обеспечивало обход процесса аутентификации. В исправлении URI запроса перед его сравнением декодируется при помощи функции decodeURI.

🐛 CVE-2023-44390, выявленной в .NET библиотеке html-санитизации HtmlSanitizer до версии 8.0.723, позволяет обходить процесс санитизации и добавлять вредоносные html-объекты. В библиотеке данные, находящиеся в комментариях или в текстовых полях html документа, обрабатывались без экранирования. Для этих случае в патче была добавлена замена символов "<" и ">" на их html-мнемоники ("<" и ">").

🐛 CVE-2023-26153 в библиотеке для работы с геолокацией geokit-rails до версии 2.5.0 позволяет неаутентифицированному атакующему выполнять произвольные команды с помощью эксплуатации небезопасной YAML десериализации. Проблема связана с попаданием значения "geo_location" куки в уязвимую функцию YAML.load. Для исправления уязвимости функцию YAML.load заменили на безопасную функцию JSON.parse.