Forwarded from FrontSecOps (Михаил Парфенов)
Frontend-фишинг с использованием JS Notification / Push API
Эти API предоставляют js-коду📱 возможность показывать нативные уведомления браузера на устройстве пользователя. Push API (в отличии от Notification API) может показывать уведомления даже при закрытой вкладке браузера ⚠️ , а на мобильных устройствах даже при закрытом браузере, поэтому рассмотрим именно его.
Исходные данные
Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).
В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.
Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).
Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт⚠️ . Это открывает безграничные возможности для фишинга 🤒
⚠️ С вашего счета произведен перевод денег..
⚠️ Заказ № 123456 оформлен, сумма 14 793 руб., дата доставки..
⚠️ Обнаружен вирус на устройстве, выберите действие..
⚠️ Ваш почтовый ящик заблокирован..
⚠️ Кто-кто входит в ваш аккаунт..
Далее - кража учетных данных🪪 , загрузка вредоносного вложения с эксплойтом 💣 и т.п.
На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.
Если неквалифицированные пользователи / люди в возрасте доверяют баннерам "про обновление антивируса" на сайтах с кулинарными рецептами, то нативным уведомлениям на мобильном устройстве могут поверить даже опытные пользователи.
Злоумышленники "хотят" наш frontend больше💰 , чем мы думаем… А уязвимости браузеров 📱 🌐 делают frontend-приложения идеальной точкой проникновения на устройства пользователей.
Как защититься?
🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование
@FrontSecOps
Эти API предоставляют js-коду
Исходные данные
Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).
В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.
Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).
Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт
Далее - кража учетных данных
На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.
Если неквалифицированные пользователи / люди в возрасте доверяют баннерам "про обновление антивируса" на сайтах с кулинарными рецептами, то нативным уведомлениям на мобильном устройстве могут поверить даже опытные пользователи.
Злоумышленники "хотят" наш frontend больше
Как защититься?
🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование
@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AlexRedSec
Свежее исследование "Different Seas, Different Phishes" о нашем любимом: фишинговых симуляциях и попытках найти закономерности в поведении сотрудников🎣
В данной работе был проведен анализ 96 кампаний фишинговых симуляций, охвативших 36 организаций из различных секторов экономики, что довольно масштабно по сравнению с предыдущими аналогичными исследованиями.
Ниже описал главное и/или интересное.
Эффективность различных параметров фишинга:
🎯 Сценарии целевого фишинга (ожидаемо) повышали кликабельность на 22% по сравнению со сценариями массового фишинга.
🤑 Сценарии типа "Не упусти выгоду" демонстрировали на 18% более высокую вовлеченность, чем сценарии компрометации аккаунта, что подчеркивает эффективность страха упущенной выгоды (FOMO, привет!) по сравнению со страхом угрозы безопасности.
🧐 Повышение сложности шаблона давало лишь 6% роста кликабельности, что указывает на главенствующую роль психологического фактора и фактора контекста.
Межотраслевые и внутриорганизационные различия:
⛏ Организации сектора промышленности и производства показали на 41% меньше уровень кликабельности, чем сфера услуг, что связано с автоматизированными процессами и меньшей зависимостью от почтовых коммуникаций.
👨💻 Отделы маркетинга и продаж продемонстрировали более чем в два раза большую подверженность фишинговым симуляциям по сравнению с финансовым департаментом. Это различие может объясняться несколькими факторами: сотрудники финансовых департаментов, возможно, более осторожны с электронной почтой из-за характера их работы с конфиденциальной финансовой информацией, в то время как сотрудники отделов продаж и маркетинга могут быть более склонны к активному взаимодействию с внешними контактами и новыми возможностями.
👨💻 Менеджеры среднего звена на 15% чаще взаимодействовали с фишинговыми письмами, чем топ-менеджеры, что опровергает стереотип о большей уязвимости высшего руководства.
Рекомендации ИБ-специалистам:
➡️ При построении системы защиты необходимо учитывать коммуникационные паттерны и рабочие процессы свойственные конкретной индустрии.
➡️ При проведении тренингов также необходимо учитывать специфику работы различных департаментов, в т.ч. нюансы коммуникаций с "внешним миром".
➡️ Использование фишинговых симуляций с прогрессивно увеличивающейся персонализацией позволяет точнее оценивать реальную уязвимость организации, чем статичные тесты на базе шаблонных сценариев.
Также, авторы исследования подсветили, что в публичных отчетах вендоров решенийsecurity awareness human risk management сообщается о более высоких показателей кликов, что может свидетельствовать о предвзятой оценке, направленной на увеличение продаж их продуктов😏
#awareness #phishing #training #risk #hrm #simulation
В данной работе был проведен анализ 96 кампаний фишинговых симуляций, охвативших 36 организаций из различных секторов экономики, что довольно масштабно по сравнению с предыдущими аналогичными исследованиями.
Ниже описал главное и/или интересное.
Эффективность различных параметров фишинга:
Межотраслевые и внутриорганизационные различия:
Рекомендации ИБ-специалистам:
Также, авторы исследования подсветили, что в публичных отчетах вендоров решений
#awareness #phishing #training #risk #hrm #simulation
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Злоумышленники используют фишинговые домены с поддельными страницами входа для кражи учетных данных разработчиков npm-пакетов
Socket
npm Phishing Email Targets Developers with Typosquatted Doma...
A phishing attack targeted developers using a typosquatted npm domain (npnjs.com) to steal credentials via fake login pages - watch out for similar sc...
Верховный суд РФ вступился за заказчиков услуг в интернете | Российское агентство правовой и судебной информации - РАПСИ
http://rapsinews.ru/judicial_analyst/20250731/311057799.html
http://rapsinews.ru/judicial_analyst/20250731/311057799.html
РАПСИ
Верховный суд РФ вступился за заказчиков услуг в интернете
Верховный суд РФ запретил перекладывать на пользователей интернета проверку подлинности сайтов и распознавание "зеркал": бизнесмены, как профессиональные участники рынка, сами должны следить за предложением в сети «Интернет» услуг от их имени.
Год назад ICANN полностью перевела доступ к данным регистрации доменных имён в зонах gTLD с устаревшего протокола WHOIS на современный и безопасный RDAP (Registration Data Access Protocol).
🔹 Что изменилось?
— WHOIS больше не будет поддерживаться как основной источник данных.
— Все запросы о регистрации теперь должны направляться через RDAP — протокол, разработанный IETF с учётом требований безопасности, международной совместимости и гибкого контроля доступа.
— RDAP поддерживает различные методы аутентификации, HTTPS, структурированный JSON-формат и возможность дифференцированного доступа: данные можно разделять по уровням — публичные (для всех) и непубличные (для спецслужб, судов, кибербезопасников).
👨💻 Что делать разработчикам и SOC-командам?
— Новые gTLD могут не поддерживать RDRS в периходный период, поэтому лучше реализовать поддержку обоих протоколов.
— Интегрировать ICANN Lookup API или использовать публичные RDAP-адреса регистраторов.
— Настроить процессы запроса непубличных данных через RDRS — особенно если вы работаете в сфере кибербезопасности, защиты брендов или расследования инцидентов.
💡 Полезные ссылки
— Новость о переходе
— ICANN Lookup
— Документация по RDAP: RFC 7480-7483, 8521, 8056.
VK Telegram
#RDAP #WHOIS #ICANN
🔹 Что изменилось?
— WHOIS больше не будет поддерживаться как основной источник данных.
— Все запросы о регистрации теперь должны направляться через RDAP — протокол, разработанный IETF с учётом требований безопасности, международной совместимости и гибкого контроля доступа.
— RDAP поддерживает различные методы аутентификации, HTTPS, структурированный JSON-формат и возможность дифференцированного доступа: данные можно разделять по уровням — публичные (для всех) и непубличные (для спецслужб, судов, кибербезопасников).
👨💻 Что делать разработчикам и SOC-командам?
— Новые gTLD могут не поддерживать RDRS в периходный период, поэтому лучше реализовать поддержку обоих протоколов.
— Интегрировать ICANN Lookup API или использовать публичные RDAP-адреса регистраторов.
— Настроить процессы запроса непубличных данных через RDRS — особенно если вы работаете в сфере кибербезопасности, защиты брендов или расследования инцидентов.
💡 Полезные ссылки
— Новость о переходе
— ICANN Lookup
— Документация по RDAP: RFC 7480-7483, 8521, 8056.
VK Telegram
#RDAP #WHOIS #ICANN