-
Похожий контент
-
Автор KL FC Bot
Группа авторитетных исследователей представила на симпозиуме NDSS 2026 атаку AirSnitch, которая позволяет обходить функцию Wi-Fi client isolation, известную также под названиями «гостевая сеть» и «изоляция устройств». При помощи AirSnitch атакующий может подключиться к одной беспроводной сети на точке доступа и затем получить доступ к любому из подключенных к той же точке устройств, в том числе и к тому, которое использует иные SSID. Атакуемые устройства вполне могут работать в беспроводной подсети, защищенной WPA2/WPA3. Атака вообще не нарушает шифрование, а злоупотребляет способами обработки групповых ключей и маршрутизации пакетов на точке доступа.
На практике это означает, что роль «гостевой сети» в общей защите незначительна. Если сети для гостей и для сотрудников работают на одном устройстве, AirSnitch позволяет подключенному атакующему внедрять вредоносный трафик в «соседние» SSID, а в ряде случаев выполнять полноценную атаку «человек посередине» (MitM).
Безопасность Wi-Fi и роль изоляции
Защита беспроводных сетей постоянно эволюционирует, и после появления практически реализуемых атак на очередное поколение защиты Wi-Fi индустрия всегда переходила на более сложные алгоритмы и процедуры. Это началось с применения атак FMS для расшифровки ключей шифрования протокола WEP и продолжается по сей день — относительно свежими примерами являются атаки KRACK на WPA2 и FragAttacks для всех версий от WEP до WPA3.
Эффективно и незаметно атаковать современные сети Wi-Fi непросто, и практики сходятся на том, что для защиты достаточно использовать WPA2/WPA3 со сложными ключами, а также разделять беспроводные сети разного назначения. И только узкие специалисты знают, что «изоляция клиентов» никогда не была стандартизована в рамках протоколов IEEE 802.11. Разные производители воплощают изоляцию совершенно по-разному (используя 2-й или 3-й уровень сетевой архитектуры, уровень маршрутизатора или уровень контроллера Wi-Fi), и поведение изолированных подсетей значительно отличается в зависимости от модели точки доступа или роутера.
Хотя реклама утверждает, что «изоляция клиентов» хорошо подходит для того, чтобы гости ресторана или отеля не атаковали друг друга, а посетители корпорации не получали доступа ни к чему, кроме Интернета, на практике изоляция работает как «защита от честных людей». Именно это и демонстрирует исследование AirSnitch.
View the full article
-
Автор KL FC Bot
Мода последних лет на умные устройства и подключение всего и вся, от лампочек до чайников, к Сети не обошла стороной и производителей секс-игрушек, выпускающих все больше умных моделей. Подключение секс-игрушки к смартфону открывает доступ к дополнительным функциям, но сопряжено с угрозами для безопасности и приватности пользователя. Хорошая новость — большинство рисков можно существенно снизить при правильной настройке и использовании.
Как работают приложения для секс-игрушек
Сразу оговоримся: хотя эксперименты по непосредственному захвату контроля над секс-игрушками и проводились, реальная вероятность того, что хакеры будут напрямую управлять вашим вибратором, прямо скажем, невысока. Поэтому в нашем посте мы сконцентрируемся на рисках, связанных с приватностью и безопасностью пользовательских данных.
Большинство современных продуктов на рынке секс-игрушек можно связать с приложением производителя. Они предлагают разные опции взаимодействия: многие игрушки можно контролировать как самостоятельно, так и передавая управление другому пользователю через Интернет.
View the full article
-
Автор KL FC Bot
Компании системно работают над снижением поверхности атаки: сегментируют сети, управляют уязвимостями, внедряют EDR/XDR и стремятся автоматизировать реагирование. При этом, как ни парадоксально это звучит, они зачастую забывают один критически важный элемент —безопасность средств управления всей этой защитой.
Происходит это из-за когнитивного искажения — иногда кажется, что раз в компании есть все необходимые ИБ-решения, значит, она уже в безопасности. А между тем любое ПО, и защитное в том числе, увеличивает поверхность атаки, а следовательно, и само нуждается в защите. Как минимум в виде усиления безопасности за счет корректной настройки.
Чем опасен доступ к консоли безопасности
Инструменты безопасности устойчивы ровно настолько, насколько защищена система, которая ими управляет. Если злоумышленнику удается проникнуть в инфраструктуру, то контроль над консолью управления системами защиты информации обеспечивает ему практически неограниченные возможности. По сути, в его руки попадает универсальная отмычка, предоставляющая доступ к централизованной настройке политик, мониторингу состояния всех конечных точек инфраструктуры, настройкам автоматизации через API-интеграции и многому другому.
View the full article
-
Автор KL FC Bot
Как мы уже писали в одном из предыдущих постов, современная разработка практически немыслима без использования компонентов open source. Но в последние годы связанные с этим риски становятся все разнообразнее, сложнее и многочисленней. Когда уязвимости появляются в инфраструктуре и ПО компании быстрее, чем их устраняют, данные неточны и неполны, а в популярных компонентах может таиться вредоносное ПО, недостаточно только сканировать версии компонентов и создавать задачи для ИТ по устранению. Нужно расширить процесс управления уязвимостями, охватив им политики скачивания ПО, правила работы ИИ-ассистентов и процесс сборки ПО.
Доверенный пул компонентов open source
Фундаментальная часть решения — предотвратить использование уязвимого и вредоносного кода. Для этого имеет смысл реализовать следующие меры:
Внутренний репозиторий артефактов. Единственным источником компонентов для внутренней разработки должен быть единый репозиторий, компоненты в который попадают только после серии проверок. Тщательный скрининг компонентов. Среди необходимых проверок: известные версии компонента, известные уязвимые и вредоносные версии, дата публикации, история активности, репутация пакета и авторов. Обязательно сканировать все содержимое пакета, включая инструкции по сборке, тест-кейсы и другие вспомогательные данные. Для фильтрации реестра при его наполнении должны использоваться специализированные решения для сканирования open source или комплексное решение для безопасности облачных нагрузок. Закрепление зависимостей. Процессы сборки, ИИ-инструменты и разработчики не должны использовать шаблоны при указании версий (например, latest). Сборка проекта должна идти на основе проверенной версии. При этом закрепленные зависимости должны регулярно обновляться до последней, но проверенной версии, которая сохраняет совместимость и лишена известных уязвимостей. Это значительно снижает риск атак на цепочку поставок через компрометацию известного пакета.
View the full article
-
Автор KL FC Bot
В прошлом только специализированные компании по разработке ПО и очень крупные бизнесы должны были заботиться об уязвимостях в цепочке поставок и открытом исходном коде (open source). Но сегодня даже небольшие компании имеют собственную разработку, и проблема становится актуальной и для них. Даже когда основное направление бизнеса вообще не связано с «софтом», в каждой второй компании внутренние команды ИТ пишут код, настраивают интеграции и автоматизируют бизнес-процессы. Этого требует эффективность бизнеса. Но в результате организация сталкивается с новыми видами уязвимостей в ПО, найти и устранить которые гораздо сложнее, чем просто скачать обновление Windows.
Современная разработка активно, неизбежно использует компоненты open source. Но связанные с этим риски стали в последние годы разнообразнее, сложнее и многочисленней. Это вредоносный код в популярных репозиториях, неполная и неточная информация о программных уязвимостях, систематическое использование устаревших, уязвимых компонентов и нарастающая сложность оценки цепочки зависимостей.
Дефицит данных об уязвимостях open source
Даже если в организации хорошо налажено управление уязвимостями в готовом ПО, для open source процесс придется значительно перерабатывать и дополнять. Публичные, наиболее популярные источники информации об уязвимостях часто неполны, неточны и пополняются поздно в части, касающейся ПО с открытым исходным кодом. В результате приоритизация уязвимостей превращается в гадание, и никакая автоматизация здесь помочь не способна, пока не будут устранены пробелы в базовой информации.
Например, по данным Sonatype, около 65% open-source-уязвимостей, получивших идентификатор CVE, не имеют оценки критичности (CVSS) в наиболее популярной базе уязвимостей NVD. Из этих уязвимостей 46% получили бы высокую оценку критичности.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти